Agile - SCRUM
L’agilité valeurs principes et pratiques
21/02/2015
Contrat de groupe
Pause?
Avant de commencer
PC?
On se fixe notre contrat de groupe ensemble
Questions
Portable? On s’engage à le respecter
Agenda
Sprint1: L’agilité en Théorie
Comprendre l’agilité
La constitution agile
Les lois de l’agilité
Les Méthodologies agiles
Sprint2: L’agilité en Pratique: SCRUM
Définition et la Théorie SCRUM
Les rôles SCRUM
Les artéfacts SCRUM
Les cérémonies SCRUM
Agenda
Sprint3: SCRUM en Pratique
Les bonnes pratiques SCRUM
Le workflow SCRUM
Release Planning
Atelier « Construire ma base de lancement de fusées »
Écrire des User Stories
Construire un Product Backlog
Estimation et planification
Workflow SCRUM
Amélioration Continue
C’est quoi l’agilité à votre avis ??
L’Agilité : fausses Définitions
L’agilité, c’est la liberté de faire à sa façon
L’agilité, c’est simple donc c’est facile
L’agilité peut s’appliquer à tout
Les méthodes agiles sont des méthodes de développement rapide
Dans les méthodes agiles, on donne beaucoup plus de pouvoir aux
développeurs
Les méthodes agiles exigent des développeurs seniors
Les méthodes agiles sont réservées aux “petits” projets
L’agilité: définition
Définition philosophique
L’agilité c’est la composante majeure d’un large
mouvement d’auto-management, où la résolution de la
complexité de détail est confiée à la compétence et à la
motivation rationnelle du personnel d’exécution.
L’agilité a émergé d’une recherche d’amélioration
continue se basant sur l’intelligence collective des
équipes qui la pratiquent
L’agilité: définition
Définition pragmatique
Etre agile est le fait de développer un logiciel
d’une grande qualité fournissant
le maximum de valeur ajoutée
le plus tôt possible
L’agilité n’est pas simplement
une réaction au changement
la flexibilité
la réactivité
La constitution agile: les valeurs
Utah Février 2001
Naissance du mot agile
Formulation du manifeste agile par les 17 Pioneers de l’agilité
Manifeste pour le développement agile
Nous découvrons comment mieux développer des logiciels par la
pratique et en aidant les autres à le faire
Ces expériences nous ont amenés à valoriser
Les individus et leurs interactions plus que les processus et les outils
Un produit opérationnel plutôt qu’une documentation pléthorique
La collaboration avec le client plutôt que la négociation de contrat
L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments, mais privilégions les
premiers
L’agilité s’organise en
Valeurs
Les fondements de l’agilité
Principes
«Principles are underlying truths that don’t change under time and space »
Tom and Mary Poppendieck
Pratiques
« Practices are the application of principles to a particular situation. »
Tom and Mary Poppendieck
Les principes Agiles
7 principes pour être AGILE
L’agilité: les principes (1/7)
Deliver as fast as possible/ Livrer aussi vite que possible
Satisfaire le client en livrant tôt et régulièrement des logiciels utiles
Livrer fréquemment une application fonctionnelle.
Focus sur les fonctionnalités avec le plus de business value
Travailler séquentiellement et non parallèlement
Gestion des retards
A B
Planning Initial C D
Week 1 Week 2 Week 3 Week 4
A B
Approche traditionnelle de la gestion des retards
C D
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
Approche agile de la gestion des retards
A B
A B C D
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
L’agilité: les principes (2/7)
Decide as late as possible / Retarder l’engagement
S‘engager seulement sur ce qui est claire et estimable
Planifier les itérations suivant les fonctionnalités priorisées
Ajuster le planning suivant la vitesse de l’équipe
Accepter les changements client, même tardivement
L’agilité: les principes (3/7)
Eliminate Waste / Eliminer les gaspillages
Favoriser la simplicité : l’art de maximiser la quantité de travail à ne pas faire
Faire un refactoring permanent. Tout ce qui est inutile est source de problèmes
Se concentrer sur les fonctionnalités les plus importantes pour l’utilisateur final
Pourcentage de l’utilisation des fonctionnalités
L’agilité: les principes (4/7)
Build Quality In / Intégrer la qualité dès la conception
Mettre l’accent sur l’excellence technique et la qualité de la conception
Le travail par itération et la qualification du produit à chaque itération
permet d’améliorer la qualité le plutôt possible
Un produit fonctionnel est la meilleure unité de mesure de la progression du
projet.
Avenant
Prévisionnel Réel
Cycle en V
Qualification
Correction
Agile Livraison
Qualification
L’agilité: les principes (5/7)
Amplify Learning/ Améliorer l'apprentissage
L’apprentissage est accéléré par
la pratique des itérations courtes: détection des problèmes et recherche des solutions
Le feedback régulier des clients: détection des anomalies à temps ajustement des
efforts sur les améliorations futures
Instaurer la culture de l’amélioration continue
The Deming Cycle
L’agilité: les principes (6/7)
Favoriser la communication
Transmettre l’information en privilégiant une conversation en face à face.
Favoriser une collaboration quotidienne entre les gens du business et les
R&D
L’agilité: les principes (7/7)
Respect People/ Responsabiliser l'équipe
Bâtir le projet autour de personnes motivées. Croire en leur
capacité à faire le travail.
Promouvoir un rythme de développement soutenable
La pyramide traditionnelle La pyramide agile
Moral noir Rythme de
des employées développement soutenable
Délai Budget Qualité Valeur
figé figé figé figée
Contour figé Délai et budget fixes
Contour variable
L’agilité en pratique
Une science pas si nouvelle...
1947 Kanban Workflow de travail bien défini
Kanban & Toyota Production Systems / Lean Système par flux tiré
Taiichi Ohno invente Kanban chezToyota limitation de la quantité à stocker
Amélioration continue
1987 Lean / Lean Thinking Respect des personnes
Invention du terme "Lean" chez MIT issue de la
Remettre tout en cause
méthode de production chez Toyota
Embrasser le changement
1995 Scrum transparence,
Framework de développement itératif
Un cycle de développement itératif,
présenté par KenSchwaber et JeffSutherland
l’amélioration continue à chaque cycle
1999 eXtreme Programming (XP) 13 pratiques d’ingénierie logicielle
créé par Kent Beck, Ward Cunningham and Ron Jeffries
Le manifeste agile 4 valeurs /12 principes
2001 Implémentés essentiellement par
Écrit par 17 pratiquants des méthodes ci dessus Scrum
2003 Lean Software Development
De l’industrie vers
2007 Kanban For Software Development l’IT
Les pratiques agiles
Plus Normatif Plus adaptatif
XP (13) Scrum (9) Kanban(5)
• Un représentant du client sur site • Scrum Master • Visualiser les éléments de
• Planning game • Product Owner travail (Kanban board)
• Intégration continue • Team • Limiter le travail en cours
• Release fréquente • Sprint Planning (WIP)
• Rythme soutenable • Daily Scrum • Système par flux tiré
• Tests de recette • Demo • Workflow de travail
• Tests unitaires • Retrospective prédéfini
• Conception simple • Backlog de produit • Amélioration collective
• Utilisation de métaphores • Burndown Chart
• Refactoring du code
• Convention de nommage
• Programmation en binôme
• Appropriation collective du code
SCRUM : définition et
théorie
Qu’appelle-t-on une startup ??
startup : définition
Une start-up est « une institution humaine conçue
pour créer un nouveau produit ou service dans des
conditions d’incertitude extrême. »
Eric Ries, auteur de « The Lean Startup »
startup : définition
“ A 'start-up' is a company that is confused about
what its product is,
who its customers are,
how to make money.”
— QUORA
Top-rated answer for ‘Start-Up’
complexité des systèmes
Dans un environnement d’incertitude extrême,
quelle est la méthode de gestion de projet qu’il faut choisir?
Les méthodes de gestion de projet
Les méthodes de gestion classiques
méthode en cascade
méthode du cycle en V
Les méthodes Agile
Scrum
Kanban
XP
…
Méthode en Cascade
vs
méthodes agile
Les problèmes des méthodes classiques
Réponses aux demandes de changements
– Elles prennent beaucoup de temps
Ce qui implique dépassement des délais et du budget!
Suivi de l’avancement
– Souvent inexistant, au mieux, inexact ou erroné!
Ce qui implique l’effet tunnel
Les fonctionnalités demandées
– Généralement, ne convergent pas ou difficilement!
Ce qui implique l’insatisfaction du client
My expectation My specification My product
Attente client – produit final
Scrum : définition
Complexité
Changements
Productivité
Scrum est un Framework
Créativité
Produit avec la plus
grande valeur possible
Scrum : théorie
Scrum se base sur la théorie du contrôle empirique de processus, ou l’empirisme.
Expériences
Connaissances
Faits Prises de
connus décision
Scrum : théorie
Trois piliers permettent d’implémenter le contrôle empirique de processus.
Transparence
Inspection
Adaptation
Scrum : théorie
Approche itérative
et incrémentale
Optimiser la Contrôler le
prédictibilité risque
Scrum : théorie
Approche incrémentale
Approche itérative
Approche itérative
et incrémentale
Source : Jeff Patton / Steven Thomas
[Link]
Scrum : en bref
•Divisez votre organisation en petites équipes
multidisciplinaires et auto-organisées.
•Divisez votre travail en une liste de petits livrables concrets
Triez cette liste par priorité et estimez la taille relative de chaque
élément
•Divisez le temps en petites itérations de durée fixe
faites une démonstration à l’issue de chaque itération avec un produit
potentiellement livrable
D’après le livre « KANBAN ET SCRUM –
TIRER LE MEILLEUR DES DEUX »
Scrum : en bref
•Mettez à jour et optimisez le planning de la version
Révisez les priorités en collaboration avec le client, sur la base de ce
que vous avez appris après chaque itération.
•Optimisez le processus
Capitalisez les bonnes pratiques et améliorez les moins bonnes après
chaque itération
D’après le livre « KANBAN ET SCRUM –
TIRER LE MEILLEUR DES DEUX »
Scrum : en bref
un grand groupe passant beaucoup de temps sur la
construction d'une grande chose
une petite équipe passant un peu de temps à construire une
petite chose… mais intégrant régulièrement pour voir l'ensemble.
D’après le livre « KANBAN ET SCRUM –
TIRER LE MEILLEUR DES DEUX »
Scrum : pratique ??
3 rôles
Product Owner, Scrum Master, la Team
3 cérémonies
Sprint Planning, Daily Scrum, Sprint Review
3 artefacts
Product Backlog, Sprint Backlog, L’Incrément
3 bonnes pratiques
User Stories, Planning Poker, Scrum Board
Sprint : le cœur de SCRUM
Une itération, un cycle de développement élémentaire
De courte durée entre 1 et 4 semaines. La durée est fixe pour tous les sprints d’un projet
Le contour du sprint doit être fixé au préalable.
Toute modification doit être injectée dans le
Sprint d’après
Se termine par un produit potentiellement
livrable
Chaque sprint doit ajouter de la valeur au
Produit
SCRUM : les rôles
Le product owner
Représentant des clients:
Travaille sur la satisfaction du client
Collecte et négocie les priorités des exigences
Maximise la valeur Business du système
Expert produit
établit la vision produit
Maintient une liste des exigences bien priorisée
planifie les releases et livraisons
Membre de la grande équipe:
participe aux cérémonies SCRUM et répond aux questions fonctionnelles
valide fonctionnellement les développements
Met à jour le planning suivant la capacité de l’équipe
L’équipe de développement (team)
Experts techniques
pluridisciplinaire, a toute les compétences pour réaliser son projet
doit participer à la montée en compétences de chaque membre
Auto-organisée
prend ses propres décisions (contour et estimation)
s’engage à les tenir
Autogérée
Disciplinée
Toujours à la quête d’une meilleure performance via l’amélioration continue
Le SCRUM master
Expert SCRUM :
Assure sa compréhension et sa mise en application
Planifie et organise les cérémonies
Gère les indicateurs SCRUM pour l’équipe
Facilitateur:
Aide l’équipe à gérer son effort et la charge de travail demandée,
Aide le Product Owner à gérer le Product Backlog et le Release Plan
Veille à éliminer les points de blocages
Coach de l’équipe:
l’isole des contraintes extérieures
la motive et la mène à l’autonomie
Garantit un rythme soutenable.
Scrum: Composition de l’équipe
Le maximum de la taille d’une équipe efficace est entre 3-9 personnes
Ajouter des personnes à un projet en retard, retarde le projet encore plus
La team, quelques vérités basiques
Motivation de l’équipe
Les Hommes sont plus productifs quand ils se gèrent eux même: ils prennent
les engagements faits par eux plus au sérieux que les engagements faits pour eux.
Sous pression de « travailler dur », les Hommes réduisent automatiquement
la qualité de leur travail.
Les Hommes font du mieux qu’ils peuvent
Performance de l’équipe
Une Equipe est plus productive que le même nombre d’individus
Les Hommes travaillent mieux quand ils ne sont pas interrompus
Les Equipes s’améliorent quand ils résolvent leurs propres
problèmes
Et le manager?
Manager traditionnel
C’est quelqu’un qui guide et dirige l’équipe
Manager agile
C’est quelqu’un qui accompagne et aide l’équipe à s’améliorer
Imposer devient faire confiance
Contrôler devient faciliter
Diriger devient accompagner
Exiger devient demander
SCRUM : les artéfacts
Scrum: La User Story
C’est la traduction d’une exigence client en une phrase simple
Chaque demande de fonctionnalité est traduite sous forme de petite histoire
L’histoire précise essentiellement :
Pour qui on fait la fonctionnalité (end user)
Qu’est ce que l’utilisateur veut faire
Pourquoi il veut faire ceci
Scrum: La User Story
Elle est confirmée par des critères d’acceptation rédigés au
même moment que l’histoire
Son format standard est:
En tant que <role>, je veux <faire quelque chose> pour atteindre <valeur métier>
Elle doit respecter les critères INVEST suivants:
• I - Independent. des autres User Stories autant que possible
• N - Negotiable. dans les réunions de planning poker et de planification du Sprint.
• V - Valuable. source de valeur pour le Client final ou l‘utilisateur
• E - Estimable. Sa complexité est estimée par les équipes;
• S - Sizeable. suffisamment petite pour être traitée par l’équipe sur une seule itération.
• T - Testable. Elle doit être testable, à travers la validation de ses critères d’acceptation
Exemple de User Story fonctionnelle
Histoire:
En tant qu’équipe support, je veux que mon CRM intègre une “aide en ligne”
pour que les utilisateurs y accèdent avant de soumettre leurs tickets
Critères d’acceptation: Vérifier que
•le lien vers « l’aide en ligne » est fonctionnel
•le lien vers « l’aide en ligne » est facilement accessible aux utilisateurs
•le lien vers « l’aide en ligne » est présent dans l’application qui permet
d’entrer les tickets
•l’utilisateur peut revenir facilement de « l’aide en ligne » à l’application de
départ, soit le CRM soit l’application qui permet d’entrer les tickets
52/38
Les artéfacts de SCRUM
Le Backlog produit
C’est une liste ordonnée de tout ce qui pourrait être requis dans le produit
C’est l’unique source des besoins pour tout les changements à effectuer dans le
produit
Le Product Owner est le propriétaire et le seul responsable du Backlog produit
Le product backlog évolue au fur et à mesure que le projet avance
Le product backlog contient pour chaque US
Une description
Un ordre
Une estimation de l’effort
Une estimation de la valeur Business
Le Backlog produit
Le PO créé le backlog. EPIC/
le priorise
le maintient à jour
Fonctionnalité
Minimum de Minimum de Minimum de
fonctionnalité fonctionnalité fonctionnalité
livrable livrable livrable
Le PO créé les histoires
fonctionnelles
Histoire Histoire Histoire Histoire Histoire La Team créé les histoires
techniques
La Team crée les tâches
Tâche Tâche Tâche
Les premières fonctionnalités sont généralement plus détaillées que les suivantes
Il ne faut créer que les tâches du sprint à venir
Exemple de Backlog produit
Backlog Produit Backlog priorisé
En tant qu‘utilisateur je En tant qu‘utilisateur je
veux m’enregistrer veux m’enregistrer
Exigences Produit
En tant qu‘utilisateur je En tant qu‘utilisateur je
veux éditer mon profil veux éditer mon profil
Gestion des
utilisateurs En tant que support je
veux pouvoir chercher un En tant que manager je
utilisateur veux recevoir des rapports
En tant que support je en format html, pdf et excel
Rapport en format veux pouvoir effacer un En tant que support je
utilisateur veux pouvoir chercher un
html, pdf et excel
utilisateur
En tant que manager je
veux recevoir des rapports En tant que support je veux
en format html, pdf et excel avoir un manuel pour
Manuel des toutes les opérations
opérations En tant que support je veux En tant que manager je veux
avoir un manuel pour que 100 connexions
toutes les opérations simultanées soient supportées
100 connexions En tant que manager je veux En tant que support je
que 100 connexions veux pouvoir effacer un
simultanées simultanées soient supportées utilisateur
Le Backlog du Sprint
Le backlog du sprint est un sous ensemble du Backlog du produit
Il contient les items qui permettent de réaliser l’objectif du sprint.
Il représente le travail nécessaire que l’équipe prévoit pour livrer les
fonctionnalités demandées.
C’est un plan suffisamment détaillé pour permettre de suivre l’avancement
pendant le sprint
Il peut être mis à jour par l’équipe pendant le sprint s’il s’avère qu’un travail
est nécessaire pour atteindre l’objectif du sprint
Les estimations des charges du travail restant sont mises à jour
quotidiennement pour donner le plus de visibilité sur la progression du sprint
Le sprint Backlog appartient à l’équipe.
Exemple du sprint backlog Backlog
Sprint 1
Tâche 1
Backlog priorisé
Sprint 1
En tant qu‘utilisateur je
veux m’enregistrer
Tâche 2
En tant qu‘utilisateur je
veux éditer mon profil
Tâche 3
En tant que manager je
Sprint 2
veux recevoir des rapports
en format html, pdf et excel
Tâche …
En tant que manager je veux
que 100 connexions
simultanées soient supportées
Tâche 1
En tant que support je
Sprint 3
veux pouvoir chercher un
utilisateur
En tant que support je
veux pouvoir effacer un Tâche 2
utilisateur
Sprint …
En tant que support je veux
avoir un manuel pour Tâche …
toutes les opérations
L’incrément
L’incrément est la somme :
des éléments du Product Backlog finalisés et livrés pendant le sprint
la valeur cumulative des incréments précédents.
À la fin du sprint, l’incrément doit être dans un état utilisable et
potentiellement livrable.
Scrum: Les indicateurs
Il faut faire attention à ce qu’on mesure
A la fin on recevra exactement ce qu’on voudra mesurer
Scrum: La vélocité
La vélocité de l’équipe est le nombre de points d’effort réalisé
Il faut s’orienter dans la planification d’un sprint à la vélocité
de l’équipe
Le PO utilise la vélocité pour ajuster la roadmap produit
Scrum: Les indicateurs d’avancement
Burndown Chart
Burndown Chart du sprint se
base sur les heures des tâches
Mesure quotidienne pour voir si
on est conforme à l’engagement
du sprint
Burnup Chart de la release se base
sur les points des histoires
Permet de détecter un retard assez
tôt
SCRUM : les cérémonies
Le Sprint Planning
La cérémonie de sprint Planning
Réunion en début de chaque Sprint.
Le P.O présente à l’équipe le sprint Backlog
L ’équipe décortique chacune des histoires en tâches
L ’équipe estime la durée de chacune des tâches. La somme des
tâches estimée ne doit pas dépasser la capacité réelle de l’équipe.
L’équipe s’engage à livrer les tâches estimées au plus tard en fin de
sprint.
Exemple de décortication en tâches
Répartition en tâches lors du Sprint
planning
Développement
Histoires Ecrire les coté serveur 8h
Tests
unitaires 4h Développement
En tant qu‘utilisateur je
GUI 6h
veux m’enregistrer
5 Schéma
Base de Tests
Grande Histoire données 4h d’intégration 2h
En tant qu‘utilisateur je
Epic veux éditer mon profil
2
Gestion des
utilisateurs 13 En tant que support je L’implémentation d’une histoire
veux pouvoir chercher doit cadrer dans un sprint
un utilisateur
3
L’estimation en temps permet
En tant que support je de lisser le contenu du sprint
veux pouvoir effacer par rapport à la disponibilité de
un utilisateur 5
l’ équipe
Le daily Meeting
Réunion quotidienne de l’équipe Scrum
Ne doit pas dépasser 15 minutes et doit être menée
debout
Les membres de l’équipe doivent répondre aux trois
questions suivantes:
1. Ce qu’ils ont fait la veille
2. Ce qu’ils comptent faire aujourd’hui
3. S’ils ont eu des points de blocage
A quoi sert le daily au fait?
Le daily Meeting
Le sens du daily
Recentrer sur l’objectif des tâches
Une visibilité claire sur toutes les tâches en cours
Une visibilité sur ce qui reste à faire pour atteindre l’objectif du sprint
Compréhension du projet/produit à partir des tâches des autres
Feedback de l’équipe sur les problèmes
Communication fluide avec les autres
Entraide des uns aux autres pour résoudre les
points de blocage
Sentiment d’engagement/Responsabilité: terminer la tâche avant le daily
Suivi de l’équipe: montée en compétence, besoins
Agile Simulation - Part 20
The Daily Standup
[Link]
Le sprint review : la démo
La démo
Réunion en fin de chaque sprint
Son objectif: L’équipe présente toutes les histoires achevées
durant le sprint le résultat du Sprint
Le PO et toutes les parties prenantes inspectent le produit
A la fin de la démo le PO calcule la vélocité effective du Sprint et réajuste le
plan de release
A la fin de la démo le Product Backlog est actualisé (UserStory achevées,
Ajout de nouvelles UserStory émergentes, anomalies, etc.)
Les BurndownChart sont réinitialisés ou remis à jour
Le sprint review : La rétrospective
Réunion en fin de chaque sprint
Son objectif: l’amélioration continue de tous les aspects:
ressources, processus, technique
L’équipe revoie les évènements du sprint écoulé
1. ce qui s’est bien passé,
2. ce qui n’a pas marché,
3. les points à améliorer,
4. les erreurs à ne plus faire et
5. les actions à entreprendre.
Le sprint review : La rétrospective
Responsabiliser les ressources par rapports aux points qui leur
appartiennent
Ne jamais les blâmer.
Le processus a permis l’erreur changer le processus pour l’éviter
Discuter et éliminer tous les malentendus, problèmes personnels
Renforcer l’esprit d’équipe, d’appartenance par des jeux agiles
Outil pour la Rétrospective:
le ROTI (Return On Time Invested)
Vote sur le déroulement de la réunion….
Lever la main et donner une note de 1 à 5
• 5 doigts :Excellente. Voilà une super réunion dont moi et l’équipe allons
bénéficier. Ça valait bien plus que le temps qu’on y a passé
• 4 doigts : Bonne. Voilà un atelier Voilà une super réunion au dessus de la
moyenne. J’ai gagné plus que le temps que j’y ai passé
• 3 doigts : Juste moyenne. Je n’ai pas perdu mon temps sans plus.
• 2 doigts : Utile mais ça ne valait pas à 100% le temps que j’y ai passé
• 1 doigt : Inutile. Je n’ai rien gagné, rien appris. J’ai perdu 4 heures.
