Le 2ème principe agile

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Bienvenue aux changements. Pas n'importe quel changement.
Avantage compétitif du Client.

Un changement de vision

Dans une approche classique, les exigences sont traduites par un "dossier de spécifications" sensé être complet, parfait.
L'agilité - empirique - va à l'encontre de ce besoin de tout modéliser au début de projet :

  • le déroulement par le plan qualité de plusieurs dizaines de pages
  • le planning par un Gantt de plusieurs centaines d'activités
  • ...

Dans ce cas, un changement est vu comme un trublion.
Qu'en est-il ?
Les exigences sont le résultat d'une maturation.
Comment voulez-vous qu'un Product Owner spécifie parfaitement tout un produit qu'il est en train d'inventer et qui a pour but d'automatiser un savoir-faire probablement lui aussi en cours d'évolution ?
Ce que l'on retrouve dans cette donnée qu'il est bon de garder derrière l'oreille : en fin de vie d'un logiciel le constat est que plus de 60 % des spécifications implémentées l'ont été après la première version.

Émergence des exigences

Ce deuxième principe a pour corollaire un autre principe que nous verrons un peu plus tard et qui pose l'émergence des exigences.

C'est en utilisant le produit que l'on peut mieux le spécifier.


Pratiques

Maintien du backlog

Une pratique essentielle est donc le maintien du backlog produit.
On présente habituellement une itération comme ce qui permet d'obtenir une nouvelle version du produit "potentiellement" déployable.
Or, un backlog réellement à jour est nécessaire en fin d'itération, tout simplement pour mener correctement le prochain plan d'itération (sprint meeting).
Donc... pendant que le PO participe journellement aux développements des stories en cours (spécifications par les tests, passage de tests, conversations..) il maintient également son backlog.
La démonstration (revue de sprint) est aussi un moment privilégié pour recueillir le feedback des participants et ainsi détecter des possibilités d'évolution du backlog.

Planification par la Valeur Métier

L'autre pratique importante ici est la planification par la Valeur Métier, sur des cycles courts. Voir par exemple les pratiques XP :

  • Cycle trimestriel (versions fréquentes)
  • Cycle habdomadaire (itérations).

Une question de choix

Pour certains, cette maturation des exigences est insupportable : "Comment ? On ne sait jamais où on va ?"
Pour d'autres, il est préférable de jouer sur un feedback concret et rapide

  • itération
  • version

et ainsi d'éviter de développer des choses inutiles car envisagées au départ... par ignorance.


Retrouvez tous les billets "Principes agiles".



Changement