Liste des bonnes pratiques agiles
J'essaie de définir quelles pratiques agiles nous allons utiliser et j'ai du mal à définir la liste des meilleures pratiques agiles. J'aimerais que ma liste soit plus d'un point de vue technique (l'angle de vue de l'ingénieur), et devrait définir comment les ingénieurs SW devraient aborder le développement. La liste doit être liée le moins possible à la gestion.
Si cela compte, nous programmons en C++.
Il est assez facile de trouver de nombreuses bonnes pratiques, et voici la liste que j'ai réussi à dresser jusqu'à présent:
- Refactoring
- Petits cycles de libération
- Norme de codage
- Propriété collective
- Métaphore du système
- Jeu de Planing
- Équipe entière
- Réunions quotidiennes Scrum
- Programmation en binôme
- Conception pilotée par les tests
- Développement axé sur le comportement
- Intégration continue
- Revues de code et de conception
- Parties prenantes actives
- Document en retard
- Utilisation intensive des modèles de conception
Nous utilisons déjà certaines des pratiques de la liste. Certains que nous n'allons pas utiliser.
Y a-t-il de bonnes pratiques agiles que je pourrais ajouter à la liste?
PS Je peux ajouter une petite description des pratiques, si demandé.
MODIFIER
Comme je l'ai dit, nous utilisons déjà certaines pratiques agiles (principalement les pratiques qui s'avèrent être les meilleures):
- Intégration continue - c'est une très bonne pratique. Obtenir des commentaires rapides sur les derniers enregistrements est très utile. Avoir un temps d'arrêt parce que quelqu'un a cassé une construction peut être très frustrant, surtout si cela dure plus longtemps.
- Métaphore du système - cela n'aide pas grand-chose, car avoir des noms de classe et de fonction descriptifs aide à mieux comprendre le code
- Norme de code - nous avons créé la norme de codage avant d'entrer dans le codage. Utiliser un style de code uniforme est une bonne chose, car n'importe qui peut prendre le code d'un autre et travailler dessus comme tout seul.
- TDD - avant de commencer le codage, nous avons configuré l'environnement pour créer facilement des tests unitaires, mais ce n'est que récemment que nous avons commencé à adopter les principes TDD. Je l'ai personnellement essayé il y a plusieurs années, et ça ne s'est pas très bien passé, mais maintenant je l'adore. Malheureusement, tous les membres de l'équipe ne le font pas - seulement la moitié de l'équipe.
- Réunions quotidiennes Scrum - nous avons essayé les réunions quotidiennes et elles ne se sont pas très bien déroulées. En plus de mon travail précédent, les réunions quotidiennes se transforment généralement en discussions de plus de 30 minutes. Je suppose que nous avons raté le bon Scrum Master (ou leader, comment ça s'appelle?)
- Refactoring - nous avons refactoring, mais uniquement si un membre de l'équipe crée une demande de changement. Nous ne l'avons pas fait exprès: "Asseyons-nous maintenant et réduisons notre dette technique".
- Petits cycles de publication - pour le moment, nous avons d'énormes cycles de publication (6 mois), et pour la prochaine version, nous prévoyons de briser le cycle en 4-6 versions internes.
- Revues de code et de conception - nous avons effectué la revue de conception initiale (comme il y a 5 ans), et peu de revues de conception de certains sous-composants mineurs pendant cette période. Nous avons révisé le code de certaines classes
- Document en retard - nous l'avons fait pour cette version. Seule la documentation requise signifie que la documentation est de moins en moins codée et de plus en plus amusante. Les développeurs adorent ça :)
- Utilisation de modèles de conception - nous utilisons déjà des modèles de conception, le cas échéant.
En raison de la structure de notre organisation, nous ne pouvons pas utiliser d'autres pratiques, mais comme vous pouvez le voir, la liste est longue et vous ne pouvez pas tout choisir. De plus, nous ne sommes plus que 4 développeurs de logiciels, chacun maintenant environ 80 kLOC et travaillant sur de nouvelles choses. On ne peut donc pas faire par exemple de programmation en binôme, ou de propriété collective.
Ce texte résume toutes les meilleures pratiques agiles (avec des liens):
Exigences
- Vision/Déclaration de vision du produit
- Backlog produit
- Histoires d'utilisateurs
- Cas d'utilisation
- Scénarios d'utilisation
- Personnages
- Planification du poker
Hiérarchisation des exigences
Conception
- Spikes architecturaux/Solutions de pointes
- Conception pilotée par domaine
- Conception émergente/conception évolutive
- Cartes CRC
- Conception par contrat
- Métaphore du système
Construction
- Style de codage/Directives de codage/Norme de codage
- Développement piloté par les tests
- Développement axé sur le comportement
- Programmation/appairage par paires
- Refactoring
- Propriété du code collectif
- Constructions quotidiennes/Constructions automatisées/Constructions en dix minutes
- Intégration continue
- Revues de code/Revues par les pairs
- Métriques logicielles/Métriques et analyse de code
- Contrôle de la source/Contrôle de version
- Suivi des problèmes/Suivi des bogues
- Gestion de la configuration
- Livraison fréquente/Libérations fréquentes
Tests - Tests unitaires
- Test de fumée/Test de vérification de construction
- Test d'intégration
- Test du système
- Essais exploratoires
- Automatisation des tests
- Test d'histoires/Critères d'acceptation/Test d'acceptation
Processus
- Timeboxing/Sprints fixes/Durée d'itération fixe
- Planification des versions
- Planification d'itérations/Jeu de planification/Planification de sprint
- Backlog de sprint
- Tableau de bord
- Définition de Terminé/Terminé
- Réunion debout quotidienne/Scrum quotidienne
- Rapidité
- Revue de sprint/Démo d'itération
- Cartographie des flux
- Analyse des causes profondes/5 pourquoi
- Burn Down Charts/Burn Up Charts
- Grandes cartes visibles/radiateurs d'information
- Atelier de rétrospective/réflexion
Organisation
- Petite équipe
- Équipe interfonctionnelle
- Équipe auto-organisée/Équipe Scrum
- Équipe colocalisée/Assis ensemble/Espace de travail commun
- Client/Product Owner sur place
- Scrum Master
- Rythme durable
- Déplacer les gens
- Scrum of Scrums
Tout d'abord, allez lire les Douze principes du logiciel Agile .
Deuxièmement, déterminez à partir de ce que vous savez comment atteindre les principes qui sont les plus importants pour vous.
Les gens font constamment l'erreur de s'attendre à ce que le développement Agile soit une balle d'argent ou un ensemble rigoureux de processus auxquels vous devez adhérer et qui fera de votre développement logiciel un succès.
Ce n'est pas ce que ça veut dire. Le fait que vous ayez déjà une liste de 15 "Bonnes Pratiques" me fait un peu peur. Ne le prenez pas trop au sérieux et n'y pensez pas trop. Si vous constatez que vous avez manqué quelque chose ... récupérez-le dans la prochaine itération.
Je suis en train de lire "Réussir avec Agile" en ce moment. Dans le chapitre 2, Mike Cohn met en garde contre l'établissement de "meilleures pratiques" de toute nature:
"Lors de la transition vers Scrum ... collecter les meilleures pratiques est dangereux. Comme les sirènes qui nous chantent depuis les rochers, les meilleures pratiques nous incitent à nous détendre et à arrêter l'effort d'amélioration continue qui est essentiel à Scrum ... Bien que les membres de l'équipe doivent toujours regarder pour partager leurs bonnes méthodes de travail récemment découvertes, ils doivent résister à l'envie de les codifier en un ensemble de bonnes pratiques ... "
Il poursuit en citant Taiichi Ohno, de Toyota:
"... il y a quelque chose qui s'appelle le travail standard, mais les normes devraient être constamment modifiées. Au lieu de cela, si vous pensez que la norme est le" mieux que vous puissiez faire ", c'est fini ... [si nous établissons quelque chose comme] le meilleur possible, la motivation pour kaizen [amélioration incrémentale continue] disparaîtra. "
Attribution: Réussir avec Agile: Développement logiciel avec Scrum, Mike Cohn, 201
Quelques éléments très importants que vous pourriez ajouter sont:
Equipes auto-gérées - faisant référence à "Les meilleures architectures, exigences et conceptions émergent d'équipes auto-organisées"
Rétrospectives - se référant à "À intervalles réguliers, l'équipe réfléchit à la façon de devenir plus efficace, puis ajuste et ajuste son comportement en conséquence"
Solutions de conception simples qui minimisent le travail effectué
Faire une liste des meilleures pratiques semble être BDUF pour une transition agile. Si vous voulez être agile, essayez d'y arriver de manière agile.
Quel est le pire problème avec votre processus actuel? Que pouvez-vous changer pour résoudre ce problème? Essayez-le et voyez comment cela fonctionne.
Rincez et répétez.
Et faites tout cela en équipe.
ÉDITER:
Certaines choses sont difficiles à mettre de manière raisonnable dans les commentaires, alors je vais développer certains des commentaires ici:
Je pense que le problème est que certaines personnes refusent d'écrire des tests unitaires, mais à mon avis, les tests unitaires fournissent un plus grand filet de sécurité. Je ne sais pas ce qui peut être fait à ce sujet.
Une mauvaise couverture de test est vraiment une solution négative et non un problème réel.
Si vous avez une mauvaise couverture des tests, vous livrez probablement des logiciels avec des bogues ou là où il est difficile et long d'apporter des modifications sans introduire de bogues. Ce sont des problèmes.
Si les gens refusent d'écrire des tests, soit ils ne croient pas qu'il y a un problème, ils ne croient pas que l'écriture de tests unitaires le résoudra, ou ils s'en moquent.
La meilleure chose à faire à ce sujet est de se réunir avec votre équipe et de décider quels sont les problèmes et de s'entendre sur les choses à essayer d'améliorer.
Si des membres de votre équipe ne souhaitent pas s'améliorer, c'est un problème plus grave. Vous devriez toujours essayer de le traiter en tant qu'équipe entière, mais c'est difficile et vous pourriez avoir besoin d'une aide de gestion.
Comme je l'ai déjà mentionné, nous utilisons déjà avec succès certaines pratiques agiles, mais il existe peut-être de nouvelles et meilleures façons de faire les choses. Ce que j'essaie de faire, c'est de réévaluer la façon dont nous faisons les choses.
Bien. C'est essentiellement ce que je vous suggère de faire, mais faites-le en équipe et concentrez-vous sur la résolution des problèmes identifiés au lieu d'essayer de dresser une longue liste de bonnes pratiques.
Quelques autres idées à ajouter, bien que certaines puissent être implicites à partir d'autres pratiques que vous avez:
N'oubliez pas que chacun peut être personnalisé à sa manière et c'est un aspect important car ce n'est pas nécessairement une bonne chose de devenir trop religieux pour suivre une pratique si elle n'est pas utile pour votre situation.
Les Sprint Reviews sont différents des Sprint Retrospectives, du moins à mon avis. L'examen est l'endroit où ce qui a été terminé dans le sprint est montré à d'autres, généralement des parties prenantes, pour obtenir des commentaires et mettre à jour le backlog du produit avec de nouveaux éléments pouvant provenir de la visualisation du produit. La rétrospective est l'endroit où l'équipe se réunit pour discuter de ce qui s'est bien passé et de ce qui peut être amélioré pour le prochain sprint, ce qui est légèrement différent à mon avis.
Je pense que votre liste est assez complète. Vous pouvez ajouter "une portée claire et fixe pour chaque itération", car c'est ce avec quoi j'ai souvent vu des problèmes dans la pratique - bien que l'on puisse dire que cela fait juste partie de "petits cycles de publication".
De plus, j'énumérerais les "petits cycles de publication" et le "refactoring" comme des points séparés - ils sont assez indépendants.
En tout cas, je ne craindrais pas trop de "manquer" une partie de l'agilité. Une propriété importante des méthodes agiles est qu'elles ne sont pas du tout ou rien - vous pouvez commencer avec une partie qui fonctionne bien pour vous, puis monter en puissance. Certaines pratiques dépendent les unes des autres (par exemple, la refactorisation et la propriété collective du code), mais la plupart peuvent être utilisées indépendamment.
"Agile" ou "Agile Software Development" n'est pas une méthode unique. C'est un terme générique couvrant juste un ensemble de "valeurs" que vous pouvez choisir de conserver. Deux méthodes différentes peuvent à la fois être "agiles" et entrer en conflit l'une avec l'autre lorsqu'il s'agit de pratiques que vous devriez ou ne devriez pas faire.
Il n'y a pas de définition claire de "agile" - il n'est donc pas possible de faire une liste définitive des "pratiques agiles".
Il y a ne liste définitive des pratiques de programmation extrêmes de base (c'est-à-dire les choses que vous devez faire pour répondre à la définition de base de "faire XP".)
Il y a aussi un nombre minimum de choses que vous devez faire pour faire Scrum (bien que ce ne soit pas très utile car ne dit absolument rien sur les pratiques d'ingénierie spécifiques.)
Scrums chaque période donnée (quotidienne, hebdomadaire, etc.) et les sprints qui en résultent.
Pas obscur, mais vaut quand même un lien vers une explication.