Formation scrum v1.0

Formation Scrum

Mahfoud Amiour
Directeur de projet
Expert Agile Scrum

06 63 53 43 74
mamiour@softenia-solutions.com
www.softenia-solutions.com

Directeur de projets Freelance

18 ans d’expériences en génie logiciel
Mahfoud AMIOUR
8 ans d’expériences en gestion de projet
Agile/Scrum
06 63 53 43 74
mamiour@softenia-solutions.com Certifié Scrum Master : CSM
www.softenia-solutions.com
Certifié Product 0wner : CSPO

Plan de la présentation
Introduction à l’agilité
Généralités Scrum
Le framework Scrum
Les règles
L’équipe Scrum
Les artefacts
Les événements
Gestion de projet avec Scrum
Estimer avec Scrum
Planifier avec Scrum
Pratiques d’ingénierie pour Scrum



Approche classique
Modèle en cascade
Principales limitations
Approche Agile
Motivations
Un peu d’histoire
Exemples de méthodes
Les valeurs
Les principes
Les caractéristiques

© 2012 SOFTENIA Solutions 4


L’approche classique • L’approche classique

Modèle en cascade

6-12 mois

Recueil Analyse Tests
des & Codage &
Besoins Conception Validation

Produit
final



Limitations du modèle en cascade • L’approche classique
• Limitations

Modèle devenant inadapté
Difficulté de réagir aux changements
Les besoins doivent être connus à l’avance
Validation trop tardive
Effet tunnel
o Le client doit attendre la fin du projet pour avoir une valeur métier tangible
o Feedback tardif



Limitations

Taux d’échec des projets très élevé*
Seuls 16% réussissent
53% sont problématiques
o Hors délais
o Hors budgets
o Ne répondent pas aux besoins
31% sont abandonnés

*Source : Standish group (Chaos report)



• Limitations

Des produits qui ne répondent pas aux besoins*
45% des fonctionnalités jamais utilisées
20% rarement utilisées
20% réellement utilisées
Les raisons?
Les besoins évoluent
A vouloir fixer tout le périmètre dès le départ, on y inclut des choses
inutiles

Source : Standish group (Chaos report)



L’approche Agile : Motivations • L’approche Agile
• Motivations

Répondre aux limitations du modèle en cascade
Proposer un model mieux adapté
Objectifs
Respecter les délais
Réduire le « time to market »
Réduire les risques
Améliorer la qualité
Permettre d’intégrer le changement
Faire plus avec le même budget
Motiver les équipes de développement


Améliorations constatés avec les méthodes • L’approche Agile

Agile • Motivations

Quelques chiffres*

Amélioration constatée % de réponses

Satisfaction de l’utilisateur 56%
Amélioration de la productivité 41%
Respect des délais 40%
Respect du budget 16%
Amélioration de la qualité 75%
Satisfaction des équipes de développement 36%

*Source : Enquête réalisée par le SUG 2009



Un peu d’histoire • L’approche Agile
• Historique

A partir de A partir de
1986 1991 1994 1995 2001

Aptitude au • Itération • Spécialisation • Pratiques Standardisation
Changement • Incrément des rôles d’ingénierie • Valeurs
Auto organisation • Adaptation • Prescription • Estimation • Principes
Imbrication des des réunions consensuelle
Phases • Processus • Reporting visuel
légers

Scrum, FDD, XP,
The new new game RAD RAD2, BDDSM Manifeste Agile
ASD



Exemples de méthodes • L’approche Agile
• Exemple de méthodes

Scrum
eXtreme Programming
Lean
Kanban
Rapid Application Development
Dynamic Systems Development Method
Feature Driven Development
Adaptative Software Development
Crystal Clear



4 valeurs Agile* • L’approche Agile
• Les valeurs

1 Les individus et leurs interactions
plus que les processus et les outils

4 L’adaptation au changement 2 Des logiciels opérationnels
4 valeurs

4
plus que le suivi d’un plan plus qu'une documentation exhaustive

3 Collaboration avec le client
plus que la négociation d'un contrat

* Source : Manifeste Agile



12 principes Agile* • L’approche Agile
• Les principes

1. Satisfaire le client
2. Accepter le changement
3. Livrer fréquemment
4. Travailler avec l’utilisateur
5. Personnes motivées
6. Dialogue en face à face
7. Le logiciel est la mesure d’avancement
8. Rythme constant
9. Excellence technique
10. La simplicité
11. Equipe auto organisée
12. Inspection régulière

* Sources : Manifeste Agile



Caractéristiques de l’approche Agile • Caractéristiques

Un modèle de gestion de projet
Itératif
Incrémental
Empirique
Orienté valeur métier
Estimation & Planification multi-niveaux



Un processus itératif • Caractéristiques

Itération Itération Itération …… Itération Produit
final

Produit partiel exploitable

Planification Analyse
Déploiement

Conception

Tests & QA Codage



Un processus Incrémental • Caractéristiques

Itération Itération Itération …. Itération

Produit
final

Produit partiel exploitable



Un Processus Empirique • Caractéristiques

Théorie de l’empirisme
La connaissance vient de l’expérience
Prise de décision basée sur des éléments connus
Trois piliers
Transparence
Inspection
Adaptation

S’adapter et progresser tout au long du projet : PDCA
Plan
DO
Check
Adapt



Un Processus Empirique • Caractéristiques

PDCA : Processus d’amélioration continue

Adapt Plan

Check Do
Adapt Plan

Check Do

Pente de progrès



Une planification multi-niveau • Caractéristiques

