BB_Scrum_1_Refresh

Pierre Becquart - 27 avril 2016

A propos de ScrumUn rappel des notions de base… à toutes fins utiles

© La présente présentation est basée sur différentes sources libres de droits dont principalement : la présentation « Introducing Scrum » de mai 2007

de Mike Cohn de www.mountaingoatsoftware.com - +1 (720) 890-6110 et « Le Guide Scrum » de juillet 2013 par Ken Schwaber et Jeff Sutherland de www.scrum.org

Sommaire

1. Généralités

2. Le modèle Scrum

3. Les Sprints

4. Les rôles

5. Les événements

6. Les indicateurs

Scrum & Documentation Brown Bag - 27/05/2016 Slide 2 of 41

1. GÉNÉRALITÉS

Let’s do it the Scrum way!


Les 4 valeurs du Manifeste Agile :

Processus et outilsPersonnes et interactions >

Suivi d'un planAdaptation au changement >

Source : www.agilemanifesto.org

DocumentationLogiciel qui fonctionne >

Négociation à partir d'un contrat

Collaboration avec le client >

Scrum & Documentation Brown Bag - 27/05/2016Slide 4 of 41

Le rugby plutôt que la course-relais

L’approche course-relais pour le développement de

produits… ne répond plus aux besoins du marché en

termes de délais et de flexibilité.

Une approche holistique comme au rugby

- où l’équipe essaie d’avancer en restant unie, en se

passant le ballon de main en main - peut mieux

satisfaire les exigences de compétitivité d’aujourd’hui.

Hirotaka Takeuchi, Ikujiro Nonaka, Janvier 1986.


Scrum en résumé

Plus efficace et plus amusant

• Plus de valeur-métier (business value) en un temps plus court.

• Une release fonctionnelle est livrable (*) à la fin de chaque sprint (1 à 4 semaines).

• C’est le business qui définit les priorités.

• L'équipe s’auto-organise pour se répartir les exigences en fonction des priorités et la meilleure façon de les produire.

(*) A chaque fin de sprint, tout le monde peut voir fonctionner le dernier stade du produit et décider soit de le livrer dans l'état, soit de continuer à l'améliorer.


Domaines d’application du Scrum

• Jeux vidéo

• Sites Web

• Logiciels pour PDA

• Téléphonie mobile

• Infrastructure réseaux

• Logiciels commerciaux

• Développements internes

• Développements custom

• Systèmes embarqués

• Applications financières

• Systèmes sécurisés SIL

avec exigences de

disponibilité 24/7 @ 99.99%

• Systèmes réglementés de

type FDA

• Logiciels de contrôle de

satellites

Constat:

Scrum est compatible avec les métiers réglementés… à condition

d’être persévérant, rigoureux et discipliné dans son déploiement.


2. LE MODÈLE SCRUM



Le modèle scrum


Un Backlog Produit

• Les exigences sont rassemblées dans un backlog produit sous

forme de user stories.


Un Product Owner

• Le backlog produit est alimenté et priorisé par le product

owner.


Du Backlog Produit au Sprint Backlog

• Une sélection de user stories priorisées du backlog produit

sont transférées dans le sprint backlog pour être décomposées

en tâches et développées au cours de sprints d’une durée de 1

à 4 semaines.


Le Sprint Planning

• Lors de la réunion de sprint planning, chacun des membres de

l’équipe prend une ou plusieurs tâches et quantifie le nombre

d’heures par tâche et le degré de complexité. La répartition du

travail se fait en cherchant l’efficacité maximale dans un esprit

d’équipe (consensuel).

• Un calendrier d’allocation des ressources est maintenu par le

R&D manager ou le Scrum Master et est visible de tous.


Le Tableau de Bord

• Un tableau de bord affiche clairement qui fait quoi et

l’avancement de chaque tâche.

Sprint 4/2016 – 25/02 > 10/03 But du sprint : gestion utilisateurs

Membre A faire En cours En test Terminé

Christophe A.

François

David

Christophe G.

