Cartographie d'histoire / d'impact – Contexte, principes et vue d'ensemble

Le développement logiciel en petits lots est bénéfique
Il existe de nombreux avantages à suivre l'approche des petits lots (de nombreuses petites étapes individuelles) dans le développement logiciel :

• Feedback plus rapide
• Les problèmes sont localisés
• Risque réduit
• Plus de pression et de routine pour réduire les efforts

Le développement logiciel naïf en petits lots n'est pas aussi bénéfique

Cependant, si tu abordes le développement logiciel en petits lots de manière naïve, il y a aussi un inconvénient significatif : le manque de lien avec l'objectif global.

Jeff Patton a décrit ce phénomène à l'aide de l'exemple d'un arbre et d'un sac rempli de feuilles :

« J'imagine un arbre dont le tronc est constitué des objectifs et des bénéfices souhaités qui font avancer le système. Les grosses branches représentent les utilisateurs, les branches plus fines et les rameaux sont les capabilities dont ils ont besoin. Les feuilles représentent les User Stories, suffisamment petites pour être développées au cours des itérations.
Après tout ce travail, après avoir construit tant de compréhension partagée, j'ai l'impression que nous retirons toutes les feuilles de l'arbre pour les fourrer dans un grand sac – et qu'ensuite nous abattons l'arbre. »

Le « sac de feuilles » fait référence à une liste de tâches priorisée et sans contexte dans un backlog, et reflète la compréhension naïve des « backlogs » qui, à mon avis, est particulièrement typique chez les débutants en agilité. Même si en théorie cela ressemble à une approche par petits lots, le « sac de feuilles » rompt le lien avec les principes et objectifs sous-jacents, sapant ainsi l'autonomie.

Les 5 attributs d'une approche par petits lots efficace dans le développement logiciel

Une approche plus efficace va cependant au-delà de la simple division en unités plus petites. Une approche plus efficace :

• met l'accent sur l'intention réelle à travers des objectifs.
• souligne le lien logique entre les objectifs et les tâches nécessaires.
• rend visibles les objectifs, les tâches et leurs relations pour révéler d'éventuelles incohérences et malentendus.
• est orientée vers le travail collaboratif.
• est itérative, c'est-à-dire qu'elle ne nécessite pas d'être complète dès le départ.
• Story/Impact Mapping vs. développement logiciel par petits lots
  Tant le « User Story Mapping » de Jeff Patton que l'« Impact Mapping » de Gojko Adzic sont des réponses (largement équivalentes) aux approches naïves pour déterminer les étapes individuelles plus petites dans le développement logiciel par petits lots (c'est-à-dire pour la création de backlogs). Je le décrirais de la manière suivante :

Remarque : Ce processus d'Impact Mapping devrait être itératif. Il est présenté ici de manière séquentielle uniquement pour une meilleure compréhension. Il n'est ni nécessaire ni recommandé d'effectuer chaque étape dans cet ordre. Tu peux plutôt commencer là où tu te trouves actuellement et échanger les étapes selon tes besoins.

1) Identifier les objectifs
Qu'est-ce que tu veux accomplir ?

Cela devrait être quelque chose d'observable et donc mesurable. C'est pourquoi j'aime le terme « impact », car il implique que quelque chose est mesurable. Cependant, « objectif » est plus courant, et je n'aime pas introduire de nouvelle terminologie quand ce n'est pas absolument nécessaire.

Il peut y avoir plusieurs objectifs.

2) Identifier les rôles et les activités
Qui doit participer à une activité pour atteindre les objectifs ? Ou quelles activités doivent être réalisées par quelqu'un pour atteindre les objectifs ?

En général, je préfère commencer par les activités. En pratique cependant, c'est plutôt un processus assez itératif.

Note bien que « rôle » ne signifie pas « personne ». « Personne » peut faire référence à d'autres rôles qui n'ont rien à voir avec tes objectifs, mais plutôt avec leurs propres objectifs. Cela signifie généralement qu'il faut ajouter des objectifs supplémentaires qui doivent être soutenus.

3) Identifier les capabilities
Quelle est la condition préalable pour qu'un rôle puisse réaliser une activité ?
Les capabilities ne sont pas nécessairement quelque chose qui doit être intégré dans le logiciel.

4) Identifier les features et les stories
Que faut-il faire pour créer ou permettre les capabilities ?
Les stories devraient consister en des travaux plus petits. Les features servent plutôt à permettre des discussions à un niveau plus détaillé.

Ce texte provient du blog de Jason Yip et a été traduit par nos soins en français.