Writing a Fixed Contract for an Agile Project

http://www.brighthub.com/office/project-management/articles/125813.aspx écrit par Michael Kirkham-Jones et édité par Michele McDonough

Comment rédigez-vous un contrat au forfait sur une proposition Agile embryonnaire ? Ce n’est pas aussi difficile que certains le font paraître mais cela implique un vrai changement de mentalité et un exercice d’apprentissage pour tout un chacun. Clairement définir « fait » (« done »), évaluer des histoires et comprendre la vélocité sont clés à la réussite.

Ne limitez pas Agile

Si toute l’idée d’Agile est que vous ne pouvez pas prévoir l’avenir, alors comment pouvez-vous l’utiliser dans un Environnement de contrat de forfait où il est essentiel de préciser vos coûts, votre temps et votre contenu de projet ? Peut-être que la réponse est de regarder au-delà de relier Agile à des modèles de contrat mal adaptés et de proposer une nouvelle structure.

OK, donc la chose fondamentale que nous pouvons affirmer de tout ce que nous lisons sur Agile est le fait que les besoins ont vraiment tendance à être très brumeux. Au contraire, le modèle de contrat fixe exige d’un jeu détaillé, stable et précis de besoins, définissant clairement des limites et des pénalités si quelqu’un pose le pied à l’extérieur de celles-ci.

Le faire de façon professionnelle

Comment diable deux animaux si différents peuvent-ils coexister dans le même environnement ? Il y a tant de débat sur comment ceci peut être fait que couvrir chaque idée, pensée ou sentiment nécessiterait des dizaines d’articles. Je pense que ma meilleure approche est de décrire mon expérience et comment je configure un Contrat Agile.

Au tout début d’aborder la question d’Agile et forfait, il était impératif de partir d’une structure logique et professionnelle pour le processus. Je voyais si souvent des présentations où la société a offert une approche de toute évidence biaisée et il n’y avait absolument aucune chance que le projet puisse commencer, encore moins être complété. Mon conseil à toute société travaillant dans le marché de contrat au forfait Agile est de passer du temps à définir votre évaluation, cadencement et l’approche de définition du contenu. Un travail bâclé se sent à un kilomètre.

Alors, comment approchons-nous une proposition de contrat au forfait ? La première chose que nous avons faite a été de regarder le processus Agile que nous avions entrepris et le découper en trois domaines distincts. Sur chacun de ces domaines, nous avons alors passé beaucoup de temps à définir et documenter clairement et précisément le quoi et le comment. Pour nous, cela nous a ouvert une structure complètement différente de notre organisation et a potentiellement ajouté de nouvelles sources de revenu.

Le temps et les coûts dans un contrat au forfait sont raisonnablement faciles à définir et pour Agile l’approche itérative a durée contrainte est très facile à définir. Ceci nous laisse donc seulement avec le problème du contenu/portée/périmètre. Comment pourrions-nous fixer les livrables sans étrangler la méthodologie Agile que nous suivons si fièrement ? Le problème était de changer le concept de contenu en un budget.

Définition de l’élément « contenu » du Contrat

La toute première étape était de collecter les besoins des utilisateurs sous forme d’un arriéré de produit en utilisant des histoires utilisateur pour détailler les attentes des clients. Nous utilisons alors cet arriéré de produit pour prioriser puis évaluer les fonctionnalités en utilisant des techniques d’estimation de groupe comme le « Planning Poker » et donner des valeurs sous forme de points d’histoire « Story Points ».

En allant plus loin dans ce processus nous passons 1 à 2 jours à définir :

• Histoires Utilisateur « User Stories »
• Estimations

« L’histoire utilisateur est une façon d’exprimer des besoins qui sont compréhensibles pour les deux clients et nous-mêmes. Les histoires utilisateur sont rapides à écrire et impliqueront tous les niveaux de la structure d’organisation concernée. Elles sont, plus important encore, orientées fonctionnalité, donc elles peuvent fournir une bonne vue du contenu réel d’un projet et nous pouvons les comparer l’une à l’autre en termes de taille, d’effort « , etc [1]

