Le document présente l'expérience et les qualifications de Martin Lapointe en gestion de projets agiles, en mettant l'accent sur la méthode Scrum et ses valeurs. Il décrit les rôles au sein d'une équipe Scrum, le processus de planification des sprints, ainsi que les principales difficultés et avantages liés à l'agilité. Enfin, il aborde des concepts clés comme les user stories, les backlogs et la dynamique des équipes agiles.

1. Martin Lapointe, PMP, ScrumMaster
1

2. Martin Lapointe
 12 ans d’expérience en gestion de projets (PMBOK et Agiles)
2

3. 2009 Certification ScrumMaster complétée
2008 Certification PMP complétée
2003 Maîtrise courte en Technologie de l’information
Expériences:
 e-learning (Pharmaceutiques Américaines)
 Site Web de médias
 Sites e-commerce
 Plateformes SOA et géo-positionnement
 Applications bancaires
 Portail télécom avec portion BI
 Responsable Assurance Qualité Processus - Banque 3

4.  Agilité, un peu d’histoire
 Une définition
 Les valeurs Agiles
 Le jargon de cette nouvelle organisation
 La logique Scrum
 L’ingénierie logicielle
 Ce que l’on en dit…
 Les objections
 Etapes suivantes
4

5. Mais c’est quoi l’Agilité ?
Quelques synonymes :
alerte, habile, léger, rapide, souple, vif…
C’est un contenant de valeurs !
Agile
(Valeurs)
Avec entre autre :
 Scrum pour le pilotage Scrum
(Pilotage
 XP pour l’ingénierie logicielle Projet)
XP
(Ingénierie)
5

6. Les 4 valeurs du développement Agile :
 Individus et échanges plus que processus et outils.
 Produit fonctionnel plus que documentation.
 Collaboration du client plus que négociation du
contrat.
 Réactivité au changement plus que suivi d'un plan.
+ Les 12 principes du développement Agile
6

7. Un résumé :
 Un client à satisfaire
 Basé sur l’humain et la communication verbale
 Focus sur une partie limitée et maîtrisable
 Périodes de durées fixes
 Livraison d'un produit fonctionnel
 Qualité implicite et non-négociable
 Adaptation rapide au changement
7

8. Fixe Charge Délai Coût
Développement
logiciel Agile
Négociable Développement
logiciel
traditionnel
Délai Coût Charge
8

9. 9

10.  Le terme Scrum :
 Est emprunté au rugby et signifie mêlée.
 Il représente :
 Une équipe soudée, qui cherche à atteindre un but,
pour faire avancer le ballon pendant une mêlée.
10

11. 11

12. Le travail à réaliser est découpé en incréments
appelés « User Stories »
Le format :
 En tant que <rôle>
 Je veux <faire quelque chose>
 Dans le but de <obtenir de la valeur>
12

13.  Une User Story représente:
 Le besoin d’un usager
 La description d’une fonctionnalité
 Un item de planification
 Un élément de conversation
 Point de vue adopté non technique pour
identifier la valeur métier (Business value).
 Aspect narratif (voici ce qui se passe).
13

14.  Une bonne User Story respecte le principe
"INVEST":
 I – Independent (Indépendant)
 N – Negotiable (Négociable)
 V – Valuable (Apporte de la valeur)
 E – Estimable (Estimable)
 S – Small (Petit)
 T –Testable (Testable)
14

15. Un Product Backlog c’est :
 Le regroupement des
fonctionnalités à réaliser.
 La compilation de toutes
les User Stories par Epic.
 Une priorisation par la
Business value.
15

16. Le Sprint Backlog c’est :
 Une sélection de User Stories,
priorisée par le client, qui seront à
réaliser dans un Sprint.
 Les éléments les plus importants qui
représentent une valeur ajoutée.
 Des Users Stories découpées en
tâches et estimées par l’équipe.
16