Raphaël

US1

US2 US4US5

US6US8

US10

US11

US13US14

US15 US16


Equipe autogérée

• L’équipe fonctionne en autogestion. Chacun est

coresponsable et aussi polyvalent que possible. Pendant les

sprints, la hiérarchie traditionnelle s’estompe. Les chefs, les

experts et autres seniors partagent leurs connaissances pour

aider les autres membres à réussir leur tâche.


Peu de règles mais des règles respectées

• Utilisation de règles simples et génériques permettant de

conserver la dynamique agile du projet (dont la définition de

terminé ou DoD)


3. LES SPRINTS



Le Sprint : incrément releasable du produit

• Les projets Scrum progressent par une série de sprints

• Chaque sprint a un objectif clair pour tous

• La durée d’un sprint est de 1 à 4 semaines (*)

• La durée des sprints est constante (rythme prédictible)

• Un nouveau sprint débute immédiatement après le précédent

• Le produit (partiel) est conçu, codé et testé pendant le sprint

• Les changements d’exigences en cours de sprint sont interdits

• Aucun compromis sur la qualité (versatilité, pas précipitation)

• Périmètre du sprint renégociable avec le Product Owner en

cours de sprint si nécessaire (obstacle imprévu)

(*) fonction de a) du temps de réponse requis par le client (pour la prise en compte de nouvelles

exigences et pour la résolution de bugs prioritaires) et b) des temps moyens nécessaires pour

« terminer » une release.Scrum & Documentation Brown Bag - 27/05/2016 Slide 18 of 41

Au générique du sprint, il y a…

* Ceremonies

** Artifacts

• Product Owner

• Scrum Master

• Équipe R&D

… des rôles

• Sprint planning

• Standup quotidien

• Sprint review

• Rétrospective

• Backlog grooming

… des événements*

• Product backlog

• Sprint backlog

• Burndown charts

… des indicateurs**


4. LES RÔLES



Le Product Owner

• Voix du client, du marché, des opportunités

• Lui seul est responsable (*) de la définition des

fonctionnalités du backlog produit et doit s’assurer que celui-ci

est bien connu et compris par tous les membres de l’équipe

• Définit la roadmap avec les dates et contenus des release

• Définit les priorités dans le backlog en fonction de la valeur-

métier (business value)

• Ajuste les fonctionnalités et les priorités à chaque sprint si

nécessaire

• Accepte ou rejette les tâches considérées comme terminées sur

base des critères de la « définition de terminé » (DoD).

(*) L’équipe ne peut recevoir des tâches d’aucune autre

personneScrum & Documentation Brown Bag - 27/05/2016 Slide 21 of 41

Le Scrum Master

• Au service du Product Owner, de l’équipe

et de l’organisation

• Responsable de la mise en œuvre de Scrum (dont formations)

• Veille à ce que tous les intervenants respectent bien les valeurs

et les pratiques de Scrum (facilitateur des événements, gardien

du respect des horaires et des temps impartis – boxed time)

• Aide l’équipe à s’autogérer et développe sa pluridisciplinarité

• Élimine les obstacles

• S'assure que l'équipe soit complètement opérationnelle et

productive. La protège des interférences extérieures.

• Facilite une coopération poussée entre tous les rôles et

fonctions de l’organisation (autres services, dont le QA)


L’équipe de R&D

• Typiquement de 5 à 10 personnes

• Regroupant tous les rôles

o Architectes

o Concepteurs

o Développeurs

o Spécialistes IHM/GUI

o Testeurs, etc.

• A temps plein de préférence

o Exceptions possibles (administrateur, traducteurs, rédacteurs…)

• L’équipe s’autogère

• Sauf événements imprévus ou planifiés, la composition de l’équipe

ne change pas pendant un SprintScrum & Documentation Brown Bag - 27/05/2016 Slide 23 of 41

5. LES ÉVÉNEMENTS

(ceremonies)



Sprint planning

But du sprint

Liste des tâches

Conditionsmétier

Capacitéde l'équipe

