« Story Mapping (technique externe et qualitative) » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
Ligne 20 : | Ligne 20 : | ||
** Les user stories (ou "tâches") sont placées le long de cet axe, dans l'ordre dans lequel elles sont effectuées par l'utilisateur ; | ** Les user stories (ou "tâches") sont placées le long de cet axe, dans l'ordre dans lequel elles sont effectuées par l'utilisateur ; | ||
* L'axe vertical représente la '''criticité''' ; | * L'axe vertical représente la '''criticité''' ; | ||
** Les user stories (ou "tâches") sont organisées verticalement selon leur importance (de haut en bas); | ** Les user stories (ou "tâches") sont organisées verticalement selon leur importance (de haut en bas) ; | ||
** Des stories de même importance peuvent être conservées à la même hauteur, mais gardez à l'esprit qu'en général, il est important de différencier l'importance relative des stories pour pouvoir créer de meilleurs plans de release. | ** Des stories de même importance peuvent être conservées à la même hauteur, mais gardez à l'esprit qu'en général, il est important de différencier l'importance relative des stories pour pouvoir créer de meilleurs plans de release. | ||
* Les groupes de user stories associées peuvent être regroupés en tant qu'''Activités'': | * Les groupes de user stories associées peuvent être regroupés en tant qu'''Activités'': | ||
** Créez une ligne verticale pour séparer les groupes de stories des autres; | ** Créez une ligne verticale pour séparer les groupes de stories des autres; | ||
** Par exemple, une activité peut être "gestion du courrier électronique", avec "envoyer un courrier électronique à une ou plusieurs adresses" en tant que tâche utilisateur; | ** Par exemple, une activité peut être "gestion du courrier électronique", avec "envoyer un courrier électronique à une ou plusieurs adresses" en tant que tâche utilisateur ; | ||
** Les activités se situent au-dessus de l'axe vertical et ne s'inscrivent pas dans une séquence d'utilisation, elles sont "juste là" - ces activités constituent les principaux attributs du produit et ne peuvent pas être hiérarchisées (pensez "vous ne pouvez pas donner la priorité au moteur d'une voiture par rapport à ses roues"). | ** Les activités se situent au-dessus de l'axe vertical et ne s'inscrivent pas dans une séquence d'utilisation, elles sont "juste là" - ces activités constituent les principaux attributs du produit et ne peuvent pas être hiérarchisées (pensez "vous ne pouvez pas donner la priorité au moteur d'une voiture par rapport à ses roues"). | ||
<br/> | <br/> | ||
[[Fichier:Story-map-1024x758.png|600px|border]]<br/> | [[Fichier:Story-map-1024x758.png|600px|border]]<br/> | ||
<br/> | |||
Ce type d’organisation du backlog présente de nombreux avantages, mais les plus importants pour la priorisation et l’exécution sont les suivants :<br/> | |||
* C'est un outil visuel qui permet aux clients, aux parties prenantes et aux membres de l'équipe de développement de partager une compréhension commune de ce que fait le système ; | |||
* Il définit très clairement la manière dont les itérations du produit sont séquencées de manière incrémentale, fournissant des releases tout à fait opérationelles avec une sophistication croissante - tel est le concept du [http://alistair.cockburn.us/Walking+skeleton squelette ambulant] (NdT : ''walking skeleton'') d'Alistair Cockburn. | |||
** Pour définir des releases, créez des lignes horizontales le long de la carte, en sélectionnant des stories avec des niveaux de criticité équivalents ; | |||
** Cela conduit à terminer les releases du produit de bout en bout et par conséquent à accélérer la livraison et la validation du marché (ce qui est crucial au stade [https://en.wikipedia.org/wiki/Minimum_viable_product MVP]). | |||
<br/> | |||
[[Fichier:Story-map-release-1024x655.png|600px|border]]<br/> | |||
<br/> | <br/> |
Version du 12 août 2018 à 06:57
Auteur : Daniel Zacarias
Source : 20 Product Priorization Techniques: A Map and Guided Tour
Traducteur : Fabrice Aimetti
Date : 12/08/2018
Traduction :
Article de référence : Tableau périodique des techniques de priorisation produit
Les Cartes de Story ont été introduites pour la première fois par Jeff Patton dans cet article de 2005 et ont été suivies par une autre qui décrit son expérience la plus récente. Les deux sont d'excellentes lectures que je ne peux que fortement vous recommander de lire.
L’idée principale des Cartes de Story est que les backlogs de produits sous forme de liste unique constituent un moyen épouvantable d’organiser et de hiérarchiser le travail à effectuer. Une structure plus riche est nécessaire.
De manière très générale, une Carte de Story est organisée comme suit :
- Il y a un axe horizontal qui représente la séquence d'utilisation ;
- Les user stories (ou "tâches") sont placées le long de cet axe, dans l'ordre dans lequel elles sont effectuées par l'utilisateur ;
- L'axe vertical représente la criticité ;
- Les user stories (ou "tâches") sont organisées verticalement selon leur importance (de haut en bas) ;
- Des stories de même importance peuvent être conservées à la même hauteur, mais gardez à l'esprit qu'en général, il est important de différencier l'importance relative des stories pour pouvoir créer de meilleurs plans de release.
- Les groupes de user stories associées peuvent être regroupés en tant qu'Activités:
- Créez une ligne verticale pour séparer les groupes de stories des autres;
- Par exemple, une activité peut être "gestion du courrier électronique", avec "envoyer un courrier électronique à une ou plusieurs adresses" en tant que tâche utilisateur ;
- Les activités se situent au-dessus de l'axe vertical et ne s'inscrivent pas dans une séquence d'utilisation, elles sont "juste là" - ces activités constituent les principaux attributs du produit et ne peuvent pas être hiérarchisées (pensez "vous ne pouvez pas donner la priorité au moteur d'une voiture par rapport à ses roues").
Ce type d’organisation du backlog présente de nombreux avantages, mais les plus importants pour la priorisation et l’exécution sont les suivants :
- C'est un outil visuel qui permet aux clients, aux parties prenantes et aux membres de l'équipe de développement de partager une compréhension commune de ce que fait le système ;
- Il définit très clairement la manière dont les itérations du produit sont séquencées de manière incrémentale, fournissant des releases tout à fait opérationelles avec une sophistication croissante - tel est le concept du squelette ambulant (NdT : walking skeleton) d'Alistair Cockburn.
- Pour définir des releases, créez des lignes horizontales le long de la carte, en sélectionnant des stories avec des niveaux de criticité équivalents ;
- Cela conduit à terminer les releases du produit de bout en bout et par conséquent à accélérer la livraison et la validation du marché (ce qui est crucial au stade MVP).