17. Le burndown c’est :
 Un affichage graphique de la consommation des tâches du
projet pour piloter la santé du Sprint.
17

18. Un Scrum Board avec beaucoup de Post-it
18

19. 19

20. Product Owner (PO)
 Le Product Owner est le représentant des
clients et des utilisateurs.
 Son objectif est de maximiser la valeur du
produit développé.
 Il rédige les User Stories et prépare le Backlog.
 Il définit l'ordre dans lequel les fonctionnalités
seront développées.
 Il prend les décisions importantes.
 Il valide les développements.
20

21. ScrumMaster
 Le ScrumMaster est responsable de la méthode. Ce n'est pas un Chef
de projets, c’est un facilitateur.
Parmi ses attributions :
 Fait disparaître les obstacles !
 Communiquer la vision et les
objectifs à l'équipe.
 Apprendre au PO à rédiger le Backlog.
 Faciliter les rituels de Scrum.
 Coacher l'équipe de développement.
 Aider à l'adoption de l’Agilité au niveau de l'entreprise.
21

22. Membres de l’équipe
 L'équipe est auto-gérée et pluridisciplinaire.
 Il n'y a pas de notion de hiérarchie interne : toutes les décisions sont prises
ensemble.
 L'équipe s'adresse directement au PO.
 Une équipe agile est composée de 7+/- 2, donc entre 5 et 9 personnes max.
 Une équipe pluridisciplinaire comporte toutes les compétences suivantes:
▪ Développeurs logiciel et progiciel
▪ Testeur
▪ Intégrateur Frontend
▪ Architecte technique et de solution
▪ Architecte de l’information
▪ DBA
22

23. 23

24. Sprint Planning
 Requis :
 Toute l’équipe 100% disponibles
 le Backlog priorisé
 les User Stories « Ready » à expliquer à l’équipe
 Les scénarios de tests
 L'équipe négocie le Sprint avec le PO, estime les User Stories du
Sprint et planifie les tâches en équipe.
24

25. Daily Scrum – Stand-up
 Au quotidien, le stand-up, permet à l’équipe de faire un point sur les
tâches en cours et sur les difficultés.
 Cette réunion dure 15 minutes maximum.
 Cette réunion a pour but la synchronisation de l'équipe.
 A tour de rôle, chaque membre répond à 3
questions :
▪ Qu'est-ce que j'ai fait hier ?
▪ Qu'est-ce que je compte faire aujourd'hui ?
▪ Quelles sont les difficultés que je rencontre ?
25

26. La Démo
Tout le monde participe
 Objectif : valider le logiciel
développé pendant le Sprint.
 L'équipe effectue une démo à
son auditoire.
 Feedback des participants.
26

27. Rétrospective du Sprint
 Faite en interne avec l'équipe par le
ScrumMaster.
 Objectif :
 Comprendre ce qui s’est passé dans le Sprint
▪ les gains, succès
▪ les erreurs, problèmes
 Prendre des décisions pour
s'améliorer au prochain Sprint.
27

28.  Une équipe Agile planifie un
produit par couches.
 Les couches sont les
caractéristiques ou des
fonctionnalités du produit.
 Les couches seront ajoutées
de façon itérative.
Rérérence: Jeff Patton, www.AgileProductDesign.com 28

29.  L’évolution itérative en Scrum. Un produit complet intégrant
le changement à chaque itération.
L’approche incrémentale demande
de formaliser l’idée avec des estimés
et exigences.
Rérérence: Jeff Patton, www.AgileProductDesign.com 29

30. Développement d’un site d’emploi
Source: Pyxis -
http://fr.slideshare.net/p
yxistech/iiba-story-
mapping-jscv2-12286011
30

31.  Estimation : durant le Sprint planning l’équipe
va utiliser le Poker Planning.
 Consiste à attribuer des
points de complexité.
 Une valeur de référence sera
attribuée à une User Story.
 L’équipe vote avec des cartes
