Spécifiez agile

Table des matières

• Préface
• Avant-propos
• L’écriture émergente
• Expression de besoins agile
• Errare humanum est
• Pourquoi raconter cette histoire
• Historique
• Objectifs de “Spécifiez agile”
• Conception de l’ouvrage
• Un autre monde
• Concepts et pratiques
• Être agile
• Modéliser
• Conclusion
• Remerciements
• I Un autre monde
• 1 Introduction
• 1.1 Terminologie
• 1.2 Product Owner et Spécifieur
• 1.2.1 Spécifieur
• 1.3 Exigences ?
• 1.4 Sur le terrain
• 1.4.1 Product Owner, qui es-tu ?
• 1.5 Communauté agile
• 2 Le Club des Chercheurs de Trésors
• 2.1 Exploration
• 2.1.1 Les Personas du site
• 2.1.2 Vision
• 2.1.3 Un premier backlog
• 2.2 Itération 1
• 2.3 Itération 2
• 2.4 Et si…
• 3 Agile ?
• 3.1 Livrer fréquemment et régulièrement
• 3.1.1 Retour sur investissement plus rapide
• 3.1.2 Feedback concret et rapide
• 3.2 Communication directe
• 3.3 Spécifications émergentes
• 3.4 Amélioration continue
• 3.5 Planification agile
• 3.6 Acceptation
• 3.7 Expression de besoins agile : multi-fonction
• 4 Les niveaux d’expression de besoins agile
• 4.1 La vie du produit
• 4.1.1 Durée de vie : plusieurs années
• 4.1.2 Projet et maintenance
• 4.2 Plusieurs niveaux de plans
• 4.2.1 Schéma directeur
• 4.2.2 Phase Produit
• 4.2.3 Version
• 4.2.4 Itération
• 4.3 Proposition de niveaux d’expression de besoins
• 4.3.1 Évolution du Système d’Information
• 4.3.2 Les objectifs assignés au produit
• 4.3.3 Feature
• 4.3.4 User Story
• 4.4 Similarités entre niveaux
• 4.4.1 Backlog
• 4.4.2 Attributs de planification
• 4.4.3 Juste à temps
• 4.4.4 Niveaux intermédiaires
• 5 Communiquez !
• 5.1 Pas si facile…
• 5.1.1 Ignorance pluraliste
• 5.1.2 La dictature des minorités
• 5.1.3 Milgram, Asch : des expériences troublantes
• 5.2 Heureux qui communique ⁵⁶
• 5.2.1 Prise de décision
• 5.2.2 Simplicité
• 5.2.3 Respect
• 5.2.4 Vocabulaire commun
• 5.2.5 Radiateur d’information
• 5.2.6 La Voix du Client
• 5.2.7 Jouer
• 6 Valeur métier
• 6.1 Qu’est-ce que la valeur métier ?
• 6.1.1 Valeur métier : les facteurs de valeur
• 6.1.2 Impliquer l’Utilisateur, le vrai
• 6.1.3 Intérêt des Utilisateurs et valeur stratégique
• 6.1.4 Temps et valeur
• 6.2 Trois pratiques simples
• 6.2.1 Déterminer les valeurs métier relatives
• 6.2.2 Investigation
• 6.2.3 Le jeu de la perfection
• 6.2.4 Valeur par consentement
• 6.2.5 Surveiller la valeur métier
• 6.2.6 Pour aller plus loin
• II Concepts et pratiques
• 7 User Story
• 7.1 Ce que n’est pas une user story
• 7.1.1 Dossier de specs “relooké” ? Non
• 7.1.2 Une story est une carte ? Non
• 7.1.3 Une User Story n’est pas une tâche technique
• 7.2 L’essence de la story
• 7.2.1 Les composants obligatoires d’une story
• 7.2.2 Story : des informations optionnelles
• 7.2.3 Tout n’est pas écrit
• 7.2.4 Estimation d’effort
• 7.2.5 Quand la story est trop lourde : les epics
• 7.3 Maintien du backlog
• 7.4 Story mapping
• 7.5 Tests d’acceptation
• 7.5.1 Tests d’acceptation : le malentendu
• 7.5.2 Format d’un test
• 7.5.3 Stratégie de test
• 7.6 Discussion
• 7.7 Critères de qualité
• 7.7.1 INVEST
• 7.7.2 TRES
• 7.8 Backlog de produit
• 7.8.1 Technical Story
• 7.8.2 Défauts
• 7.8.3 Outils
• 7.9 Traçabilité
• 8 Besoins non fonctionnels
• 8.1 Besoins non fonctionnels du produit
• 8.1.1 Développement
• 8.1.2 Opération
• 8.1.3 Plateformes
• 8.2 Contraintes réglementaires
• 8.2.1 Une solution
• 8.2.2 Valider la conception
• 9 Features
• 9.1 Rôles et Personas
• 9.1.1 Rôles
• 9.1.2 Persona
• 9.1.3 Carte d’empathie
• 9.2 Features
• 9.3 Valeur métier d’une feature
• 9.3.1 Pratiques classiques
• 9.3.2 Jeux pour faire le travail
• 9.4 Thème
• 10 Vision
• 10.1 Vision : le cap
• 10.1.1 Le contenu d’une vision
• 10.1.2 Aligner la vision
• 10.1.3 Partager la vision
• 10.1.4 Critères de qualité d’une vision
• 10.2 Vision et feuille de route
• 10.3 Créer et maintenir la vision
• 10.3.1 Jouer pour établir et maintenir la vision
• 10.3.2 Maintenir la vision
• 10.3.3 Pratiques Lean
• 10.3.4 Le test de l’ascenseur
• III Être agile
• 11 Démarche
• 11.1 Analyse
• 11.2 Synthèse
• 11.3 Spécification agile
• 11.3.1 Équilibre des démarches
• 11.3.2 Spéficications émergentes
• 11.3.3 Pilotage par feedback
• 11.4 Spécification propre
• 11.4.1 Alignement
• 11.4.2 Clean Specifications
• 12 Intelligence collective
• 12.1 Spécifier par Consentement
• 12.1.1 Consentement ou délégation ?
• 12.2 Consentement : le protocole
• 12.2.1 Cercle et parole
• 12.2.2 Le cadre de sécurité
• 12.2.3 Déroulement
• 12.3 Beauté du consentement
• IV Modélisation agile
• 13 Unified Modeling Language (UML)
• 13.1 Les règles de la modélisation agile
• 13.1.1 Concept, élément de modélisation, représentation
• 13.1.2 Qui modélise ?
• 13.2 Valeurs agiles et modélisation
• 13.2.1 Un “bon” diagramme
• 13.2.2 La question de l’outil
• 13.3 Modélisation métier
• 13.4 Cas d’utilisation agile
• 13.4.1 Cas d’utilisation et acteur
• 13.4.2 Description textuelle
• 13.4.3 Du cas d’utilisation aux user stories
• 13.5 Modélisation : pourquoi ?
• 14 Systèmes peu ou pas interactifs
• 14.1 Diagrammes d’états-transitions
• 14.1.1 Les bases
• 14.1.2 Quelques concepts supplémentaires
• 14.2 État-Transition agile
• 14.2.1 Retour sur les stories
• 14.2.2 State story
• 14.2.3 Rester agile
• 14.2.4 Aller plus loin avec UML
• 15 Gestion de parc
• 15.1 Le contexte
• 15.2 Gérer le parc ?
• 15.3 Démarche ascendante
• 15.3.1 Stories
• 15.3.2 Vocabulaire et features
• 15.3.3 Modélisation
• V Conclusion
• 16 À vous de jouer
• 16.1 Pimp your communication !
• 16.2 Prochaine étape
• 17 Glossaire
• 18 Bibliographie
• 18.1 Outillage utilisé pour concocter Spécifiez agile