Scrumby thebookv3

SCRUM by the Book

Scrum, méthode agile dédiée à la gestion de projets

13/09/2010 Philippe Launay [email protected] Monville – [email protected] Philippe Launay [email protected]

12/10/20122

Merci aux Sponsors


12/10/20123

Qui sommes nous…

Philippe

LAUNAY

Coa

ch A

gile

& t

eam

Coo

rdin

ator

Con

sult

ant A

gile

Alexis

Monville


12/10/20124

5 minutes


12/10/20125

un produit


12/10/20126

1 à 4 semainesplanificationréunion quotidiennedémonstrationrétrospectiveordonnerles plus importantescollaboreradapteraméliorerfonctionnalités

TODO DOING DONE


12/10/20127

Méthodes agiles


12/10/20128

Scrum

Scrum est une méthode de gestion de projet simple pour gérer des projets complexes.

Conçue à l’origine pour le développent de logiciels, Scrum est aussi utilisé dans d’autres secteurs d’activités.

Conçue pour améliorer grandement la productivité dans les équipes auparavant paralysées par des méthodologies plus lourdes.

Scrum ne s’occupe pasd’ingénierie.

Scrum veut dire « mêlée ».Scrum est la méthode Agile

la plus populaire.


12/10/20129

Gérer un projet c’est …

Gérer la relation d’un client etdu ou des fournisseurs

Gérer la réalisation de la vision du client


12/10/201210

Le projet idéal …

Plan

tempsT0 T0 + 6 mois T0+12 mois

Analyse

Développement

Documentation

Conception

Tests

Proj

et I

Déploiement

Go live


12/10/201211

Les débuts du projet

Projet sur les railsUn contrat clair, bien détailléUne équipe motivée Un client rassuré


12/10/201212


12/10/201213

Pendant ce temps là ….

L’expression des besoins n’a pas fourni les besoins réels du client

Premier problème d’architectureCertains pré requis ont été sous estiméDifficulté technique a été mal évaluéeProblème de disponibilité pour couvrir

un autre projet plus urgent


12/10/201214

Pas de soucis

Plan modifié, chevauchements pour lisser les « petits » retards …pour finalement déraper


Analyse

Développement

Documentation

Conception

Tests

Proj

et I

Déploiement

Go live


12/10/201215

Pas de soucis

Plan modifié, chevauchements pour lisser les « petits » retards …pour finalement déraper


Analyse

Développement

Documentation

Conception

Tests

Proj

et I

Déploiement

Go live


12/10/201216


12/10/201217

Conclusions…

Un projet en retard permet le chevauchement des différentes étapes

Alors pourquoi pas le faire dès le départ?


12/10/201218

Le nouveau plan … itératif

Faire un peu de tout en même tempsAnalyse

Développement

Documentation

Conception

Tests

Proj

et

Déploiement

Go live Version finale

Qualité

Rollout & Packaging

Installation Site

Version intermédiaire

Chaque sprint contient un peu de chacune des étapes du projet

traditionnel

Livraison intermédiaire à la

fin de chaque sprint

Sprin

t

On garde le jalon de fin du projet

traditionnel


12/10/201219

SCRUM : Un cadre de gestion léger pour gérer des projets

Des rôles Le responsable produit le facilitateur les membres de l’équipe

Des artefacts La liste à faire Produit / De l’itération Les courbes d’avancement La liste des obstacles

Un processus jalonné de cérémoniesUne planificationUn suivi du reste à faire

Product OwnerEquipe

UtilisateursFacilitateur

Stake Holders


12/10/201220

Mêl

ée Q

uotid

ienn

e

Le processus

Un processus itératif basé sur ce que l’on appelle un sprint – un effort de 15 à 30 jours concentré sur des objectifs fixes, qui se répètent.

Chaque itération améliore la valeur du produit, apporte de nouvelles fonctionnalités ou des améliorations, qui peuvent être livrées au client.

2 à 4 semaines

24 h

Backlog produit Backlog Itération Itération

Plan

ning

iter

atio

n

Produit

Dém

o

Rét

rosp

ectiv

e

temps

Planifier Faire Contrôler Agir


12/10/201221

Collaboration avec le client

On organise des réunions avec le clientEnfin production, service et client dans le même bateau

ObjectifsEtablir une relation de confianceComprendre le besoin fonctionnelDiscuter les besoins fonctionnelsPrioriser les besoins fonctionnels

Touver un responsable produit


12/10/201222

Le product owner

Recense les besoins dans un Product backlogExprime la vision pour le produitPrend en compte la gestion

des risquesExprime la valeur des fonctionsDoit être priorisé de façon absolue

