oct
16
Voici la suite de mon compte-rendu de l’étape genevoise de l’Agile Tour avec deux présentation sur la dette technique et le lean.
Pour passer la crise, remboursez votre dette technique par Freddy Mallet et Rémy Sanlaville. La dette technique est définie comme l’ensemble des mauvaises pratiques qui rendent plus coûteux l’ajout d’une nouvelle fonctionnalité. On peut citer par exemple la duplication de code, l’absence de commentaires ou de standards, le manque de tests automatisés. La dette technique en tant que telle n’est pas forcément négative, mais un surendettement peut conduire à la paralysie du projet, voire sa mort. Parmi les symptômes d’une telle situation, on trouve la peur de faire des changements, la dépendance dans un seul super développeur ou les effets de bords lors d’évolutions. Freddy Mallet a montré comment un outil comme Sonar permettait de contrôler le niveau de dette technique afin d’élaborer un plan d’action pour en soigner les causes. Rémy Sanlaville s’est ensuite attaché à montrer que le problème de la dette technique n’était pas seulement à l’intérieur du code. Les problèmes peuvent aussi venir du build (gestion de la configuration), de la gestion de configuration (fréquence des commits), de la gestion et prioritisation du backlog ou des fréquences des releases en production. Le coût de la dette technique peut apparaître lorsque l’on doit intégrer un nouveau développeur dans le projet. La conséquence d’une dette technique importante est aussi la croissance du prix d’un ajout d’une nouvelle fonctionnalité. En conclusion, les orateurs ont insisté sur l’importance des équipes pour trouver des remèdes aux problèmes, les outils n’étant là que pour faire émerger une conscience collective de l’importance de la dette.
Introduction du Lean de le développement dans le développement de la webTV d’Orange par Régis Medina et Antoine Cortal. Ce fut un intéressant et honnête compte-rendu de l’histoire d’une équipe agile qui cherche à intégrer le Lean dans sa pratique. Les orateurs (un Scrumaster et un coach Lean) ont présenté comment l’approche Agile intégrait déjà en partie les techniques du Lean. L’équipe de projet avait fait la constatation d’un manque d’évolution malgré l’utilisation des rétrospectives, ce qui a incité le Scrumaster à chercher dans le Lean. Le coach a présenté la démarche Plan, Do, Check, Adjust (PDCA) avec pour objectif l’amélioration de la vélocité de l’équipe que le client considère comme le problème principal du projet. Il a conseillé au Scrumaster d’aller voir sur le terrain (le code) où pouvaient être les gaspillages alors que celui-ci restait encore souvent au niveau d’une analyse de la gestion du projet par le radiateur d’information. Il est cependant souvent difficile de mettre en place des améliorations lorsque l’équipe est déjà sous pression pour la réalisation. Une solution peut être la négociation d’une time box dédiée à l’amélioration. Le coach a aussi conseillé la mise en place d’un document standard pour le traitement des incidents. Alors que les standards et la documentation peuvent paraître anti-agile, ceux-ci permettent au contraire d’accélérer le travail et de fournir une base pour l’amélioration. L’équipe a ainsi créé son propre standard pour la réunion journalière et une check-list pour la définition du « done ». Après 4 mois de mise en oeuvre, la vélocité n’a pas augmenté, mais la pratique du Lean est installée dans l’équipe et celle-ci va repartir dans un deuxième cycle de PDCA. En conclusion, si le Lean ne résout pas immédiatement tous les problèmes, il les fait émerger, ce qui peut créer un niveau de lucidité qui n’est pas toujours facile à accepter.