Une solution agile au problème contractuel des changements
Jusqu’ici, aucune méthode agile ne disposait d’une métrique formelle du changement. Cette notion est pourtant indispensable à la mise en œuvre raisonnable des valeurs de l’agilité dans le cadre des impératifs d’un forfait ou simplement pour sécuriser de nombreuses modifications en cours de développement. Voici une solution formalisée.
Pour être vraiment agile, une méthode de conduite de projet appliquée au développement du système d’information se doit d’être incrémentale, itérative et adaptative. Avec la méthode Scrum par exemple, depuis sa publication en 2001 par Ken Schwaber et Mike Beedle, seul le concept incrémental était mis en œuvre et la modification importante de fonctionnalités en cours de développement était interdite durant le « sprint ». La notion d’itération qui consiste à « revenir sur pour affiner » n’était donc pas supporté ce qui nécessitait un gros travail prédictif initial pour spécifier les fonctionnalités à produire (baklog). Plus récemment, une mise à jour du guide d’utilisation permis de légères modifications en cours de développement à condition qu’elles ne modifient pas les objectifs de l’incrément à livrer. Les méthodes RAD (1991) et XP (1999) étaient parfaitement itératives et s’appuyaient sur la notion de conception émergente pour tenter d’être aussi « adaptative » mais jusqu’ici aucune de ces méthodes ne disposaient d’une métrique formelle du changement. Cette notion était pourtant indispensable pour permettre la mise en œuvre raisonnable des valeurs de l’agilité dans le cadre des impératifs d’un forfait ou simplement pour éviter les incompréhensions entre développeurs et clients en cas de changements importants ou fréquents en cours de développement. Voici donc une solution à ce problème qui a durant des années laissé à penser qu’un forfait agile n’était pas gérable.
Un contrat agile se base sur l'évaluation du périmètre connu à produire avec une technique comme, par exemple, le jeu d'estimation consensuelle ou « planning poker game ». Ce principe exprime en unité d'œuvre, comme les journées idéales par exemple (Ideal Day), un engagement de l’équipe sur le périmètre initial définit. C’est ce périmètre qui fait l’objet du contrat-projet initial. Le contenu fonctionnel peut ensuite être modifié, en permanence et même en cours de développement, par le propriétaire du produit. Chaque modification sera tracée sur la fiche de récit utilisateur (post-it) de la fonctionnalité modifiée ou abandonnée en cours de développement. Les fiches en question seront conservées en bas du « reporting mural » (kanban) dans une zone latérale nommée tout simplement « Abandonné, achevé ou en cours de développement ». Les parties de développement éventuellement réutilisables seront ensuite réintégrées dans l’évaluation formelle des modifications ou des nouvelles fonctionnalités. Dans ce contexte, l’équipe aura pour obligation de livrer en fin d’incrément un nombre d’unité d’œuvre au moins égal à sa vitesse nominale prévue en début de projet (nombre de personnes * nombre de jours ouvrés de travail sur l’incrément). Le nombre d’unité d’œuvre (UE) permettant de présenter graphiquement la productivité obtenue pour chaque incrément (BurnUp chart) se composera alors ainsi : UE livrées au total = UE livrées utiles + UE livrées abandonnées.