Backlogde produit

Technos

Produitactuel

Périmètre

• Analyser et évaluer le backlog de

produit

• Définir le but du sprint

Planification

• Décider comment s'y prendre

(conception)

• Créer la liste des tâches à partir

des user stories du backlog produit

• Estimer les tâches en heures et en

complexité

Sprint planning (1/2)


Sprint planning (2/2)

• L'équipe choisit, à partir des user stories du backlog produit, les

tâches qu'elle s'engage à terminer (suivant la définition de terminé,

DoD).

• Une liste des tâches, le sprint backlog, est créé

o Les user stories sont découpées en tâches de conception à haut niveau

o Les tâches de conception sont attribuées collectivement et le temps

nécessaire pour les terminer est estimé (essentiellement par le « preneur »

en accord avec l’équipe)

• Coder la couche persistance (8 heures)

• Coder l'IHM (4)

• Ecrire les test (4)

• Coder la classe foo (6)

• Maj les tests de performances (4)

User Strory

En tant que touriste potentiel dans

la région, je veux voir les photos

des hôtels

Ventilation tâches


Standup quotidien (1/2)

• Paramètreso Rigoureusement tous les jours à 10:00

o Ponctualité ! (respect des autres)

o Time box de 15 minutes (surveillé par SM)

o Debout au pied du tableau de bord

• Chacun prend la parole pour répondre à 3 questions:

Qu'ai-je fait hier ?1

Que vais-je faire aujourd'hui ?2

Y a t-il un obstacle qui me freine ?3


Standup quotidien (2/2)

• Pas pour débattre de solutions ni

résoudre des problèmes > à voir après

avec les personnes concernées

• Tout le monde est le bienvenu

Si un participant externe souhaite

prendre la parole, il en informe le

Scrum Master qui peut accepter ou

refuser suivant l’impact sur la durée

de 15 minutes et selon que le sujet

entre dans le cadre ou non.

• Il s'agit d’informer toute l’équipe, pas de faire un reporting au

Scrum Master

Les engagements pris lors du sprint planning le sont devant tous les pairs, et

non pas devant un supérieur


Sprint review (1/2)

• Paramètreso Chaque dernier jour du sprint

(souvent le vendredi)

o Time box 1h par semaine de sprint

(surveillé par SM)

o Temps de préparation maxi: 2 heures

o Toute l’équipe participe (PO indispensable)

o Tout le monde est le bienvenu

o Dans une salle de réunion avec projecteur

o Préférer les démos aux présentations

• Objectif

o Le Product Owner prend connaissance de ce que l’équipe a terminé, de ce

qui ne l’a pas été et pour quelles raisons


Sprint review (2/2)

• Déroulement

o Chaque membre de l'équipe présente

ce qu‘il a fait pendant le sprint

(autant que possible par démo sur écran)

o L’équipe R&D expose ce qui s’est bien

passé ainsi que les problèmes

rencontrés pendant le sprint et comment

ces problèmes ont été résolus (ou non).

o Analyse du graphe de burndown. Heures réelles par rapport au heures

planifiées et explication des déviations (SM)

o Mise à jour du calendrier du projet, des ressource nécessaires, des efforts

particuliers à consentir, des impacts sur les budgets (PO)

• Si le temps restant le permet

o Screening du backlog produit pour préparer le sprint planning du sprint

suivant (qui a généralement lieu le lundi suivant)


Rétrospective (1/2)

• Paramètreso Idéalement après chaque sprint

En pratique souvent tous les 3 ou 4 sprints

o Time box entre 30 minutes et 3 heures suivant la période couverte

o L’équipe de R&D et le Scrum Master participent, les autres sont bienvenus

o Idéalement, debout devant le tableau de bord

• Objectifo Valoriser les leçons apprises, évaluer et décider d’améliorations à apporter

au processus

• Déroulemento Chaque membre évoque les choses qui marchent bien et celles qui

pourraient marcher mieux

o Compilation dans des listes par le Scrum Master

