Le développement agile construit sur un contrat accepté par des avocats semble impossible. Le fonctionnement traditionnel des processus d'achat et de contractualisation s'oppose aux principes Agiles. Pour les petits projets, vous pouvez trouver des contournements, mais pour de gros projets à risque, la situation est autre. Le client veut comprendre ce pour quoi il paye, alors qu'en fait, il ne peut détailler suffisamment ce dont il a besoin. Ayant adopté les principes de l'Agile il y a quelques années, nous avons été confrontés à ce challenge à un moment. Et c'est exactement comme le disait Nelson Mandela : "Cela paraît toujours impossible jusqu'à ce que ce soit fait". Partageons notre expérience avec une entreprise d'assurance.
C'était une situation inhabituelle. Une compagnie d'assurance voulait lancer un nouveau service de santé en moins de six mois. Les applications back-office et de communication étaient à construire à partir de rien, tandis que l'intégration avec les couches applicatives d'enregistrement était obligatoire. Il n'y avait pas de spécifications claires. A bien y réfléchir, un projet ambitieux et risqué. Plusieurs fournisseurs préparèrent une proposition, que le client ne crut pas du fait des écarts de prix. Il comprit heureusement qu'une approche Agile était nécessaire pour aboutir à une solution opérationnelle en six mois. Ce fut notre chance car dans beaucoup d'autres cas, il nous faut beaucoup d'efforts pour convaincre le client qu'une approche Agile est préférable.
Les RFP fournissent beaucoup d'Informations, et souvent pas celles attendues
Le RFP se composait de plusieurs pages de besoins techniques et fonctionnels. Il était facile de comprendre pourquoi les autres fournisseurs émirent des propositions différentes. Malgré tout le travail des analystes du client, beaucoup de choses restaient floues, et des fonctionnalités essentielles et des descriptions d'intégration manquaient.
Comme il était sûr que certaines informations manquaient, nous avons proposé de commencer par trois semaines de brainstorming pour rencontrer les analystes et les experts de chaque domaine (avec de nombreux utilisateurs finaux).
Ensemble, nous avons discuté les différentes fonctions et tâches, défini les rôles, ce qui a permis de définir le "périmètre du projet". Nous avons résumé les échanges par des "épiques", et dès que possible par des user stories pour montrer notre compréhension des besoins.
Même le client a mieux appréhendé la complexité de ses processus après ces ateliers.
Estimer pour préparer la Proposition
Est-il raisonnable de définir une date de fin et un budget si vous ne connaissez pas le livrable ? La réponse est oui - mais seulement si vous utilisez des méthodes projets qui correspondent à ce type de situations. L'Agile en est un. Bien que d'accord sur le périmètre, nous avions encore un problème majeur à affronter : définir et formaliser l'accord. Aujourd'hui, il existe des cadres de contrats agiles, qui n'étaient pas là quand nous préparions notre offre.
Nous avons décidé d'estimer de deux manières différentes. Premièrement, nous avons estimé d'une manière classique en discutant du temps requis pour chaque user story. Nous avons vérifié ces éléments en "devinant" la capacité requise en design, développement, tests et implémentation pour réaliser le projet dans les temps donnés. La seconde approche fut le "Planning Poker". Les membres de l'équipe définirent la complexité des épiques et des US en les comparant. En s'inspirant de notre expérience avec des projets similaires, nous connaissions plus ou moins la vélocité attendue (le temps de développement par US).
Bien sûr, ces méthodes aboutirent à des estimations distinctes, mais ces approches différentes nous ont permis de définir l'effort total qui nous semblait nécessaire pour livrer la solution demandée. Nous y avons ajouté un facteur de risque, car nous avons considéré qu'il faudrait de l'encadrement complémentaire pour faire tourner le projet.
C'est alors que la Négociation sur le Prix commence
Pour le client, le budget total mentionné était trop haut (comme d'habitude pourrait-on dire). Grâce à notre estimation complètement transparente, le client était conscient de la manière dont nous arrivions au total. Grâce à cette transparence, le client savait que tout ce qui était présent était nécessaire.
Nous avons convaincu le client d'accroître son budget pour se rapprocher de notre estimation. Nous nous sommes accordés pour appeler le budget d'origine "la cible" budgétaire du projet. Nous y avons ajouté 40% pour construire un budget maximum, appelé "plafond" budgétaire. Dès que le budget dépasserait le budget "cible", le client ne serait facturé que la moitié du taux du développeur. Nous avons également conclu que si l'ensemble du projet devait être fait sous le budget "plafond", nous partagerions la différence. Au dessus du budget "plafond", il nous faudrait travailler gratuitement. Ce budget ne pourrait pas servir pour ajouter des fonctionnalités nouvelles non prévues préalablement. Dans ce cas, un processus standard de changement de périmètre devrait être mis en oeuvre. L'approche Coût-Cible-Plafonné a été inspirée par l'article de John Rask “Target Cost Contracts” (en).
Une fois cet accord oral atteint, le projet commença. Les formalités prendraient encore deux mois, mais nous ne pouvions plus attendre plus longtemps. Sur ce Gentlemen's agreement, nous avons lancé le projet.
Besoin d'Avocats ...
Ebaucher un accord est une chose, mais l'écrire d'une manière qui plaît aux processus administrativo-bureaucratiques sans bloquer l'exécution d'un projet agile est un vrai challenge. A notre requête, le client nous envoya ses conditions d'achats. Et elles étaient loin d'être Agile.
Notre avocat qui avait appris à être plus agile avait déjà préparé un accord, incluant plusieurs des conditions du client, et nous l'avons renvoyé. Leurs avocats le relurent et retirèrent simplement toutes nos propositions.
Nous avons conclu que ces itérations juridiques ne mèneraient nulle part, et dès lors avons organisé un rendez-vous entre les directeurs représentant la partie "business" et tous les avocats, pour expliquer aux avocats du client l'objectif du projet, les raisons pour le mener en Agile et ce que cela signifiait.
Cela aida.
La construction du Contrat
Un accord cadre fut ébauché. En dehors des conditions générales, il présentait des règles comme :
- L'objet du contrat étant le développement logiciel. La maintenance, l'administration, la documentation et la formation utilisateur, etc, furent par exemple écartées.
- La séparation du projet en releases.
- Le plan de livraison des releases.
- L'explication des processus Agile, dont le principe des itérations et l'usage des user stories pour définir le périmètre des releases.
- Le processus de validation des releases construits sur des critères d'acceptation et l'acceptation finale du système après la dernière livraison et la satisfaction client. Le document d'acceptation était annexé.
- Les procédures de gestion des fautes.
- La communication entre le client et le fournisseur, et le pouvoir de décision des personnes clés impliquées.
- Les documents types à utiliser durant le processus de développement.
- Les échéances de paiements basées sur le lotissement.
Pour des raisons administratives, le client nous demandait des formalités que nous avons acceptées de fournir durant le projet.
Diviser le Projet en Petits Bouts
Le système complet fut découpé en 10 releases pour mieux définir et gérer le périmètre. Chaque release avait son budget propre, construit sur des estimations haut-niveau des épiques et US. Grâce à l'approche en "story points" et "planning poker", nous arrivions à définir le temps requis pour chacune.
Nous avons rédigé un cadre de "règles" pour notre coopération. En plus, chaque release possédait ses propres règles et protocoles d'acceptation.
Pour chaque release, une équipe d'analystes et de consultants définissait le périmètre, conduisant au “Release Product Backlog”. Il contenait tous les cas d'utilisation à implémenter avec les critères d'acceptation attendus et la "Definition of Done" pour chaque cas d'utilisation. Grâce à cela, nous savions exactement ce qu'il fallait faire et quand c'était vraiment fait. Cela constituait la définition de release.
C'est alors que l'équipe de développement découpait la release en user stories plus détaillées. En couplant cela aux priorités du Product Owner, nous avions le planning de l'itération, formalisé par "l'accord d'itération". A cela, l'équipe définissait pour chaque itération la vélocité attendue, qui était l'un des indicateurs de réussite de l'itération.
Durant le développement, le Product Owner était régulièrement informé de l'avancement et les experts des domaines étaient intégrés avec d'autres, pour éclaircir certains points, vérifier le design des interfaces et pour tester ou changer les fonctionnalités.
Chaque release était testée par le client, d'après les tests d'acceptation définis. Si le client confirmait que la release était "done" à plus de 85%, le projet continuait, la release devait être payée et le planning de la suivante commençait. Le travail restant était ajouté à la release suivante. Cela menait à l'approbation du protocole d'acceptation de la release, un document nécessaire aux services financiers du client pour le paiement.
Grâce au très bon niveau de coopération, le niveau d'acceptation dépassa largement les 85% pour chaque release.
L'accord cadre définissait les dates de début et de livraison de chaque release, ce qui obligeait tous les participants au projet à s'y maintenir. Changer une date ne pouvait pas se faire, pas plus que le budget de chaque release (aussi bien cible que plafond). La seule latitude était le périmètre, c'est-à-dire le nombre de fonctionnalités à réaliser.
La manière dont le Contrat a soutenu le Projet en Réalité
Quand le client nous approcha avec son RFP, nous n'étions pas à l'aise du tout avec ce projet. Le risque était bien trop grand. Grâce à cette phase contractuelle, il devint gérable. En fait, le grand projet fut divisé en dix petits, qui étaient recontractualisés chaque fois. L'avantage d'un tel fonctionnement était que toutes les parties prenantes devaient se rencontrer régulièrement pour vérifier l'avancement du projet et ajuster l'approche si nécessaire. La satisfaction client était mesurée en continu. Cela bureaucratisa un peu le processus, et le rendit plus prédictible. Cela réduisit fortement les risques projets des deux côtés.
Tous ces avantages furent aussi perçus par les clients. Ils comprirent qu'ils avaient besoin d'un peu plus d'agilité pour atteindre leurs objectifs et éviter la sclérose quand il fallait introduire des changements durant le processus de développement. Ce contrat leur apporta les éléments essentiels pour gérer leurs processus administratifs, tout en conservant le développement agile du projet.
L'accord cadre resta inchangé durant tout le projet. Des ajustements à la marge furent effectués sur les documents utilisés pour mieux correspondre aux besoins du client et de l'équipe.
Le contrat fournit une direction claire au projet et posa bien le terrain de jeu. En s'appuyant sur le contrat, nous pouvions pousser le Product Owner à fournir les éléments dans les temps, à avoir les critères d'acceptation à l'heure, etc. Régulièrement, nous devions rappeler les obligations contractuelles de chacun, mais uniquement pour maintenir la concentration de l'équipe sur la livraison du projet à l'heure et dans le budget.
Le contrat nous aida également à être payés pour le travail fait. Il posait clairement les moments où il fallait payer les parties du projet et le client remplit ses obligations suivant le plan dans la majorité des cas.
Nous avons décidé en interne d'inclure le niveau de satisfaction client dans les incitations de certaines personnes clés de l'équipe de développement. Cela sembla très stimulant.
Flexibilité dans les Coûts sous Contrôle Permanent - Est-ce possible ?
Interactions fréquentes des deux côtés et tests réguliers de nouvelles fonctionnalités du système sont rarement pratiques pour l'introduction de changement au périmètre initial. Ce n'est généralement pas possible dans les gestions traditionnelles de projet - chaque changement menant à une augmentation du coût total ou à des longues discussions entre les parties pour vérifier si une fonctionnalité a déjà été suffisamment bien définie et peut sortir de la documentation initiale.
Sachant que durant le développement, les idées sur le système optimal changeront (et elles changent !), le client est autorisé à ajuster à la fois le périmètre et les priorités des releases / itérations. Tant que cela reste budgétairement neutre, il n'y a pas de problèmes. Du fait de nouvelles perspectives durant le développement, de nombreuses demandes aboutirent à l'accroissement du périmètre et du budget. Heureusement, la date de livraison ne bougea pas. L'équipe de développement parvint à ajouter des ressources supplémentaires quand cela fut vraiment nécessaire. Ceci permit au client d'explorer de manière empirique les fonctionnalités ajoutant le plus de valeur. Ils furent capables d'ajuster la plateforme à leurs vrais besoins.
Une solution bien ajustée et à l'heure
Grâce à l'approche choisie, nous avons pu montrer les premiers résultats - une interface utilisateur fonctionnelle - après la première itération (2 semaines). Après 2 mois, nous avons commencé à déployer la première partie du système et les utilisateurs ont pu le remplir avec des données de production. A ce moment là, le contrat n'était toujours pas signé.
Pour le client, ce mode de fonctionnement signifiait qu'il pouvait commencer à utiliser des morceaux du système très tôt, plutôt que d'attendre la première livraison planifiée. C'était un soulagement pour leur planning business. De plus, il pouvait immédiatement ajuster le système d'après les retours d'expérience. L'ensemble du processus métier étant neuf, il ne savait pas exactement à quoi s'attendre.
A chaque release, de nouveaux participants (côté client) ont été introduits. Les représentants des utilisateurs finaux validaient le système et remontaient des retours intéressants, ce qui a permis à l'équipe de développement d'affiner le système et de reprioriser certaines fonctionnalités.
Cette approche permit non seulement de livrer un système stable et opérationnel, mais aussi de l'optimiser en ne livrant que la plus forte valeur.
Grâce aux livraisons itératives, le système était souvent testé. Le volume total de bugs et problèmes potentiels a été considérablement réduit du fait de tests automatisés permettant à l'équipe de vérifier la rétro-compatibilité.
Chaque itération finissait par le déroulement de plusieurs séries de tests automatisés couvrant les versions antérieures du système - pour vérifier que la nouvelle version ne remettait pas en cause les fonctionnalités existantes. De plus, de nouveaux tests automatisés étaient créés pour couvrir les nouvelles. En plus, les utilisateurs finaux testaient chaque itération.
Ceci transforma l'acceptation du système complet en une simple formalité.
Conseils pour la Contractualisation Agile
Suivant le type de coopération, le client peut demander un contrat "bureaucratique". Nous pensons que cela ne doit pas gêner la coopération Agile. Prenez le temps de construire une compréhension mutuelle des besoins/demandes, du périmètre exact du projet, de l'approche, etc. Définissez les besoins sous forme de User Stories, car cela stimule chacun à décrire les fonctionnalités dans un langage plus compréhensible que d'habitude.
Convaincre les représentants peu engagés dans le projet peut parfois ressembler à une mission. Ne les "attaquez" pas, car il vous faudra saisir qu'ils ne comprennent pas vraiment ce que signifie une approche Agile. En général, ils veulent sentir qu'ils gardent le contrôle, et il vous faudra leur expliquer comment ils peuvent aussi contrôler un projet Agile.
Petit à petit, en travaillant ensemble, la confiance grandit des deux côtés, ce qui profite à tous.
Avec le client, nous avons accepté un petit peu d'administratif dans le projet Agile. Nous l'avons limité à du reporting que le responsable projet pouvait gérer. Cela consolidait la gouvernance du projet dans une vision plus traditionnelle, nécessaire à l'organisation interne du client. L'équipe de développement ne fut jamais perturbée, développant la solution en Scrum. A la fin, quasiment tout le budget plafond fut utilisé, ce qui honnêtement, ne nous surprit pas. Nous nous y attendions. Un budget additionnel pour de nouveaux développements et un accord de maintenance à long terme rendirent cet investissement intéressant pour les deux parties. Notre client fut vraiment très content d'avoir une solution opérationnelle spécifique dans les temps et dans les limites du budget convenu.
D'après la description de ce projet, nous concluons qu'il est possible de développer un énorme projet en Agile en le découpant en petits morceaux. Cela prend du temps de le définir et de préparer le contrat, mais l'effort est récompensé. En passant beaucoup de temps ensemble au début du projet, nous avons compris nos désirs et besoins réciproques. Cette compréhension mutuelle forgea une confiance partagée avec le bon niveau de coopération, et ceci grâce au temps investi en amont.
Et maintenant, nous pouvons dire que Mandela avait raison.
A propos des Auteurs
Paweł Bejger est un architecte Microsoft .NET basé à Gdansk, Pologne, où il est le directeur des opérations de Goyello, une entreprise de développement logiciel. Il cherche toujours (et crée) la manière la plus efficace de travailler pour satisfaire à la fois l'équipe de développement et le client. En tant que Certified Scrum Professional, il est un vrai porte-parole de Scrum.
Peter Horsten est un entrepreneur Hollandais basé à Gdansk, Pologne, où il est co-fondateur de Goyello, une entreprise de développement Agile. Ingénieur en électrotechnique et diplômé de sociologie, il cherche toujours les solutions (IT) qui correspondent le mieux à l'organisation. Il déploya Scrum chez Goyello en 2009 et est un vrai porte-parole de l'agilité depuis.