« Contrats agiles » : différence entre les versions

<br />  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.<br /> <br /> [[Image:contrat-cone-of-uncertainty.png|contrat-cone-of-uncertainty.png]]<br /> <br />  Crédit Photo : http://www.construx.com/Page.aspx?cid=1648<br /> <br />  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.<br /> <br />  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é.<br /> <br /> '''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.<br /> <br />  Plusieurs expériences ont été faites sur la création de contrats spécifiquement adapté aux environnements agiles. Certains d'entre eux incluent :<br />