La planification est un processus continu
Plusieurs niveaux de planification

Vision du produit

Roadmap

Release
Itération

Quotidien



Introduction à l’agilité Origines
Généralités Scrum Caractéristiques
Le framework Scrum Cycle de vie du projet Scrum
Les règles
L’équipe Scrum
Les artefacts
Les événements
Estimer avec Scrum


Origines de Scrum • Origines

1986
Nouvelle méthode : « The New New game »
Début des années 90
Emploi du terme Scrum
Introduction de la méthode dans plusieurs entreprises
1995
Formalisation de la méthode : Schwaber et Sutherland


Scrum : Généralités

Scrum : Caractéristiques • Caractéristiques

Framework de gestion de projet Agile
Itératif
Incrémental
Empirique
Centré valeur métier
Planification multi-niveaux


Un Framework de gestion de projet Agile • Caractéristiques

Composants du Framework

Règles

Equipe
Framework Scrum Artefacts
Scrum

Evénements


Processus Itératif • Caractéristiques

Itération = Sprint
Le projet avance par une série de Sprints successifs
La durée du Sprint est fixe
2 à 4 semaines


Processus Incrémental • Caractéristiques

Chaque Sprint produit un logiciel partiel « Fini »
potentiellement exploitable : Incrément
Testé
Validé
Livrable en production


Processus Empirique • Caractéristiques

PDCA à plusieurs niveaux
Planification du Sprint
Mêlée quotidienne
Revue du Sprint
Rétrospective du Sprint
Transparence
Artefacts de gestion visibles
Radiateur d’information


Orienté valeur métier Caractéristiques

On fixe

Délai Coûts

On vise à maximiser Périmètre


Cinq niveaux de planification • Caractéristiques

Vision Roadmap Release Sprint Quotidien

Release1
Backlog
de Sprint1
fonctionnalités

Jour J
Jour J
Sprint2
Release2 J J J J J J J …
1 2 3 4 5 6 7
Sprint3

Release3 Sprint4



Cycle de vie du projet Scrum • Cycle de vie du projet Scrum

• Backlog initial
Phase de • Montage de l’équipe
Préparation • Estimations
• Architecture, etc.

Planification de • Plan de la release
• Nombre de Sprints
la release • Périmètre fonctionnel
• Dates des Sprints

Déroulement des
Sprints
Sprint

…

Sprint
Produit final



Déroulement du Sprint • Cycle de vie du projet Scrum

Planification du
Sprint
Déroulement des
Sprints
Mêlées
Sprint quotidiennes Travailler
sur
… Le Sprint suivant
Sprint

Sprint

Revue du
Sprint

Rétrospective
du Sprint



Le framework Scrum
Les règles
L’équipe Scrum
Les artefacts
Les événements
Estimer avec Scrum

Les règles

Les règles

Pratiques et procédures à suivre
Issues des expériences sur des milliers de projets
Quelle est l’utilité?
Fixer les règles du jeu dans le projet
Lier les événements, les rôles et les artefacts

Introduites tout au long de la présentation


Les règles

Exemples de règles

Chaque réunion Scrum a une durée maximale
La taille du Sprint est fixe
Le périmètre du Sprint ne doit pas changer en cours de route


Les règles

Conseil

Les règles doivent être appliquées dans leur globalité
Ne pas les changer avant d’être sûr de leur bonne application
Se servir des réunions de rétrospective pour discuter/adapter
les règles



Le framework Scrum
Les règles Les rôles
L’équipe Scrum Constitution de l’équipe Scrum
Les artefacts
Les événements
Estimer avec Scrum

L’équipe Scrum

L’équipe Scrum : Plan

Les rôles
Vue d’ensemble
Product Owner
ScrumMaster
Equipe de développement
Parties prenantes

Constitution de l’équipe Scrum
Les membres de l’équipe
Les valeurs de l’équipe
Facteurs de réussite
Multidisciplinarité
Atelier : Team Building


L’équipe Scrum

Les rôles Scrum • Les rôles

Formalisent les responsabilités dans le processus Scrum
Ce ne sont pas des positions dans l'entreprise
Permettent à chacun de bien connaître ses responsabilités
dans le projet


L’équipe Scrum

Les rôles : vue d’ensemble • Les rôles
• Vue d’ensemble

Product Owner

ScrumMaster Equipe de
Les Rôles
SM développement

Parties
prenantes*


L’équipe Scrum

Product Owner : caractéristiques • Les rôles
• Le Product Owner

Responsable du produit
Représente le client et les utilisateurs
Une personne, pas un comité
Disponible pour l'équipe
Le seul habilité à gérer et prioriser les besoins


L’équipe Scrum

Product Owner : responsabilités • Les rôles
• Le Product Owner

Gestion du Backlog du produit
Gestion de la release
Interactions avec le client
Validation des résultats
Collaboration avec l’équipe


L’équipe Scrum

Le ScrumMaster : caractéristiques • Les rôles
• Le ScrumMaster

Responsable du processus Scrum envers
le Product Owner
l’équipe de développement
L’organisation
Leader au service de l'équipe
Ne possède pas d'autorité hiérarchique
Interface avec le management


Le Framework Scrum

Le ScrumMaster : responsabilités • Les rôles
• ScrumMaster

Envers l’équipe de développement
Coacher l’équipe
Aider à l’élimination des obstacles
Faciliter la tenue des réunions Scrum
Guider l’équipe à créer des produits de qualité


Le Framework Scrum

• Le ScrumMaster

