L'expérience d'hier m'incite à publier ce billet sur les techniques d'élaboration de besoins en agilité (dans les domaines plus "classiques", on parle d'"Ingénierie des exigences")
Vue fonctionnelle d'ensemble
Dans le Business Value Game, on dispose les user stories de la façon suivante : En haut, de gauche à droite, on place les features (ensemble fonctionnel de haut niveau, autonome et consistant, répondant à la notion de service rendu de bout en bout avec un résultat observable apportant de la valeur... ouf) de gauche à droite, par valeurs décroissantes (voir la notion de valeur expliquée précédemment)
En dessous, on dispose horizontalement les user stories de haut en bas par valeurs décroissantes (valeurs divisées) et verticalement, en face de la feature à laquelle elles appartiennent.
On obtient ainsi une vue matricielle de l'ensemble. On peut alors considérer une "diagonale" bas-gauche/haut-droite en dessus de laquelle se trouve les user stories les plus intéressantes à élire pour le court terme. Évidemment, ce n'est pas le seul critère à prendre en compte (antécédences entre items, investissements techniques etc)
Même s'il existe beaucoup d'autres organisations possibles de ce genre de tableau (par groupe de priorités (MoSCoW), par personas ou utilisateur etc), cette organisation permet en un coup d'oeil de cerner les éléments déterminants à prendre en compte pour optimiser la livraison de valeur.
Techniques de décomposition fonctionnelle
Très fréquemment, on est amené à adopter des niveaux intermédiaires entre la feature et la story. On parle de "Minimal Marketable Feature", qui représente en quelque sorte l'unité de gestion du marketing. Alors que les user stories représentent des unités de gestion de la planification. C'est sensiblement la même problématique que pour splitter une story trop grosse.
Les techniques de décomposition sont principalement guidées par :
- des notions de sous-priorités : est-il intéressant de discerner un sous-ensemble à mettre en priorité ?
- de sous-coûts : est-il intéressant de livrer un sous-ensemble de grande valeur mais de faible coût ?
Pratiquement, on peut guider la découpe en :
- isolant les scénarii nominaux, prioritaires
- isolant les données principales manipulées, prioritaires
Bill Wake évoque la métaphore de la tarte : "Slicing the cake". On coupe une tarte de façon radiale, pas en travers. De la même façon on décompose les features en profondeur plutôt qu'en largeur, dans le sens du "service minimal rendu de bout en bout" plutôt que de saucissonner les features en étapes de workflow successives. Cela a également pour intérêt de solliciter davantage les couches applicatives, donc de plus travailler sur la fiabilité du logiciel immédiatement.
- Exemple : Vous voulez implémenter une fonctionnalité de recherche dans un site web. Classiquement, on veut plusieurs types de recherche : un simple avec un seul champ à saisir et un complexe avec toutes sortes de combinaisons de critères de recherche. Une part de la tarte pourrait être par exemple de n'implémenter que le premier type de recherche, mais jusqu'au bout, c'est-à-dire jusqu'à une page de description de l'article recherché. Ainsi le cycle de recherche est réalisé du début à la fin du service attendu. Une part mal découpée pourrait être par exemple d'implémenter tous les types de recherche, mais en s'arrêtant à l'obtention du résultat de requête de base de données, ce qui représente certainement un intérêt pour le développeur mais ne représente aucune valeur pour le client.
Toutefois, je dois confesser que ma gourmandise pressante m'a souvent poussée à couper les tartes n'importe comment !
A l'inverse, nous avons les techniques de regroupements de stories (rarement au niveau des features car elle sont déjà assez grosses). On considère majoritairement la notion de XP : "Tout prend 4 heures (idéales)". A savoir qu'on regroupe plusieurs stories trop petites pour représenter cet effort à chacune d'elle. Nous en reparlerons.
Quant aux stories présentant plus de la complexité que de la grande taille, on préconise l'emploi de spikes pour fiabiliser les estimations. Cela consiste à consacrer une (ou plusieurs) itération à évaluer l'effort d'une story complexe en "tâtant le terrain". Pour cela, on s'impose une timebox car l'objectif n'est que d'estimer, pas d'implémenter tout de suite. Voilà aussi pourquoi il est intéressant d'avoir des itérations de courte durée : on peut différer la livraison d'une story complexe aux prochaines itérations en séparant l'analyse du travail de son implémentation, sans avoir à attendre un mois.