Concordiagile

Kent Beck nous propose dans sa méthode eXtreme Programming d’adopter sur nos projets la pratique de propriété collective du code. Il propose que l’application soit comprise et maitrisée par tous les membres de l’équipe.

A titre d’exemple, une équipe peut mettre cette pratique en œuvre au travers des actions suivantes :

• Les développeurs travaillent en binômes sur une grande majorité du codage de l’application. Les binômes tournent régulièrement. (Pair Programming)
• Aucune personne ne se spécialise dans un module ou une partie de l’application en particulier. L’équipe évite de se retrouver avec un spécialiste de la base de données, du build, du framework IHM ou de l’architecture générale de l’application.
• Tout le monde participe à l’effort de création des jeux de tests unitaires et fonctionnels. L’équipe évite d’avoir une personne dédiée uniquement à la qualité.

Voici quelques situations qui doivent vous amener à penser méthodes agiles (XP, Scrum, ...) :

Votre client/MOA sait exprimer ses besoins mais ne se sent pas capable de spécifier complètement sa nouvelle application ?

C'est normal. Personne ne sait figer ses exigences dans les moindres détails avant que les développements ne commencent.

Les clients qui vous le promettent ne sont pas de mauvaise foi, par contre leurs utilisateurs en voudront pour leur argent et changeront forcément de point du vue en cours de projet. Sans parler des changements d'environnement tout au long du projet (fusion, changement de stratégie, nouvelle législation, infaisabilité technique, mauvaise compréhension du besoin, ...)

Votre client/MOA ne croit plus aux développements forfaitisés à prix fixe. Ce soit disant prix fixe explose dès le premier comité de pilotage !

C'est normal. Aucun développeur, chef de projet ou directeur de projet ne peut chiffrer un développement à l'avance. S'il dit le contraire, il n'est pas de mauvaise foi, il se voile juste la face en se rassurant avec des feuilles de calcul Excel, des points de fonction et des abaques. Un développement est une fonction avec trop d'inconnues.

La pire des situations est l'appel d'offre ouvert qui incite les prestataires à évaluer à la baisse sans jamais voir le client en face pour lui poser des questions sur son projet.

Au mieux, on doit pouvoir donner une estimation du type : Votre projet a 70% de chances de prendre 1000hj, plus ou moins 200hj. Ceux qui ont un peu étudié les statistiques, savent que les résultats de sondages doivent être donnés sous cette forme, même si les médias pensent que communiquer un pourcentage est suffisant.

Votre client/MOE souhaite contrôler la qualité de vos livrables sans savoir trop comment s'y prendre.

C'est normal. Dans le cas de forfaits, l'application livrée a rarement la qualité attendue, faute de temps pour mieux faire. Pour se protéger, les clients fixent donc des normes de développement, des outils de vérification (type cast), des jalons de livraisons, des processus complexes, ... En fait, nos clients cherchent à nous faire porter les risques en fonctionnant en forfait. Mais comme nous n'arrivons pas à livrer la qualité attendue dans le temps imparti, ils doivent passer en mode flicage.

Le pire c'est que ce mode flicage nous rapporte (nous SSII), puisque l'on aide d'autres clients à mettre au point des normes, des processus, des audits,...

Le seul indicateur de qualité devrait être le produit livré, confronté aux utilisateurs finaux. Pour tester la satisfaction de ses clients, Sun ne pose plus qu'une question : Seriez-vous prêt à recommander nos produits ?

Alors que faire ?

Il faut aider nos clients à utiliser les méthodes "agiles". Les bénéfices sont multiples :

Plus de big upfront design, donc des coûts réduits : Le projet classique (architecture technique, POC, socle technique personnalisé, développement) est remplacé par une architecture émergeante au fil de l'eau plus légère et plus flexible. Cela ne veut pas dire que l'on ignore les règles d'architecture ou d'urbanisation du client. Cela reste des exigences en entrée du système.

Plus de dépassement de budget incontrôlé : Si le budget maximal est atteint, on peut choisir :

D'arrêter les développements et d'utiliser le produit tel quel. Avec les méthodes agiles, on a un produit fini à chaque itération. Avec les méthodes classiques (même itératives), le projet est rarement utilisable en l'état.

De contrôler l'augmentation de budget car le produit est affiné à chaque itération sans risque de régression (grâce au test driven development). Pourquoi pas ne pas mettre le logiciel en production tout en repoussant l'ajout de fonctionnalités à l'année prochaine ? C'est d'ailleurs un peu ce que l'on fait en achetant un progiciel.

Les meilleurs développeurs travaillent pour vous : Les méthodes agiles attirent en effet les développeurs expérimentés ou en quête de nouvelles compétences. Grâce au pair programming ou au rythme des itérations, ils seront plus motivés, plus efficaces et le turn-over est réduit.

Voila pour un court article sur les bénéfices des méthodes agiles. Un dernier point en passant : L'itératif n'est pas forcément agile. Ne vous trompez pas, il manque beaucoup à UP pour devenir agile. Pour moi, les deux points importants sont le pilotage par les tests et le fait que l'on doit aider le client à décider le contenu des itérations lui-même. C'est donc bien le client qui tient les commandes ! (Pas juste le porte monnaie)

La décision est prise, demain matin vous devez développer un logiciel pour votre entreprise. Un budget est disponible et un premier choix s’impose à vous : la méthode de travail.... Chronique à paraître dans 01 Informatique