Voici donc le lien pour obtenir une version électronique de deux des chapitres du livre à venir:

Roman Pichler is writing about the product owner role in his book, Agile Product Management: Turning Ideas into Winning Products with Scrum. Two of his chapters are available now.

Bonne lecture!

Par expérience, j’encourage généralement les équipes à débuter avec des outils de gestion simple au début afin de bien saisir leurs besoins en la matière. À mon avis, il est important de sélectionner l’outil le plus simple qui puisse répondre aux besoins de l’équipe afin d’éviter la complexité souvent associée aux outils qui offrent des solutions mur à mur.

L’équipe Human Interactions in Programming a comme mission d’offrir de meilleurs outils de génie logiciel en appliquant les pratiques d’utilisabilité. On a longtemps cru que les outils de développement s’adressaient à un public de “nerds” et qu’il n’était pas nécessaire d’investir au niveau de l’expérience utilisateur. Ils essaient aussi d’identifier les interactions qu’on retrouve dans le jeux coopératif qu’est le développement logiciel et qui influencent directement le succès des projets.

Le  groupe spécialisé sur les approches empiriques de développement logiciel concentre ses travaux sur trois axes: fiabilité des systèmes, impact des processus de développement et études empiriques sur les pratiques de développement. Malgré que le groupe ne semble composé que de quelques individus seulement, on retrouve sur leur site un bon nombre de publications reliées à leurs travaux.

Un autre groupe se concentre quant à lui sur les pratiques rigoureuses de génie logiciel. Là encore on retrouve d’intéressantes publications, mais dans ce cas-ci on parle de recherches assez poussées. Je suppose que c’est un peu comme en formule 1, un jour les innovations se retrouvent, pour le plus grand bénéfice de tous,  dans les voitures de tourisme. On dira sans doute un jour du résultat de ces recherches: “Bientôt disponible dans un IDE près de chez-vous!”.

Selon ses auteurs, l’article conclu que l’application du TDD permet une réduction variant de 40 à 90% par rapport à des projets similaires n’utilisant pas cette pratique de développement. Ils dénotent aussi une augmentation du temps de développement, mais comme je l’ai mentionné dans cet article précédent, il est fort probable qu’en comparaison les équipes témoin ne faisent pas (ou très peu) de tests unitaires. N’en demeure pas moins que l’augmentation de la qualité relevée est impressionnante.

InfoQ rapporte également une publication de Maria Siniaalto datant de 2006 dans laquelle l’auteur compare 13 expérimentations portant sur l’application de TDD dans divers contextes. Ses conclusions rejoignent celles de l’article du Empirical Software Engineering journal pour ce qui touche l’amélioration de la qualité. Fait intéressant, elle note qu’aucune étude à ce jour (2006) ne mesure l’impact de TDD sur la conception logicielle, alors qu’il s’agit pourtant d’un des première promesse de cette pratique. Tiens, un autre aspect de TDD sur lequel il me faudrait fouiller un peu plus et voir si des mesures ont été publiées au cours des trois dernières années.

Parmi les études sur l’utilisation du TDD recensées sur Internet, on retrouve un cas qui implique deux équipes de produits chez Microsoft (dans les divisions Windows et MSN). Dans les deux cas étudiée chez le géant de Redmond, l’impact de la pratique de TDD sur le temps de développement et sur le nombre d’anomalies ont été mesurés. En se basant sur les données recueillies, l ‘étude démontre que la qualité du code livré est de beaucoup supérieure lorsque l’équipe applique TDD. Les mesures ont permis d’identifier une augmentation de 4.2 fois dans la qualité du code développé en utilisant TDD lorsque comparé à une projet réalisé dans un contexte organisationnel similaire mais n’utilisant pas cette pratique.

Toutefois, l’étude fait ressortir le fait que les programmeurs utilisant une approche TDD sont moins rapide. L’écart rapporté est de 16%. En se questionnant sur cet écart je crois nécessaire d’apporter un bémol par rapport au chiffre avancé. En effet il est beaucoup plus facile de calculer le temps total engagé pour développer une fonctionnalité lorsqu’on utilise TDD que lorsqu’on utilise une approche traditionnelle. La notion “d’avoir terminé” une fonctionnalité donnée est beaucoup plus claire avec TDD. En mode traditionnel, avoir terminé est plus une question de confiance par rapport à ce qu’on a réalisé; confiance qu’on a produit du code assez robuste et couvrant l’ensemble des attentes. Avec TDD, avoir termin. une fonctionnalité se produit lorsque l’ensemble des tests unitaires s’exécutent avec succès. Je crois qu’une grande partie de la réduction des anomalies notée dans l’étude de Microsoft est dû à cette formalisation de la notion  “d’avoir terminé”.