spéciales.
http://www.mountaingoatsoftware.com/topics/planning-poker
31

32.  User Stories complétées = points
Evaluer une vélocité sur plusieurs Sprints.
Sur le long terme la vélocité va se stabiliser :
Sprint 0 Sprint 1 Sprint 2 Sprint 3
10 points 20 points 25 points 26 points
32

33.  Prochaine étape = Release Planning à grande échelle
 Technique : Story mapping
temps
nécessaire
première release
Plus ou
deuxième release
optionnalité
moins
optionel troisième release
Rérérence: Jeff Patton, www.AgileProductDesign.com
33

34.  Le Scrum est avant
tout dédié à la
gestion de
projets.
 L’équipe de
développement doit
s’organiser autour
des principes de
développement
XP.
34

35. Les principes XP
1. Client sur site
2. Jeu du Planning ou Planning poker
3. Intégration continue
4. Petites livraisons
5. Rythme soutenable
6. Tests de recette (ou tests
fonctionnels)
7. Tests unitaires
8. Conception simple
9. Utilisation de métaphores
10. Refactoring (ou remaniement du
code)
11. Appropriation collective du code
12. Convention de nommage
13. Programmation en binôme
35

36.  Trop souvent, l’Agilité fait face à la pensée
magique
mais…
 Non, ça ne va pas coûter moins cher pour la même chose
 Non, ça ne va pas prendre moins de temps pour la même chose
 Non, on ne parle plus d’exigences
36

37. Avantages du Scrum
 Entièrement développé et testé pour de courtes itérations
 Simplicité des processus
 Règles définies clairement
 Augmentation de productivité
 Organisation personnelle
 Chaque équipe a son lot de responsabilités
 Amélioration de la communication
37

38. Difficultés reliées au Scrum
 Changement, Changement, Changement.
 Change les habitudes, peut déstabiliser plusieurs.
 Rend visible les maillons faibles très rapidement, ce qui crée de
la résistance au changement.
 Trouver un équilibre entre anticipation et adaptation.
 Pas de garanties au delà du Sprint.
 L’incompréhension de la disparition des specs traditionnelles
pour des User Stories.
38

39. Pourquoi une entreprise passerait au Scrum ?
 Time to market ! Livrer des itérations de produits plus rapidement et
devancer la compétition.
 Eviter le développement de fonctionnalité inutiles ($$).
 Elimine les périodes de stabilisations ($$) puisque chaque Sprint
livre en Production.
39

40. 40

41.  Nous travaillons sur un système complexe, nous devons faire l’architecture en premier.
 En scrum, le focus est mis sur une architecture émergeante mais rien n’empêche de mettre en place
une base en place et trouver un équilibre entre anticipation et adaptation.
 Ecrire les tests en premier prend plus de temps et je n’ai pas de temps à perdre.
 Il est évalué que faire les tests en premier prend environ 15% plus de temps. Par contre des études
faites chez Microsoft ont aussi démontrés que les bugs étaient en déclin de 24 à 38%.
 Scrum, c’est trop de réunions !
 En effet la pratique de Scrum engendre un certain nombre de réunions, et que ces dernières
mobilisent toute l’équipe. Toutes les réunions sensibilisent et responsabilisent au projet l’équipe. De
plus elles sont structurées, timeboxées (limitées dans le temps), et ont un but précis connus de tous
les participants.
 C’est mon code, je ne veux pas fixer les bugs des autres.
 Personne ne veut mal paraître en face des autres. Il est reconnu que les équipes qui pratique les
« collective ownership » écrivent du code plus propre et avec moins de bugs.
41

42. Mike Cohn
 mountaingoatsoftware.com/scrum
Ken Schwaber
 controlchaos.com
Manifeste Agile
 agilemanifesto.org
Agile Alliance
 agilealliance.com
Scrum Alliance
 scrumalliance.org
42