Nos détracteurs ont raison. Du moins ont-ils raison sur les symptômes, mais leur solution est erronée. Car le « feature boxing » oublie un élément important du comportement humain : le rythme. Travailler avec des jalons connus est plus rassurant et plus motivant. C’est une méthode éprouvée pour garder un niveau d’énergie élevée. Travailler avec une ligne d’arrivée fuyante, qui s’éloigne lorsque l’on tente de s’en rapprocher ne permet pas de mobiliser les énergies aussi efficacement. Afin de compenser la faiblesse structurelle du cycle itératif « time boxé », les agiliste ont adopté un autre principe complémentaire : l’intégration continue. Grâce à elle, tests et intégration ne sont pas localisés en fin d’itération, mais vérifiés continuellement sur une plateforme dédiée, chaque fois qu’une tâche est terminée. On n’obtient plus le système à livrer par assemblage final en fin d’itération, mais par accrétion continue durant toute l’itération. En fait le système est théoriquement livrable à n’importe quel moment ! A ce niveau le « petit cycle » journalier ou de réalisation des tâches transparaît au sein du cycle de l’itération. La réalisation d’une fonctionnalité se suffit à elle-même, le chef de projet peut, une fois celle-ci terminée, faire passer la fiche de la fonctionnalité de la colonne « à faire » à la colonne « terminée ». La plupart des équipes de développement sont équipées d’un logiciel de gestion des changements (ou de gestion des « faits techniques », ce qui revient au même !), qui rend silencieux ou anodin ces accomplissements. Le chef de projet se doit néanmoins de rendre ces progrès visibles, et répéter la liste des fonctionnalités gérée sous l’outil de gestion des changements sur un tableau blanc ou sur un radiateur d’information est un moyen de donner du poids à ces accomplissements tout en donnant une visibilité large et permanente sur l’avancement de l’itération. 2.2.5
Réflexion et adaptation
La fin d’itération est un moment privilégié pour jeter un regard rétrospectif sur l’itération, sur ce qui a bien marché et ce qui a moins bien marché. De plus, la nature des travaux tend à évoluer au fil du temps : d’abord exploratoire, il se tourne ensuite vers l’habillage de fonctionnalités et la mise en production, bien que ces transitions sont moins marquées que dans les projets classiques. L’équipe doit se poser les 4 questions suivantes : 1. Quelles sont les pratiques qui ont bien marché, que je dois continuer à pratiquer ? 2. Quelles sont les pratiques dont la mise en œuvre a été déficiente, pénalisant ma vélocité ou la qualité du produit livré, sur lesquelles je dois donc m’améliorer ? 3. Quelles sont les pratiques qui m’ont fait défaut et que je devrais adopter ? 4. Quelles sont les pratiques qui n’apportent pas de plus value au projet et que je devrais abandonner ? Parallèlement à ces questions sur les pratiques, l’équipe doit également se poser la question de son agilité : le processus n’est-il pas en train de s’alourdir, l’efficacité et la capacité de travail sont-elles toujours consacrées à l’avancement du projet ? Répondre à ces questions, c’est analyser les propriétés agiles du projet : • Livraisons fréquentes : Nos itérations donnent-elles lieu à des livraisons permettant d’obtenir du feedback sur le système en cours de construction ? L’itération donne-t-elle une sensation de progrès et d’accomplissement à l’équipe ? • Réflexion et amélioration : L’équipe apprend-elle de ses erreurs ? La qualité du produit livré progresse-t-elle au fil des itérations ? L’efficacité du travail et la satisfaction de l’équipe sontelles sur la pente ascendante ? • Sécurité personnelle : Les membres de l’équipe se sentent-ils suffisamment en confiance pour exprimer leur point de vue, faire connaître les difficultés qu’ils rencontrent ? Un climat de confiance règne-t-il dans l’équipe, par exemple lorsqu’un membre de l’équipe a besoin de se faire aider ?
12