Les principes de conception logicielle généralement admis dans l’industrie actuelle s’appuient sur un modèle en 5 couches empilées verticalement : (de bas en haut) 1- données, 2- intégration, 3- métier, 4- application et 5- présentation. Chaque couche représente un métier et une dimension technologique. Si l’axe vertical représente donc les différentes dimensions technologiques, l’axe horizontal porte quant à lui l’axe fonctionnel, à savoir l ‘ensemble des fonctionnalités logicielles ce qui intéresse tout particulièrement l’utilisateur : le client d’un point de vue Lean.

Ainsi, pour obtenir une fonctionnalité (l’élément lui porteur de valeur), l’utilisateur doit attendre que chaque couche soit construite, développée et intégrée dans l’ensemble. Il s’agit du modèle hérité du cycle en V : les développeurs commencent par la structure des données puis l’intégration et terminent par la présentation : ce que voit l’utilisateur. Ceux-ci vont s’organiser de façon à construire l’ensemble des fonctions d’une couche avant de s’attaquer à la supérieure.

La fonctionnalité attend donc, et le client aussi. En effet, chaque couche étant portée par une technologie, des compétences spécifiques sont nécessaires : base de données, langage informatique, environnement développement, framework, … En remontant les niveaux, les développeurs se mettent d’accord, s’ajustent, et cela est long voire très long avant qu’un écran utilisable sorte de terre et puisse être montré à un utilisateur. Quand cela arrive, ce dernier découvre bien souvent que l’équipe projet n’a pas compris ce qu’il demandait ou que ce n’était pas vraiment ce qu’il attendait. Parfois même, le temps a passé, le contexte et la cible ont changé et il faut refaire. Ce modèle est centré sur la technologie et le processus : il a perdu de vue l’utilisateur.

C’est ainsi pour répondre à ce problème, qu’a émergé dans la communauté agile une autre façon de faire. Une approche qui a pour objet de satisfaire le client et la meilleure façon de savoir si on le satisfait est de lui proposer au plus tôt un vrai produit logiciel à tester. Cette approche, orthogonale à la précédente est parfois appelée « The Cake Slice Pattern » ou « Vertical Slice » pour montrer que dans une petite part, on retrouve l’ensemble des dimensions technologiques nécessaires. Une approche que Mike Cohn (auteur de Agile Planning and Estimating) ou Tom & Mary Poppendieck (dans les ouvrages Lean Software Development) ont largement contribué à diffuser.

Il s’agit de s’intéresser à l’utilisateur et surtout à ce qu’il veut, ce qu’il utilise, finalement à ce qui a de la valeur pour lui. S’attaquer à l’ensemble de l’application en une seule fois et par couches donc par technologies successives revient à faire des lots énormes. Ces pratiques bien connues dans la logistique créent des stocks d’encours importants ce qui a pour conséquences d’allonger mécaniquement les délais. A l’instar des logisticiens, les Agilistes se sont efforcés de réduit la taille des lots de façon à accélérer le flux.

Concrètement, il s’agit de découper le logiciel en petits éléments représentant de la valeur pour le client, que l’équipe de développeurs peut leur soumettre rapidement à tester. Cette pratique à bien des avantages :

• D’une part, l’équipe obtient rapidement l’avis des utilisateurs et s’assure qu’elle est sur la bonne voie et qu’elle comprend bien les besoins de ses utilisateurs ;
• Les ajustements sont plus faciles et convergent plus rapidement vers la solution attendue ;
• Cette pratique est tout à fait en accord avec les principes « Minimum Viable Product » qui s’attachent à livrer en premier ce qui a le plus de valeur pour le client ;
• Cette pratique met rapidement en évidence les problèmes, contraintes ou limites des choix d’architecture et d’intégration technique voire technologique afin de les régler au plutôt ;
• Et enfin, en phase ultime de maîtrise de cette pratique, a la capacité d’innover en expérimentant des minuscules incréments logiciels sans perturber les utilisateurs.

L’élément à la base du Cake Slice Pattern en Agile est la User Story. Cet outil permet de définir une unité de travail logiciel, à travers un cas d’utilisation simple du client. Cette unité de travail représente donc de la valeur pour le client et doit impliquer chacune des couches logicielles. Elle est définie ainsi :

En tant que {rôle} je peux {action} afin d’obtenir {valeur}

Exemple :

En tant qu’utilisateur de mon application de mail je peux écrire la première lettre du nom dans le champ destinataires afin de sélectionner plus rapidement parmi une liste les destinataires souhaités

L’élément essentiel ici : la capacité du système est définie depuis la perspective de l’utilisateur.

Il s’agit d’un changement radical avec la perspective ISO-9001 dans laquelle la capacité est définie depuis la perspective du système. Dans l’exemple ci dessus cela se traduirait ainsi :

Le système de gestion de mail doit proposer la complétion dans le champ destinataire

Voyez-vous le site d’Amazon évoluer ?

Et pourtant, il change toutes les 7 secondes.