Les équipes de développement logiciel agiles doivent s'assurer que les produits qu'elles développent ont une qualité suffisante. Le Management attend également que la vélocité augmente pour fournir de nouvelles fonctionnalités plus rapidement à leurs clients. Plusieurs auteurs se sont penchés sur la question et proposent des solutions pour améliorer les deux conjointement.
Bob Galen a écrit sur l'importance de la qualité logicielle par rapport au fait de gagner en vitesse dans l'article Lisez sur mes lèvres – l'agilité n'est pas rapide :
L'Agilité est un "jeu de Qualité", qui, si vous le jouez avec intégrité, en vous y investissant et de manière équilibrée, peut devenir une superbe partie de vitesse. Mais cette vitesse n'est pas gratuite...
Si vous ne vous y prenez pas bien, il se pourrait même que l'adoption de l'agilité soit plus lente que votre approche précédente !
Les équipes doivent s'engager à finir le travail embarqué dans une itération, ce qui signifie de valider tous les critères de leur Définition de fini (ndt : Definition of Done ou DoD) :
Trop d'équipes agiles autorisent le re-travail comme des corrections de bugs, la finition d'automatisation de tests, le refactoring ou le design de mauvaise qualité d'échapper au sprint et d'être remis à plus tard. De nombreux outils agiles permettent d'ailleurs de séparer les histoires entre le travail fait dans le sprint et le travail différé. Je pense que cela transmet le mauvais message aux équipes. Ce biais au-delà du sprint est acceptable.
Lisez sur mes lèvres - Ce n'est acceptable, finissez tout-tout-tout !
Les sociétés ne devraient pas se concentrer à devenir plus rapide mais plutôt à produire de la qualité comme l'explique Bob :
Donc la prochaine fois que vous entendez quelqu'un parler des conséquences de l'agilité et de l'impact sur la vitesse, se laissant entraîner par l'enthousiasme juvénile, merci de les arrêter. Essayez de leur expliquer que ce n'est pas une course de vitesse et insistez sur le fait qu'il s'agit plutôt d'un "jeu de qualité qui peut devenir rapide".
Tim Ottinger a écrit 14 Observations Bizarres sur la Vélocité des Equipes Agiles. Une de ses observations concerne la relation entre qualité et vélocité :
Bien que les gens tranchent dans la qualité pour finir les choses plus rapidement à court terme, sur le long terme, cela affecte la vélocité de tous les sprints si la qualité de code est faible.
Dans son article la vélocité n'est pas un but ou un objectif, Stephen Haunts décrit ce qui peut arriver à la qualité lorsque les managers fixent des objectifs de vélocité aux équipes :
(…) pour livrer plus de points, l'équipe va devoir sacrifier sur la qualité du système, ce qui à terme ralentit l'équipe et introduit de la dette technique. Il vaut mieux se concentrer sur la qualité du système que vous construisez et sur le processus (livraison continue et intégration continue, etc.) ainsi que sur les gens qui construisent le système.
Les développeurs logiciel doivent trouver l'équilibre entre vélocité et qualité comme l'explique Blake Haswell dans qu'est-ce que la qualité de code :
Il y a souvent beaucoup de pression extérieure qui fait pencher la balance vers la vélocité, mais si vous ne faites pas suffisamment attention à votre qualité, votre vélocité finira par chuter et votre projet risque de s'effondrer. Etant donné que la qualité d'un projet détermine sa facilité d'adaptation au changement, la solution viable est de toujours accorder un temps pour se préoccuper du code.
Blake propose une liste d'attributs qualitatifs qui peuvent servir de base de discussion sur la qualité de code :
- Compréhensible. Le code devrait être facilement compréhensible à tous les niveaux. Idéalement, le logiciel devrait être si simple qu'il n'y a évidemment pas de défaut.
- Testable. Le code doit être écrit de façon à être facilement testable.
- Correct. Le code doit correspondre aux attentes fonctionnelles et non fonctionnelles.
- Efficace. Le code doit faire un usage efficace des ressources systèmes (mémoire, CPU, connexion réseau, etc.).
Dans l'article les symptômes d'une qualité logicielle pauvre, Hugo Baraúna explique comment le logiciel peut se "détériorer" à la suite de changements diminuant la qualité et impacter négativement la vélocité :
Imaginer que vous êtes leader technique ou responsable produit dans une startup ; Vous êtes le CTO. Vous avez déjà une première version de votre produit qui a été un succès. Votre modèle économique est validé, maintenant vous êtes dans la phase de croissance. C'est génial. Mais cela a un coût et apporte son lot d'épreuves.
La première version fonctionne mais la base de code n'est pas dans l'état qui va vous être utile. Peut être que votre vélocité n'est plus ce qu'elle était. Votre équipe ne cesse de se plaindre de la qualité du code. Le CEO et le directeur produit demandent de nouvelles fonctionnalités et vos projections ne vont pas être à la hauteur des attentes métier.
Baraúna propose une liste de symptômes qui sont des indicateurs d'une mauvaise qualité et qui peuvent aider à identifier le besoin d'une réécriture ou d'un refactoring :
- Tout est difficile
- Une vélocité faible
- Une suite de tests lente
- Des bugs qui ne disparraissent pas
- Une équipe qui se démotive
- Une connaissance en silo
- La montée en compétence de nouveaux développeurs prend trop de temps
Comment équilibrez-vous qualité et vélocité ?