Enfin un contrat vraiment agile !

 Dans Non classé

Pré-requis à un contrat agile

Qui dit contrat, dit convention. Il est évidemment nécessaire avant toute chose de définir le Vocabulaire qui fera foi tout au long du contrat. Compte tenu des différences importantes entre les concepts classiques et les concepts agiles, ce vocabulaire doit être défini de façon très précise. Il doit également être complété par l’obligation pour les parties prenantes, de connaître les pratiques agiles. Elles devront donc soit justifier de leur bonne connaissance, soit assister au minimum à une introduction à l’agilité d’une demie journée. En préalable, le contrat agile devra donc comprendre :

  • Une liste de définitions pour les termes et les concepts contractuels utilisés dans le corps du contrat;
  • Une clause stipulant l’obligation pour les parties prenantes de connaître les pratiques agiles avant le démarrage des prestations commandées. En cas de nécessité d’introduire l’agilité auprès du Client, une prestation du fournisseur pourra être prévue au contrat.

Contenu du contrat agile

Un contrat agile définira :

  1. L’engagement de résultat
  2. La manière de définir le produit en apportant un maximum de flexibilité
  3. La liberté du client vis à vis des délais sur le projet
  4. La façon dont les budgets peuvent être utilisés et ajustés
  5. La visibilité et la transparence nécessaire à la collaboration Client-Fournisseur
  6. La façon dont la qualité du produit est garantie
  7. Les clauses apportant de la flexibilité au contrat

1. Engagement de résultat

Engagement côté Fournisseur :

Les engagements du fournisseur portent sur la réalisation d’un scope à chaque itération du projet. ce scope est défini par :

  • L’utilisation de 95% de la capacité de production de l’équipe, 5% étant provisionné pour gérer des aléas;
  • Une répartition de 3 types d’activités sur 100% des charges disponibles :
    • Un nombre de points Fibonacci (vélocité) à réaliser en fonction d’une productivité de référence;
    • Un nombre d’anomalies connues à corriger en surveillant le non dépassement d’un seuil d’anomalie de référence;
    • Un nombre de tâches associées ni aux corrections, ni aux fonctionnalités pondérées, à réaliser durant l’itération (gestion de projet, mise en place d’outil…).
  • Une prédictibilité de référence représentant le %  minimum des objectifs d’itération à atteindre en fin d’itération (85% en général) réalisation des 3 types d’activités. Le rendement de la machine à réaliser des produits logiciels en quelque sorte.

En fin d’itération, la prédictibilité réelle est mesurée et comparée à la prédictibilité de référence. Des bonus ou des malus pour le Fournisseur en sont déduits (>85% => Bonus, <85% => Malus). Son calcul repose sur la formule :

% de vélocité + % de tâches prévues réalisées + % de corrections réalisées

Engagement côté Client :

