Il n'est pas facile de mettre en oeuvre XP voire même l'Agile, tant les visions, les perceptions, de ce qu'est un développement de logiciel sont encore marquées par une compréhension simpliste du cycle en V.
La question est alors : quelle est tout de même la prochaine étape vers l'Agile, à la fois ambitieuse et accessible ?
J'interviens actuellement sur un projet qui est sensé suivre ce type de cycle de vie :
- Spécifications
- Réalisation
- Tests de recette
- Mise en production.
Que faire ?
Quels sont les principes "agiles" qui semblent le plus nécessaires et/ou réalisables ?
En partant d'une modélisation qui "voit" l'activité de développement, le projet, comme un système, l'élément crucial est alors le feedback.
Qu'est-ce qu'un feedback concret et rapide ?
Un feedback est un retour d'information : il peut être spontané ou bien demandé, formalisé, géré. Au delà d'une apparence libertaire, XP formalise très rigoureusement de nombreux feedbacks : résultats des tests unitaires, stand-up meetings, résultats des tests-client, etc.
Ce retour d'information est sensé nous permettre de nous forger une opinion sur le déroulement du projet et, par là, de nous aider à décider. Actions, choix... autant de décisions qui sont alors rendues pertinentes grâce au feedback préalable (voir aussi l'aspect graphique dans ma présentation de l'Extreme Programming).
Feedback concret et rapide. Un principe sous-jacent au cycle habituel est qu'une documentation fournit par elle-même un feedback : "si ce document est produit, alors le projet est dans tel état d'avancement". Or, de nombreux facteurs, à commencer par la "spécification molle" rendent ce principe arbitraire, infondé, voire inopportun.
Un feedback concret est un feedback de l'application elle-même, donné aux utilisateurs. Injecter des intermédiaires : personnes (chef de projet, analystes...) et/ou d'autres livrables (documents) rend le feedback de moins en moins valable.
Un feedback est rapide (sachant qu'il est aussi concret) lorsqu'il intervient au plus vite après la production de ce qui est l'objet du feedback. Autrement dit, si l'équipe développe une fonctionnalité demandée semaine 9, le feedback devrait intervenir semaine 9, 10 ou semaine 11. Ainsi, les équipiers ont encore en tête les éléments constitutifs du produit testé et leur intervention de mise au point est alors plus efficace.
En pratique
Il s'agit donc de créer les conditions d'un feedback rapide et concret. Quelles sont les questions ?
Tout d'abord, préciser les pratiques à mettre en place : écriture des tests-client, passage de ces tests, analyse et prise de décision par rapport aux résultats de ces tests.
Ensuite, qui fait quoi ? La MOA - utilisateurs - est toute désignée pour conduire ces opérations, dans le cadre d'une collaboration avec les développeurs.
Enfin, quel est le rythme ? Il me semble qu'un rythme basé sur :
- des tests "permanents" autrement dit, tester dès qu'une fonctionnalité est programmée,
- dans un cadre itératif incrémental centré sur des itérations de 2 semaines à un mois
Le mieux étant l'ennemi du bien, il convient alors de faire la part des choses. Sur le principe, découper une "longue" phase de réalisation en plusieurs itérations est déjà une avancée significative. Attention, il s'agit de bien comprendre quelle est l'unité de travail. Dans un cadre XP, c'est la user story qui joue naturellement ce rôle. Dans un cadre plus classique, ce sont les exigences qui prennent le relai.
Autre point important : jouer sur la notion de "fin d'une réalisation". Trop souvent, le développement d'une fonctionnalité est réputé terminé lorsque le développeur a saisi le dernier point-virgule de la dernière instruction. Ici, une fonctionnalité est terminée lorsque le client, qui s'appuie sur les résultats de ses tests, le décide, pas avant.
Enfin, si votre MOA rechigne parfois à écrire des tests... aidez-là.
Ce qui est fait
Nous mettons donc en place des itérations d'un mois. Il se trouve que l'environnement de développement et le domaine sont parfaitement adaptés à une découpe en fonctionnalité "courtes". Ce sont des aspects du logiciel (les droits d'accès, les éléments structurants...) qui sont traités lors d'ateliers et qui donnent lieu à un ensemble de spécifications, de tests-clients, d'implémentation et de passages de tests.
En conclusion...
Vous souhaitez être agile ? Interrogez-vous : comment pouvez-vous mettre en oeuvre un feedback concret et rapide sur vos projets ?
photo : plage du Diamant, Martinique (Thierry Cros)
Aucun commentaire:
Enregistrer un commentaire