Envers le PO
Trouver les techniques pour gérer le backlog du produit
Faciliter la tenue des événements
Communiquer/rappeler la vision à l’équipe de développement


L’équipe Scrum

• Le ScrumMaster

Envers l’organisation
Guider l’organisation dans l’adoption de Scrum
Planifier l’implémentation de Scrum
Aider les employés à comprendre Scrum
Agir comme un agent de changement


L’équipe Scrum

L’équipe de développement : Caractéristiques • Les rôles
• L’équipe de développement

Auto-organisée et autonome
Multidisciplinaire
Toutes les compétences nécessaires sont présentes
o Développeurs, Testeurs, Analystes, Architectes, DBA ...

Responsable collectivement
Taille
5-9 membres (développeurs Scrum)


L’équipe Scrum

L’équipe de développement : responsabilités • Les rôles
• Equipe de développement

Réaliser les tâches
Tenir la mêlée quotidienne
Participer aux événements Scrum
Définir les pratiques d'ingénierie
Livrer des produits de qualité
Estimer les éléments du Backlog
Définir et gérer le planning du Sprint
Identifier les tâches
Estimer les tâches
Tenir le planning à jour


L’équipe Scrum

Les parties prenantes • Les rôles
• Parties prenantes

Rôle non officiel dans Scrum
Mais indispensable
Exemples
Le client
Les utilisateurs directs et indirects
Le management
Les personnes impactés par le déploiement et l’exploitation
…


L’équipe Scrum

L’équipe Scrum : Plan

Les rôles
Vue d’ensemble
Product Owner
ScrumMaster
Parties prenantes

Constitution de l’équipe Scrum
Les membres de l’équipe
Les valeurs de l’équipe
Facteurs de réussite
Multidisciplinarité
Atelier : Team Building


L’équipe Scrum

Constitution de l’équipe Scrum • Constitution de l’équipe

Parties prenantes

ScrumMaster Product Owner
SM

Equipe de
développement


L’équipe Scrum

Les membres de l’équipe Scrum • Constitution de l’équipe

Product Owner
ScrumMaster
Personne différente du PO
Profils polyvalents
Chaque membre a un domaine d’excellence + des compétences
partielles

Profils en T


L’équipe Scrum

Les valeurs de l’équipe • Constitution de l’équipe

Partagent les mêmes valeurs
Engagement
Courage
Respect
Transparence
Jouer collectif


L’équipe Scrum

Les valeurs de l’équipe : L’engagement • Constitution de l’équipe

Poules du projet
Cochons du projet
o Parties prenantes
o Product Owner
o ScrumMaster
o Equipe de développement


L’équipe Scrum

Facteurs de réussite • Constitution de l’équipe

Doter le Product Owner d’un réel pouvoir
Priorisation des exigences
Prise de décision
Un ScrumMaster
Au service de l’équipe
Non un chef
Autogérée
Multidisciplinaire


L’équipe Scrum

Facteurs de réussite • Constitution de l’équipe

Equipe de développement autogérée
L’équipe gère elle-même sa façon de travailler
Personne ne peut dicter à l’équipe comment procéder
Equipe de développement Multidisciplinaire
Toutes les compétences sont présentes de façon équilibrée
o Conception, codage, test, documentation, etc.
Les membres sont polyvalents : Profiles en T


L’équipe Scrum

Facteurs de réussite : Les enjeux • Constitution de l’équipe

Comment transformer un groupe d’individus en une équipe
cohérente est soudée?
Comment bâtir une équipe polyvalente?
Comment améliorer l’efficacité de l’équipe?

La gestion de l’équipe doit être au centre de
la transformation Agile


L’équipe Scrum

Multidisciplinarité : Profiles en T • Constitution de l’équipe

Les membres de l’équipe de développement
o Peuvent être experts dans certaines domaines
o Possèdent des compétences secondaires qui leur permettent de réaliser des tâches
hors leur domaine d’excellence

Exemples
Profil B
Profil A JAVA BDD T Conception
E
Test BDD Conception Architecture
J S
A T
V S
A


L’équipe Scrum

Multidisciplinarité : Equilibre des compétences • Constitution de l’équipe

Que pensez vous de cette équipe

Architecture Développement BDD Tests Intégration
& .NET fonctionnels
conception
Marie Connait Connait Connait

Pierre Connait Connait Connait

Marc Connait Connait Connait Connait

Rémi Connait Connait Connait

Céline
Luc Connait Connait

Equipe de généralistes


L’équipe Scrum

Multidisciplinarité : Equilibre des compétences • Constitution de l’équipe


& .NET fonctionnels
conception
Marie Expert

Pierre Expert Expert

Marc Expert

Rémi Expert Expert

Céline Expert

Luc Expert

Equipe d’experts


L’équipe Scrum

Multidisciplinarité : Equilibre des compétence • Constitution de l’équipe


& .NET fonctionnels
conception
Marie Expert Connait Connait

Pierre Expert Expert Connait

Marc Connait Expert Connait Connait

Rémi Expert Connait Connait Expert

Céline Expert

Luc Expert Connait

Equipe multidisciplinaire


Les rôles

Atelier : Team building • Constitution de l’équipe Scrum

Objectif : Former une équipe polyvalente
Time box : 1 heure



Le framework Scrum
Les règles
Vue d’ensemble
L’équipe Scrum Artefacts transverses
Les artefacts Artefacts liés à la Release
Les événements Artefacts liés au Sprint
Artefacts du management visuel
Estimer avec Scrum

Les Artefact Scrum