o Chaque membre peut jeter des fleurs virtuelles à ceux qu’il veut féliciter pour

une réalisation ou qu’il veut remercier (pour de l’aide reçue p/ex)


Rétrospective (2/2)

• La collecte du feedback peut se faire en demandant à chaque

membre de l’équipe ce qu’il/elle aimerait :

Commencer à faire

Arrêter de faire

Juste une façon parmi d'autres

de faire une rétrospective.

Continuer à faire


6. LES INDICATEURS

(artifacts)



Backlog produit (1/3)

• Liste des user stories

et autres jobs à réaliser ou tout

ce qui va entraîner du travail pour l'équipe de R&D

• Les user stories sont formulées de telle façon que chaque élément

apporte de la valeur aux utilisateurs ou clients du produit

• Le contenu du backlog produit et les priorités sont exclusivement

définis par le Product Owner

• L’équipe de R&D est responsable des temps de réalisation

estimés. Ceux-ci peuvent faire l’objet de discussions avec les

Product Owner, mais le dernier mot revient aux personnes qui

effectueront le travail



• Les priorités peuvent être

changées à chaque sprint

• Le contenu du backlog produit évolue en cours de réalisation

• Les user stories évoluent - s’affinent - en cours de réalisation,

notamment lors des Backlog Groomings

• Le backlog produit continue d’exister pendant toute la durée de vie

du produit, pas uniquement pendant son développement initial

• Si une user story demande plus que la durée d’un sprint pour être

développée, il est préférable de la décomposer en tâches plus

petites. La granulosité des tâches doit tenir compte de ce qui peut

être terminé en 1 sprint (d’où l’importance du choix de sa durée).



User stories et tâchesTemps de réalisation

estimés

En tant que hôte, je peux faire une réservation 3

En tant que hôte, je peux annuler ma réservation 5

En tant que hôte, je peux changer la date de ma

réservation3

En tant qu'employé de l'hôtel, je peux imprimer un rapport

de revenu par chambre8

En tant que fournisseur de logiciel, je souhaite que la

gestion des exceptions soit améliorée8

…. 30

…. 50


Sprint Backlog (1/2)

• Lors du Sprint Planning, n'importe qui peut suggérer l’ajout, la

suppression ou la modification de tâches listées dans le Sprint

Backlog. Le dernier mot revient cependant au Product Owner.

• Chacun s'engage de terminer (DoD) les tâches qu'il a choisies

• Le travail n'est jamais attribué par un autre

• L'estimation de ce qui reste à faire est ajustée en temps réél

• Si une tâche n'est pas assez claire, définir une méta-tâche avec

plus de temps et la décomposer en tâches de plus petite

granulosité


Sprint Backlog (2/3) – temps planifiés

Tâches Lun Mar Mer Jeu VenTot

sprint

Coder l’IHM - FBE 8 4 8 0 0 20

Coder la couche business - CAL 16 12 8 4 0 40

Tester l’intégration - PCD 0 0 8 8 8 24

Ecrire l’aide en ligne - PBT 12 0 0 0 0 12

Ecrire la classe foo - CGD 8 8 8 8 8 40

Tracer les erreurs – PCD/FBE 0 0 8 4 0 12

Totaux 34 24 40 24 16 148


Sprint Backlog (2/3) – temps restants le mercredi

Tâches Est Lun Mar Mer Jeu Ven

Coder l’IHM 20 20 12 6

Coder la couche business 40 40 32 24

Tester l’intégration 24 24 24 24

Ecrire l’aide en ligne 12 12 5 5

Ecrire la classe foo 40 40 32 32

Tracer les erreurs 12 12 12 9

Totaux 148 148 117 100


Burndown

0

20

40

60

80

100

120

140

160

Te

mp

s n

éce

ssa

ire

re

sta

nt (h

)

Projet XYZ - Graphe Burndown Sprint #1

Heures restantes

Temps estimé

Tendance actuelle

Lun Mar Mer Jeu Ven +1 +2


MERCI !



Documents

BB_Scrum_1_Refresh