Rédiger des contrats est un élément clé pour les équipes de commerciaux impliqués dans des projets agiles. Dans des projets utilisant une méthodologie traditionnelle, les entreprises ont initié deux types de modèles de contrats populaires :

Prix fixe
T & M (Temps et Matériels)

Lorsqu’ils travaillent sur un contrat à prix fixe, les éditeurs examinent les exigences puis s’engagent sur un prix avec le client. Très souvent, le client fixe un prix et l’éditeur qui s’engage sur ce prix remporte le projet.

Crédit Photo : http://www.construx.com/Page.aspx?cid=1648

Les incertitudes innées au développement logiciel rendent ce modèle inepte. Comme le démontre le célèbre et bien documenté Cône d’incertitude, l’estimation initiale faite au début du projet peut être sur ou sous-évaluée de 400 % par rapport au coût réel calculé à la fin. Afin d’atténuer ces risques incertains, les entreprises participants à ce type de contrats doivent ajouter tout un tas de dispositifs non scientifiques pour s’en accommoder.

Les projets appliquant les méthodologies agile sont supposés être associés à un flux d’exigences. Le périmètre peut changer n’importe quand, cela doit être pris en compte dans le contrat, et ce n’est pas évident. C’est une des raisons pour lesquels les contrats à prix fixe ne sont pas très populaires dans les projets agiles. Bien qu’il existe plusieurs études de cas de son utilisation dans des projets agiles, il en résulte à la fin que les contraintes imposées par le modèle à prix fixe peuvent détruire l’agilité.

Temps & Matériels (T&M) comme son nom peut le laisser supposer, ce modèle est censé bien fonctionner avec le développement agile de logiciel, aucune restriction n’existant sur le prix ou sur le périmètre. Le client continue à payer aussi longtemps que de la valeur est livrée. Toutefois, mon expérience montre que ce modèle fonctionne bien dans un environnement de confiance.

Plusieurs expériences ont été faites sur la création de contrats spécifiquement adapté aux environnements agiles. Certains d’entre eux incluent :

1. Livraison par phase
2. Basé sur la capacité
3. Basé sur la valeur

Les contrats à livraison par phase divisent le cycle de vie du projet en plusieurs phases différentes. Un objectif est fixé pour chaque phase et les fonds sont versés à la livraison. L’objectif pourrait être le nombre de user stories à livrer pour chaque phase accompagné d’informations additionnelles liées à la qualité. Les contrats basés sur la capacité affecte un nombre X de personnes pour le projet et aucune contrainte liée au périmètre de la livraison n’est signée. J’envisage aussi le contrat basé sur la livraison de valeur, et je ne suis pas certain que quelqu’un l’ait déjà expérimenté. Je pense que, soit la valeur monétaire soit une quelconque autre unité pourrait être assignée à des épiques ou à des thèmes. Les conditions et calendriers de livraisons seraient proportionnels aux montants des fonds à verser. De nouveau, des critères de qualité pourraient être une clause supplémentaire du contrat. Un agiliste a établi une liste 10 styles de contrats agile existants. Consultez ce lien pour plus d’informations.

En résumé

Je crois fermement que la confiance et le contrat sont inversement proportionnels l’un à l’autre. Autrement dit, moins nous avons confiance, plus nous avons besoin d’un contrat.

Confiance∝ Contrat

Auteur : Venkatesh Krishnamurthy
Source : Agile Contracts
Date de parution originale : 1er Novembre 2011

Traducteur : Nicolas Mereaux
Date de traduction : 15/10/2013

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.