Les artefacts : vue d’ensemble

Artefacts transverses
Définition de Fini : DoD (Definition of Done)

Artefacts relatifs à la release
Backlog de produit
Elément de Backlog de produit : PBI
Burndown du produit
Plan de la release

Artefacts relatifs au Sprint
L'incrément
Objectif de Sprint
Backlog de Sprint
Tâche
Burndown du Sprint
Backlog d'obstacles
Backlog d'amélioration

Radiateur d'information


Les Artefact Scrum

Les artefacts relatifs à la release


Backlog de produit
Burndown du produit
Plan de la release

L'incrément
Objectif de Sprint
Backlog de Sprint
Tâche
Burndown du Sprint
Backlog d'obstacles



Les Artefacts Scrum

Définition de « Fini » : DoD • Définition de « Fini » : DoD

Partager la même signification de « Fini »
DoD = Definition of Done
Exprime les critères de fin d'un travail
Pourquoi?
Eviter le syndrome de 90% fini
Fini = 100% Fini


Les Artefacts

Quels artefacts concernés par le DoD? • Définition de Fini : DoD

Artefact Exemple de DoD
Elément du Backlog de Tests d’acceptation sur environnement d’intégration
produit
Codage terminé
Tâches Tests unitaires automatisés
Tests unitaires 100% réussis

Tests de non régression sur environnement de recette
Incrément Release Notes élaborée

Release Déploiement Pré-Prod
Tests en Pré-Prod


Les Artefact Scrum



Backlog de produit
Burndown du produit
Plan de la release

L'incrément
Objectif de Sprint
Backlog de Sprint
Tâche
Burndown du Sprint
Backlog d'obstacles



Artefacts Scrum

Backlog de produit • Backlog de Produit

Liste d'éléments représentant les exigences
Fonctionnalités
Améliorations
Correctifs
Besoins non fonctionnels : performance, sécurité, etc.

Seul endroit pour stocker les exigences


Artefacts

Caractéristiques • Backlog de Produit

Détaillé pertinemment
Détails apportés au bon moment : JIT
Emergeant
Evolue tout au long du projet
Estimé
Quelle est la taille des éléments
Priorisé
Dans quel ordre réaliser les éléments

DEEP


Artefacts

Niveaux de granularité • Backlog du Produit

(User) Stories

Epics

Thèmes


Artefacts

Exemple de Backlog de produit • Backlog du Produit


Artefacts

Eléments de Backlog de Produit : PBI • Eléments de Backlog de Produit :
PBI

PBI : Product Backlog Item
Exigence du système
Fonctionnel
Non fonctionnel
Performance
Portabilité
Sécurité
Réutilisabilité, etc.

Base de l’estimation et de la planification Agile

Artefacts

Exemples de PBI • Eléments de Backlog de Produit :
PBI

Exemple de PBI Catégorie
En tant que candidat Fonctionnel
Je veux faire des recherches de postes ….

En tant que candidat, Fonctionnel
Je veux visualiser les détails des postes …
En tant que recruteur, Fonctionnel
Je veux poster des offres …

Mettre à jour la version du SGBD Technique

Corriger le bug Mantis 200 Correctif

Artefacts

Caractéristiques des PBI • Eléments de Backlog de Produit :
PBI
• Caractéristiques

Les PBIs doivent être INVEST

Independant Negociable

Testable INVEST Valuable

Small Estimable


Artefacts

Structure des PBI • Eléments de Backlog de Produit :
PBI

Priorité

Description Valeur métier

PBI Taille

Etat
DoD

Tests
d’acceptation

Artefacts

Priorité des PBI • Eléments de Backlog de Produit :
PBI

L’ordre de réalisation des PBI
Critères de priorisation
Valeur métier
Retour sur investissement
Degré de risque
…

Responsabilité du PO


Artefacts

Description des PBI • Eléments de Backlog de Produit :
PBI

Enoncé court de l’objet du PBI : Point d’entrée

« Starter » pour la conversation entre le PO et l’équipe de développement

Détails apportés par les tests d’acceptation



Artefacts

PBI

Format de description
Qui : le rôle bénéficiaire
Quoi : L’objet
Pourquoi : La valeur ajoutée

Modèle des User Stories

En tant que <Rôle>
Je veux <Quoi>
Pour <Pourquoi>

Artefacts Scrum

PBI

Point de départ pour la conversation autour du besoi
Méthodes des 3C : Ron Jeffries

Card Conversation
(Description)

Confirmation
(Détails)

Artefacts

Tests d’acceptation des PBI • Eléments de Backlog de Produit :
PBI

Le projet est piloté par les tests d’acceptation
Tests fonctionnels

Conditions d'acceptation

Constituent la spécification du PBI

• Elaborés par le PO
• Exécutés par l'équipe de développement
• Vérifiés par le PO


Artefacts

Valeur des PBI • Eléments de Backlog de Produit :
PBI

Chiffre représentant la valeur métier
Gain en productivité

Augmentation des ventes

Augmentation du chiffre d’affaire, …



Artefacts

Taille des PBI • Eléments de Backlog de Produit :
PBI

Valeur relative
Reflet de plusieurs paramètres
Complexité, incertitude, difficulté technique, etc.
Quantité de points
Base de la planification

Estimation de la taille : responsabilité de l’équipe de
développement


Artefacts

DoD des PBI • Eléments de Backlog de Produit :
PBI

Tests d’acceptation
Autres conditions

• Elaboré par le PO
• Exécutés par l'équipe de développement


Artefacts

