Contrats agiles - Historique des versions

Fabrice Aimetti le 8 mai 2020 à 11:03

2020-05-08T11:03:54Z

Fabrice Aimetti le 16 avril 2020 à 13:28

2020-04-16T13:28:46Z

Fabrice Aimetti le 16 avril 2020 à 13:28

2020-04-16T13:28:19Z

Fabrice Aimetti le 24 août 2018 à 17:45

2018-08-24T17:45:39Z

Fabrice Aimetti le 24 juin 2018 à 10:54

2018-06-24T10:54:53Z

Fabrice Aimetti : Page créée avec « Category: Portail Contrat-Pilote Category: Venkatesh Krishnamurthy
Auteur : Venkatesh Krishnamurthy
2018-06-24T10:53:02Z

Page créée avec « Category: Portail Contrat-Pilote Category: Venkatesh Krishnamurthy <div id="content_view" class="wiki" style="display: block"> Auteur : Venkatesh Krishnamurthy<br... »

Nouvelle page
[[Category: Portail Contrat-Pilote]]
[[Category: Venkatesh Krishnamurthy]]
<div id="content_view" class="wiki" style="display: block"> Auteur : Venkatesh Krishnamurthy Source : [http://agileworld.blogspot.fr/2011/11/agile-contracts.html Agile Contracts] Date : 01/11/2011 
----
Traducteur : [/Nicolas%20Mereaux Nicolas Mereaux] Date : 15/10/2013 
----
''Traduction'' : 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. [[Image:contrat-cone-of-uncertainty.png|contrat-cone-of-uncertainty.png]] 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 : 

# Livraison par phase
# Basé sur la capacité
# 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. [http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts 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