Le Client a obligation de collaborer durant toute la durée du projet sur :

  • Les différents ateliers d’IHM, fonctionnels, techniques …;
  • Les cérémonies agiles (planification et bilan d’itération, Sanity check, Rétrospectives …;
  • Les recettes intermédiaires et la recette définitive;
  • Les comités de pilotage;
  • Les vérifications documentaires;
  • Le suivi de projet.

2. Flexibilité du produit commandé

Product backlog :

Durant la première ‘itération (itération 0), le produit est défini par son Product Backlog (liste de fonctionnalités). Ce dernier peut évoluer à chaque fin d’itération selon les souhaits du Client.

Iteration backlog :

  1. Le scope de la première itération (itération 1) est défini à partir du Product backlog pondéré sur la base de la productivité de référence définie dans le contrat;
  2. Le scope des itérations suivantes est défini à partir de la productivité moyenne des deux dernières itérations;
  3. Le scope de l’itération courante peut exceptionnellement être ajusté via un Sanity check (vérification de la possibilité d’atteinte des objectifs initiaux et ajustement lorsque nécessaire).

Le produit et ses spécifications :

La définition du produit est réalisée au fil de l’eau via divers ateliers

  • Ateliers fonctionnels : compréhension du besoin, fonctionnalités, exigences de performance …
  • Ateliers techniques : architecture cible, choix technologiques …
  • Atelier d’IHM : maquette d’écran, prototype d’IHM …

Des documents complémentaires sont élaborés en suivant.

3. Flexibilité des délais

 Démarrage dun projet :

  • Un démarrage suppose une visibilité de 3 itérations minimum;
  • Le démarrage se fait par une itération 0 qui cadre :
    • La Vision du Client;
    • Le Product backlog : produit à réaliser;
    • Les ressources;
    • La Roadmap produit : planning du projet;
    • Les critères « done » côté Fournisseur et « done done » côté Client pour l’avancement produit;
    • Les indicateurs agiles : hypothèses de départ, productivité, seuil d’an omalie et prédictibilité de référence.

Arrêt du projet :

  • Un projet peut être arrêté par le Client à tout moment en respectant un préavis d’une itération (hors itération courante) => Le budget non consommé est disponible
  • Un projet peut également reprendre à tout moment en respectant un délai maximum de 2 itérations de préavis => affectation de nouvelles ressources

4. Flexibilité des budgets

Un Budget optionnel représentant 10% à 20% du budget ferme permet de prendre en charge des demandes de changements sans changer les clauses contractuelles.

L’impact des changements sur un produit en cours de réalisation sont gérés e la façon suivante :

  1. Suppression de fonctionnalités non démarrées du Product backlog => réintégration de la totalité des points correspondants dans le budget disponible (excepté effet de bord);
  2. Ajout de nouvelles fonctionnalités dans le Product backlog => 20% des charges associées au changement sont déduites du budget disponible (coûts de recueil des besoins, analyse des impacts, chiffrage …);
  3. Suppression de fonctionnalités déjà démarrées => récupération d’un % de points non utilisés en fonction des activités déjà réalisées après déduction d’un forfait de 20% pour analyse et chiffrage des changements.

A chaque changement, le budget disponible est remis à jour.

5. Visibilité et transparence

 Visibilité :

  • Les phases projet (boîte noire) sont remplacées par des itérations courtes de 2 à 4 semaines (boîte blanche);
  • Chaque itération se solde par une démonstration suivie d’une livraison et d’une recette intermédiaire du périmètre livré (produits + documents) => pas d’effet tunnel;
  • Les décisions sont acceptées conjointement et enregistrées systématiquement et leurs conséquences présentées en Comité de pilotage.

Transparence :

  • Le Client doit fournir son cahier de recette partiel correspondant au scope de l’itération courante au plus tard à mi itération;
  • Durant une recette, une relivraison au Client donnera lieu à de nouveaux tests de recette dont la durée ne pourra pas dépasser 20% de la durée de recette précédente sur les tests déjà passés;
  • En cas d’échec d’une recette, la recette suivante prendra au maximum 50% du temps de la recette précédente (hors délai lié à des relivraisons).

La visibilité et la transparence sont totales sur les ressources, les moyens et les compétences.

6. Plus grande qualité produit

 Acceptance :

Suite aux démonstrations de fin d’itération, le Client vérifie et accepte les livraisons, les documents liés au produit et les fonctionnalités livrées.

Anomalie :

  • La correction des anomalies détectées au fil de l’eau est plus prioritaire que la réalisation de nouvelles fonctionnalités, même si ces dernières dont partie des objectifs de l’itération;
  • Un Seuil d’anomalie de référence permet de suivre la qualité des livraisons en mesurant le % de la charge d’une itération consacré à ces corrections (plus ce % est important, moins bonne est la qualité de la livraison précédente);
  • Les anomalies détectées par le Client ou par le Fournisseur sont corrigées au fil de l’eau => optimisation des budgets en minimisant les coûts de corrections;
  • Le nombre d’anomalies connues en fin d’itération ne dépasse jamais 20 anomalies mineures : pas d’anomalie majeure ni bloquante non corrigée en fin d’itération.

Recettes :

  • Les Critères de recettes intermédiaires sont identiques à ceux de la recette définitive;
  • La Qualité du produit en continue via des recettes intermédiaires => fondations solide du produit au fil de l’eau;
  • La Recette définitive du produit final plus courte que dans l’approche classique, du fait des recettes intermédiaire =>cela suppose une implication du Client plus continue;
  • Lors de la recette définitive, les fonctionnalités non encore recettées sont recettées (provenant de la dernière itération) et des tests de non régression sont menés sur les fonctionnalités déjà recettées.

7. Flexibilité du contrat

Les clauses contractuelles peuvent sans avenant être modifiées à chaque Comité de pilotage en enregistrant les décisions prises et les conséquences de ces décisions.

Les engagements de résultats sont ajustés :

  • A chaque fin d’itération :
    • Nouvelle productivité de référence pour le calcul de la vélocité objectif;
    • Décision éventuelle d’itération morte au frais du fournisseur lorsque le seuil d’anomalie de référence est dépassé de façon répétitive ou significative.
  • A chaque fin de release :
    • Nouvelle productivité de référence;
    • Nouvelle prédictibilité de référence;
    • Nouveau seuil d’anomalie de référence.

La collaboration se distingue par l’obligation mutuelle de conseil et d’alerte, ainsi que par un copilotage du projet avec partage des rôles et des responsabilités.

Enfin, l’échéancier de paiement est basé sur l’avancement réel du produit et non sur des phases ou des documents. Il n’est donc pas défini à priori en termes de % ni de montant mais découle directement du % de fonctionnalités livrées et acceptées par le Client (notion de « done done ») à la fin de chaque itération.

Définitions incontournables

Les définitions agiles  incontournables sont au minimum :

  • Termes liés au cycle de vie itératif et incrémental : ItérationRelease;
  • Termes définissant les rôles des parties prenantes : Scrum masterProduct OwnerChef de projetEquipe de réalisation, Utilisateur;
  • Termes liés aux différentes cérémonies mise en œuvre pour piloter les itérations : Plan d’itérationScrum meeting, Sanity CheckDémonstrationBilan d’itérationRetrospective;
  • Termes liés aux concepts agiles : Product backlogIteration backlog,  Burn-down chartValeur métierComplexité FibonacciVélocitéPrédictibilitéProductivité, « Done », « Done done »;
  • Termes liés au produit logiciel et aux tâches associées : User storyTechnical storySpikeEpic, Tâche.

Les définitions plus classiques incontournables sont :

  • Termes liés aux prestations possibles : Lots fonctionnelsRecetteGarantieMaintenance, Réversibilité, Migration de donnéesTransfert de connaissance;
  • Termes liés aux livrables : SpécificationsArchitectureCode sourceTests unitairesTests de validationTests de recette;
  • Termes liés aux anomalies : AnomalieAnomalie bloquanteAnomalie majeureAnomalie mineure

 Morale de l’histoire

Le contrat agile induit un niveau de confiance et une collaboration réelle entre le Client et le Fournisseur. Il prend sa source dans la capacité du Client à accepter de ne pas savoir exactement ce que fera son produit au démarrage du projet, et dans la transparence et la visibilité avec son Fournisseur. La maîtrise du projet et du produit est mesurée en permanence ce qui rassure et permet aux parties prenantes de mieux accepter les bonnes comme les mauvaises nouvelles. La performance globale de l’équipe dans le contexte de copilotage avec le Client est quantifiée à chaque itération et permet de prendre les décisions qui permettent d’améliorer la productivité de l’équipe, de continuer ce qui fonctionne bien et d’améliorer ce qui fonctionne moins bien dans l’intérêt de tous en optimisant l’utilisation des budgets pour faire un produit à plus haute valeur ajoutée.

Hubert GILLON

Commencer à écrire puis appuyer sur Entrée pour lancer la recherche