| Titre : |
Le story mapping : visualisez vos user stories pour développer le bon produit |
| Type de document : |
texte imprimé |
| Auteurs : |
Jeff Patton, Auteur ; Claude Aubry, Préfacier, etc. ; Dominique Maniez, Traducteur |
| Editeur : |
Paris [France] : Dunod |
| Année de publication : |
DL 2015 |
| Collection : |
InfoPro |
| Sous-collection : |
Etudes, développement, intégration |
| Importance : |
1 vol. (XVI-247 p.) |
| Format : |
25 cm |
| ISBN/ISSN/EAN : |
978-2-10-074030-7 |
| Note générale : |
Bibliogr. p. [241]-242. Index |
| Langues : |
Français (fre) |
| Catégories : |
Efficacité de l'organisation
Génie logiciel
Méthodes agiles (informatique)
Production ** Planification
Projets informatiques
Travail collaboratif
|
| Index. décimale : |
004B Logiciels |
| Résumé : |
"Une user story est une description simple et compréhensible d'une fonctionnalité logicielle telle que l'imagine l'utilisateur et telle qu'il la décrit.
Le mapping de ces user stories consiste à placer celles-ci dans une carte en deux dimensions avec un axe horizontal chronologique qui matérialise l'ordre dans lequel l'utilisateur va se servir des différentes fonctions, et avec un axe vertical qui matérialise la priorité de ces fonctions.
L'une des idées fortes de cette méthode est de proner un dialogue approfondi, concret et très en amont entre les futurs utilisateurs et les concepteurs de logiciel sur ce qui est attendu du futur produit.
Le story mapping est donc une méthode de compréhension mutuelle des spécifications d'un logiciel qui vient en complément des méthodes agiles telles que Scrum. Elle a été conçue par Jeff Patton et connaît un fort développement en ce moment." (4e de couv.)
|
| Note de contenu : |
CHAPITRE 1 - Vision d’ensemble
1.1. Le mot "A"
1.2. Raconter des stories, mais pas les écrire
1.3. Raconter toute l'histoire
1.4. Gary et la tragédie du backlog plat
1.5. Parler et documenter
1.6. Formulez votre idée
1.7. Décrivez vos clients et vos utilisateurs
1.8. Raconter les stories de vos utilisateurs
1.9. Explorez les détails et les options
CHAPITRE 2 - Prévoir de moins créer
2.1. La story mapping aide les grands groupes à améliorer la compréhension mutuelle
2.2. La carte vous aide à repérer les trous dans votre story
2.3. Il y a toujours trop
2.4. Concevoir une release du produit viable minimum
2.5. Décomposer une roadmap en relaese
2.6. Ne hiérarchisez pas les features, mais l'impact!
2.7. C'est magique, vraiment magique!
2.8. Pourquoi nous soutenons tellement les WVP
2.9. Le nouveau MVP n'est pas du tout un produit!
CHAPITRE 3 - Prévoir d’apprendre plus rapidement
3.1. Commencer par discuter de l'opportunité
3.2. Valider le problème
3.3. Prototyper pour apprendre
3.4. Attention à l'expression des besoins des utilisateurs
3.5. Créez pour apprendre
3.6. Itérez jusqu'à la viabilité
3.7. Comment se tromper
3.8. Apprentissage validé
3.9. Réduisez autant que possible les expériences
3.10. Récapitulons
CHAPITRE 4 - Planifiez pour finir à temps
4.1. Communiquer avec l'équipe
4.2. Le secret d'une bonne estimation
4.3. Créez par pièce
4.4. Ne livrez pas chaque tanche
4.5. L'autre secret d'une bonne estimation
4.6. Gérez votre budget
4.7. Que ferait Léonard de Vinci?
4.8. Itératif et incrémental
4.9. Stratégie d'ouverture, de milieu et de fin de partie
4.10. Décomposez votre stratégie de développement à l'aide d'une carte
4.11. Il s'agit de risques
4.12. Et maintenant?
CHAPITRE 5 - Vous savez déjà comment faire
5.1. Ecrivez votre story, une étape à la fois
5.2. Organisez votre story
5.3. Explorez l'essentiel de votre carte pour constituer une colonne vertébrale
5.5. Décomposez les tâches qui vous aident à atteindre ou outcome spécifique
5.6. C'est fini ! Vous avez appris toutes les notions importantes
5.7. Essayez ceci à la maison ou au travail
5.8. il s'agit d'une carte actuelle, pas d'une carte du futur
5.9. Essayez ceci pour de vrai
5.10. Avec les logiciels, c'est difficile
5.11. La carte n'est que le commencement
CHAPITRE 6 - La véritable histoire des « stories »
6.1. L'idée étonnamment simple de Kent
6.2. Simple ne veut pas dire facile
6.3. Ron Jeffries et les 3 C
6.4. Des mots et des images
6.5. C'est tout
CHAPITRE 7 - Racontez de meilleures stories
7.1. Le modèle de chez Connextra
7.2. Le pattern zombie et le chasse-neige
7.3. Liste de contrôle de ce dont il faut vraiment parler
7.4. Créez des photos de vacances
7.5. Il y a beaucoup de sujets de préoccupation
CHAPITRE 8 - Tout ne figure pas sur la fiche
8.1. Différentes personnes, différentes conversations
8.2. Il nous faut une fiche plus grande
8.3. Radiateurs et glacières
8.4. Cet outil n'est pas conçu pour cela
CHAPITRE 9 - La fiche n’est que le commencement
9.1. Construisez avec une image claire en tête
9.2. Construisez une tradition orale du storytelling
9.3. Inspectez les résultats de votre travail
9.4. Ce n'est pas pour vous
9.5. Développez pour apprendre
9.6. Il ne s'agit pas toujours de logiciel
9.7. Planifiez pour apprendre et apprenez à planifier
CHAPITRE 10 - Mitonnez vos stories comme des gâteaux
10.1. Créer une recette
10.2. Découpage d'un gros gâteau
CHAPITRE 11 - Cassez les blocs
11.1. La taille a toujours de l'importance
11.2. Les stories sont comme des pierres
11.3. Les epics sont de gros roches, parfois utilisés pour frapper les gens
11.4. Les thèmes organisent des groupes de stories
11.5. Oubliez ces termes et concentrez-vous sur le storytelling
11.6. On commence par les opportunités
11.7. Découverte d'une solution viable minimum
11.8. Approfondissez les détails de chaque story au cours de la livraison
11.9. Continuez à discuter pendant que vous développez
11.10. Evaluez chaque partie
11.11. Evaluez avec les utilisateurs et les clients
11.12. Evaluez avec les parties prenantes de l'entreprise
11.13. Sortez une release et continuez à évaluez
CHAPITRE 12 - Les casseurs de blocs
12.1. Valable, utilisable et faisable
12.2. Une équipe de découverte a besoin de beaucoup d'autres personnes pour réussir
12.3. Les trois amigos
12.4. Le PO vu comme un producteur
12.5. C'est compliqué
CHAPITRE 13 - On commence par les opportunités
13.1. Tenez des conversations sur les opportunités
13.2. Approfondissez, jetez ou réfléchissez
13.3. Une opportunité ne devrait pas être un euphémisme
13.4. Story mapping et opportunités
13.5. Soyez rigoureux
CHAPITRE 14 - Utilisation de la découverte pour améliorer la compréhension mutuelle
14.1. La découverte ne concerne pas le développement
14.2. Quatre étapes essentielles de la découverte
14.3. Activités de découverte, discussions et artefacts
14.4. La découverte sert à ce que tout le monde se comprenne
CHAPITRE 15 - Utilisation de la découverte pour l’apprentissage validé
15.1. Nous avons tort la plupart du temps
15.2. La sombre époque
15.3. Empathize, Focus, Ideate, Prototype, Test
15.4. Comment gâchez les bonnes choses
15.5. Courtes boucles d'apprentissage
15.6. Comment Lean Startup modifie la conception de produit
15.7.Commencez par devinez
15.8. Donnez un nom à vos hypothèses risquées
15.9. Concevez et développez un petit test
15.10. Mesurez en exécutant votre test avec les clients et les utilisateurs
15.11. Repensez votre solution et vos hypothèses
15.12. Stories et story maps?
CHAPITRE 16 - Affinez, définissez et développez
16.1. Des fiches, des conversations, encore des fiches, encore des conversations…
16.2. Découpage et polissage
16.3. Animation des ateliers de stories
16.4. Sprint ou planification des itérations?
16.5. Les foules ne collaborent pas
16.6. Décomposez et amincissez
16.7. Utilisez votre story map pendant la livraison
16.8. Utilisez une carte pour visualisez les progrès
16.9. Utilisez des cartes simples au cours des ateliers de stories
CHAPITRE 17 - Les stories sont comme des astéroïdes
17.1. Réassemblage des blocs décomposés
17.2. N'abusez pas du mapping
17.3. Ne vous perdez pas dans les détails
CHAPITRE 18 - Tirez un enseignement de tout ce que vous développez
18.1. Débriefez en équipe
18.2. Débriefez avec d'autres personnes de votre organisation
18.3. Suffisamment de logiciel
18.4. Apprenez des utilisateurs
18.5. Apprenez des utilisateurs au moment de la release
18.6. L'outcome dans les détails prévus
18.7. Utilisez une carte pour évaluer la préparation de la release
FIN PROVISOIRE
BIBLIOGRAPHIE
INDEX
|
| Permalink : |
http://catalogue.iessid.be/index.php?lvl=notice_display&id=21574 |
Le story mapping : visualisez vos user stories pour développer le bon produit [texte imprimé] / Jeff Patton, Auteur ; Claude Aubry, Préfacier, etc. ; Dominique Maniez, Traducteur . - Paris (Rue Laromiguière, 5, 75005, France) : Dunod, DL 2015 . - 1 vol. (XVI-247 p.) ; 25 cm. - ( InfoPro. Etudes, développement, intégration) . ISBN : 978-2-10-074030-7 Bibliogr. p. [241]-242. Index Langues : Français ( fre)
| Catégories : |
Efficacité de l'organisation
Génie logiciel
Méthodes agiles (informatique)
Production ** Planification
Projets informatiques
Travail collaboratif
|
| Index. décimale : |
004B Logiciels |
| Résumé : |
"Une user story est une description simple et compréhensible d'une fonctionnalité logicielle telle que l'imagine l'utilisateur et telle qu'il la décrit.
Le mapping de ces user stories consiste à placer celles-ci dans une carte en deux dimensions avec un axe horizontal chronologique qui matérialise l'ordre dans lequel l'utilisateur va se servir des différentes fonctions, et avec un axe vertical qui matérialise la priorité de ces fonctions.
L'une des idées fortes de cette méthode est de proner un dialogue approfondi, concret et très en amont entre les futurs utilisateurs et les concepteurs de logiciel sur ce qui est attendu du futur produit.
Le story mapping est donc une méthode de compréhension mutuelle des spécifications d'un logiciel qui vient en complément des méthodes agiles telles que Scrum. Elle a été conçue par Jeff Patton et connaît un fort développement en ce moment." (4e de couv.)
|
| Note de contenu : |
CHAPITRE 1 - Vision d’ensemble
1.1. Le mot "A"
1.2. Raconter des stories, mais pas les écrire
1.3. Raconter toute l'histoire
1.4. Gary et la tragédie du backlog plat
1.5. Parler et documenter
1.6. Formulez votre idée
1.7. Décrivez vos clients et vos utilisateurs
1.8. Raconter les stories de vos utilisateurs
1.9. Explorez les détails et les options
CHAPITRE 2 - Prévoir de moins créer
2.1. La story mapping aide les grands groupes à améliorer la compréhension mutuelle
2.2. La carte vous aide à repérer les trous dans votre story
2.3. Il y a toujours trop
2.4. Concevoir une release du produit viable minimum
2.5. Décomposer une roadmap en relaese
2.6. Ne hiérarchisez pas les features, mais l'impact!
2.7. C'est magique, vraiment magique!
2.8. Pourquoi nous soutenons tellement les WVP
2.9. Le nouveau MVP n'est pas du tout un produit!
CHAPITRE 3 - Prévoir d’apprendre plus rapidement
3.1. Commencer par discuter de l'opportunité
3.2. Valider le problème
3.3. Prototyper pour apprendre
3.4. Attention à l'expression des besoins des utilisateurs
3.5. Créez pour apprendre
3.6. Itérez jusqu'à la viabilité
3.7. Comment se tromper
3.8. Apprentissage validé
3.9. Réduisez autant que possible les expériences
3.10. Récapitulons
CHAPITRE 4 - Planifiez pour finir à temps
4.1. Communiquer avec l'équipe
4.2. Le secret d'une bonne estimation
4.3. Créez par pièce
4.4. Ne livrez pas chaque tanche
4.5. L'autre secret d'une bonne estimation
4.6. Gérez votre budget
4.7. Que ferait Léonard de Vinci?
4.8. Itératif et incrémental
4.9. Stratégie d'ouverture, de milieu et de fin de partie
4.10. Décomposez votre stratégie de développement à l'aide d'une carte
4.11. Il s'agit de risques
4.12. Et maintenant?
CHAPITRE 5 - Vous savez déjà comment faire
5.1. Ecrivez votre story, une étape à la fois
5.2. Organisez votre story
5.3. Explorez l'essentiel de votre carte pour constituer une colonne vertébrale
5.5. Décomposez les tâches qui vous aident à atteindre ou outcome spécifique
5.6. C'est fini ! Vous avez appris toutes les notions importantes
5.7. Essayez ceci à la maison ou au travail
5.8. il s'agit d'une carte actuelle, pas d'une carte du futur
5.9. Essayez ceci pour de vrai
5.10. Avec les logiciels, c'est difficile
5.11. La carte n'est que le commencement
CHAPITRE 6 - La véritable histoire des « stories »
6.1. L'idée étonnamment simple de Kent
6.2. Simple ne veut pas dire facile
6.3. Ron Jeffries et les 3 C
6.4. Des mots et des images
6.5. C'est tout
CHAPITRE 7 - Racontez de meilleures stories
7.1. Le modèle de chez Connextra
7.2. Le pattern zombie et le chasse-neige
7.3. Liste de contrôle de ce dont il faut vraiment parler
7.4. Créez des photos de vacances
7.5. Il y a beaucoup de sujets de préoccupation
CHAPITRE 8 - Tout ne figure pas sur la fiche
8.1. Différentes personnes, différentes conversations
8.2. Il nous faut une fiche plus grande
8.3. Radiateurs et glacières
8.4. Cet outil n'est pas conçu pour cela
CHAPITRE 9 - La fiche n’est que le commencement
9.1. Construisez avec une image claire en tête
9.2. Construisez une tradition orale du storytelling
9.3. Inspectez les résultats de votre travail
9.4. Ce n'est pas pour vous
9.5. Développez pour apprendre
9.6. Il ne s'agit pas toujours de logiciel
9.7. Planifiez pour apprendre et apprenez à planifier
CHAPITRE 10 - Mitonnez vos stories comme des gâteaux
10.1. Créer une recette
10.2. Découpage d'un gros gâteau
CHAPITRE 11 - Cassez les blocs
11.1. La taille a toujours de l'importance
11.2. Les stories sont comme des pierres
11.3. Les epics sont de gros roches, parfois utilisés pour frapper les gens
11.4. Les thèmes organisent des groupes de stories
11.5. Oubliez ces termes et concentrez-vous sur le storytelling
11.6. On commence par les opportunités
11.7. Découverte d'une solution viable minimum
11.8. Approfondissez les détails de chaque story au cours de la livraison
11.9. Continuez à discuter pendant que vous développez
11.10. Evaluez chaque partie
11.11. Evaluez avec les utilisateurs et les clients
11.12. Evaluez avec les parties prenantes de l'entreprise
11.13. Sortez une release et continuez à évaluez
CHAPITRE 12 - Les casseurs de blocs
12.1. Valable, utilisable et faisable
12.2. Une équipe de découverte a besoin de beaucoup d'autres personnes pour réussir
12.3. Les trois amigos
12.4. Le PO vu comme un producteur
12.5. C'est compliqué
CHAPITRE 13 - On commence par les opportunités
13.1. Tenez des conversations sur les opportunités
13.2. Approfondissez, jetez ou réfléchissez
13.3. Une opportunité ne devrait pas être un euphémisme
13.4. Story mapping et opportunités
13.5. Soyez rigoureux
CHAPITRE 14 - Utilisation de la découverte pour améliorer la compréhension mutuelle
14.1. La découverte ne concerne pas le développement
14.2. Quatre étapes essentielles de la découverte
14.3. Activités de découverte, discussions et artefacts
14.4. La découverte sert à ce que tout le monde se comprenne
CHAPITRE 15 - Utilisation de la découverte pour l’apprentissage validé
15.1. Nous avons tort la plupart du temps
15.2. La sombre époque
15.3. Empathize, Focus, Ideate, Prototype, Test
15.4. Comment gâchez les bonnes choses
15.5. Courtes boucles d'apprentissage
15.6. Comment Lean Startup modifie la conception de produit
15.7.Commencez par devinez
15.8. Donnez un nom à vos hypothèses risquées
15.9. Concevez et développez un petit test
15.10. Mesurez en exécutant votre test avec les clients et les utilisateurs
15.11. Repensez votre solution et vos hypothèses
15.12. Stories et story maps?
CHAPITRE 16 - Affinez, définissez et développez
16.1. Des fiches, des conversations, encore des fiches, encore des conversations…
16.2. Découpage et polissage
16.3. Animation des ateliers de stories
16.4. Sprint ou planification des itérations?
16.5. Les foules ne collaborent pas
16.6. Décomposez et amincissez
16.7. Utilisez votre story map pendant la livraison
16.8. Utilisez une carte pour visualisez les progrès
16.9. Utilisez des cartes simples au cours des ateliers de stories
CHAPITRE 17 - Les stories sont comme des astéroïdes
17.1. Réassemblage des blocs décomposés
17.2. N'abusez pas du mapping
17.3. Ne vous perdez pas dans les détails
CHAPITRE 18 - Tirez un enseignement de tout ce que vous développez
18.1. Débriefez en équipe
18.2. Débriefez avec d'autres personnes de votre organisation
18.3. Suffisamment de logiciel
18.4. Apprenez des utilisateurs
18.5. Apprenez des utilisateurs au moment de la release
18.6. L'outcome dans les détails prévus
18.7. Utilisez une carte pour évaluer la préparation de la release
FIN PROVISOIRE
BIBLIOGRAPHIE
INDEX
|
| Permalink : |
http://catalogue.iessid.be/index.php?lvl=notice_display&id=21574 |
|  |
Ajouter le résultat dans votre panier Affiner la recherche Interroger des sources externesAnalyse des besoins pour le développement logiciel : recueil et spécification, démarches itératives et agiles / Jacques Lonchamp
