La documentation Agile du Sprint 0

Dans la résolution des problématiques - même complexes - une approche structurellement simplifiée de l’expression des exigences peut résoudre bien des difficultés de formalisation.

Formalisation des exigences

C’est sur une base de dissociation des responsabilités entre « Espace du besoin » et « Espace de la solution » que se construit un projet « Agile ». Cette dissociation des espaces de formalisation n’implique pas la séparation des ressources impliquées, mais bien au contraire la participation simultanée de l’équipe et du métier (récits utilisateurs).

Pour une approche Agile légère et novatrice, mais consciente de la complexité fréquente des systèmes à automatiser, comme PUMA (le Processus Urbanisant les Méthodes Agiles), deux espaces de travail structurent un document unique organisé en 4 classes d’exigences. À chaque itération dans le sprint 0, et pour chaque préoccupation, ce document recueille toutes les informations sur les Exigences qui seront exprimées de plus en plus précisément jusqu’à être compréhensibles et évaluable par l’équipe de développement du produit.

1. Aspects Stratégie et Contraintes.
2. Aspects Fonctionnels.
3. Aspects Technologiques.

Les 4 niveaux de profondeur itérative du moteur de solution

Ce « moteur » est en fait un simple modèle de document structuré par les quatre classes de préoccupations (nommées Aspects), représentatives d’une forme Agile  de l’expression des Exigences :

1. Aspects Stratégie et Contraintes.
2. Aspects Fonctionnels.3. Aspects Technologiques.
4. Aspects Organisationnels.


Ces aspects s’explorent dans l’ordre fondamental précisé. En revanche, et toute la complexité relative de l’opération - ainsi que sa pertinence - résident dans ce principe, ils doivent, afin de prendre en compte la globalité des interrelations et des dépendances induites, être appréhendés globalement et de manière itérative. Généralement l’exploration se limite, selon les besoins, à quatre niveaux de profondeur itérative :

 1. Vision. 
 2. Cadrage. 
 3. Spécifications. 
 4. Services.

Les Exigences sont, dans un premier temps, considérées comme des « Visions », pour devenir par affinement des « Cadrages », puis des « Spécifications » et finalement des « Services ». Ce dernier aspect est un point central en termes d’identification et de granularité dans le cadre d’une architecture orientée services. Dans les petits projets, un seul niveau du type « étape d’exploration de XP » peut s’avérer suffisant. Cette approche itérative incrémentale se réalise dans un document unique sur quatre niveaux de profondeur (Figure 2) :

1. Vision (compréhension et évaluation du problème) ;
2. Cadrage (justification et organisation du projet) ;
3. Spécification (conception de la solution) ;
4. Solution (réalisation et validation).
Un autre aspect non négligeable de l’agilité en matière de réduction documentaire serait la notion de documentation unique de type « un seul code donc un seul document  » et même, pourquoi pas, en poussant le principe à l’extrême par le positionnement de la documentation dans le fichier code source. La meilleure des documentations est celle qui se trouve à l’endroit où le code doit être modifié si besoin est.

Phasage du Sprint 0
Une approche Agile n’interdit pas, si nécessaire, de se doter d’une vue d'ensemble en préalable au développement. À partir d’une vision globale, suivant les projets, les méthodes Agiles comportent généralement trois phases d’importance variable, dans lesquelles se développent des itérations (à l’exception de Scrum qui ne précise rien sur ces sujets.
- Cadrage (ou exploration, ou encore gestion des Exigences). L’expression des besoins et des contraintes est effectuée directement par le métier, en présence des informaticiens, et lors d’entretiens structurés. Cette phase représente environ 15 % du projet.
- Architecture (structure technique ou Agile modélisation). Le métier et certains utilisateurs significatifs sont également impliqués dans cette étape de conception globale. Ils participent à l’affinage et à la validation des classes d’exigences. Ils valident également le premier niveau de prototype présentant l’ergonomie applicative. Cette phase représente environ 25 % du projet
- Solution (acquisition ou construction). Durant cette phase, l’équipe projet doit construire l’application incrément par incrément. Le métier assisté de l’utilisateur final participe toujours activement aux spécifications détaillées et à la validation des prototypes. Cette phase représente environ 50 % du projet.
- Livraison. Des recettes partielles ayant été faites en validation permanente, puis confirmées à la fin de chaque Sprint, il s’agit alors d’officialiser une livraison finale.Note : Dans les petits projets menés avec Scrum et XP, il est fréquent que la conception et le développement soient fusionnés dans une seule phase à l’exception des activités d’Exploration et de Planning.

Résumé des pratiques utilisées
Le modèle Agile instrumentant le Sprint 0 proposé par PUMA se résume donc en termes de pratiques à deux groupes distincts, traitant des deux aspects les plus importants de la définition d’une solution :La communication et la gestion des relations interpersonnelles.La formalisation de la dynamique applicative dans une approche de pilotage « par la valeur ».Note : Il n’est pas possible de détailler ici les techniques Agiles mises en œuvre dans le Modèle de Solution. Dans les organisations conséquentes, ce n’est généralement pas la technique qui fait défaut mais la communication.Le Modèle de Solution se situe à la convergence de la plupart des problématiques d’évolution de l’entreprise.  Considéré comme un outil, le Modèle de Solution permet l’instanciation rationnelle et consensuelle d’une expression des besoins généralement complexifiée par l’implication de multiples prescripteurs dans la prise en compte de multiples exigences : métier, technologie, contraintes légales, écologiques, économiques et humaines, etc.  Sur ce dernier point, le Modèle de Solution offre une réponse naturelle aux préoccupations du EVA (Earned Value Management), une approche qui situe la valeur ajoutée d’un développement à l’intersection de plusieurs contraintes et  permet un diagnostic précoce des projets en difficulté.

