Il te sera d’une aide précieuse pour mener avec succès cette phase d’avant-vente agile. D’autres articles vont suivre où tu vas découvrir tout ce qu’il te faut, depuis la compréhension des besoins du client jusqu’à la signature du contrat, en passant par les estimations. C’est vraiment l’outil indispensable pour toi !
Peut-on appliquer la méthodologie agile à tous les projets ? Cette question sera explorée dans cet article. Nous aborderons principalement les points suivants :
- Les diverses approches contractuelles agiles.
- Les principes fondamentaux intégrés dans un contrat agile.
- L’utilisation d’un outil d’évaluation de l’approche agile
- Les phases contractuelles du projet.
À la fin de cet article, tu disposeras d’outils significatifs pour collaborer avec ton client afin de prendre des décisions importantes concernant le type de contrat à établir, que ce soit en régie ou au forfait, ainsi que la méthodologie à suivre, qu’il s’agisse d’une approche séquentielle (Cycle en V) ou itérative Agile.
Extrait du Manifeste Agile
Approches Contractuelles Agiles
Dans un projet Agile, les équipes du CLIENT et du PRESTATAIRE collaborent de manière étroite pour rapprocher les équipes de développement des équipes métiers. Les rôles et les responsabilités du CLIENT et du PRESTATAIRE évoluent en fonction des contextes.
Néanmoins, le contrat demeure un élément essentiel pour établir la relation entre le CLIENT et le PRESTATAIRE :
- L’engagement de moyens (en régie) demeure la forme contractuelle la plus simple pour initier un projet Agile. La responsabilité de démontrer la non-conformité à l’engagement incombe au CLIENT.
- L’engagement de résultats (en forfait) répond au besoin de garantir un résultat spécifique dans un budget prédéfini. La responsabilité de démontrer le respect de l’engagement repose sur le PRESTATAIRE.
- L’objectif est de concevoir un contrat Agile qui inspire confiance aux DEUX PARTIES quant à leur capacité à honorer les engagements réciproques tout en respectant les valeurs et principes du Manifeste Agile.
Il n’y a pas de contrat Agile standard qui convienne à tout le monde, car il y a deux problèmatiques principales :
- C’est compliqué de dire exactement ce qui va changer en cours de route.
- C’est dur de s’engager pleinement dans la collaboration.
En général, on commence souvent un projet avec un type de contrat classique :
- Un contrat en régie (où le CLIENT prend les risques en s’engageant sur les moyens).
- Un contrat au forfait (où c’est le PRESTATAIRE qui prend les risques en garantissant des résultats).
Dans les deux situations : Le produit n’est pas le point central du projet, et l’intérêt mutuel n’est pas préservé en l’absence d’une répartition des risques équitable.
Le contrat Agile doit être conçu pour que les avantages et les risques soient mieux partagés lorsque nous travaillons ensemble pour créer le produit. Cela se fait en morcelant le travail en petites étapes appelées sprints et en validant rapidement ce que nous faisons.
Voici une liste de critères à prendre en compte lors de la décision du mode de gestion de projet qui convient le mieux à votre situation, que ce soit en optant pour un contrat en régie, un contrat au forfait, ou en adoptant une approche agile.
| Possibilité de | Régie | Forfait | Agile |
|---|---|---|---|
| Modifier le budget | Oui | Non | Oui |
| Changer le périmètre | Oui | Via Avenant | Oui |
| Produit intérmédiaire | Non | Non | Oui |
| Sélection des ressources | Oui | Non | Oui |
| Collaboration | Limitée | Moyenne | Forte |
| Risque porté par | Client | Prestataire | Client et Prestataire |
| Contraintes | Coût | Coût + Délai + Périmetre | Coût + Délai |
LE PRESTATAIRE
Engagement de Délai et Budget
Les exigences du produit sont définies (granularité, limites, coût) pour un budget et un délai fixe
A chaque fin de sprint :
- Evaluer l’adéquation de l’incrément produit avec vos enjeux
- Encourager l’intégration de nouvelles exigences, en remplacement d’autres moins prioritaires.
Livraisons Fréquentes et de Qualité
Chaque itération crée une version intermédiaire de qualité, pouvant si nécessaire être mise en production. Pas de compromis sur la qualité.
Visibilité et Collaboration
Partage conjoint en toute transparence de l’avancement du projet : délai, couverture fonctionnelle, risques, tests…
LE CLIENT
Challenge Perpétuel du Besoin
Se donner la capacité d’identifier et prioriser les exigences (si tout est prioritaire, rien n’est prioritaire)
Accepter de repousser dans des versions ultérieures les exigences secondaires ou encore floues.
Disponibilité Maximale
Assurer une forte présence tout au long des itérations:
- Préparer les itérations (contenu, scénarios de recette)
- S’impliquer dans les ateliers de conception
- Assurer un support métier lors des développements
- Recetter rapidement (5j) chaque itération
Capacité de prise de décision
Binôme Product Owner (Prestataire) et Product Owner Proxy (Client) en collaboration permanente pour faciliter la prise de décisions quotidiennes et stratégiques.
Principes Fondamentaux d’un Contrat Agile
Après avoir orchestré la réalisation de plus de 30 projets en adoptant la méthodologie agile, nous avons distillé une série de points essentiels qui devraient être intégrés dans chaque contrat agile:
- Placer le produit au cœur du projet
- Responsabiliser les équipes
- Collaborer efficacement
- Gérer le changement
- Partager les risques
NB: Le mot Unité d’Oeuvre (UO) signifie un jour de développement + tests unitaires
Partager le Product Backlog dès le début du projet
Avantages de mettre à jour le Backlog et le chiffrage avec le CLIENT :
- Être sûr d’avoir une vision initiale partagée du logiciel.
- Mettre le CLIENT en confiance lors du troc d’exigences.
- Avoir une priorisation qui tient compte de la vraie valeur métier.
- Avoir un Backlog qui utilise le vocabulaire métier.
Moyens:
- Product Backlog : Le périmètre du projet est défini par les priorités de ce dernier dans la limite du budget.
- Product Backlog Review : possibilité de réviser le Product Backlog en cours de projet.
Partager la Vision du produit
Dans la planification du produit et des Releases, favoriser une approche horizontale plutôt que verticale. Dans la mesure du possible, prévoir une V1 et une V2 de chaque fonctionnalité.
La tenue du planning est plus importante que la complexité des fonctionnalités à embarquer.
Moyens:
- Comité Roadmap : avant chaque Release (cadrage agile si besoin), revoir la vision et les moyens de l’atteindre.
- Product Backlog Review : ajustement de la Release en cours.
La simplification au centre des préoccupations
Le Product Owner doit proposer des simplifications et challenger celles proposées par l’équipe de développement. Simplifier le produit permet d’arriver plus rapidement à un résultat satisfaisant et laisse la latitude suffisante à accueillir de nouvelles fonctionnalités plus prioritaires.
Moyens:
- Ateliers technico-fonctionnels : l’équipe de développement doit proposer des simplifications des fonctionnalités ou des moyens de rester dans le natif du produit.
- Product Backlog Review : ajustement des coût le cas échéant.
Acter la livraison à chaque sprint
Chaque sprint se termine par un Sprint Review qui fait l’objet d’une démonstration afin de susciter des feedback des PARTIES prenantes et de constater l’avancement (Done).
Moyens:
Un PV de livraison est émis à chaque Sprint qui mentionne les fonctionnalités livrés et les UO associés.
Recette provisoire de chaque Sprint
La recette doit démarrer au plus tôt : à l’intérieur du Sprint pour l’équipe, dès la réception du Sprint pour le CLIENT. La qualité n’est pas négociable.
Moyens:
- Responsabilité du Product Owner de vérifier la qualité du produit même dans le cas où il délègue une PARTIE de la vérification à un Quality Analyst du PRESTATAIRE.
- Obligation du CLIENT de tester chaque Sprint livré et de prononcer la recette avant le Sprint suivant.
- Un PV de recette provisoire est émis à chaque recette de Sprint.
- Suivi du taux de défaut (inclus au Plan Projet).
Importance du Product Owner
Le Product Owner est le principal décideur sur le projet et facteur de réussite:
- Maîtrise les enjeux du produit et les spécificités du métier.
- A la délégation de prise de décision.
- Est disponible pour être capable d’arbitrer, de décider dans des délais courts (< 1j en moyenne)
- Sait renoncer à des exigences (accepte le principe de troc)
Moyens:
- Product Owner : Le CLIENT s’engage à mettre à disposition un Product Owner avec les qualités requises.
Excellence des équipes
L’équipe du PRESTATAIRE doit être fortement impliquée sur le projet. Selon l’expérience du CLIENT sur des projets Agiles, le Scrum Master du PRESTATAIRE peut vite devenir essentiel à la bonne tenue du projet. Généralement, 1 ou 2 ingénieurs côté PRESTATAIRE sont aussi indispensables à la réussite technique du projet.
Moyens:
- Indiquer dans les conditions particulières, les membres clefs de l’équipe nécessaires à la réussite du projet : ces membres ne pourront pas être remplacés sans approbation du CLIENT sur le nouveau profil (plus délai de prévenance important)
- A contractualiser seulement à la demande du CLIENT avec une clause réciproque sur les acteurs clés du CLIENT.
Disponibilité du CLIENT
Un projet Agile demande un investissement humain important du CLIENT – notamment du Product Owner et des acteurs de la recette.
Le CLIENT doit fournir des ressources de préférence à temps plein.
Moyens:
- Indiquer dans les conditions particulières, la charge estimée des profils types requis à la bonne exécution du projet.
Niveaux de services
Des indicateurs de niveaux de services sont mesurés tout au long du projet comme la vélocité, la qualité, …
Certains niveaux de services peuvent être définis pour mesurer la qualité et la cohésion de l’ensemble des équipes (PRESTATAIRE et CLIENT)
Moyens:
- Le PRESTATAIRE s’engage à réaliser les prestations dans le respect des Niveaux de Service définis dans le Plan Projet.
- Les niveaux de services sont définis lors du Sprint zéro, puis sont validés dans la phase de calibrage du projet.
- Les niveaux de services peuvent permettre principalement de mesurer la performance des équipes du PRESTATAIRE et aussi du CLIENT.
Devoir de transparence
Tous les projets informatiques sont susceptibles de connaître des difficultés non identifiées lors de la conclusion du contrat. Chacune des PARTIES s’engage à la plus totale transparence vis-à-vis de l’autre PARTIE en ce qui concerne les difficultés qu’elle pourrait rencontrer, qu’elles soient techniques, financières, humaines, organisationnelles ou logistiques.
Moyens:
- Chaque PARTIE s’engage à informer l’autre PARTIE de toute difficulté qu’elle rencontrerait, et qui serait de nature à perturber la bonne exécution des prestations, dans le plus bref délai à compter de la connaissance de cette difficulté
- En cas de difficulté, les PARTIES rechercheront en toute bonne foi une solution pour surmonter cette difficulté en respectant l’équilibre du Contrat ou pour partager les risques afférents équitablement
Proximité des membres de l’équipe
Les équipes doivent être proches – et si possible dans les mêmes locaux.
En cas de site distant (Offshore, Nearshore), le Product Owner doit rencontrer les équipes le PRESTATAIRE à chaque Sprint.
Moyens:
- Indiquer le lieu de la prestation dans conditions particulières
- Prévoir d’aménager un espace dédié pour l’équipe projet
- Si ce n’est pas possible, prévoir suffisamment de points de rencontres, et les déplacements doivent s’effectuer vers l’équipe de Développement
- Si possible, sortir les frais de déplacement du budget et les refacturer au réel
Spécifications en flux tendu ensemble
Pour être efficace, l’équipe de développement a besoin d’entrants de qualité pour couvrir la vélocité de l’équipe.
Moyens:
- Définir un modèle de Spécifications le plus adapté pour le projet au début de projet et le degré de profondeur attendu
- Le Product Owner a la responsabilité d’alimenter l’équipe de développement avec les spécifications validées même dans le cas où il délègue une PARTIE de cette rédaction à un Business Analyst du PRESTATAIRE
- Pour éviter toute rupture de charges, les spécifications du Sprint sont considérées comme validées lors du Sprint Planning. Toute modification ultérieure fera l’objet d’un nouvel item du Product Backlog
Amélioration continue en Rétrospective
Un facteur clef de succès d’un projet Agile est la progression commune des équipes CLIENT et le PRESTATAIRE.
La Rétrospective fait PARTIE des instances incontournables du projet ou l’ensemble des intervenants opérationnels doivent être réunis.
Moyens:
- Les plans d’actions issus de ces rétrospectives doivent être pris en charge de façon commune entre le PRESTATAIRE et le CLIENT
- Le CR (compte rendu) de rétrospective doit être présenté en Comité de Pilotage. Les problèmes récurrents seront traités en Comité de Pilotage.
Engagement en Unités d’Œuvres
Le CLIENT peut ajouter ou modifier des fonctionnalités en renonçant à d’autres fonctionnalités jugées moins importantes pour garder son budget projet inchangé.
Moyens:
- Engagement du PRESTATAIRE sur un nombre d’Unités d’Œuvres à produire dans un délai donné.
- Système de troc d’Unités d’Œuvre basé sur les priorités du Product Backlog.
Engagement en Sprint Planning
L’équipe le PRESTATAIRE et le CLIENT ont la possibilité de challenger régulièrement le chiffrage en UO soit par comparaison avec les abaques existants soit en proposant des simplifications.
Moyens:
- Le Sprint Planning constitue l’engagement du chiffrage en UO des items retenus pour le Sprint.
- Seuls les items terminés sont comptabilisés dans la Vélocité du Sprint.
- Toutes modifications ultérieures concernant un item embarqué en Sprint Planning sera considéré comme un nouvel item du Product Backlog à prioriser et chiffrer.
Chiffrage des demandes
L’équipe du PRESTATAIRE est responsable du chiffrage des demandes du Product Backlog qui doit être justifié auprès du Product Owner. La méthode de chiffrage doit être définie en toute transparence avec le CLIENT.
Moyens:
- Définir en sprint 0 la méthode de chiffrage des éléments du Product Backlog (inclus au Plan Projet)
- Dans le cas d’ajout ou de modification, le Product Backlog initial sert d’abaques en comparant des fonctionnalités de complexité similaire.
- 1 Unité d’Oeuvre correspond à 1 jour de codage et test unitaires par défaut.
Clauses de sorties anticipées
Un projet agile doit s’effectuer dans une collaboration des 2 PARTIES tout au long du projet dans l’intérêt du Produit.
Le CLIENT pourra décider à tout moment que le projet a atteint des objectifs suffisants pour correspondre à ses besoins.
Le PRESTATAIRE pourra décider de résilier le CONTRAT en cas de rupture économique.
Moyens:
- Sortie sur atteinte anticipée des objectifs, le CLIENT doit avoir la possibilité de sortir du projet avec un partage gagnant/gagnant des UO non consommées (plusieurs cas sont prévus)
- Clause de rupture économique pour le PRESTATAIRE basée sur la Rentabilité prévisionnelle (Vélocité / jours consommés) : seuil à définir.
- Délai de prévenance de sortie anticipée = 2 sprints.
Réversibilité sortante
A la fin du projet ou dans le cas d’une sortie anticipée, le CLIENT ou un tiers repreneur doivent être capable de continuer à développer le produit
Moyens:
- Engagement du PRESTATAIRE de proposer un devis de réversibilité à la demande du CLIENT
Clause de sortie à l’issue du lancement
La phase de cadrage (sprint 0) est une phase essentielle pour préparer le développement et s’assurer que le projet est sur de bons rails. Si la vision produit n’est pas concluante ou si les équipes ne partagent pas les valeurs agiles, la sortie de projet en fin de lancement est envisagée.
Moyens:
- Définir les critères d’acceptation du sprint 0 (lancement)
- Dans le cas où les critères ne sont pas respectés, possibilité de prolonger le sprint 0 ou de sortir du contrat
Calibrage des niveaux de services
La vélocité de l’équipe de développement se stabilise à l’issue des 3 premiers sprints après amélioration continue
Moyens:
- Engagement définitif du PRESTATAIRE sur les niveaux de service (dont la vélocité) à l’issue des 3 premiers sprints
Performance solidaire
Principe de partage des gains/pertes entre le CLIENT et le PRESTATAIRE par rapport aux objectifs de niveaux de service
Moyens:
- Objectifs définis sur les niveaux de service dans le Plan Projet
- Objectifs spécifiques au Produit
- Clause de Bonus/Malus
Facturation
Pour soutenir le processus Agile, il est intéressant d’établir un échéancier de paiement uniquement sur les fonctionnalités qui ont été livrées conformes
Moyens:
- Au forfait, la facturation se fait par sprint au prorata des UO livrées
- Au régie, la facturation se fait au temps passé
Outil d’Evaluation de l’Approche Agile
Tous les projets ne se prêtent pas nécessairement à la méthodologie agile, et parfois il est préférable de ne pas les aborder en mode agile. Dans de nombreux cas, il est préférable de maintenir une approche plus traditionnelle, telle que le cycle séquentiel en V. Dans cette approche, on commence par définir en détail le produit, puis on passe à la phase de développement, suivie de la phase de validation.
Le tableau ci-dessous présente une série de critères : si le curseur se trouve du côté droit, cela suggère qu’une approche agile peut être envisagée, tandis que s’il se trouve du côté gauche, une approche séquentielle classique est préférable.
| Critère | Cycle en V | Poids Méthodologie | Itératif Agile |
|---|---|---|---|
| Vision | Claire / Partagée |  |
Floue |
| Périmètre | Détaillé / Précis |  |
Mouvant / Flou |
| Exigences | Stables |  |
Informelles |
| Prise de Décision | Longue / Collective |  |
Rapide / Centralisée |
| Disponbilité Client | Limitée |  |
Forte / Dédiée |
| Taille Projet | < 200jh |  |
> 1000jh |
| Planning | Souple |  |
Time to Market |
| Budget | Modifiable |  |
Figé “Design to cost” |
| Démarche à adopter | Séquentielle / En V |  |
Agile / Itérative |
Phases Contractuelles d’un Projet Agile
Ce tableau synthétise les cinq étapes d’un projet agile, à savoir la phase d’avant vente, le sprint initial de lancement, la phase d’ajustement, la phase d’exécution, et enfin la réversibilité.
Avant Vente
- Définir le budget et le planning du projet à partir du Product Backlog initial basé sur la vision et la roadmap du produit.
- Si les entrants ne sont pas suffisants, proposer un cadrage agile pour définir la vision et la roadmap du produit.
1
Lancement (Sprint Zéro)
- S’assurer que tous les critères prédéfinis sont réunis pour démarrer le développement dans de bonnes conditions, sinon report ou annulation du développement.
Calibrage (sprints 1 à 3)
- Calibrer les niveaux de service de l’équipe de développement pour une amélioration opérationnelle continue.
- S’engager définitivement sur les niveaux de service.
Opérationnel (sprints 4 à N)
- S’assurer que les engagements seront tenus.
- Sinon, prendre les dispositions nécessaires pour respecter les engagements.
4
Réversibilité
- Sur demande du CLIENT, transférer les compétences acquises à un tiers en charge de reprendre la maintenance corrective et évolutive du Produit.
Avant Vente
- Définir le budget et le planning du projet à partir du Product Backlog initial basé sur la vision et la roadmap du Produit
- Si les entrants ne sont pas suffisants, proposer un cadrage agile pour définir la vision et la roadmap du produit
1
Lancement (Sprint Zéro)
- S’assurer que tous les critères prédéfinis sont réunis pour démarrer le développement dans de bonnes conditions
- Sinon report ou annulation du développement
2
Calibrage (sprints 1 à 3)
- Calibrer les niveaux de service de l’équipe de développement pour une amélioration opérationnelle continue
- S’engager définitivement sur les niveaux de service
3
Opérationnel (sprints 4 à N)
- S’assurer que les engagements seront tenus
- Sinon, prendre les dispositions nécessaires pour respecter les engagements
4
Réversibilité
- Sur demande du CLIENT, transférer les compétences acquises à un tiers en charge de reprendre la maintenance corrective et évolutive du Produit
5
Conclusion
Dans ce article, nous avons exploré les deux principales approches contractuelles, à savoir “régie” et “forfait“, ainsi que la manière dont un contrat agile intervient pour placer le produit final au centre du projet tout en gérant et partageant les risques entre le client et le prestataire. Le contrat agile requiert un fort engagement des deux côtés, la responsabilisation des équipes, une collaboration efficace et une capacité à gérer les changements.
Après avoir présenté en détail les principes fondamentaux d’un contrat agile, nous avons mis à ta disposition un tableau d’évaluation de projet pour t’aider à décider de la méthodologie à adopter : séquentielle (cycle en V) ou itérative agile.
Enfin, pour une gestion optimale d’un projet agile, nous avons élaboré un plan chronologique, couvrant la période de l’avant-vente à la réversibilité.
0 commentaires