dimanche 17 juillet 2011

Pourquoi s'embéter avec l'agilité...

...en SSII. C'est la question que je me pose. Les pratiques de conduite de projet agiles, dont l'implémentation la plus populaire en France est a priori Scrum[1], restent encore globalement méconnues (il faut dire que le manifeste a seulement 10 ans. Il faut du temps pour traverser l'Atlantique). Elles sont assez souvent jugées comme peu sérieuses (mon expérience). C'est encore délicat aujourd'hui pour les évangelistes, je pense, d'en faire susciter l'adoption dans l'enthousiasme général. Alors, pourquoi ne pas arrêter ?

Rassurez-vous, je ne vais pas vous suriner avec tout le bien que je pense des projets en cascade, en V, en Y... Les spécifications mal écrites, mal lues, pleines d'erreurs... Les cahiers de tests manuels mal écrits, jamais rejoués, périmés... Les règles de développement jamais discutées en équipe, prônant l'usage de cette saleté notation hongroise (je crois que je m'égare...).

Reprenons. Scrum, c'est quoi ?

C'est un ensemble de pratiques et de rôles qui va permettre à l'équipe de développement de se rapprocher d'un collège d'utilisateurs afin de développer une application informatique censée les aider dans leur travail, les rendre plus efficaces, heureux et riches.
Ils sentent ce qu'ils veulent mais ne savent pas -au sens de compétence mais aussi de disponibilité, de temps à consacrer- le formaliser de façon exhaustive dans des spécifications.
Ainsi l'équipe de développement fait de son mieux pour interpréter ces besoins et les traduire en application afin de les montrer rapidement aux utilisateurs. À la vue du travail effectué, leur besoin se précise et l'application évolue. On s'aperçoit que finalement, une fonctionnalité A est suffisamment remplie par une fonctionnalité B qui devient donc très peu prioritaire, que ce serait bien d'avoir telle et telle information dans un nouvel écran. Oh et Jean-Jean, tu nous ferais pas un tableau de bord là en page d'accueil ? Ce serait tellement pratique pour les gars...

Dans ce cas de figure, ça mène à un niveau de synergie étonnant. On arrive à faire de grandes choses à couts maîtriser et avec une vraie satisfaction du client en la personne de l'utilisateur final. Je l'ai vécu. En SSII. Et c'est une exception.

La règle habituelle des projets au forfait est très différente.
En premier lieu, l'équipe n'est jamais au contact des utilisateurs. Les utilisateurs formulent un besoin à une maîtrise d'ouvrage (MOA) qui la transmet accompagnée d'un budget à une maîtrise d’œuvre (MOE) qui va la traduire en cahier des charges et parfois même en spécifications (chance pour vous). La MOE fait appel à la SSII pour sous traiter le vil travail de développement (elle n'est pas obligée, mais là ça m'aide pour écrire un article sur les SSII).

La MOE n'a pas besoin du projet. Elle n'a pas un besoin viscéral du projet. Faire le plus beau logiciel du monde ne va pas rendre son travail plus efficace, plus facile. Il ne va pas rendre ces personnes plus heureuses chaque matin d'aller utiliser une application faite uniquement pour eux, pour leur besoin spécifique.

Alors pourquoi vouloir faire du Scrum ? Où est l'agilité dans ce processus ?
Un processus dans lequel le besoin des utilisateurs est livré entre 6 mois et 1 an après leur demande. Un processus au cours duquel de multiples équipes se sont interposées entre l'utilisateur et son besoin et le producteur capable de le satisfaire, avec ce que cela représente de coûts mais aussi de déformation du besoin exprimé ? Où est l'agilité lorsque le logiciel n'est pas en accord avec l'interprétation des spécifications et que les acteurs repartent dans un cycle demande-chiffrage-planning-réalisation ? Je cherche encore...

J'ai vu une fois un projet soi-disant Scrum avec une structure décrite ci-dessus et au forfait. Cela est revenu à développer un une liste d'exigences mouvante sans réviser l'engagement sur le périmètre à livrer. Un beau massacre.

On peut éventuellement se dire qu'on peut faire un contrat forfait pour rassurer la partie cliente et obtenir le budget et ensuite ne pas honorer l'engagement sur les fonctionnalités. En d'autre terme, on signe un contrat forfait pour au final de la régie. Cela peut marcher... si on aime faire de l'escalade sans corde (avec de la graisse sur les mains). C'est à refuser absolument.

Restons simples. Rendez-vous service. Rendez service à votre hiérarchie et à votre client. Si vous avez une MOE qui veut du forfait, donnez lui du forfait. Si elle veut faire du Scrum et du forfait, dirigez votre interlocuteur vers ce billet : il est possible qu'il n'ait pas réellement saisi l'intérêt.

Vous voulez cependant travailler de façon moderne malgré ce carcan austère ? Ajoutez mon journal dans votre agrégateur RSS et laissez moi formaliser la suite (on peut aussi faire du blabla incrémental :)).

Ouais, c'est un to be continued, baby.



[1] n'insistez pas, je n'ai pas de source. Vous connaissez Crystal et DSDM vous ?