Etat des PBI • Eléments de Backlog de Produit :
PBI

Cycle de vie possible

Responsabilité : l’équipe de développement, le PO


Les Artefact Scrum



Backlog de produit
Burndown du produit
Plan de la release

L'incrément
Objectif de Sprint
Backlog de Sprint
Tâche
Burndown du Sprint
Backlog d'obstacles



Artefacts

L'incrément • L’incrément

Résultat du Sprint
Logiciel partiel potentiellement exploitable
Testé
Vérifie le DoD
Possibilité de déploiement en production


Artefacts Scrum

Objectif du Sprint • Objectif du Sprint

Phrase indiquant le but principal du Sprint
Point de vue fonctionnel
Exemples

Sprint Objectif du Sprint
Sprint 1 Mettre en place la recherche multicritères

Sprint 2 Internationaliser l'application



Artefacts

Backlog de Sprint • Backlog de Sprint

Planning à l’échelle du Sprint
Contient
Les PBI sélectionnés pour le Sprint
Les Tâches de réalisation
o Conception, Codage, Tests, Documentation, etc.

Artefact interne à l’équipe de développement
Etabli lors de la réunion de planification du Sprint
Mis à jour quotidiennement

Responsabilité de l’équipe de développement


Artefacts

Backlog de Sprint : Exemple • Backlog de Sprint


Artefacts Scrum

Les tâches • Les tâches

Représentent le travail à faire
Conception, Analyse, codage, tests, documentation, déploiement, etc.

Identification des tâches
Par décomposition des PBI lors de la planification du Sprint
Peuvent émerger durant le Sprint


Artefacts

Structure des tâches • Les tâches
• Structure

Description Réalisateur

Reste à faire
Durée initiale quotidien
Tâche

DoD
Etat d’avancement


Artefacts

Réalisateur de la tâche • Les tâches
• Structure

Les tâches sont prises par les développeurs
Ne sont pas assignées par le ScrumMaster : Equipe autogérée

Responsabilité collective


Artefacts

Durée initiale des tâches • Les tâches
• Structure

Estimation initiale de la durée
En heures
Granularité recommandée
16h maximum

Estimation collective par l’équipe de développement


Artefacts

Etat d’avancement des tâches • Les tâches
• Structure

Etats types
A faire, En cours, Fini

Responsabilité : équipe de développement


Artefacts

Reste à faire quotidien • Les tâches
• Structure

Estimation du temps restant pour finir la tâche
En heures
Mis à jour quotidiennement

Responsabilité du réalisateur


Artefacts

Vélocité • Vélocité de l’équipe

Nombre de points réalisés par l’équipe de développement à la
fin du Sprint
Vélocité réelle
Utilité
Estimer la durée du projet
Estimer le nombre de points que l’équipe est capable de réaliser avant
de planifier un Sprint
Indice de performance de l’équipe


Artefacts

Comment calculer la vélocité réelle? • Vélocité de l’équipe

A la fin du Sprint
Faire la somme des points des PBI « Fini » dans le Sprint
Les PBI dont l’état n’est pas « Fini » ne rentrent pas dans le calcul de la
vélocité
Exemple
PBI Taille Etat

PBI1 3 Fini
Vélocité = 11
PBI2 8 Fini
PBI3 5 En cours


Artefacts

Burndown de Produit • Burndown de Produit

Reste à faire pour finir la release
Mis à jour à chaque fin de Sprint
Permet d'ajuster les prévisions de livraison

Responsabilité du Product Owner


Artefacts

Exemple de Burndown de produit • Burndown de Produit

Taille initiale du
Backlog du produit

Taille restante à la fin
de chaque Sprint


Artefacts

Burndown de Sprint • Burndown de Sprint

Reste à faire à chaque jour du Sprint

Reste à faire Avant
le Jour 1

Reste à faire Après
le jour 1

Responsabilité de l’équipe de développement


Artefacts

Backlog d'obstacles • Backlog d’obstacle

Liste d'obstacles identifiés par l'équipe Scrum
Géré par le ScrumMaster


Artefacts

Backlog d'amélioration • Backlog d’amélioration

Liste des améliorations identifiées par l'équipe
Géré par le ScrumMaster


Les Artefact Scrum



Backlog de produit
Burndown du produit
Plan de la release

L'incrément
Objectif de Sprint
Backlog de Sprint
Tâche
Burndown du Sprint
Backlog d'obstacles



Artefacts

Radiateur d'information • Radiateur d’information

Mur d’affichage des artefacts du projet
Utilité
Rendre visible les artefacts Scrum
Tableau de bord visuel du projet
Permet le management visuel


Artefacts

Structure type • Radiateur d’information

DoD

Objectif du Sprint
Backlog
D’obstacles
Backlog
du produit
Backlog
du Sprint Backlog
D’amélioration

Burndown
du produit
Burndown
du Sprint
Vélocité


Artefacts

Exemple • Radiateur d’information



Généralités Scrum Définitions
Le framework Scrum Le Sprint
Les règles Planification du Sprint
Atelier
L’équipe Scrum
Mêlée quotidienne
Les artefacts Atelier
Les événements Revue du Sprint
Gestion de projet avec Scrum Atelier
Rétrospective
Estimer avec Scrum Atelier
Planifier avec Scrum Préparation du Backlog du Produit

Les événements

Les Evénements

Réunions, rituels, cérémonies
« Time boxés »: Durée limitée
Utilité
Régularité dans le projet : Rythme constant
Minimiser le recours aux réunions
Opportunités pour appliquer la PDCA


Les événements

