Contrats agiles

Au début des négociations, le client et le prestataire de services décident de l'ensemble exhaustif des exigences qui doivent être satisfaites pour que le projet soit considéré comme achevé. Le contrat est également rédigé en partant du principe que le logiciel sera développé de manière séquentielle. Dans ce modèle de développement, la vision, les spécifications, l'architecture, le développement et les tests sont réalisés dans le cadre d'un processus défini. Par conséquent, toute demande de modification entraîne un effet d'entraînement qui remonte jusqu'à l'architecture, ce qui nécessite de nombreux remaniements et génère du gaspillage.

Au fur et à mesure que le produit est développé et que le client se fait une idée plus précise de la manière dont il sera utilisé, il demande une modification. L'équipe de développement est interrompue par ces nouvelles idées, ce qui la ralentit et prolonge la durée du projet. Les coûts augmentent et la date de livraison est repoussée. Ces modifications du champ d'application entraînent 75% de dépassements de coûts. En réaction, les entreprises ont mis en place des comités de contrôle des changements internes qui limitent les modifications du champ d'application (et les coûts correspondants). Malheureusement, ces comités ont pour effet secondaire de ne pas inclure dans le produit final des fonctionnalités nécessaires et agréables à utiliser.

Scrum s'appuie sur un développement itératif dans lequel une fonctionnalité individuelle est conçue, construite, testée et livrée au cours d'un sprint, ce qui permet de créer de la valeur d'un sprint à l'autre. Cette méthode est fondamentalement différente d'un processus défini et constitue le concept de base qui permet aux équipes de Scrum de faire face au changement au fur et à mesure qu'il se produit.

Au lieu de rédiger un plan qui comprend l'ensemble du projet, le processus Scrum commence par un plan d'action. Backlog de produitIl s'agit essentiellement d'une liste de toutes les fonctionnalités qui pourraient être incluses dans le produit final. Étant donné que 80% de la valeur d'un projet se trouve dans seulement 20% des fonctionnalités, l'équipe Scrum commence par travailler sur les fonctionnalités les plus importantes. Toutes les fonctionnalités sont terminées à la fin de chaque SprintLes caractéristiques les plus importantes sont : conçues, écrites et testées. Au cours du sprint suivant, les fonctionnalités les plus intéressantes sont travaillées et achevées. Ces fonctionnalités s'ajoutent les unes aux autres jusqu'à ce que la valeur accumulée soit suffisante pour lancer la première version du produit. Le carnet de commandes est élaboré en étroite collaboration avec le client afin que le fournisseur et le client aient les mêmes attentes.

Changer gratuitement : Toutes les fonctionnalités n'étant pas équivalentes, si un client décide de modifier ses priorités ou d'ajouter de nouvelles fonctionnalités, il peut le faire. Les Product Owner insérerait simplement la fonctionnalité demandée dans le Backlog du produit, le cas échéant. Cela ne ralentit pas le processus de développement et n'interrompt pas l'équipe, car celle-ci se concentre sur l'achèvement du projet en cours. Backlog de sprintqui est fixé pendant le sprint. Le client n'est pas facturé pour ce changement, à condition qu'il indique quelle fonction moins prioritaire d'une valeur en points équivalente doit être supprimée. Comme le montre clairement la diapositive ci-dessus, 65% des fonctionnalités ne sont jamais utilisées, de sorte que le choix est généralement facile. Le changement est gratuit parce que l'étendue du travail reste la même.

De l'argent pour rien : Étant donné que Scrum réalise des projets par tranches de fonctionnalités, une fois que le fournisseur a fourni suffisamment de fonctionnalités prioritaires pour que le client soit satisfait du produit, le processus de développement peut s'arrêter. Toutes les fonctionnalités qui faisaient partie du champ d'application initial du contrat mais qui n'ont pas été développées (parce que le client s'est rendu compte qu'elles n'étaient pas nécessaires) sont laissées inachevées. L'argent restant est partagé entre le client et le fournisseur, c'est-à-dire de l'argent pour rien. Le contrat doit préciser le pourcentage de l'argent restant qui revient à chaque partie. Il peut s'agir d'un partage 50-50, mais en fonction de la relation et du niveau de confiance entre le fournisseur et le client, le partage peut aller jusqu'à 75-25 dans un sens ou dans l'autre.

La participation des clients devrait inclure

• Hiérarchisation des fonctionnalités en fonction de leur valeur commerciale, en collaboration avec le Product Owner et l'équipe
• Accepter des devis pour tous les travaux. Scrum mesure la production en Des points et non des heures. Le représentant du client doit comprendre ce processus et être présent lors de l'estimation.
• Participer aux réunions de planification du sprint en discutant des fonctionnalités sélectionnées avec l'équipe. Le représentant du client doit être présent pour apporter des précisions à l'équipe si nécessaire.
• Aider à rédiger les conditions de satisfaction pour chaque fonctionnalité, afin que l'équipe et le client aient une définition commune du moment où une fonctionnalité est satisfaisante. Terminé.
• Faire partie de chaque Revue Sprint et fournir un retour d'information en temps utile, tant pour les travaux en cours que pour les travaux achevés.

Tous les clients ne se sentent pas à l'aise à l'idée de participer aussi activement au processus de développement. Plus un client est disposé à participer, meilleur sera le produit. Toutefois, si le Product Owner est en mesure d'obtenir régulièrement un retour d'information de la part du client et de jouer un rôle actif au sein de l'équipe, un client moins impliqué ne ralentira pas forcément les choses. Il s'agit de s'assurer que la vision du produit est bien représentée dans le processus de développement. C'est la raison pour laquelle un Product Owner performant est extrêmement précieux et que ce rôle ne devrait jamais être sous-doté en ressources. Payer pour un Product Owner de qualité vous rapportera.

Le prestataire s'engage à :

• S'engager à fournir la partie du projet que le client souhaite en fin de compte. (Ceci est basé sur l'idée que 80% de la valeur est livrée par 20% des caractéristiques).
• La clause "Money for Nothing" ne peut être appliquée que si le client maintient sa participation à l'équipe Scrum pendant le projet et si le fournisseur livre, à la fin de chaque sprint, des fonctionnalités complètes qui satisfont le client.
• Si les deux parties ne parviennent pas à se mettre d'accord sur les estimations de travail ou si le client ne maintient pas sa participation à l'équipe Scrum, le contrat redevient un contrat traditionnel de facturation du temps et du matériel.

Télécharger l'exemple d'appel d'offres Agile Scrum Inc.