Les auteurs ont d’ailleurs eux aussi apportés une nuance face à cet écart en indiquant que “les programmeurs du groupe de contrôle omettaient fréquemment de réaliser les cas d’essais automatisés après avoir complété leur code”. Cela n’est pas surprenant en soi et c’est un phénomène fréquent dans les équipes n’utilisant pas TDD. Dans ce contexte, les tests sont réalisés après le code et deux raisons sont fréquemment cités pour justifier le fait d’escamoter les essais unitaires.

• Contrainte dans le temps
• Conception limitant la capacité de tester unitairement le code

Même en prenant pour acquis que la réduction de productivité est bien de l’ordre de 16%, cela demeure tout de même un bien faible coût à payer en regard des bénéfices de qualité généré. Sachant que plus une anomalie est découverte tardivement dans le cycle de développement plus elle est coûteuse à régler, une réduction de plus de 4x du nombre d’anomalie apporte une économie de beaucoup supérieure à l’augmentation possible du temps initial de développement.  Dans cette optique cet écart, s’il est bie réel, devrait plutôt être considéré comme un investissement.

Une présentation de Philip Ritzkopf fait une synthèse intéressante de quelques expériences et études portant sur la pratique du TDD. Dans sa conclusion (à la page 40), on peut voir que, dans l’ensemble, l’utilisation de TDD ne réduit pas la productivité des développeurs. L’application de TDD n’engendrerait donc pas l’instauration d’une “taxe” au développement comme plusieurs pourraient le croire.

L’article publié en 2005 par Erdogmus, Morisio et Torchiano dans IEEE Transactions on Software Engineering présente les conclusions d’une expérience comparant le travail de deux groupes d’étudiants, où l’un appliquait une approche TDD alors que l’autre rédigeait les tests après avoir avoir terminé le code. Dans les deux cas les participants devaient appliquer une approche incrémentale en ajoutant les fonctionnalités une par une et en s’assurant de ne pas avoir introduit de la régression entre chaque cas.

Les auteurs arrivent à la conclusion que les participants ayant appliqué TDD on généralement écrit plus de tests que ceux ayant écrit les tests après.  Aussi, ils ont remarqué que la courbe de productivité a tendance à augmenter en fonction du nombre de tests. Les auteurs de l’étude suggèrent que ces gains en productivité découlent des éléments suivants:

• Meilleure compréhension de la tâche à réaliser
• Focus sur la tâche à accomplir
• Apprentissage plus rapide
• Réduction de l’effort de réécriture du code

Dans un premier temps, on voit que le fait de travailler par petites étapes et d’avoir toujours comme objectif à court terme de faire passer un test permet au développeur de focuser son attention sur une activité bien précise tout en ayant une meilleur compréhension de celle-ci. On réduit ainsi les chances d’être distrait pas une préoccupation provenant d’un autre aspect du système que celui sur lequel on travaille. Les trois auteurs notent que l’application du TDD par les participants “encourage une meilleure décomposition, augmente la compréhension des exigences et réduit la portée de la tâche à réaliser”.

La plupart des études citées cherchent à mesurer l’impact à court terme de l’application du TDD. Il s’en dégage clairement une tendance où l’on constate que l’impact sur la productivité de l’équipe est négligeable, voir même nul. Dès que l’on introduit l’élément qualité dans l’équation, l’amélioration générale constatée dans les études rend non-significatif tout impact sur la productivité.

Par contre qu’en est-il des impacts sur la productivité à long terme? Est-ce que l’important patrimoine de tests qu’engendre la pratique du TDD affecte la capacité de l’équipe à avancer au même rythme au fil du temps? Je reviendrai sur ce sujet en espérant apporter des réponses à ces interrogations dans un prochain article.

J’ai bien hâte de découvrir plus en détails la proposition de Ladas. C’est une lecture que j’ajoute à ma (toujours longue) liste de bouquins.