Vous êtes sur la page 1sur 72

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


http://itsadeliverything.com/revisiting-the-iterative-incremental-mona-lisa
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
http://www.youtube.com/watch?v=q_R9wQY4G5I
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.