2. Introduction
Plus le projet est imprévisible, plus votre équipe est susceptible de
rencontrer des échecs successifs pendant sa gestion. Vous aurez alors
tout intérêt à choisir un développement dit “agile”, incrémental (ajouts
successifs) et itératif (cycles répétitifs), afin de vous adapter aux
changements.
2
3. Le manifeste agile
Les méthodes agiles sont issues initialement du manifeste agile
❏ Les individus et les interactions plutôt que les processus et les outils
❏ Le logiciel en fonctionnement plutôt que l’établissement d’une documentation complète
❏ La collaboration avec le client plutôt que la négociation du contrat commercial
❏ La réponse aux changements plutôt que le suivi de plans établis
3
4. Modèle Scrum
Scrum est une méthodologie agile pour le développement de logiciels. Il
décrit une série de cérémonies (réunions) qui doivent avoir lieu à intervalles
réguliers. Il définit également les rôles des différents participants.
L’intervalle régulier de scrum est appelé sprint.
Il est à la fois itératif, incrémental et agile.
4
5. Les fondements du modèle scrum
Selon le Guide Scrum, le cadre Scrum repose sur les trois piliers suivants :
5
8. Scrum master
❏ Il n’est pas un chef de projet, ni un développeur.
❏ Il n'exerce aucune autorité sur les membres de l'équipe de développement.
❏ Son objectif principal est de permettre à toute l'équipe de travailler sans
perturbation.
❏ Il encourage l’esprit d’équipe et maintenez la motivation.
8
9. Product owner
Votre client peut rencontrer plusieurs difficultés avec le Scrum :
● Manque de disponibilité pour le projet
● Manque d'expérience en gestion de projet agile
● Manque d'informations sur les utilisateurs
Le modèle Scrum propose un rôle de product owner !
le seul qui peut compléter ou modifier à tout moment la liste des
fonctionnalités.
● L'expression des besoins avec l’équipe
● La priorisation des besoins pour l'équipe
● La validation des résultats de l'équipe
9
10. Équipe de développement
Les membres de votre équipe de développement sont en charge des
opérations du projet. Ils livrent votre client à intervalles réguliers des
fonctionnalités complètes.
● Ses membres ont de multiples compétences.
● Ses membres sont pluridisciplinaires.
● Ses membres sont autonomes.
10
13. Sprint
❏ Le sprint consiste en une période de temps prédéterminée
❏ Il peut durer au maximum un mois.
❏ Sprint est le cœur du modèle scrum.
❏ A la fin de chaque sprint on délivre un incrément fonctionnel au
client.
13
14. Sprint planning
❏ Quelles seront les user stories à développer au cours de la prochaine
itération.
❏ Le scrum master limite la durée de cette réunion à 8 heures pour un
sprint d'un mois et à 2 heures pour un sprint d'une semaine.
❏ 2 sujets à couvrir dans cette planification:
● Le Quoi? (Les éléments du Backlog produit sélectionnés )
● Le Comment? (Le plan de livraison )
14
15. Daily scrum
Daily scrum: est une réunion quotidienne qui a généralement lieu le matin
et ne peut durer plus de 15 minutes. Pas une de plus !
on repondant aux questions:
➢ Sur quoi ai-je travaillé hier ?
➢ Sur quoi vais-je travailler aujourd’hui ?
➢ Quels sont les problèmes et leurs solutions ?
15
Chaque jour même heure et au même endroit.
16. Sprint review (1)
❏ À la fin de chaque sprint, la réunion de revue est organisée.
❏ A pour but d’inspecter l’ajout incrémental réalisé au cours du sprint
et d’adapter, si nécessaire, le carnet de produit.
❏ Elle permet de passer en revue l’Incrément du produit qui vient
d’être « terminé », et ainsi le valider
❏ Sa durée maximale doit être de 4 heures. S’il s’agit d’un sprint de
moins de quatre semaines, cette durée peut être plus courte.
16
17. Sprint review (2)
Voici des exemples de sujets à aborder pendant la sprint review :
● Déroulement du sprint
● Problèmes rencontrés
● Résolutions trouvées
● Questions sur l'incrément
17
Les parties prenantes participent ( stakeholders ) à cette réunion.
18. Sprint retrospective
❏ Mettre en évidence ce qui a bien marché au cours du sprint et ce
qui doit être amélioré lors du prochain sprint.
❏ Il dure 3 heures.
❏ En qualité de scrum master, vous actualisez un radar de
satisfaction et un plan d'action en animant cette réunion pour
l'équipe Scrum.
18
Aborder aux sujets personnels
19. Product backlog grooming
Encourager l'équipe Scrum à faire le raffinage du product backlog ou toilettage. (
cette réunion n’est pas officiel par le guide scrum ).
❏ Détectez les user stories qui n'ont plus aucun sens pour le projet.
❏ Formulez et estimez les nouvelles user stories si des besoins apparaissent.
❏ Réévaluez l'ordre de priorité des user stories dans le product backlog.
❏ Corrigez les estimations en fonction de nouvelles informations.
❏ Découpez les user stories qui pourraient candidater aux prochains sprints.
19
20. Les réunions et leur durée
20
Evenements Durée
Sprint maximum 1 mois.
Sprint Planning maximum 8 heures pour un sprint d'un mois,
Daily Scrum maximum 15 minutes,
Sprint Review maximum 4 heures pour un sprint d'un mois
Sprint Retrospective maximum 3 heures pour un sprint d'un mois
21. Notions
Sprint backlog: Votre sprint backlog réunit toutes les user stories à
développer pendant le sprint.
Le planning poker: Votre équipe doit estimer la complexité de
chaque user story avec le product owner.
Le tableau kanban: Vous allez afficher chaque user stories sur un
tableau divisé en 3 colonnes : "à faire", "en cours" et "terminé".
21
22. Notions
Vélocité: Additionnez les points des user stories terminées au cours
d'une itération.
Sprint d'échauffement: C’est une sprint d’essai lors de la préparation du
projet. afin de calculer la vélocité de l'équipe.
Incrément: C’est le résultat opérationnel de votre sprint.ce n’est pas
une maquette ou une preuve de concept.
22
23. Notions
Burndown chart: un graphe qui montre la somme totale de travail restant
dans le sprint backlog à n’importe quel moment du sprint.
Burnup Chart: un graphe qui permet d’analyser l’avancement du travail
réalisé par rapport à la globalité du projet prévu.
Méthode MoSCoW: Pour prioriser les user stories du sprint backlog avant le
début d'un sprint.
23
24. Notions
Pour évaluer la bonne priorisation d'un product backlog ?
● La méthode MoSCoW
● Le questionnaire matriciel de satisfaction
Comment évaluer la qualité des users stories et les tâches ?
● Pour les user stories: La grille de critères INVEST.
● Pour les tâches: La grille de critère SMART.
L'affichette de tableau kanban doit obligatoirement contient?
● La user story de référence
● La valeur de la user story
● La complexité de la user story
● La description des tâches à réaliser
● Les critères d’acceptation (au dos de l’affichette) 24
TransparenceVous devez garantir que toutes les informations relatives à la bonne compréhension du projet sont bien communiquées aux membres.
InspectionVous vérifiez à intervalles réguliers que le projet respecte les demande de votre client.
AdaptationVous encouragez la correction des dérives constatées et proposer des changements appropriés.
L’ouverture (d’esprit), apporte bienveillance dans les relations par l’écoute active et la prise en compte des avis de chacun
Courage: créer un environnement où l’échec sera accepté et sera considéré comme une occasion d’apprendre et de grandir