Les Evénements : Vue d’ensemble • Vue d’ensemble

Une vue d’ensemble
Sprint
Réunion de planification du Sprint
Mêlée quotidienne
Revue du Sprint
Rétrospective du Sprint
Préparation du Backlog de produit


Les événements

Les événements : Enchainement • Enchainement

Planification du
Phase de Sprint
Préparation

Planification de Mêlées
quotidiennes Travailler
la release sur
Le
Déroulement des Sprint
Sprints
Sprint
Revue du
… Sprint

Sprint Rétrospective
du Sprint Sprint
suivant


Les événements

Le Sprint • Le Sprint

Itération d'une durée fixe
2-4 semaines

Facteurs déterminants dans le choix de la durée
Degré d’incertitude
Facilité ou non d’avoir du feedback
Surcoût des itérations
Stabilité des besoins


Les événements

Déroulement du Sprint • Le Sprint

Planifier le Sprint
Exécuter le travail
Organiser et participer aux mêlées quotidiennes
Mettre à jour les artefacts Scrum
Effectuer la revue de l’incrément
Faire la rétrospective du Sprint


Les événements

Quelques règles • Le Sprint

La durée n'est pas extensible
Pendant le Sprint
L'équipe ne doit pas changer
Le périmètre et d’objectif ne doivent pas changer
Si l'objectif devient obsolète

Le PO peut abandonner le Sprint


Les événements

Planification du Sprint • Réunion de Planification du Sprint

Objectif : Etablir le plan du Sprint
Définir l’objectif du Sprint
Sélectionner les PBI prioritaires
Décomposer les PBI en tâches de réalisation
Vérifier la capacité de l’équipe
S’engager sur le périmètre du Sprint
Prendre les tâches


Les événements

Déroulement en deux parties • Planification de Sprint
• Déroulement

1ère Partie 2ème Partie
Entrées Entrées
• Vélocité estimée • PBIs candidats au Sprint
• Backlog du produit estimé et priorisé • Capacité de l’équipe

Participants Participants
• Equipe de développement ; PO ; SM • Equipe de développement ; PO ; SM

Déroulement Déroulement
•Décomposer les PBI candidats en tâches
•Définir l’objectif du Sprint
•Estimer les tâches
•Discuter les PBI prioritaires
•Prendre les tâches
•Sélectionner les PBI
•S’engager 4h
4h

Sorties Sorties
• Objectif du Sprint
• Objectif du Sprint
• Backlog du Sprint
• PBIs candidats au Sprint


Les événements

Capacité de l’équipe • Planification de Sprint
• Déroulement

Nombre d’heures consacrées au Sprint dont dispose l’équipe
de développement durant le Sprint
Ne pas inclure dans le calcul de la capacité
Les congés
Les jours fériés
Le temps des réunions, email, etc. hors projet


Les événements

Capacité de l’équipe : Exemple • Planification de Sprint
• Déroulement

Données du projet
Durée du sprint : 10 jours ouvrés
Nombre de jours fériés : 0 jour
Disponibilités des membres de l’équipe de développement pendant le
Sprint

Capacité de l’équipe


Les événements

Conseils • Planification de Sprint
• Déroulement

Pour décomposer les PBIs en tâches
Commencer par établir une ébauche de la solution technique pour faire
émerger les tâches
o Conception participative
Penser à toutes les tâches et pas uniquement aux tâches de codage
o Avoir en tête la définition de « Fini »


Les événements

Conseils • Planification de Sprint
• Déroulement

Si la durée des tâches > capacité de l’équipe
Négocier avec le PO
Retirer un PBI
Le remplacer par un plus petit
Si la durée < capacité de l’équipe
Voir avec le PO pour ajouter de nouveaux PBI


Les événements

Quelques règles • Planification de Sprint
• Déroulement

Doit se tenir au début du Sprint
Toute l'équipe Scrum participe
Time box
Proportionnel à la durée du Sprint
Sprint de 4 semaines : 8 heures
Sprint de 2 semaines : 4 heures


Evénements

Atelier : Planification du Sprint • Planification du Sprint
• Déroulement

Partie 1
Objectif
o Définir l’objectif du Sprint
o Discuter les PBI prioritaires
o Sélectionner les PBI
Time box : 30 minutes
Partie 2 : Elaborer le Backlog du Sprint
Objectif
o Identifier les tâches
o Estimer les tâches
o Prendre les tâches
Time box : 30 minutes


Les événements

Mêlée quotidienne • Mêlée quotidienne

Objectif
Synchroniser les activités de l’équipe de développement
Inspecter & adapter le planning de la journée
Mettre à jour le reste à faire
Remonter les problèmes qui ralentissent l’équipe


Les événements

Déroulement • Mêlée quotidienne
• déroulement

Entrées

Participants

Déroulement
Ce que j’ai fait hier
Ce que je fait aujourd’hui
Mes obstacles 15’

Sorties
• Burndown du Sprint
• Backlog d’obstacles

15’ © 2012 SOFTENIA Solutions 123

Les événements

Quelques règles • Mêlée quotidienne
• Déroulement

Réunion interne à l'équipe de développement
Seuls les membres de l’équipe parlent
Time box
15 minutes
Se fait debout
Même endroit
Espace projet de l’équipe
Devant le radiateur d’information
Même heure
Matin de préférence


Les événements

Quelques précautions • Mêlée quotidienne
• Déroulement

Ce n'est pas une réunion pour résoudre les problèmes
Il ne s'agit pas de rendre des comptes
Ni au PO
Ni au SM
L’équipe de développement gère la réunion
Le ScrumMaster joue le rôle de facilitateur