Pour l’estimation, nous avons tendance à utiliser des points d’histoire par opposition aux jours idéaux ( Je discute de ceux-ci dans mon article sur les Burndown Charts). Il est très important de vous assurer que vous avez une vue très claire de « fait » (« done ») et que vous avez une définition explicite et concrète qui forme le point de contrôle critique du projet agile. Sans une compréhension cohérente de « fait » il sera impossible d’évaluer précisément la vélocité. « C’est aussi une façon de construire la confiance avec le client en ayant un consensus commun quant au processus de projet et sur le critère d’acceptation de haut niveau. « [1]

Ici, nous pouvons maintenant inventer une valeur définissant notre budget de contenu avec des points d’histoire. C’est cette valeur qui est fixée dans le contrat et non Pas les histoires.

Alors, combien cela coûtera-t-il et combien de temps sera nécessaire ?

Avec notre contenu défini nous pouvons maintenant concentrer à établir le prix et la durée. Et, pour ce faire, nous devons regarder la Vélocité de l’Équipe, combien de points une équipe peut-elle réaliser pendant une itération ?

La vélocité de l’équipe est basée sur beaucoup de facteurs, pas seulement combien de travail qu’ils peuvent réaliser. Nos pratiques de travail définissent déjà notre stratégie de communication et nous savons donc combien de temps est passé en réunions planifiées avec l’équipe et le client. Il y a d’autres facteurs à considérer comme les vacances, le volume des tâches, etc. En bout de ligne la vélocité journalière sera un nombre qui est en partie basé sur l’expérience, mais contient pas mal de suppositions (par exemple : si nous sommes en l’hiver, nous pouvons être sûrs que quelqu’un aura la grippe).

Disons par exemple que nous avons calculé que l’équipe peut livrer 30 points d’histoire par itération de 2 semaines et a 240 points d’histoire à livrer (tel que défini dans le contrat). Nous avons maintenant une durée de livraison de 8 itérations nécessitant 16 semaines en tout. Avec 70 heures allouées à chaque itération, une équipe de 5 personnes et un taux horaire de 100 € par membre de l’équipe nous pouvons facilement calculer le prix à 280,000 €.

Donc, maintenant nous avons nos valeurs de contrat fixes :

• Prix 280,000 €
• Temps 16 Semaines
• Contenu 200 points d’histoire

Ces valeurs font tout simplement partie de la procédure tarifaire du contrat et ils ont vraiment tendance à être les chiffres les plus difficiles à atteindre avec un niveau de confiance acceptable.

Ce que nous essayions de montrer ici est que la façon dont nous travaillons sur les projets Agile peut aussi se refléter dans l’environnement des négociations de contrat.

Qu’advient-il si..

… Le propriétaire de produit « product owner » (le client) veut ajouter une autre fonctionnalité ? Nous avons déjà travaillé étroitement avec le client, à définir l’arriéré de produit, évaluer les points d’histoire, donc il connaît la situation actuelle. En cas de demande de travail supplémentaire nous évaluons l’ajout, disons 10 points d’histoire dans ce cas et nous négocions pour soit supprimer 10 points de valeur d’histoire de fonctionnalités agréée soit ajouter une itération de plus. Maintenant que nous avons fixé les points pour le contenu nous pouvons permettre à des changements de se produire, en termes de points. Cela nous permet d’interchanger des besoins en chemin dans la limite de contenu définie. Si nous pouvons rester dans cette limite, nous pouvons aussi rester dans des prix et durée fixes.

… Le client se plaint du prix ? Nous clarifions avec nos équipes de vente que la seule négociation possible dans cette situation est le tarif horaire. Nous ne mettrons pas en péril le projet en essayant d’augmenter la vélocité. Vous ne pouvez pas changer les membres de votre équipe en super-héros en changeant des valeurs sur une feuille de papier.

Et Finalement

Une fois que vous faites signer le contrat et que le travail est en cours, il est impératif que vous managiez vos coûts. Dans mon article sur les Burndown Charts, je discute de comment ceux-ci peuvent être utilisés pour contrôler la vélocité de l’équip. Ils peuvent aussi être utilisés pour contrôler le changement de contenu et les coûts.

Un de mes secteurs de spécialisation est les Contrats au Forfait Agiles, et j’écris et présente sur le sujet régulièrement.

Pour des lecture complémentaires, regardez s’il vous plaît mon Guide to Agile Project Management.

Références

• [1] Les citations viennent de Agilist PM