|
|
Scrum et XP depuis les Tranchées
Comment nous appliquons Scrum
Date de publication : 21/01/2009 , Date de mise à jour : 03/05/2010
Par
Henrik Kniberg (autres ressources)
Traduction par Guillaume Mathias, Bruno Orsier, Emmanuel Etasse, Christophe Bunn
Ce livre fait partie de la collection de livres InfoQ "Enterprise Software Development". L'apport du livre d'Henrik est que, si vous suivez les pratiques décrites, vous aurez un Directeur de produit, des estimations pour votre Backlog de produit, une Courbe du reste à faire, et vous connaîtrez la vélocité de votre équipe ainsi que de nombreuses autres pratiques essentielles pour un Scrum dangereusement opérationnel. Vous passerez le test Nokia pour Scrum et serez digne de l'investissement dans votre travail. Si vous êtes une startup, vous pouvez même bénéficier du financement d'une société capital-risque. Vous serez peut-être le futur du développement logiciel et le créateur d'une nouvelle génération d'éminents logiciels.
Jeff Sutherland, Ph.D., Co-Créateur de Scrum
Jeff Sutherland, Ph.D., Co-Créateur de Scrum
Cette traduction de l'édition originale que vous pouvez trouver sur la page de l'ouvrage sur InfoQ (tout comme les autres traductions) a été faite bénévolement par les traducteurs français, et Henrik Kniberg et InfoQ en ont autorisé la publication.
Henrik Kniberg
Préfaces de Jeff Sutherland, Mike Cohn
Préfaces de Jeff Sutherland, Mike Cohn
Copyright
Copyright original
Preface
Remerciements
Préface de Jeff Sutherland
Préface de Mike Cohn
Préface - Hé, Scrum ca marche !
Intro
1. Intro
1.1. Avertissement
1.2. Pourquoi j'ai écrit ceci
1.3. Mais Scrum, qu'est ce que c'est ?
Comment nous faisons les backlogs de produit
2. Comment nous faisons les backlogs de produit
2.1. Champs d'histoire supplémentaires
2.2. Comment nous gardons le backlog de produit à un niveau métier
Les sprints
3. Comment nous préparons la réunion de planning du sprint
4. Comment nous faisons les plannings de sprint
4.1. Pourquoi le directeur de produit doit y assister
4.2. Pourquoi la qualité n'est pas négociable
4.3. Les réunions de planning de sprint qui s'éternisent...
4.4. L'ordre du jour de la réunion de planning de sprint
4.5. Le choix de la durée du sprint
4.6. La définition du but du sprint
4.7. Le choix des histoires à inclure dans le sprint
4.8. Comment le directeur de produit peut-il exercer une influence sur les histoires qui iront dans le sprint ?
4.9. Comment les équipes choisissent-elles les histoires à inclure dans le sprint ?
4.9.1. Estimation en utilisant les calculs de vélocité
4.9.2. Quelle technique d'estimation utilisons-nous ?
4.10. Quelle technique d'estimation utilisons-nous ?
4.11. Pourquoi nous utilisons des fiches
4.12. Définition de "terminé"
4.13. L'estimation de temps avec le poker de planning
4.14. La clarification des histoires
4.15. La décomposition des histoires en plus petites histoires
4.16. La décomposition des histoires en tâches
4.17. Le choix du lieu et l'heure pour la mêlée quotidienne
4.18. Où tracer la limite ?
4.19. Les histoires techniques
4.20. Système de suivi de bug vs. backlog de produit
4.21. La réunion de planning de sprint est finalement terminée !
5. Comment nous communiquons sur les sprints
6. Comment nous faisons les backlogs de sprint
6.1. Format du backlog de sprint
6.2. Comment le tableau des tâches fonctionne
6.3. Exemple 1 - Après la première mêlée quotidienne
6.4. Exemple 2 - après quelques jours
6.5. Comment le burndown chart fonctionne
6.6. Les signaux d'avertissement du tableau des tâches
6.7. Hé, et la traçabilité ?!
6.8. Estimations en jours vs. heures
Le bureau de l'équipe
7. Comment nous organisons le bureau de l'équipe
7.1. Le coin conception
7.2. Installez l'équipe ensemble !
7.3. Garder le directeur de produit à distance
7.4. Garder les directeurs et les coachs à distance
Les mêlées quotidiennes
8. Comment nous faisons les mêlées quotidiennes
8.1. Comment nous mettons à jour le tableau des tâches
8.2. Traiter avec les retardataires
8.3. Traiter avec « je ne sais pas quoi faire aujourd'hui »
Les démos de sprint
9. Comment nous faisons les démos de sprint
9.1. Pourquoi nous insistons pour que tous les sprints finissent par une démo
9.2. S'occuper des choses « indémontrables »
Les rétrospectives
10. Comment nous faisons les rétrospectives de sprint
10.1. Pourquoi nous insistons pour que toutes les équipes fassent des rétrospectives
10.2. Comment nous organisons les rétrospectives
10.3. La diffusion des enseignements tirés entre équipes
10.4. Changer ou ne pas changer
10.5. Exemples de choses qui peuvent remonter pendant les rétrospectives
10.5.1. « Nous devrions passer plus de temps à décomposer les histoires en sous-éléments et tâches »
10.5.2. « Trop de dérangements extérieurs »
10.5.3. « Nous nous sommes trop engagés et nous n'avons terminé que la moitié du travail »
10.5.4. « Notre bureau est trop bruyant et bordélique »
11. Relâcher le rythme entre les sprints
Le contrat au forfait
12. Comment nous faisons la planification de release et les contrats au forfait
12.1. Définir vos seuils d'acceptation
12.2. Estimation en temps des éléments les plus importants
12.3. Estimer la vélocité
12.4. Tout mettre ensemble dans un plan de release
12.5. Adapter le plan de release
Scrum et XP
13. Comment nous combinons Scrum avec XP
13.1. La programmation en binôme
13.2. Le Développement Dirigé par les Tests (DDT)
13.2.1. Le DDT sur du nouveau code
13.2.2. Le DDT sur du vieux code
13.3. La conception incrémentale
13.4. L'intégration continue
13.5. La propriété collective du code
13.6. Un espace de travail informatif
13.7. Les normes de codage
13.8. Le rythme soutenable / le travail énergisé
Les tests
14. Comment nous faisons les tests
14.1. Vous ne pouvez probablement pas éliminer la phase de tests d'acceptation
14.2. Minimisez la phase de tests d'acceptation
14.3. Augmenter la qualité en mettant des testeurs dans l'équipe Scrum
14.3.1. Le testeur est le « gars qui signe officiellement »
14.3.2. Que fait le testeur quand il n'y a rien à tester ?
14.4. Augmenter la qualité en en faisant moins par sprint
14.5. Est-ce que les tests d'acceptation devraient faire partie du sprint ?
14.6. Des cycles de sprints vs. des cycles de test d'acceptation
14.7. Ne distancez pas le maillon le plus lent de votre chaîne
14.8. Retour à la réalité
Les équipes multi-Scrum
15. Comment nous gérons les équipes multi-Scrum
15.1. Combien d'équipes faut-il créer
15.1.1. Equipes virtuelles
15.1.2. La taille optimale de l'équipe
15.2. Sprints synchronisés - ou non ?
15.3. Pourquoi nous avons introduit le rôle du « meneur d'équipe »
15.4. Comment nous affectons les personnes aux équipes
15.5. Equipes spécialisées - ou non ?
15.5.1. Approche n°1 : équipes spécialisées par composant
15.5.2. Approche n°2 : équipes transversales aux composants
15.6. Réarranger les équipes entre les sprints - ou pas ?
15.7. Les membres d'équipe à temps partiel
15.8. Comment nous faisons les Scrums-de-Scrums
15.8.1. Scrum-de-Scrums de niveau produit
15.8.2. Scrum-de-Scrums de niveau global
15.9. Intercaler les mêlées quotidiennes
15.10. Les équipes de pompiers
15.11. Partager le backlog de produit - ou pas ?
15.11.1. Stratégie 1 : un directeur de produit, un backlog
15.11.2. Stratégie 2: un directeur de produit, plusieurs backlogs
15.11.3. Stratégie 3 : plusieurs directeurs de produit, un backlog par directeur
15.12. Branches de code
15.13. Rétrospectives multi-équipes
Les équipes distribuées
16. Comment nous gérons les équipes géographiquement dispersées
16.1. Délocaliser Offshore
16.2. Équipiers travaillant de la maison
Pense-bête
17. Pense-bête du Scrum Master
17.1. Début du Sprint
17.2. Tous les jours
17.3. Fin du Sprint
Conclusion
18. Mot de la fin
18.1. Lectures recommandées
18.2. A propos de l'auteur
Copyright original
Preface
Remerciements
Préface de Jeff Sutherland
Préface de Mike Cohn
Préface - Hé, Scrum ca marche !
Intro
1. Intro
1.1. Avertissement
1.2. Pourquoi j'ai écrit ceci
1.3. Mais Scrum, qu'est ce que c'est ?
Comment nous faisons les backlogs de produit
2. Comment nous faisons les backlogs de produit
2.1. Champs d'histoire supplémentaires
2.2. Comment nous gardons le backlog de produit à un niveau métier
Les sprints
3. Comment nous préparons la réunion de planning du sprint
4. Comment nous faisons les plannings de sprint
4.1. Pourquoi le directeur de produit doit y assister
4.2. Pourquoi la qualité n'est pas négociable
4.3. Les réunions de planning de sprint qui s'éternisent...
4.4. L'ordre du jour de la réunion de planning de sprint
4.5. Le choix de la durée du sprint
4.6. La définition du but du sprint
4.7. Le choix des histoires à inclure dans le sprint
4.8. Comment le directeur de produit peut-il exercer une influence sur les histoires qui iront dans le sprint ?
4.9. Comment les équipes choisissent-elles les histoires à inclure dans le sprint ?
4.9.1. Estimation en utilisant les calculs de vélocité
4.9.2. Quelle technique d'estimation utilisons-nous ?
4.10. Quelle technique d'estimation utilisons-nous ?
4.11. Pourquoi nous utilisons des fiches
4.12. Définition de "terminé"
4.13. L'estimation de temps avec le poker de planning
4.14. La clarification des histoires
4.15. La décomposition des histoires en plus petites histoires
4.16. La décomposition des histoires en tâches
4.17. Le choix du lieu et l'heure pour la mêlée quotidienne
4.18. Où tracer la limite ?
4.19. Les histoires techniques
4.20. Système de suivi de bug vs. backlog de produit
4.21. La réunion de planning de sprint est finalement terminée !
5. Comment nous communiquons sur les sprints
6. Comment nous faisons les backlogs de sprint
6.1. Format du backlog de sprint
6.2. Comment le tableau des tâches fonctionne
6.3. Exemple 1 - Après la première mêlée quotidienne
6.4. Exemple 2 - après quelques jours
6.5. Comment le burndown chart fonctionne
6.6. Les signaux d'avertissement du tableau des tâches
6.7. Hé, et la traçabilité ?!
6.8. Estimations en jours vs. heures
Le bureau de l'équipe
7. Comment nous organisons le bureau de l'équipe
7.1. Le coin conception
7.2. Installez l'équipe ensemble !
7.3. Garder le directeur de produit à distance
7.4. Garder les directeurs et les coachs à distance
Les mêlées quotidiennes
8. Comment nous faisons les mêlées quotidiennes
8.1. Comment nous mettons à jour le tableau des tâches
8.2. Traiter avec les retardataires
8.3. Traiter avec « je ne sais pas quoi faire aujourd'hui »
Les démos de sprint
9. Comment nous faisons les démos de sprint
9.1. Pourquoi nous insistons pour que tous les sprints finissent par une démo
9.2. S'occuper des choses « indémontrables »
Les rétrospectives
10. Comment nous faisons les rétrospectives de sprint
10.1. Pourquoi nous insistons pour que toutes les équipes fassent des rétrospectives
10.2. Comment nous organisons les rétrospectives
10.3. La diffusion des enseignements tirés entre équipes
10.4. Changer ou ne pas changer
10.5. Exemples de choses qui peuvent remonter pendant les rétrospectives
10.5.1. « Nous devrions passer plus de temps à décomposer les histoires en sous-éléments et tâches »
10.5.2. « Trop de dérangements extérieurs »
10.5.3. « Nous nous sommes trop engagés et nous n'avons terminé que la moitié du travail »
10.5.4. « Notre bureau est trop bruyant et bordélique »
11. Relâcher le rythme entre les sprints
Le contrat au forfait
12. Comment nous faisons la planification de release et les contrats au forfait
12.1. Définir vos seuils d'acceptation
12.2. Estimation en temps des éléments les plus importants
12.3. Estimer la vélocité
12.4. Tout mettre ensemble dans un plan de release
12.5. Adapter le plan de release
Scrum et XP
13. Comment nous combinons Scrum avec XP
13.1. La programmation en binôme
13.2. Le Développement Dirigé par les Tests (DDT)
13.2.1. Le DDT sur du nouveau code
13.2.2. Le DDT sur du vieux code
13.3. La conception incrémentale
13.4. L'intégration continue
13.5. La propriété collective du code
13.6. Un espace de travail informatif
13.7. Les normes de codage
13.8. Le rythme soutenable / le travail énergisé
Les tests
14. Comment nous faisons les tests
14.1. Vous ne pouvez probablement pas éliminer la phase de tests d'acceptation
14.2. Minimisez la phase de tests d'acceptation
14.3. Augmenter la qualité en mettant des testeurs dans l'équipe Scrum
14.3.1. Le testeur est le « gars qui signe officiellement »
14.3.2. Que fait le testeur quand il n'y a rien à tester ?
14.4. Augmenter la qualité en en faisant moins par sprint
14.5. Est-ce que les tests d'acceptation devraient faire partie du sprint ?
14.6. Des cycles de sprints vs. des cycles de test d'acceptation
14.7. Ne distancez pas le maillon le plus lent de votre chaîne
14.8. Retour à la réalité
Les équipes multi-Scrum
15. Comment nous gérons les équipes multi-Scrum
15.1. Combien d'équipes faut-il créer
15.1.1. Equipes virtuelles
15.1.2. La taille optimale de l'équipe
15.2. Sprints synchronisés - ou non ?
15.3. Pourquoi nous avons introduit le rôle du « meneur d'équipe »
15.4. Comment nous affectons les personnes aux équipes
15.5. Equipes spécialisées - ou non ?
15.5.1. Approche n°1 : équipes spécialisées par composant
15.5.2. Approche n°2 : équipes transversales aux composants
15.6. Réarranger les équipes entre les sprints - ou pas ?
15.7. Les membres d'équipe à temps partiel
15.8. Comment nous faisons les Scrums-de-Scrums
15.8.1. Scrum-de-Scrums de niveau produit
15.8.2. Scrum-de-Scrums de niveau global
15.9. Intercaler les mêlées quotidiennes
15.10. Les équipes de pompiers
15.11. Partager le backlog de produit - ou pas ?
15.11.1. Stratégie 1 : un directeur de produit, un backlog
15.11.2. Stratégie 2: un directeur de produit, plusieurs backlogs
15.11.3. Stratégie 3 : plusieurs directeurs de produit, un backlog par directeur
15.12. Branches de code
15.13. Rétrospectives multi-équipes
Les équipes distribuées
16. Comment nous gérons les équipes géographiquement dispersées
16.1. Délocaliser Offshore
16.2. Équipiers travaillant de la maison
Pense-bête
17. Pense-bête du Scrum Master
17.1. Début du Sprint
17.2. Tous les jours
17.3. Fin du Sprint
Conclusion
18. Mot de la fin
18.1. Lectures recommandées
18.2. A propos de l'auteur
Copyright © 2009 Henrik Kniberg. La copie, modification et/ou distribution par quelque moyen que ce soit, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc sans l'autorisation expresse de l'auteur.
Copyright © 2000-2012 - www.developpez.com