Scrum
Une méthode agile pour vos projets
Ce livre s'adresse à toute personne souhaitant mettre en application ou travailler avec Scrum. Il a pour objectif de présenter cette méthode agile, la plus utilisée, sous ses aspects théoriques et pratiques afin que les lecteurs disposent des connaissances nécessaires pour la mettre en place lors de leurs futurs [...]
[lire le résumé du livre]
Auteur : Jean-Paul SUBRA
Editeur : Eni
Collection : Datapro
Date parution : 09/2019 (3ème édition)Quel est le sujet du livre "Scrum"
Ce livre s'adresse à toute personne souhaitant mettre en application ou travailler avec Scrum. Il a pour objectif de présenter cette méthode agile, la plus utilisée, sous ses aspects théoriques et pratiques afin que les lecteurs disposent des connaissances nécessaires pour la mettre en place lors de leurs futurs projets oupour occuper efficacement leur rôle, quel qu'il soit, sur un projet Scrum. Cette nouvelle édition est actualisée selon la version du Guide Scrum officiel de novembre 2017.
Après un bref rappel sur les méthodes de gestion de projet traditionnelles (Cascade, Cycle en V) et leurs limites qui ont abouti à la naissance des approches agiles, l'auteur présente des méthodes apparentées à Scrum aussi bien en termes de concepts que d'outils pratiques (Lean Management, Kanban ou bien encore l'eXtreme Programming).
Dans les chapitres suivants, après avoir fait un tour d'horizon de la méthode Scrum, permettant au lecteur d'en avoir rapidement une vue globale, l'auteur s'attarde sur les spécificités de l'équipe Scrum avec les rôles et responsabilités qui en découlent, puis explore en détail les pratiques Scrum : formuler et ordonner les besoins, planifier et estimer la duréedes différentes phasesdu projetafin d'en construire les plans, gérer le cycle de vie et le suividu projet et enfin tester ce qui est développé.
En plus de cet apprentissage proprement dit de la méthode, l'auteur a choisi de donner au lecteur des éléments qui l'aideront à aborder la problématique, parfois épineuse, du déploiement de Scrum et de la gestion du changement qui en découle.
Enfin, deux chapitres permettent d'explorer des pistes pour aller plus loin. L'un aborde les outils logiciels qui peuvent être très utiles dans le cadre de la gestion des projets Scrum, l'autre apporte des réponses concrètes à des questions que l'on peut souvent se poser dans la mise en œuvre pratique de Scrum : Quelles sont les méthodes pour le déployer sur plusieurs équipes ? Quelles sont les différences et complémentarités entre Scrum et Kanban ? Quels rapports entre Scrum et DevOps ? Comment contractualiser avec Scrum ?
Enfin, cet ouvrage se termine par un questionnaire qui permettra au lecteur de vérifier ses connaissances et d'identifier les points qu'il n'aurait pas bien assimilés. Des éléments complémentaires sont en téléchargement sur le site www.editions-eni.fr.
Quizinclus dans
la version en ligne !Téléchargements
Jean-Paul SUBRA est ingénieur Supélec et travaille depuis plus de 20 ans dans l'industrie du logiciel. Après plus de 10 ans en tant que responsable d'équipes de développement, en DSI et chez des éditeurs de logiciels, il exerce depuis 2009 dans un environnement Agile. En 2015, il crée son activité de conseil, SoftMethods, dont la mission est d'aider les entreprises qui produisent du logiciel à mettre en œuvre les méthodes les plus efficaces possibles dont Scrum fait évidemment partie.
En suivant ce lien, retrouvez tous les livres dans la spécialité Développement d'applications.
Sommaire et contenu du livre "Scrum - Une méthode agile pour vos projets"
Avant-propos
- Objectif du livre
- Notre démarche
- Structure du livre
- Remerciements
De la gestion de projet traditionnelle à l’Agilité
- Introduction
- Quelques faits et chiffres
- Le modèle de gestion de projet "en cascade"
- Le modèle (ou cycle) en V
- 1. La théorie
- 2. La mise en pratique du modèle en V
- 3. Les rôles
- 4. Notion d’effet tunnel
- L'Agilité au cœur des projets
- 1. Un peu d’histoire
- 2. Les valeurs
- 3. Les 12 principes sous-jacents
- 4. L’Agilité, ce n’est pasl’anarchie…
- Scrum, un cadre de travail Agile
- Information, formation et certifications
- Pour conclure
Lean, Kanban et eXtreme Programming
- Un chapitre nécessaire
- Liens de parenté entre les méthodes
- Le Lean Management
- 1. Objectif du Lean
- 2. Les 14 principes du Lean
- Le Kanban
- 1. Principes du Kanban
- 2. Le Kanban pour le développement de logiciel
- 3. Kanban et Scrum
- La méthode XP ou eXtreme Programming
- 1. Les principes de base
- 2. Les pratiques d’eXtreme Programming
- a. Livraisons fréquentes
- b. Rythme durable
- c. Client sur site
- d. Conception simple
- e. Mise en place de règles de codage
- f. L’équipe est responsable du code
- g. Utilisation de tests unitaires
- h. Test de recette
- i. Mise en place de l’intégration continue
- j. Réaliser du refactoring de code
- k. Programmation en binôme (Pair Programming)
- l. Estimation à l’aide du Planning Poker
- m. Utilisation de métaphores et analogies
- 3. Cycle d’eXtreme Programming
Tour d'horizon de Scrum
- Naissance de Scrum
- Scrum en quelques mots
- 1. Les valeurs Scrum
- 2. L’équipe
- 3. Les trois piliers de Scrum
- a. Transparence
- b. Inspection
- c. Adaptation
- 4. Les événements (cérémoniaux)
- a. Le Sprint
- b. La réunion de planification de Sprint
- c. La mêlée quotidienne
- d. La revue de Sprint
- e. La rétrospective de Sprint
- 5. Les artefacts
- a. Backlog Produit
- b. Backlog de Sprint
- c. Suivi de la progression
L'équipe Scrum
- L’équipe, point central de Scrum
- 1. Équipe auto-organisée
- 2. Équipe pluridisciplinaire
- Le Scrum Master
- 1. Les responsabilités du Scrum Master
- a. Application de Scrum
- b. Lever les obstacles
- c. Optimiser les interactions
- d. Leader du changement
- 1. Les responsabilités du Scrum Master
- 2. La personnalité et les compétencesdu Scrum Master
- a. Connaître Scrum
- b. Être un leader
- c. Être communicant
- d. Avoir des capacités de médiation
- e. Jouer la transparence
- 1. Les responsabilités du Product Owner
- a. Créer la vision du produit
- b. Gérer le Product Backlog
- c. Maximiser la valeur du produit et du travail de l’équipe
- d. Définir le plan de Release
- e. Implication dans le processus Scrum
- f. Accepter ou non le résultat d’un Sprint
- g. Ses pouvoirs et limites
- a. Posséder des connaissances fonctionnelles
- b. Être organisé
- c. Avoir des capacités de prise de décision
- 1. Généralités
- 2. Caractéristiques
- a. Auto-organisée et multi-disciplinaire
- b. Taille de l’équipe
- 1. La disparition du chef de projet…
- 2. Les autres rôles
- 1. Rassembler pour gagner
- 2. Cas d’une équipe morcelée
Construire et prioriser le Product Backlog
- Pourquoi investir dans le Product Backlog ?
- La brique de base du Product Backlog : la User Story
- Comment rédiger les User Stories et Epics ?
- 1. Règle des 3C
- 2. Rédiger une bonne User Story : le principeINVEST
- 3. Erreurs courantes
- 4. La Story technique : solution ou aveu d’échec ?
- 5. Identifier les fonctionnalités clésavec le Product Box
- a. Objectifs
- b. Mode opératoire
- 6. Une méthode efficace de découvertedu Product Backlog : le Story Mapping
- a. Le Story Mapping, c’est quoi ?
- b. Story Mapping illustré par un exemple
- 7. Principes de priorisation du Product Backlog
- a. Pourquoi prioriser ?
- b. Approche générale de la priorisation
- c. Les facteurs qui influencent la priorisation
- d. Survol des méthodes de priorisation
- 8. Zoom sur la priorisation par les thèmes
- a. Theme Screening (sondage des thèmes)
- b. Theme Scoring (mesure des thèmes)
- c. Priorisation des thèmes par l’utilisationde poids relatifs
- 9. Zoom sur la priorisation par l’utilisationdu modèle de Kano
- 10. Zoom sur la méthode MoSCoW
- 11. Zoom sur la méthode WSJF
Planifier et estimer
- Des pratiques à ne surtout pas négliger
- Pourquoi la planification traditionnelle échoue
- Horizons de planification
- Outils d’estimation
- 1. T-Shirt sizing
- 2. Les story points
- 3. Alors, story point ou jh ?
- 4. Notion de vélocité
- 5. Comment initialiser la vélocité ?
- a. Mise en place d’un projet test
- b. Choisir au feeling
- c. Estimation de la vélocité à partirde l’historique
- 6. Qui estime ?
- 7. Une méthode pratique d’estimation :le Planning Poker
- a. Le déroulement du Planning Poker
- b. Bénéfices et risques
- c. Erreurs communes
- d. Découper pour bien estimer : AtelierCarpaccio
- 1. Avoir un objectif clair
- 2. Posséder un Product Backlog priorisé
- 3. Estimer le Product Backlog
- 4. Connaître la vélocité del’équipe
- 5. Définir la fin
- 6. Définir la durée des Sprints
- 7. Créer le plan de Release
La vie d'un Sprint
- Introduction
- Quelle durée pour les Sprints ?
- Doit-il y avoir un Sprint 0 ?
- Le rythme du Sprint : vue d’ensemble
- Préparation du Sprint
- 1. Environnement de travail
- 2. Équipe
- 3. Définition de « Terminé »
- Réunion de planification de Sprint
- 1. Pourquoi la présence du Product Owner est-elleimportante ?
- 2. Definition of Ready
- 3. Première étape : présentationdes User Stories
- 4. Deuxième étape : quel travail seraréalisé durant le Sprint ?
- 5. Troisième étape : comment réaliserle travail prévu ?
- a. Estimation des tâches
- b. Affectation des tâches
- 6. La gestion du temps
- 7. Et les corrections de bugs ?
- 8. Backlog Grooming
- 1. Un protocole à respecter
- 2. Une mêlée efficace et utile…
- 3. Le Scrum Master toujours à l’écoute!
- 4. Suivi de l’avancement
- 5. Je n’ai plus rien à faire !
- 6. L’objectif du Sprint sera-t-il atteint ?
- 1. Qui, quoi, combien de temps ?
- 2. Un objectif, une motivation
- 3. Démontrer ce qui n’est pas démontrable…
- 1. Une méthode pour vous aider
- 2. État d’esprit
- 3. Environnement de la rétrospective
- 4. Méthode numéro 1 : KickDrop Start
- 5. Méthode « classique »
- 6. Présentation « en étoile »
- 7. Le SpeedBoat
- 8. Autres méthodes
Tester en mode Agile
- Adopter Scrum : quel impact sur la stratégie de test ?
- Typologies de tests
- 1. Tests fonctionnels de validation
- a. Critères de validation
- b. Les données de tests et scénarios
- c. Les tests de validation et les User Stories
- 1. Tests fonctionnels de validation
- 2. Tests de non-régression
- 3. Tests d’IHM (interface homme-machine)
- 4. Tests fonctionnels « de bout enbout »
- 5. Tests de composants
- 6. Tests unitaires
- 7. Test-Driven Development
- 8. Acceptance Test-Driven Development
- 1. Trouver du temps pour l’écriture
- 2. Faut-il écrire les tests de toutes les UserStories ?
- 3. Comment écrire les tests ?
- 4. Definition of Done et tests d’acceptation
- 1. Le test fait partie de l’équipe
- 2. Testeur Agile : un métier en mutation
Conseils pour déployer Scrum
- Comment mener le changement vers Scrum ?
- État des lieux
- 1. Adoption des méthodes Agiles
- a. Scrum largement déployé
- b. Les motivations pour l’adoption de Scrum
- c. Comment Scrum est pratiqué ?
- d. Succès et challenges
- 1. Adoption des méthodes Agiles
- 2. Un bilan positif
- 1. Que faire des responsabilités existantes ?
- 2. La structure
- 1. Scrum n’est pas une approche structurée
- 2. Il n’existe pas de notion de planification
- 3. Scrum bannit la documentation
- 4. Avec Scrum, nous passons trop de temps en réunion
- 1. Résistance d’intérêt oupolitique
- 2. Résistance de confort
- 3. Résistance d’incapacité ou affective
- 1. Pour briser la glace…
- a. Le secret du succès
- b. On se classe par âge
- c. Le réseau social papier
Scrum à l'aide d'un logiciel
- Faut-il obligatoirement utiliser un logiciel ?
- Tour d’horizon des outils de gestion de projets Scrum
- 1. Jira
- 2. Axosoft
- 3. iceScrum
- 4. Tuleap
- Autres outils utiles
- 1. Story Mapping
- 2. Pour les rétrospectives d’équipesdistribuées : IdeaBoardz
- 3. Outils de collaboration d’équipe
- Conclusion
Aller plus loin
- Avant-propos
- Mise à l’échelle de Scrum
- 1. LeSS
- a. Les principes de base
- b. Qu’est-ce qui est différent de Scrum dansLeSS ?
- c. Notre avis sur LeSS
- 1. LeSS
- 2. SAFe
- a. Introduction
- b. Les fondations
- c. Le niveau « Équipe »
- d. Le niveau « Programme »
- e. Le niveau « Gestion de portefeuille »
- f. Notre avis sur SAFe
- 3. La méthode Spotify
- a. Description du modèle
- b. L’équipe
- c. Les tribus
- d. Les guildes et chapitres
- e. Notre avis sur le modèle Spotify
- 1. Différences entre les deux méthodes
- 2. Mixer ou non les approches…
- a. Quelques considérations générales
- b. Un hybride de plus en plus utilisé : ScrumBan
- c. Faire son choix…
- 1. Contradictions
- 2. Créer les conditions de la confiance
- 3. Répondre à un appel d’offres
- 4. Mise en place d’un plan d’assurance qualité (PAQ)
- 5. Contractualisation par Sprint
- a. Comment calculer le coût d’un Sprint ?
- b. Quid des User Stories non livrées ?
- c. Gestion des bugs et « non-validation » deUser Stories
- a. Coûts variables
- b. Coûts fixes, périmètrevariable
- c. Coûts fixes, périmètrefixe
- d. Coûts fixes, périmètrefixe mais avec ajustement
- e. Budget par itération
- f. Utilisation d’une marge de profit
- g. Mise en place de pénalités
- h. Travail collaboratif
- i. Money For Nothing (payer pour rien) et Change ForFree (changement offert)
Vérifiez vos connaissances
- Pourquoi ce questionnaire ?
- Les questions
- Les réponses
- L'heure du résultat
- Il est temps de se quitter