Bas

sePr

iorit

éH

aute

Prio

rité • Histoire 1

• Histoire 2• Histoire 5• Histoire

10

• Histoire 8

• Histoire 3

• Histoire 14• Histoire 6

• Histoire 7

• Histoire 4

• Histoire 11• Histoire 13• Histoire 9


Prod

uct B

ackl

og

8

5

13

20

3

20

40

20

13

8

20

5

13

3

5

Peut être supprimée

• Histoire 13

Ajouts à tout moment


• Histoire 19

Sprint en

cours


12/10/201223

Chaque itération est un micro projet

En début d’itération, l’équipe planifie et s’engage a atteindre son objectif En fonction de la vélocité précédente En fonction de la capacité pour le sprint a venir

Les estimations sont faite collectivement par les équipes Utilisation d’estimation relative (Story Points) Session d’estimation avec le poker card game

L’équipe s’auto organise pour atteindre son objectifL’équipe fait une rétrospective à la fin de chaque itération pour

trouver les axes d’améliorations


12/10/201224

Itératif mais planifié

Un plan de releases basé sur le backlog produit En tenant compte de la vitesse de l’équipe En tenant compte du type de fin

(date, périmètre fonctionnel, etc.) Une réunion une fois avant le début de chaque itération

Estimation / ré estimation Estimation nouvelle storiesAdapter le plan en fonction de l’avancement

Bas

sePr

iorit

éH

aute

Prio

rité • Histoire 1


10

• Histoire 8

• Histoire 3


• Histoire 7

• Histoire 4



Product Backlog

8

5

13

20

3

20

40

13

20

13

20

5

13

20

20Sprint Sprint

Release

Version partielle utilisable Version finale

Sprint Sprint Sprint Sprint

Release

Sprint Sprint

Version partielle utilisable Version finale

• Histoire 1• Histoire 2• Histoire 5• Histoire

10

temps


14

• Histoire 4

• Histoire 6

• Histoire 7• Histoire

11• Histoire 13• Histoire 9


• Histoire 1• Histoire 2• Histoire 5• Histoire

10• Histoire 3• Histoire 8• Histoire

14

• Histoire 4

• Histoire 6

• Histoire 7• Histoire

11• Histoire 13• Histoire 9



12/10/201225

Le Scrum Master

Il dirige l’équipe, résous ou élimine les Obstacles et travaille constamment pour s’assurer que l’équipe est dans les meilleures circonstances pour atteindre les objectifs fixés pour le sprint.

Il est un mélange de coach, de réparateur et de gardien.

Il est un bouclier pour l’ équipe.

Il doit aider l’équipe à rester concentrée sur l’objectif


12/10/201226

L’équipe

Réalise le travail nécessaire à résoudreles problèmes ou nécessaire pour satisfaireles nouveaux concepts.

est normalement constituée de 7 personnes (+/- 2).

Les membres décident comment faire le travail et commentle répartir. Il n’y a pas de rôles spécifiques, tout le monde doit être capable d’échanger une tâche avec un autre membre.Cela n’empêche pas d’avoir tout de même des membres avec plus d’expertises sur un sujet particulier.

Equipe


12/10/201227

Suivre l’avancement du projet

Les courbes de suivi du reste à faire Prévision en fonction de la vélocité et/ou de la capacité Suivi de l’avancement de la release, montre le reste à faire en story points, ou en heures

tempsSprint 1 Sprint 2 Sprint 3 Sprint 4

100

Storypoints

Vélocité idéale

Effort restant à

faire

En avance

En retard


12/10/201228

Définition de « Fini »

Nécessité de connaitre le « fini »chaque équipe doit avoir sa propre définition

Importance de définir quand une fonctionnalité est finie

Le point de vue peut–être différent : Selon les acteurs (développeur, utilisateur, testeur) Selon le niveau (tâche, Fonction, Itération, Release)

Il faut une définition claire, ou une listed’état permettant de savoir quelle est la situation

Utiliser cette définition comme garantie dequalité

His

toire

Tâch

esIté

ratio

nR

elea

se

• Toutes les itérations finies• Plus de reste à faire avant le passage

en production

• Tests d’acceptations vérifiés• Documentation réalisée• Release notes réalisées• Acceptée par le product owner

• Couverture du code par des Tests (Junits)

• Existence de tests automatisés• Vérification qualité du code• Documentation du code

• Toutes les fonctions sont finies• Contrôles de fin d’itération faits• Produit partiel livré• Rétrospective faite, actions

documentées


12/10/201229

Merci de votre attention


12/10/201230

Questions?

Documents

Scrumby thebookv3