Le Modèle de Solution induit aussi des gains significatifs comme la réduction des délais de production et accroissement de la qualité applicative. Mais le plus important concerne l’impact organisationnel où sa mise en œuvre dépasse notablement la simple production d’une solution, aussi performante ou utile soit-elle. Le Modèle de Solution s’avère alors un puissant moyen d’enrichissement des modes de travail. En transformant les relations interpersonnelles conflictuelles en échanges et en partages de la responsabilité, il facilite la fluidification des communications ainsi que l’adoption du savoir-être coopératif.  Entre la notion de conception émergeante  et de livraison en itération permanente d’une part, et les contraintes des cycles incrémentaux d’autre part, il se caractérise par un juste milieu entièrement dépendant du type de projet. Par contre, comme toutes les techniques Agiles, il se focalise sur la fourniture précoce d’un résultat tangible testable de type « fonctionnalité logicielle approuvée par le métier et l’utilisateur ».

Phasage du Sprint 0

Une approche Agile n’interdit pas, si nécessaire, de se doter d’une vue d'ensemble en préalable au développement. À partir d’une vision globale, suivant les projets, les méthodes Agiles comportent généralement trois phases d’importance variable, dans lesquelles se développent des itérations (à l’exception de Scrum qui ne précise rien sur ces sujets.

- Cadrage (ou exploration, ou encore gestion des Exigences). L’expression des besoins et des contraintes est effectuée directement par le métier, en présence des informaticiens, et lors d’entretiens structurés. Cette phase représente environ 15 % du projet.

- Architecture (structure technique ou Agile modélisation). Le métier et certains utilisateurs significatifs sont également impliqués dans cette étape de conception globale. Ils participent à l’affinage et à la validation des classes d’exigences. Ils valident également le premier niveau de prototype présentant l’ergonomie applicative. Cette phase représente environ 25 % du projet.

- Solution (acquisition ou construction). Durant cette phase, l’équipe projet doit construire l’application incrément par incrément. Le métier assisté de l’utilisateur final participe toujours activement aux spécifications détaillées et à la validation des prototypes. Cette phase représente environ 50 % du projet.

- Livraison. Des recettes partielles ayant été faites en validation permanente, puis confirmées à la fin de chaque Sprint, il s’agit alors d’officialiser une livraison finale.
Note : Dans les petits projets menés avec Scrum et XP, il est fréquent que la conception et le développement soient fusionnés dans une seule phase à l’exception des activités d’Exploration et de Planning.

Résumé des pratiques utilisées

Le modèle Agile instrumentant le Sprint 0 proposé par PUMA se résume donc en termes de pratiques à deux groupes distincts, traitant des deux aspects les plus importants de la définition d’une solution :

1. La communication et la gestion des relations interpersonnelles.
2. La formalisation de la dynamique applicative dans une approche de pilotage « par la valeur ».

Note : Il n’est pas possible de détailler ici les techniques Agiles mises en œuvre dans le Modèle de Solution. Dans les organisations conséquentes, ce n’est généralement pas la technique qui fait défaut mais la communication.Le Modèle de Solution se situe à la convergence de la plupart des problématiques d’évolution de l’entreprise.  Considéré comme un outil, le Modèle de Solution permet l’instanciation rationnelle et consensuelle d’une expression des besoins généralement complexifiée par l’implication de multiples prescripteurs dans la prise en compte de multiples exigences : métier, technologie, contraintes légales, écologiques, économiques et humaines, etc.  Sur ce dernier point, le Modèle de Solution offre une réponse naturelle aux préoccupations du EVA (Earned Value Management), une approche qui situe la valeur ajoutée d’un développement à l’intersection de plusieurs contraintes et  permet un diagnostic précoce des projets en difficulté.

Le Modèle de Solution induit aussi des gains significatifs comme la réduction des délais de production et accroissement de la qualité applicative. Mais le plus important concerne l’impact organisationnel où sa mise en œuvre dépasse notablement la simple production d’une solution, aussi performante ou utile soit-elle. Le Modèle de Solution s’avère alors un puissant moyen d’enrichissement des modes de travail. En transformant les relations interpersonnelles conflictuelles en échanges et en partages de la responsabilité, il facilite la fluidification des communications ainsi que l’adoption du savoir-être coopératif.  Entre la notion de conception émergeante  et de livraison en itération permanente d’une part, et les contraintes des cycles incrémentaux d’autre part, il se caractérise par un juste milieu entièrement dépendant du type de projet. Par contre, comme toutes les techniques Agiles, il se focalise sur la fourniture précoce d’un résultat tangible testable de type « fonctionnalité logicielle approuvée par le métier et l’utilisateur ».