Evénements

Atelier : Mêlée quotidienne • Mêlée quotidienne
• Déroulement

Objectif : Pratiquer la mêlée quotidienne
Time box :
15 minutes


Les événements

Revue de Sprint • Revue de Sprint

Objectif
Effectuer une revue de l'incrément : PBI finis
Recueillir le feedback
Adapter le Backlog du produit si nécessaire


Les événements

Revue du Sprint : Déroulement • Revue de Sprint
• Déroulement

Entrées
• Incrément
• Liste des PBI Finis

Participants
• PO,
• SM ;
• Parties prenantes
Déroulement
• Présenter les PBIs Finis : Equipe de développement
• Accepter ou refuser les PBI : PO
• Recueillir le feedback
• Mettre à jour le Backlog du produit
• Mettre à jour le Burndown du produit
• Calculer la vélocité 4h

Sorties
• Backlog du produit ; Burndown du produit ; Vélocité réelle


Les événements

Quelques règles • Revue de Sprint
• Déroulement

A organiser à la fin du Sprint
Montrer uniquement les PBI Finis
Informelle
Pas de Slides
Time box
4 heures pour un Sprint de 4 semaines


Les événements

Quelques précautions • Revue de Sprint
• Déroulement

Moins d'une heure de préparation
Inciter les parties prenantes à donner leur feedback
Les PBI non acceptés par le Product Owner doivent retourner
dans le Backlog du produit


Evénements

Atelier : Revue de Sprint • Revue de Sprint

Objectif
Apprendre à organiser une revue de Sprint réussie
Time box
30 minutes


Les événements

Rétrospective de Sprint • Rétrospective de Sprint

Objectif
Inspecter le processus
Améliorer le processus si nécessaire


Les événements

Déroulement • Rétrospective de Sprint
• Déroulement

Entrées
• Sprint sortant

Participants
• PO
• SM

Déroulement
• Discuter le processus
Sprint
• Points positifs
sortant
• Points négatifs
• Définir un plan d’amélioration

3h

Sorties
Backlog d’amélioration


Les événements

Quelques règles • Rétrospective de Sprint
• Déroulement

Doit se tenir à la fin du Sprint et avant le démarrage du Sprint
suivant
Toute l'équipe Scrum participe
Time box
3h pour Sprint de 4 semaines


Evénements

Atelier : Rétrospective de Sprint • Rétrospective de Sprint
• Déroulement

Objectif
Apprendre à organiser une rétrospective réussie
Time box
30 minutes


Les événements

Préparation du Backlog de Produit • Préparation du Backlog du Produit

Objectif : préparer les PBI pour le Sprint suivant
Décomposition
Estimation
Rendre les éléments INVEST
Changement des priorité
…
Participants
PO : Tâche de fond
Equipe de développement : 5-10% du temps



Le framework Scrum
Les règles
L’équipe Scrum
Les artefacts Introduction
Les événements Démarche d’estimation Agile
Gestion de projet avec Scrum Estimation au niveau release
Estimer avec Scrum Estimation au niveau Sprint

L’estimation Agile avec Scrum Estimation Agile avec Scrum

Introduction à l’estimation
Démarche d’estimation Agile
Estimation au niveau release
Estimation au niveau Sprint


Estimation Agile

Pourquoi estimer? • Introduction

Prévoir les ressources
Calculer le coût
Evaluer la quantité de travail
Prévoir les délais de livraison

L’estimation est indispensable à la planification

Estimation Agile

Difficultés de l’estimation • Introduction

Information incertaine et incomplète

Plage d’incertitude
des estimations

Marge d’erreur
trop importante
au début du projet

Il faut (re)estimer tout au long au projet

Estimation Agile

Caractéristique de l’estimation Agile • Démarche d’estimation Agile

Activité collective
Faite par ceux qui réalisent le travail
C’est l’équipe de développement qui estime

Estimation ≠ Engagement
Aide à la prise de décision
Activité régulière
On estime tout au long du projet
Différents niveau d’estimation : Release, Sprint, au quotidien

Estimation Agile

Les niveaux d’estimation • Démarche d’estimation Agile

❶ Release ❷ Sprint ❸ Au quotidien
Quand ? Quand ? Quand ?
Phase de préparation Avant le début du Sprint Tous les jours

Quoi estimer ? Quoi estimer ? Quoi estimer ?
• Taille du Backlog du produit • Vélocité de l’équipe de • Reste à faire pour chaque tâche
• Vélocité de l’équipe de développement
développement • Durée des tâches
• Taille du Backlog du produit

Pourquoi ? Pourquoi ? Pourquoi ?
• Evaluer le périmètre • S’engager sur le contenu de • Actualiser le Burndown du Sprint
fonctionnel réalisable l’incrément • Evaluer les tendances de
• Actualiser & affiner les estimations l’avancement
du Backlog du produit

Estimation Agile

La taille du Backlog de produit • Démarche d’estimation Agile
• Niveau Release

Taille du backlog du produit ൌ∑ tailles des PBI
Taille du PBI
❶ Release
Nombre entier appartenant à une échelle de valeurs relatives
Quand ?
o S, M, L, XL, XXL Phase de préparation
o 1, 2, 3, 5, 8, 13, ..
Quoi estimer ?
o 0 1, 2, 3 5, 8, 30, 20, 40, 100.
Reflet de plusieurs paramètres • Vélocité de l’équipe de
o Complexité développement
o Niveau de risque
Pourquoi ?
o Difficulté • Evaluer le périmètre
o Incertitude, etc. fonctionnel réalisable

