Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Never settle for the best

Publié par Louis-Philippe Carignan le dimanche 15 mars 2009 à 14:04

Never settle for the best: c'est la philosophie chez Google. Quand on y pense, ça vient facilement rejoindre les slogans d'autres compagnies Lean:

  • Toyota: Faire toujours mieux
  • Lexus: À la conquête de la perfection

Groupes de recherche sur le développement logiciel chez Microsoft Research

Publié par David Beaumier le lundi 2 mars 2009 à 22:14

J'ai pensé partager avec vous le site de quelques groupes œuvrant du côté du développement logiciel au sein de Microsoft Research. On y retrouve sur le site de chacun des groupes du contenu très intéressant et bien souvent applicable dans un contexte d'entreprise.

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!".

Études sur l’amélioration de la qualité par l’utilisation du TDD

Publié par David Beaumier le lundi 2 mars 2009 à 17:27

Un article publié dans le Empirical Software Engineering journal présente le résultats de quatre études qui comparent l'impact de l'utilisation de TDD sur la réduction des anomalies. L'article s'intitule Realizing quality improvement through test driven development: results and experiences of four industrial teams. Les auteurs proviennent de Microsoft, IBM et de l'Université de la Caroline du Nord.

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.

L’impact du TDD sur la productivité

Publié par David Beaumier le lundi 2 mars 2009 à 15:53

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.

Mélanger Scrum et Kanban

Publié par David Beaumier le mardi 10 février 2009 à 23:04

Corey Ladas a récemment publié un livre électronique s'intitulant Scrumban - Essays on Kanban Systems for Lean Software Development dans lequel il propose de réunir le meilleur de Scrum et de Lean.

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.

Mots-Clés :

Archive