Résumé
Les axes de réflexion que je considère pour construire une définition de Terminé :
- qualité externe
- qualité interne
- autorisations
- déploiement
- exploitation
Lorsque je travaille avec une équipe à établir ou modifier notre définition de “Terminé” (le Done de Scrum), je ne leur propose pas d’exemple comme point de départ de la discussion. Par contre je leur propose les différents axes de réflexion dans lesquels nous allons identifier les points pertinents pour eux.
Pour démarrer la discussion, je propose de commencer par explorer les axes qualitatifs :
- qualité externe
- qualité interne
Qualité externe
Cette notion de qualité externe nous parle de notre capacité à construire le bon logiciel, celui qui rend les services souhaités, à un niveau de performance satisfaisant, à un niveau d’ergonomie qui fluidifie sa prise en main et son utilisation. C’est la qualité perçue lorsqu’on utilise le système.
Pendant cette réflexion, nous partageons alors comment nous comprenons cette idée de qualité externe et nous décidons quels types de tests nous souhaitons construire notre confiance dans notre code : des tests automatiques qui exercent le système dans son ensemble avec des données réalistes, des tests qui spécifient les conditions aux limites des services rendus, des tests de performance, des tests de sécurité, des tests de traduction, …
La question des anomalies est parfois abordée à ce moment dans la discussion. Cette discussion peut être difficile parce que chargée d’un historique peu flatteur pour les programmeurs. On distingue ici deux types d’anomalies: les anomalies que l’on découvre après la mise en production et celles que l’on connaît avant la mise en production.
Pour les premières, il s’agit de définir comment nous allons les prendre en compte, c’est à dire comment leur découverte va impacter le travail en cours. La démarche stop the line du Lean est la démarche la plus cohérente avec une approche empirique, même si elle représente des défis importants.
Pour les secondes une attitude cohérente avec ce que l’on vient de dire consiste à ne jamais déployer un système avec des anomalies connues. Cela demande souvent beaucoup de courage dans des environnements qui ont malheureusement appris à supporter des systèmes avec beaucoup d’anomalies.
Qualité interne
Cette notion de qualité interne nous parle de notre capacité à construire correctement un logiciel. Par correctement, on entend ici un logiciel que l’on peut faire évoluer durablement. Plusieurs outils aujourd’hui sont capables de construire des indicateurs qui, lorsqu’on les améliore, nous aide à construire un logiciel que l’on peut faire évoluer durablement. Par exemple le pourcentage de couverture de code par des tests unitaires et d’intégration, la compléxité cyclomatique, le taux de duplication… Certains outils, comme Sonar, vous permettent même assez simplement d’implémenter votre propre règle.
Les tests automatiques sont des indicateurs de qualité assez simples à construire car ils se basent sur une analyse statique du code, c’est à dire sur une photo du code à un instant donné. Or il se trouve que l’on a constaté que le fait d’écrire un test avant d’écrire le code de production qui le fait passer a un impact majeur très positif sur la qualité du logiciel construit. On parle ici d’un indicateur de qualité dynamique qui nous renseigne sur la manière dont le logiciel a grandit. La plupart des équipes mettent en place cette idée simplement en ayant la discipline de toujours écrire un test avant d’écrire du nouveau code.
Vient ensuite, dans l’ordre chronologique des étapes à passer pour être prêt à déployer un système en production, la question des autorisations nécessaires.
Autorisations
Certaines industries contrôlées imposent aux créateurs de logiciels de faire la preuve de certaines caractéristiques dans un format imposée par une convention. C’est le cas par exemple dans l’avionique ou la pharmacie, pour en citer deux à priori assez éloignées. D’autres normes, internes celles-ci s’imposent parfois aux équipes.
La plupart du temps, ce besoin d’autorisation déclenche la rédaction de document dans un format souvent imposée à l’équipe. Le travail récurrent d’une itération à l’autre consiste alors selon les cas à les créer ou bien à les tenir à jour.
Déploiement
Le déploiement par incréments successifs suppose que plusieurs déploiements vont être effectués pour mettre à jour un système. Dans ce contexte, il est pertinent de ne pas considérer le premier déploiement comme un cas particulier mais bien comme le déploiement d’un incrément qui part d’un état précédent vide.
Des éléments de différentes natures sont à considérer. Sans ordre d’importance, on peut citer : un moyen d’interdire l’accès au système pendant le déploiement du nouvel incrément, la modification de l’environnement, la modification des configurations réseaux, la modification de la structure de données, la migration des données, … Disposer de tests automatiques de déploiement s’avère encore une fois très utile pour être capable de déployer chaque incrément sans détruire le système déjà en place.
Exploitation
Ce qui précède concerne la préoccupation de mise à jour d’un système existant. Il faut aussi considérer les activités qui tournent autour de l’utilisation du système en place. Selon les cas il s’agit de choses aussi variées que des scripts de redémarrage, la formation des utilisateurs, la formation des équipes travaillant à la hot-line du système, …
Si le développement incrémental est nouveau pour vous et que vous avez des difficultés à établir votre définition de Terminé avant de commencer, rassurez-vous c’est normal. Explorez pendant une première discussion les différents axes de réflexion qui vous semblent sensés et établissez vos premiers indicateurs en fonction de la vision du produit. Faites une itération et pendant la revue d’itération posez vous la question: est-on prêt à déployer cet incrément en production ? Si oui, faites le. Si non, améliorez votre définition de Terminé pour la suite.
We are already approaching the end of 2010. With the Agile Manifesto turning 10 years-old next year and the growing interest of Agile in organizations, I am launching the 2010 World’s Most Agile Manager (WMAM) contest.