Exprimée en points
o Story points
Valeur relative
o Comparer les PBI les uns par rapport aux autres

Estimation relative

Estimation Agile

L’estimation relative : Exercice • Estimation au niveau Release
• Estimation relative

Attribuer des points pour comparer la taille des monuments
parisiens suivants

Monument Taille
Tour Eiffel
Tour Montparnasse
Arc de Triomphe
Arche de la défense
Notre dame
Sacré Cœur

Quelles sont les difficultés rencontrées?

Estimation Agile

L’estimation relative : Techniques • Estimation au niveau Release

Planning Poker
Séance d’estimation collective utilisant des cartes
Largement utilisé dans XP et Scrum
Triangulation
Séance d’estimation collective basée sur la comparaisons des éléments à
estimer

Estimation Agile
Technique d’estimation relative : Planning • Estimation au niveau Release

Poker • Estimation relative

Estimation collective par les développeurs
Les cartes représentent l’échelle de valeurs
Echelle préconisée par Mike Cohn

0

1 2 3 5 8

13 20 40 100

Estimation Agile

Planning Poker : Déroulement • Estimation au niveau Release

Avant de commencer
Chaque membre de l’équipe de développement reçoit un jeu de cartes
Etapes
Le Product Owner présente le PBI
Les membres de l’équipe de développement posent des questions pour bien
comprendre le PBI
Chaque développeur choisit une carte représentant son estimation sans la
montrer
Au signal de l’animateur (ScrumMaster) les participants montrent leurs cartes au
même moment
En cas de divergence
o On discute les estimations hautes et basses
o On effectue un deuxième tour d’estimation si nécessaire
Les estimations devraient converger après la discussion
Répéter les étapes pour chaque PBI

Estimation Agile

Planning Poker : Exemple • Estimation au niveau Release

Estimer la taille des PBI suivants
PBI Taille estimée
Un utilisateur peut chercher des livres par auteur, par titre ou par numéro
ISBN
Un utilisateur peut visualiser les informations détaillées du livre : Nombre
de page, date de publication, résumé.
Un utilisateur peut mettre les livres dans un caddie pour les payer plus
tard.
Un utilisateur peut supprimer des livre du caddie.
Pour payer un livre l’utilisateur saisit son adresse de facturation, son
adresse de livraison et les informations de sa carte de crédit
Un utilisateur peut évaluer un livre
Un utilisateur peut créer un compte pour mémoriser ses informations

Estimation Agile
Technique d’estimation relative : La • Estimation au niveau Release

triangulation • Technique des Story points

Principe
Comparer les PBI les uns par rapport aux autres
Positionner les BPI sur l’échelle de valeurs

1 2 3 5 8 13 …

PBI PBI PBI
PBI
PBI PBI

PBI PBI PBI

Estimation Agile

La triangulation : déroulement • Estimation au niveau Release
• Technique des Story points

PO : Choisir un PBI de référence et le présenter à l’équipe

Equipe dev + PO : Discuter le PBI de référence

Equipe dev : Estimer et Positionner le PBI de référence sur le
tableau de triangulation

PO : Passer au PBI suivant

Equipe dev + PO : Discuter et comparer le PBI avec les PBI déjà
positionnés

Equipe dev : Positionner le PBI sur le tableau
Changer les positions existantes si nécessaire

Estimation Agile

Triangulation : Exemple • Estimation au niveau Release

Estimer la taille des PBI suivants (Dice game)

N° PBI
1 Lancer un dé jusqu’à obtenir 1
2 Lancer un dé jusqu’à obtenir 1, 3 ou 5
3 Lancer deux dés jusqu’à obtenir 1 et 2
4 Lancer un dé jusqu’à obtenir 2, 4 ou 6
5 Lancer un dé jusqu’à obtenir plus de 4
6 Lancer deux dés jusqu’à obtenir plus de 6
7 Lancer deux dés jusqu’à obtenir un double 6

Estimation Agile

Estimer la vélocité de l’équipe • Estimation au niveau Release
• Estimer la vélocité

Objectif : Estimer la quantité de points
réalisable par l’équipe durant un Sprint
❶ Release
Quand ?
Phase de préparation
Quoi estimer ?
• Vélocité de l’équipe de
développement

Pourquoi ?
• Evaluer le périmètre
fonctionnel réalisable


Estimation Agile

Vélocité au début du projet • Estimation au niveau Release
• Estimer la vélocité

• Prendre le nombre d’heures disponibles de l’équipe sur un Sprint capacité

• Choisir un PBI de petite taille taille

• Décomposer en tâches
• Estimer collectivement la durée de chaque tâche en heures

• Calculer la somme des durées de toutes les tâches identifiées durée

• Appliquer la règle des trois pour obtenir la vélocité Vélocité

capacité * taille
Vélocité =
durée


Estimation Agile

Vélocité au début du projet : Exemple Estimation au niveau Release

Données du projet
Capacité = 360 heures

PBI Taille • Tâche 1 : 15h
• Tâche 2: 10h
PBI 1 3 • Tâche 3 : 15h
PBI 2 8 ________________
durée= 40h
PBI 3 5

Quelle est la vélocité de l’équipe?

capacité * taille 360 * 3
Vélocité = = = 27 Pts
durée 40


Formation scrum v1.0

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Formation scrum v1.0

Similaire à Formation scrum v1.0 (20)

Formation scrum v1.0