Introduction à l’Agilité
Scrum, ScrumMaster, User Stories, Backlog… Ces mots vous sont peut-être familiers ? En vogue depuis plusieurs années, l’Agilité est en expansion rapide sur les projets informatiques.
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
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
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
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
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
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