SlideShare une entreprise Scribd logo
1  sur  93
Télécharger pour lire hors ligne
Les méthodes agiles
Introduction à SCRUM
Blackbird est une agence de développement web spécialisée
dans l’accompagnement et le développement de projets e-
commerce sur la solution Magento.
http://black.bird.eu
About
Sommaire
● Introduction
● Les principes fondamentaux
● Présentation des Users Stories
● 6 stratégies pour rédiger des US efficaces
● Évaluer la taille des Users Stories
● Prioriser les Users Stories
● Plannifier les Sprints
● Les cérémonies : des outils pour communiquer
● Mesurer la vélocité de la production
● Déroulement d’un sprint
● Les signaux d’alertes, savoir interpréter le tableau de sprint
● Traiter plusieurs projets en simultané
● Aspects contractuels
● Concepts et ressources pour aller plus loin
1980 1990 2000 2010
Gantt / PERT : Cascade ( Waterfall, V Model, etc.)
Méthodes Agiles
Origines des méthodes Agiles
19501900
Taylorisme
Lean
Toyota
Production
System
Process
focus
People
focus
Des outils plus ou moins normatifs
RUP XP SCRUM KANBAN
Faites ce que
vous voulez
120+ 13 9 3 0
plusnormatif
plusadaptatif
RUP est assez normatif -
avec plus de 30 rôles, plus
de 20 activités et plus de
70 artefacts; une énorme
quantité de choses à
apprendre.
XP (eXtreme
Programming) inclut une
majorité des règles de
Scrum plus un ensemble
de pratiques d'ingénierie
bien spécifiques comme le
développement piloté par
les tests et la
programmation en
binôme.
Scrum est moins normatif
que XP puisqu'il ne
recommande aucune
pratique d'ingénierie
particulière. Scrum est
plus normatif que Kanban
cependant, car il impose
des choses comme les
itérations et les équipes
multidisciplinaires.
Kanban laisse tout ouvert.
Les seules contraintes
sont de Visualiser Votre
Workflow et de Limiter
Votre TAF. Tout près du
"Faire N'importe Quoi",
mais étonnamment
puissant.
source : http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/
Les principales différences entre
cycle en V et méthodes agiles
Personnes et interactions
Logiciel qui fonctionne
Collaboration avec le client
Adaptation au changement
Processus et outils
Documentation
Négociation sur le contrat
Suivi d’un plan pré-établi
vs
vs
vs
vs
Agile Cycle V
Le paradoxe
de la gestion de projet
Capacité d’action
Temps
Connaissance du projet
Pourquoi ?
● Faciliter l’expression des besoins
● Aider à l’acceptation du changement
Comment ?
● Organiser l’expression des besoins
● Intégrer le client
● Démarche itérative
Le modèle
Agile
Quels
projets
favoriser ?
● Besoin rapide de mise à disposition du produit
● Imprévisibilité des besoins du client
● Nécessité de changements fréquents
● Besoin de visibilité du client sur l'avancement
des développements
● Présence de l'utilisateur assurant un feedback
immédiat
● Indisponibilité du client ou de l'utilisateur
● Dispersion géographique des ressources
humaines
● Inertie des acteurs du projet ou refus des
changements
● Gouvernance complexe de la DSI
Quels
projets
éviter ?
Les principes
fondamentaux
Les 4 valeurs fondamentales
L'équipe
« Les individus et leurs interactions, plus que
les processus et les outils »
L'application
« Des logiciels opérationnels, plus qu'une
documentation exhaustive »
L'acceptation du changement
« L'adaptation au changement, plus que le
suivi d'un plan »
La collaboration
« La collaboration avec les clients, plus que la
négociation contractuelle »
source : Wikipedia
Les 12 principes
généraux
User
Focus
1. La plus haute priorité est de satisfaire le
client (l’utilisateur final du produit) en livrant
rapidement et régulièrement des
fonctionnalités à forte valeur ajoutée.
source : Wikipedia
Un modèle
itératif
2. La livraison s’applique à une application
fonctionnelle, toutes les deux semaines à deux
mois, avec une préférence pour la période la plus
courte.
3. L’unité de mesure de la progression du projet
est un logiciel fonctionnel (ce qui exclut de
comptabiliser les fonctions non formellement
achevées).
4. Le changement est accepté, même tardivement
dans le développement, car les processus agiles
exploitent le changement comme avantage
concurrentiel pour le client
source : Wikipedia
Un modèle
Collaboratif
5. Le projet doit impliquer des personnes
motivées. Donnez-leur l'environnement et le
soutien dont elles ont besoin et faites leur
confiance quant au respect des objectifs.
6. Le métier et les développeurs doivent
collaborer régulièrement et de préférence
quotidiennement au projet.
7. La méthode la plus efficace pour transmettre
l'information est une conversation en face à face.
8. À intervalle régulier, l'équipe réfléchit aux
moyens de devenir plus efficace, puis accorde et
ajuste son processus de travail en conséquence.
source : Wikipedia
Focus on
quality
9. Les processus agiles promeuvent un rythme de
développement soutenable
10. Les processus agiles recommandent une
attention continue à l'excellence technique et à la
qualité de la conception.
11. La simplicité et l'art de minimiser les tâches
parasites, sont appliqués comme principes
essentiels.
12. Les équipes s'auto-organisent afin de faire
émerger les meilleures architectures,
spécifications et conceptions.
source : Wikipedia
Structure opérationnelle et
pratique du développement agile
… là on parle de SCRUM
Les rôles
Product Owner Scrum Master Team
Démarche itérative
Produit
Release 1 Release 2
Sprint 1 Sprint 2 Sprint 3
Story
Story
Story
Itérations Release
Chaque fin de release apporte de nouvelles fonctionnalités
pour les utilisateurs
ROADMAP
Release 1 Release 2 ...
Itérations Sprint
Chaque fin de sprint apporte de nouvelles fonctionnalités
pour les Product Owner
RELEASE
Sprint 1 Sprint 2 ...
Itérations Stories
Chaque fin de Story est une nouvelle liste de tâches
terminées pour la team
SPRINT
Story 1 Story 2 ...
Planning
ROADMAP
RELEASE ...
SPRINT SPRINT SPRINT
Story Story
Story Story
Sprint review Sprint review Sprint review
Sprint planning Sprint planning Release review
Le process Scrum
Le Backlog
an accumulation of something
Définition
du Backlog
Une liste des fonctionnalités à réaliser
Chaque fonctionnalité est décrite par une Story
Le backlog est défini en amont du projet puis
actualisé tout au long du projet
Les stories y sont priorisées en fonction de leur
taille (plus petites en premier) et de leur valeur
(plus grande valeur en premier)
Backlog et planification
Backlog
Sprint 1
Sprint 2
Produit partiel
Produit partiel
Story Story
StoryStory
StoryStory
StoryStory
StoryStory
Story Sprint 3
...
Produit partiel
Story
...
Actualisation
du backlog
Les Users Stories
Tout projet est un ensemble de belles histoires
En tant qu’utilisateur je
veux ajouter un produit
à mes favoris afin de
pour le retrouver
facilement plus tard
User Story
En tant qu’utilisateur jeveux ajouter un produità mes favoris afin depour le retrouverfacilement plus tard
En tant que Sylvianne,
je veux ajouter un
produit à mes favoris afin
de le retrouver
facilement plus tard
Une user story est un
élément fonctionnel qui
apporte une valeur et qui
peut être développée au
cours d’un sprint.
Pourquoi User ? Pourquoi Story ?
Pourquoi pas simplement une tâche ?
Format engageant du
"Story Telling"
L’information est spécifique
concise et précise.
L’accent est mis sur les
buts et les comportements.
L’utilisateur est clairement défini,
c’est le héro des petites "histoires".
Ce n’est pas un panel (“80% des
femmes,“ “entre 25 et 35 ans“, etc.)
Ouvre au dialogue, à l’échange.
Le format “User Voice”
En tant que < Rôle d’utilisateur >,
Je veux < But >,
Afin de < Justification >
Le format « User Voice » donne du sens à la
fonctionnalité… pour qui et pourquoi l’équipe va la
développer
Il permet de se rapprocher d’une démarche
expérience utilisateur, donne une vision concrète,
réaliste et partagée de l’utilisateur final.
Il est clairement orienté ACTION et BUT (démarche de
conception le plus efficace). La valeur Business
représente les bénéfices qui se dégagent de l’
action : Il justifie toutes les fonctionnalités d’un point
de vue Business, et oblige le Product Owner et les
équipes à s’interroger systématiquement sur la valeur
de chaque fonctionnalité
Attributs d’une U.S.
Libellé court de la fonction. Une phrase d’
action à l’infinitif.
Exemples : «Voir les commandes», «Choisir
un produit», «imprimer les factures», ... etc.
Numéro d’identification unique
Description libre ou structurée (“User
Voice” ou liste d’actions élémentaires)
Titre
ID
Description
Type
Etat
Taille
Priorité
Attributs d’une U.S.
User (administrateur, utilisateur, etc.) ou
Technique (vue développeur, bug, etc.)
Créee, Acceptée, Estimée, Planifiée, En
cours, Terminée
Selon l’évaluation faîte lors du planning
pocker
Classement selon taille / valeur
Titre
ID
Description
Type
Etat
Taille
Priorité
INVEST’ir
dans une bonne histoire
Indépendante | éviter les dépendances
Négociable | elle peut être discutée avec l’
équipe chargée de la réalisation. Il n’est pas
nécessaire d’inclure tous les détails
Valeur | elle est source de valeur pour le
client ou l’utilisateur.
Estimable | elle peut être estimée par l’
équipe de réalisation avec un risque d’erreur
faible.
Size (Taille) | Des petites histoires qui
peuvent se combiner. Elle doit pouvoir être
conçue, développée et testée au sein d’une
itération.
Testable | Un test démontre que l’histoire
correspond bien aux besoins du client
Quelques exemples
Bon ? pas bon ?
Je suis un client,
je veux payer avec
ma MasterCard ...
INVEST ? not INVEST ?
Je suis un client, je veux
payer en ligne …
◻ avec ma CB
(Mastercard, Visa, etc.)
◻ avec Paypal
N’est pas
Indépendante
Une boîte de dialogue permet aux
utilisateurs d’éditer la liste des
imprimantes. La boîte de dialogue
permet aux utilisateurs d’ajouter ou de
supprimer des imprimantes. Un
utilisateur peut ajouter une
imprimante par une recherche
automatique ou manuelle par le biais d’
une adresse DNS ou d’une adresse IP.
Une recherche avancée optionnelle
permet de filtrer les imprimantes par
adresse IP ou par le masque de réseau
INVEST ? not INVEST ?
Je suis un utilisateur, je peux
ajouter une imprimante afin d’y avoir
accès depuis n’importe quel logiciel de
mon système
◻ Recherche automatique
◻ Recherche manuelle (IP
ou DNS)
◻ Autres solutions ?
Difficilement négociable,
manque de flexibilité
De la valeur pour le client
Je suis RH, je veux Qualifier la liste
des candidats afin de la réduire et y
retrouver facilement les profils
correspondants à différents critères
◻ Attribuer une note
◻ Associer un tag
◻ Marquer l’état (à
conserver, rejetté,
entretien, etc.)
De la valeur pour
l’utilisateur
Je suis demandeur d’
emploi, je veux
rechercher un emploi par
poste et par région afin
de trouver une offre
correspondant à mes
besoins.
INVEST ? not INVEST ?
Non estimable, le
développeur ne maîtrise
pas le domaine technique
EPIC !
Non estimable, le
développeur ne maîtrise
pas le domaine fonctionnel
Je suis
Commercial, je
veux suivre la
marge net
mensuelle de mes
ventes afin de ...
INVEST ? not INVEST ?
Je suis Médecin, je
veux accéder aux
informations de
mon patient sur
DXCARE
Je suis Chômeur,
je recherche un
emploi ...
EPIC !
Je suis vendeur je
veux gérer mes
objets en vente ...
INVEST ? not INVEST ?
Découper en données
opérationnelles
Je suis vendeur, je
veux créer une
fiche produit afin
de vendre un objet
Je suis vendeur, je
peux ajouter
plusieurs photos
afin d’améliorer la
visibilité de mon
produit
Je suis vendeur, je
veux supprimer ma
fiche afin de neplus être contacté
une fois ma venteeffectuée.
Détailler en données
opérationnelles
EPIC !
Je suis Joueur je
veux jouer en ligne
contre un max d’
autres joueurs
INVEST ? not INVEST ?
Je suis joueur, je veux
lister les rooms
multiplayeurs et voir le
nombre de joueurs
connectés afin de
rejoindre la room la plus
fréquentée
Rédiger des informations
Vérifiables
Je suis
utilisateur et je
ne veux pas
attendre ...
INVEST ? not INVEST ?
En tant qu’utilisateur je
veux recharger la page
en moins de 1 seconde 95%
du temps
6 stratégies
Pour avoir des User Stories efficaces
1.)
Par étapes d’
un Workflow
L’utilisateur accomplit une tâche selon un workflow
bien établi. On découpe les stories par étapes qui
seront développées de façon incrémentale.
source : http://www.qualitystreet.fr/
2.)
Par scénarios
On obtient une User Story pour le scénario
principal, le cas où tout se passe bien, on en a d’
autres pour les cas d’erreurs ou les scénarios
alternatifs : quand il se passe A ; quand il se passe B
source : http://www.qualitystreet.fr/
3.)
Par
opérations
Souvent le mode de décomposition le plus évident
… Le CRUD (create, Retrieve, Update, Delete) est un
bon exemple ; il est souvent utile de découper ou d’
en faire deux en même temps…créer un compte, le
consulter, le modifier et le supprimer.
source : http://www.qualitystreet.fr/
4.)
Par Format ou
type de
données
On joue sur le type d’objet (ex : compte titres,
devises, images, messages en français, anglais,
espagnol…)
source : http://www.qualitystreet.fr/
5.)
Par type d’
entrée, de
sortie ou de
configuration
Des variations d’un point de vue matériel ou non,
selon les configurations mais aussi en termes de
moyens de saisie. Cela peut se jouer aussi au
niveau de l’interface…
source : http://www.qualitystreet.fr/
6.)
Par persona
Cette fois-ci, on décompose les user stories en
fonction du rôle et de celui qui va utiliser le produit,
le fameux « en tant que… ». Pour cela, on peut s’
appuyer le user story mapping, une activité menée
au début du projet pour définir le backlog de
produit et la roadmap produit.
source : http://www.qualitystreet.fr/
Évaluer la taille
Comment juger de la compléxité d’une User Story
(avant de les plannifier)
Taille et répartition
Pour planifier les sprint, il faudra
répartir l’effort nécessaire à la
production en fonction de la
capacité de l’équipe
Il faut donc connaître la taille de l’
effort nécessaire pour chaque User
Story "Ça dépend"... Oui, ça évidemment, on vous
demande de répondre par OUI ou par NON,
alors forcement : "ça dépend", ça dépasse !
La taille
Elle est exprimée en Story Point.
C’est une valeur arbitraire qui
permet de calculer l’effort à fournir
pour la réaliser et non le temps
nécessaire à sa réalisation
Pour aller de Rome à Paris, la question de la durée
du voyage va dépendre de la vélocité du moyen de
transport choisi ... la distance, elle, ne change pas.
Une mesure relative ...
Pour démarrer :● Prendre une User Story de référence, depréférence petite et connue ou déjàexpérimentée par les développeurs;● lui attribuer une valeur basse (1, 2 ou 3Story Point)
● Traiter les autres Users Stories enappliquant des valeurs relatives (-2, +1, etc.)
Comme il s’agit de déterminer la
compléxité d’une User Story, il est
plus simple de la calculer en
valeur relative : “beaucoup plus
simple, plus facile, plus difficile,
beaucoup plus difficile”
… et exponentielle !
Nous cherchons à évaluer un ordre
de complexité. plus le scénario est
gros, moins l'évaluation est
précise.
0.5 1 2 3 5 8
13 20 40
La méthode d’évaluation ...
Problème : le premier qui parle influence les autres ...
Je suis RH, je veux
Qualifier la liste des
candidats afin de la
réduire et y retrouver
facilement les profils
correspondants à
différents critères
Quelle
taille ?
5 jours !
Ha oui, 5
c’est bien
Pareil
Pas mieux
Peut-être 6 ...
… pour
être sûr
… version Planning Pocker !
En utilisant des cartes, sorties en même temps,
chacun donne librement sa propre estimation, basée sur sa propre compréhension de la story
Je suis RH, je veux
Qualifier la liste des
candidats afin de la
réduire et y retrouver
facilement les profils
correspondants à
différents critères
Quelle
taille ?
5 3
8
5
13
ce qui permet la discussion
Si les écarts sont trop importants, on lance un débat autour des extrèmes pour comprendre les
différents points de vu, puis un nouveau tour est lancé jusqu’au concensus.
Je suis RH, je veux
Qualifier la liste des
candidats afin de la
réduire et y retrouver
facilement les profils
correspondants à
différents critères
3 et 13 :
justifiez !
5 3
8
5
13
Blah blah blah
blah blah blah
blah
Blah blah
blah blah
blah blah
blah
Prioriser
Ordonner les Users Stories (avant de les plannifier)
Fixer les priorités
Fixer les priorités consiste généralement à classer les Users Stories selon la
valeur apportée au projet
Nécessaire Souhaitable Si possible
Priorité
Critères objectifs de priorité
13 5
1313
Même taille
Valeur différente
Taille différente
Même Valeur
Priorité
Plannifier
Enfin ! Lancer la production des sprints
1. Définir la durée d’un sprint
Les sprints doivent avoir une durée
fixe.
La durée est définie en fonction :
- de vos besoins en réactivité
- des besoins en montée en
puissance de l’équipe
Les sprints peuvent avoir une
durée de 1 à 5 semaines.
Comment choisir ?
les sprints courts sont bénéfiques. Ils autorisent
l'entreprise à être “agile”, c'est-à-dire à changer
souvent de direction. Sprint court = cycle de feedback
court = des livraisons plus fréquentes = plus de
feedback des clients = moins de temps passé à courir
dans la mauvaise direction = apprendre et améliorer
plus rapidement, etc.
les longs sprints sont bien aussi. L'équipe a plus
temps pour monter en puissance, ils ont plus de
temps pour récupérer des problèmes et parvenir tout
de même à atteindre le but du sprint, il y a moins de
surcharge en terme de réunions de planning de
sprint, de démonstrations, etc.
Conclusion : il n’y a pas de règles. faîtes des tests au
début.
2. Définir la taille d’un sprint
La taille est déterminée en Story points
et dépend de la capacité de
production de l’équipe pour la durée
du sprint fixé.
Ce calcul se résume ainsi :
Jours-hommes disponibles multipliés
par le facteur de focalisation (c’est à
dire la capacité pleine de travail).
Comment calculer ?
Exemple :
● Durée des sprint :
3 semaines, soit 15 jours.
● Taille de l’équipe :
3 développeurs dont 1 à ⅔ temps , soit :
15+15+10 = 40 jours hommes.
● Facteur de focalisation :
Des perturbations externes et des réunions
sont prévues pendant ce sprint, soit une
estimation de 40% de capacité pleine de travail
Résultat : 40 Jours homme * 40% = 16 Jours
3. Créer le plan de Sprint
3 5
8
SPRINT 1 - 16 pts
5
32
SPRINT 2 - 15 pts
5
SPRINT 3 - 13 pts
85
2
Cette US dépasse la
capacité du sprint 1, elle est
reportée au sprint suivant
Les cérémonies
Un rythme qui “force” la communication...
Rythme des sprints
SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4
Sprint backlog
Démo
Rétrospective
Production
Daily meeting
Daily meeting
Une réunion courte, en début de journée
(pendant le café ?), de préférence debout
(appellée aussi standing meeting) ... c’est
une réunion “informelle“ qui doit
maintenir le lien au sein de l’équipe.
Les membres de l’équipe ont la parole. L’
objectif est de soulever les éventuels
obstacles rencontrés et de les consigner
dans le Backlog des problèmes.
Les 3 questions que chaque membre de l’équipe expose :
- Qu’ai-je fait hier ?
- Que vais-je faire aujourd’hui ?
- Quels sont les obstacles que j’ai rencontré ?
Sprint Review (démo)
Une réunion importante puisqu’elle
consiste à présenter le produit partiel
réalisé pendant le sprint.
Déroulement :
- Démo de ce qui a été fait (et fini)
- Mise à jour du Backlog : revue des
priorités, ce qui permettra de définir
le contenu du prochain sprint
L’équipe prépare la réunion et fait la présentation du
produit au Product Owner
Le scrumaster organise la mise à jour du Backlog
Rétrospective
Cette réunion, en équipe uniquement,
permet de faire le point sur le Backlog des
problèmes rencontrés durant le sprint et
de définir un plan d’action pour corriger
ces problèmes.
Objectif : Amélioration Continue
Le backlog des problèmes est consolidé
Un plan d’actions d’amélioration est défini et mis à jour
Mesurer
Connaître la vélocité pour améliorer
sa capacité à anticiper l’avenir
Estimation de la vélocité
92
80
64
48
32
16
s1 s2 s3 s4 s5 s6 s7A faire
Storypoints
Sprints
Vélocité idéale
Mesure de la vélocité
92
80
64
48
32
16
s1 s2 s3 s4 s5 s6 s7A faire
Storypoints
Sprints
Vélocité réelle
Plus lent
Plus rapide
Projection réelle
Déroulement
d’un sprint
Le backlog de sprint
Début du
sprint
TODO PROGRESS DONE :o)
5
3
3
1
8
5
2
5
1
5
5
5
ADMIN11
FRONT16MIGRATION
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
Story
Tâches
Sprint en
cours
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
1
5
5
5
ADMIN11
FRONT16MIGRATION
Les tâches, puis les stories
migrent vers Done
Certaines tâches
peuvent être
remises à plus
tard
De nouvelles
tâches peuvent
apparaître en
cours de prod
Le Burndown chart
est mis à jour
quotidiennement
5
2
Fin du
Sprint
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
1
5
5
5
ADMIN11
FRONT16
Cette Story n’est pas
terminée, elle ne sera
pas présentée lors de
la démo
2
MIGRATION
Les signaux d’alerte
Comprendre le Scrum Board
Trop de
tâches
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
1
5
5
5
ADMIN11
FRONT16MIGRATION
2
Besoin de supprimer
des éléments du
Sprint Backlog
Trop d’
imprévus
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
1
5
5
5
ADMIN11
FRONT16MIGRATION
2
Attention : l’
accumulation de
tâches non plannifiées
peuvent tuer le Sprint
Manque
de tâches
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
1
5
5 5
ADMIN11
MIGRATION
2
Besoin d’ajouter des
éléments du Sprint
Backlog
FRONT16
Respect
des
priorités
TODO PROGRESS DONE :o)
1 2 3 4 5
Sprint 3
Objectif : Présenter la béta !
Non planifiés
Suivants
5
3
3
1
8
5
5
1
5
5
5
ADMIN11
FRONT16
MIGRATION
2
Attention : L’équipe
néglige les tâches
prioritaires
Vous avez 10 projets ?
Peut-on travailler sur plusieurs projets en simultané ?
Oui !
Pour le backlog, aucun soucis : Mais attention : il faudra calculer de
manière plus précise votre facteur
de focalisation pour chaque projet,
imputé nécessairement par la
production sur les autres projets au
sein d’un même Sprint !
Projet 1
Projet 2
… etc.
Exemple multi-projets
SPRINT 1 (44 points) SPRINT 2 (44 points) SPRINT 3 (44 points) SPRINT 4
Sprint backlog
Démo
Rétrospective
Production
Daily meeting
Projet 1
Projet 2
Projet 3
Focus = 15 %
Focus = 30 %
Focus = 15 %
Taille équipe : 3 développeurs
Focus équipe : 60%
Taille Sprint : 2 semaines
Capacité Sprint = 30jh * 60% = 18 jours, soit : 9 + 4,5 + 4,5
SI 1 sp = 3h, la capacité est donc de 22 + 11 + 11, soit 44 SP par sprint
CAPACITÉ :
Planning :
Et les contrats ?
Est-ce que les méthodes agiles sont adaptées
aux prestataires de services ?
Les 2 types de contrats :
Au forfait
Le forfait est par nature antinomique avec les
méthodes agiles … mais rien n’empêche de
décomposer un forfait en lots, équivalent à vos
incréments.
Attention à bien définir le périmètre fonctionnel en
amont pour garantir au fournisseur (le développeur)
qu’il ne rognera pas sa marge.
A la régie
C’est la méthode la plus naturelle, mais qui nécessite
une relation de confiance forte.
Définir le périmètre peut également être une bonne
idée pour garantir au client qu’il ne dépensera pas
plus que nécessaire.
Paradoxes des contrats
En régie : plus le projet avance, moins la valeur perçue par le
client est forte. Le développement devrait donc prendre fin
lorsque le coût dépasse la valeur marginale acquise.
Avec le mode forfait, le coût est négocié d’avance. Ainsi, plus le
développeur travaille (pour une valeur moindre), plus il rogne sa
marge.
source : http://blog.xebia.fr/
Découpage par lots
C’est une alternative ...
En définissant des
budgets par lots on
peut lier anticipation et
engagement avec la
flexibilité des méthodes
agiles
Merci !
That’s all Folks
Des concepts pour aller plus loin
Le Story Mapping :
Il s’agit d’une représentation à 2 dimensions et plus riche de
celle offerte par le Backlog de produit. En horizontal : les usages,
en vertical : les priorités.
Kanban :
Un outil plus souple que SCRUM … et pourquoi ne pas le
mélanger avec SCRUM ?
Behaviour Driven Development :
Compléter les stories en expliquant les comportements : Given
When Then
Les Personas :
Rédaction de fiches utilisateurs précises et détaillées. Les
personas évitent de parler en terme de “panel” et permettent
une approche plus personnifier des fonctions.
Definition of Done :
Définition du “fini”, pour les stories, les sprint et les releases afin
de s’assurer que toute l’équipe suive un même niveau de
qualité.
RESSOURCES
Les méthodes Agiles expliquées
www.qualitystreet.fr/
www.agiliste.fr/
henrik-kniberg.developpez.com/livre/scrum-xp
henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban
La culture Agile
http://blog.xebia.fr/category/agilite
www.areyouagile.com/
Contrat Agile
http://www.contrat-agile.org/
www.scrum.org
15 minutes
pour
comprendre
SCRUM

Contenu connexe

Tendances

Introduction aux méthodes agiles
Introduction aux méthodes agilesIntroduction aux méthodes agiles
Introduction aux méthodes agilesGuillaume Collic
 
Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsPierre E. NEIS
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slidesNicolas Deverge
 
De l'expression de besoins vers spécifications de la solution
De l'expression de besoins vers spécifications de la solutionDe l'expression de besoins vers spécifications de la solution
De l'expression de besoins vers spécifications de la solutionCOMPETENSIS
 
Présentation de l’agilité
Présentation de l’agilitéPrésentation de l’agilité
Présentation de l’agilitéJean Yves Klein
 
Méthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPMéthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPYouness Boukouchi
 
Formation Professional Scrum Master I
Formation Professional Scrum Master IFormation Professional Scrum Master I
Formation Professional Scrum Master IGuillaume LAURIE
 
Mon cours Agile scrum.ppt
Mon cours Agile scrum.pptMon cours Agile scrum.ppt
Mon cours Agile scrum.pptamani75494
 

Tendances (20)

Introduction aux méthodes agiles
Introduction aux méthodes agilesIntroduction aux méthodes agiles
Introduction aux méthodes agiles
 
Gestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskillsGestion de projets agiles avec scrum actiskills
Gestion de projets agiles avec scrum actiskills
 
Scrum Guide
Scrum GuideScrum Guide
Scrum Guide
 
Methodes agile
Methodes agileMethodes agile
Methodes agile
 
Formation Agile Scrum
Formation Agile ScrumFormation Agile Scrum
Formation Agile Scrum
 
Scrum
ScrumScrum
Scrum
 
L'agilité en quelques slides
L'agilité en quelques slidesL'agilité en quelques slides
L'agilité en quelques slides
 
De l'expression de besoins vers spécifications de la solution
De l'expression de besoins vers spécifications de la solutionDe l'expression de besoins vers spécifications de la solution
De l'expression de besoins vers spécifications de la solution
 
Introduction à Scrum
Introduction à ScrumIntroduction à Scrum
Introduction à Scrum
 
Présentation de l’agilité
Présentation de l’agilitéPrésentation de l’agilité
Présentation de l’agilité
 
La gestion de projet agile
La gestion de projet agileLa gestion de projet agile
La gestion de projet agile
 
Les différentes phases d’un projet - La phase d’initialisation
Les différentes phases d’un projet - La phase d’initialisationLes différentes phases d’un projet - La phase d’initialisation
Les différentes phases d’un projet - La phase d’initialisation
 
Rôles product-owner
Rôles product-ownerRôles product-owner
Rôles product-owner
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
 
Méthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XPMéthodes agiles: Scrum et XP
Méthodes agiles: Scrum et XP
 
Formation Professional Scrum Master I
Formation Professional Scrum Master IFormation Professional Scrum Master I
Formation Professional Scrum Master I
 
Methodes agiles
Methodes agilesMethodes agiles
Methodes agiles
 
Gestion de projet agile avec Scrum
Gestion de projet agile avec ScrumGestion de projet agile avec Scrum
Gestion de projet agile avec Scrum
 
Gestion de projet
Gestion de projetGestion de projet
Gestion de projet
 
Mon cours Agile scrum.ppt
Mon cours Agile scrum.pptMon cours Agile scrum.ppt
Mon cours Agile scrum.ppt
 

En vedette

Historique des méthodes agiles
Historique des méthodes agilesHistorique des méthodes agiles
Historique des méthodes agilesazeau
 
Thiga - Notre retour d'expérience sur le Design sprint
Thiga - Notre retour d'expérience sur le Design sprintThiga - Notre retour d'expérience sur le Design sprint
Thiga - Notre retour d'expérience sur le Design sprintThiga
 
Installation magento 2 avec mamp
 Installation magento 2 avec mamp Installation magento 2 avec mamp
Installation magento 2 avec mampBlackbird
 
soft-shake.ch - De Hermes RUP à Hermes Scrum
soft-shake.ch - De Hermes RUP à Hermes Scrumsoft-shake.ch - De Hermes RUP à Hermes Scrum
soft-shake.ch - De Hermes RUP à Hermes Scrumsoft-shake.ch
 
L’art de faire des présentations ...
L’art de faire des présentations ...L’art de faire des présentations ...
L’art de faire des présentations ...Blackbird
 
Kanban, un outil simple de gestion de la production.
Kanban, un outil simple de gestion de la production.Kanban, un outil simple de gestion de la production.
Kanban, un outil simple de gestion de la production.Blackbird
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementNassim Bahri
 
Rapport de stage pfe odoo 8
Rapport de stage pfe odoo 8 Rapport de stage pfe odoo 8
Rapport de stage pfe odoo 8 ayoub damir
 
Méthodologie 2 Track Unified Process
Méthodologie 2 Track Unified ProcessMéthodologie 2 Track Unified Process
Méthodologie 2 Track Unified ProcessZakaria Bouazza
 
Méthodes Agiles, L’essentiel de KANBAN.
Méthodes Agiles, L’essentiel de KANBAN.Méthodes Agiles, L’essentiel de KANBAN.
Méthodes Agiles, L’essentiel de KANBAN.aettarrouzi
 
DEVOPS - La synthèse
DEVOPS - La synthèseDEVOPS - La synthèse
DEVOPS - La synthèseCOMPETENSIS
 
Gestion des Chercheurs d’Emploi
Gestion des Chercheurs d’EmploiGestion des Chercheurs d’Emploi
Gestion des Chercheurs d’EmploiAzzeddine Elouadi
 
Journée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOpsJournée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOpsPublicis Sapient Engineering
 
Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agilesguesta206aa87
 

En vedette (19)

Historique des méthodes agiles
Historique des méthodes agilesHistorique des méthodes agiles
Historique des méthodes agiles
 
Thiga - Notre retour d'expérience sur le Design sprint
Thiga - Notre retour d'expérience sur le Design sprintThiga - Notre retour d'expérience sur le Design sprint
Thiga - Notre retour d'expérience sur le Design sprint
 
Rédiger des User Stories
Rédiger des User StoriesRédiger des User Stories
Rédiger des User Stories
 
Installation magento 2 avec mamp
 Installation magento 2 avec mamp Installation magento 2 avec mamp
Installation magento 2 avec mamp
 
soft-shake.ch - De Hermes RUP à Hermes Scrum
soft-shake.ch - De Hermes RUP à Hermes Scrumsoft-shake.ch - De Hermes RUP à Hermes Scrum
soft-shake.ch - De Hermes RUP à Hermes Scrum
 
L’art de faire des présentations ...
L’art de faire des présentations ...L’art de faire des présentations ...
L’art de faire des présentations ...
 
Kanban, un outil simple de gestion de la production.
Kanban, un outil simple de gestion de la production.Kanban, un outil simple de gestion de la production.
Kanban, un outil simple de gestion de la production.
 
Scrum vs RUP
Scrum vs RUPScrum vs RUP
Scrum vs RUP
 
Atam2014 manager agile
Atam2014 manager agileAtam2014 manager agile
Atam2014 manager agile
 
User stories
User storiesUser stories
User stories
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Rapport de stage pfe odoo 8
Rapport de stage pfe odoo 8 Rapport de stage pfe odoo 8
Rapport de stage pfe odoo 8
 
Méthodologie 2 Track Unified Process
Méthodologie 2 Track Unified ProcessMéthodologie 2 Track Unified Process
Méthodologie 2 Track Unified Process
 
Méthodes Agiles, L’essentiel de KANBAN.
Méthodes Agiles, L’essentiel de KANBAN.Méthodes Agiles, L’essentiel de KANBAN.
Méthodes Agiles, L’essentiel de KANBAN.
 
DEVOPS - La synthèse
DEVOPS - La synthèseDEVOPS - La synthèse
DEVOPS - La synthèse
 
Gestion des Chercheurs d’Emploi
Gestion des Chercheurs d’EmploiGestion des Chercheurs d’Emploi
Gestion des Chercheurs d’Emploi
 
Journée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOpsJournée DevOps : La boite à outil d'une équipe DevOps
Journée DevOps : La boite à outil d'une équipe DevOps
 
Les MéThodes Agiles
Les MéThodes AgilesLes MéThodes Agiles
Les MéThodes Agiles
 
Agilité pour les nuls
Agilité pour les nulsAgilité pour les nuls
Agilité pour les nuls
 

Similaire à Introduction à Scrum et aux méthodes agiles (v1.0)

Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013agnes_crepet
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Pyxis Technologies
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmseagnes_crepet
 
Agile Sans Frontières
Agile Sans FrontièresAgile Sans Frontières
Agile Sans FrontièresCARA_Lyon
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_finalagnes_crepet
 
Agile Day Tunisia 2012 - Agile entre opportunités et résistance
Agile Day Tunisia 2012 - Agile entre opportunités et résistanceAgile Day Tunisia 2012 - Agile entre opportunités et résistance
Agile Day Tunisia 2012 - Agile entre opportunités et résistanceTunisia Scrum User Group
 
Les tests automatisés par mots-clés, le complément parfait d’un projet Agile
Les tests automatisés par mots-clés, le complément parfait d’un projet AgileLes tests automatisés par mots-clés, le complément parfait d’un projet Agile
Les tests automatisés par mots-clés, le complément parfait d’un projet AgileAgile Montréal
 
Webinaire BluTech 02/2023 - L'agilité
Webinaire BluTech 02/2023 - L'agilitéWebinaire BluTech 02/2023 - L'agilité
Webinaire BluTech 02/2023 - L'agilitéAdrienMusserotte1
 
Le scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheurLe scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheursebastien_fournel
 
Gestion de projet #4 : spécification
Gestion de projet #4 : spécificationGestion de projet #4 : spécification
Gestion de projet #4 : spécificationJean Michel
 
Scrum pour les (nuls) devs
Scrum pour les (nuls) devsScrum pour les (nuls) devs
Scrum pour les (nuls) devsJenny Beaumont
 
Comment créer un produit en mode startup Agile @Digicoop - Maxime Bouroumeau-...
Comment créer un produit en mode startup Agile @Digicoop - Maxime Bouroumeau-...Comment créer un produit en mode startup Agile @Digicoop - Maxime Bouroumeau-...
Comment créer un produit en mode startup Agile @Digicoop - Maxime Bouroumeau-...Agile En Seine
 
Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Dominic Danis
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de ScrumPyxis Technologies
 

Similaire à Introduction à Scrum et aux méthodes agiles (v1.0) (20)

Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
 
Introduction à l'agilité ensmse
Introduction à l'agilité   ensmseIntroduction à l'agilité   ensmse
Introduction à l'agilité ensmse
 
Agile Sans Frontières
Agile Sans FrontièresAgile Sans Frontières
Agile Sans Frontières
 
Agile Tour Lille 2008
Agile Tour Lille 2008Agile Tour Lille 2008
Agile Tour Lille 2008
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
Agile Day Tunisia 2012 - Agile entre opportunités et résistance
Agile Day Tunisia 2012 - Agile entre opportunités et résistanceAgile Day Tunisia 2012 - Agile entre opportunités et résistance
Agile Day Tunisia 2012 - Agile entre opportunités et résistance
 
#3 etapes projet
#3 etapes projet#3 etapes projet
#3 etapes projet
 
Les tests automatisés par mots-clés, le complément parfait d’un projet Agile
Les tests automatisés par mots-clés, le complément parfait d’un projet AgileLes tests automatisés par mots-clés, le complément parfait d’un projet Agile
Les tests automatisés par mots-clés, le complément parfait d’un projet Agile
 
Methodologies agiles
Methodologies agilesMethodologies agiles
Methodologies agiles
 
Webinaire BluTech 02/2023 - L'agilité
Webinaire BluTech 02/2023 - L'agilitéWebinaire BluTech 02/2023 - L'agilité
Webinaire BluTech 02/2023 - L'agilité
 
Le scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheurLe scrum master, metamorphe du bonheur
Le scrum master, metamorphe du bonheur
 
Gestion de projet #4 : spécification
Gestion de projet #4 : spécificationGestion de projet #4 : spécification
Gestion de projet #4 : spécification
 
Brochure Vers l'entreprise Agile
Brochure Vers l'entreprise AgileBrochure Vers l'entreprise Agile
Brochure Vers l'entreprise Agile
 
Agile expliqué aux managers
Agile expliqué aux managersAgile expliqué aux managers
Agile expliqué aux managers
 
Agilite Scrum
Agilite Scrum Agilite Scrum
Agilite Scrum
 
Scrum pour les (nuls) devs
Scrum pour les (nuls) devsScrum pour les (nuls) devs
Scrum pour les (nuls) devs
 
Comment créer un produit en mode startup Agile @Digicoop - Maxime Bouroumeau-...
Comment créer un produit en mode startup Agile @Digicoop - Maxime Bouroumeau-...Comment créer un produit en mode startup Agile @Digicoop - Maxime Bouroumeau-...
Comment créer un produit en mode startup Agile @Digicoop - Maxime Bouroumeau-...
 
Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de Scrum
 

Introduction à Scrum et aux méthodes agiles (v1.0)

  • 2. Blackbird est une agence de développement web spécialisée dans l’accompagnement et le développement de projets e- commerce sur la solution Magento. http://black.bird.eu About
  • 3. Sommaire ● Introduction ● Les principes fondamentaux ● Présentation des Users Stories ● 6 stratégies pour rédiger des US efficaces ● Évaluer la taille des Users Stories ● Prioriser les Users Stories ● Plannifier les Sprints ● Les cérémonies : des outils pour communiquer ● Mesurer la vélocité de la production ● Déroulement d’un sprint ● Les signaux d’alertes, savoir interpréter le tableau de sprint ● Traiter plusieurs projets en simultané ● Aspects contractuels ● Concepts et ressources pour aller plus loin
  • 4. 1980 1990 2000 2010 Gantt / PERT : Cascade ( Waterfall, V Model, etc.) Méthodes Agiles Origines des méthodes Agiles 19501900 Taylorisme Lean Toyota Production System Process focus People focus
  • 5. Des outils plus ou moins normatifs RUP XP SCRUM KANBAN Faites ce que vous voulez 120+ 13 9 3 0 plusnormatif plusadaptatif RUP est assez normatif - avec plus de 30 rôles, plus de 20 activités et plus de 70 artefacts; une énorme quantité de choses à apprendre. XP (eXtreme Programming) inclut une majorité des règles de Scrum plus un ensemble de pratiques d'ingénierie bien spécifiques comme le développement piloté par les tests et la programmation en binôme. Scrum est moins normatif que XP puisqu'il ne recommande aucune pratique d'ingénierie particulière. Scrum est plus normatif que Kanban cependant, car il impose des choses comme les itérations et les équipes multidisciplinaires. Kanban laisse tout ouvert. Les seules contraintes sont de Visualiser Votre Workflow et de Limiter Votre TAF. Tout près du "Faire N'importe Quoi", mais étonnamment puissant. source : http://henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban/
  • 6. Les principales différences entre cycle en V et méthodes agiles Personnes et interactions Logiciel qui fonctionne Collaboration avec le client Adaptation au changement Processus et outils Documentation Négociation sur le contrat Suivi d’un plan pré-établi vs vs vs vs Agile Cycle V
  • 7. Le paradoxe de la gestion de projet Capacité d’action Temps Connaissance du projet
  • 8. Pourquoi ? ● Faciliter l’expression des besoins ● Aider à l’acceptation du changement Comment ? ● Organiser l’expression des besoins ● Intégrer le client ● Démarche itérative Le modèle Agile
  • 9. Quels projets favoriser ? ● Besoin rapide de mise à disposition du produit ● Imprévisibilité des besoins du client ● Nécessité de changements fréquents ● Besoin de visibilité du client sur l'avancement des développements ● Présence de l'utilisateur assurant un feedback immédiat
  • 10. ● Indisponibilité du client ou de l'utilisateur ● Dispersion géographique des ressources humaines ● Inertie des acteurs du projet ou refus des changements ● Gouvernance complexe de la DSI Quels projets éviter ?
  • 12. Les 4 valeurs fondamentales L'équipe « Les individus et leurs interactions, plus que les processus et les outils » L'application « Des logiciels opérationnels, plus qu'une documentation exhaustive » L'acceptation du changement « L'adaptation au changement, plus que le suivi d'un plan » La collaboration « La collaboration avec les clients, plus que la négociation contractuelle » source : Wikipedia
  • 14. User Focus 1. La plus haute priorité est de satisfaire le client (l’utilisateur final du produit) en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée. source : Wikipedia
  • 15. Un modèle itératif 2. La livraison s’applique à une application fonctionnelle, toutes les deux semaines à deux mois, avec une préférence pour la période la plus courte. 3. L’unité de mesure de la progression du projet est un logiciel fonctionnel (ce qui exclut de comptabiliser les fonctions non formellement achevées). 4. Le changement est accepté, même tardivement dans le développement, car les processus agiles exploitent le changement comme avantage concurrentiel pour le client source : Wikipedia
  • 16. Un modèle Collaboratif 5. Le projet doit impliquer des personnes motivées. Donnez-leur l'environnement et le soutien dont elles ont besoin et faites leur confiance quant au respect des objectifs. 6. Le métier et les développeurs doivent collaborer régulièrement et de préférence quotidiennement au projet. 7. La méthode la plus efficace pour transmettre l'information est une conversation en face à face. 8. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son processus de travail en conséquence. source : Wikipedia
  • 17. Focus on quality 9. Les processus agiles promeuvent un rythme de développement soutenable 10. Les processus agiles recommandent une attention continue à l'excellence technique et à la qualité de la conception. 11. La simplicité et l'art de minimiser les tâches parasites, sont appliqués comme principes essentiels. 12. Les équipes s'auto-organisent afin de faire émerger les meilleures architectures, spécifications et conceptions. source : Wikipedia
  • 18. Structure opérationnelle et pratique du développement agile … là on parle de SCRUM
  • 19. Les rôles Product Owner Scrum Master Team
  • 20. Démarche itérative Produit Release 1 Release 2 Sprint 1 Sprint 2 Sprint 3 Story Story Story
  • 21. Itérations Release Chaque fin de release apporte de nouvelles fonctionnalités pour les utilisateurs ROADMAP Release 1 Release 2 ...
  • 22. Itérations Sprint Chaque fin de sprint apporte de nouvelles fonctionnalités pour les Product Owner RELEASE Sprint 1 Sprint 2 ...
  • 23. Itérations Stories Chaque fin de Story est une nouvelle liste de tâches terminées pour la team SPRINT Story 1 Story 2 ...
  • 24. Planning ROADMAP RELEASE ... SPRINT SPRINT SPRINT Story Story Story Story Sprint review Sprint review Sprint review Sprint planning Sprint planning Release review
  • 27. Définition du Backlog Une liste des fonctionnalités à réaliser Chaque fonctionnalité est décrite par une Story Le backlog est défini en amont du projet puis actualisé tout au long du projet Les stories y sont priorisées en fonction de leur taille (plus petites en premier) et de leur valeur (plus grande valeur en premier)
  • 28. Backlog et planification Backlog Sprint 1 Sprint 2 Produit partiel Produit partiel Story Story StoryStory StoryStory StoryStory StoryStory Story Sprint 3 ... Produit partiel Story ... Actualisation du backlog
  • 29. Les Users Stories Tout projet est un ensemble de belles histoires
  • 30. En tant qu’utilisateur je veux ajouter un produit à mes favoris afin de pour le retrouver facilement plus tard User Story En tant qu’utilisateur jeveux ajouter un produità mes favoris afin depour le retrouverfacilement plus tard En tant que Sylvianne, je veux ajouter un produit à mes favoris afin de le retrouver facilement plus tard Une user story est un élément fonctionnel qui apporte une valeur et qui peut être développée au cours d’un sprint.
  • 31. Pourquoi User ? Pourquoi Story ? Pourquoi pas simplement une tâche ? Format engageant du "Story Telling" L’information est spécifique concise et précise. L’accent est mis sur les buts et les comportements. L’utilisateur est clairement défini, c’est le héro des petites "histoires". Ce n’est pas un panel (“80% des femmes,“ “entre 25 et 35 ans“, etc.) Ouvre au dialogue, à l’échange.
  • 32. Le format “User Voice” En tant que < Rôle d’utilisateur >, Je veux < But >, Afin de < Justification > Le format « User Voice » donne du sens à la fonctionnalité… pour qui et pourquoi l’équipe va la développer Il permet de se rapprocher d’une démarche expérience utilisateur, donne une vision concrète, réaliste et partagée de l’utilisateur final. Il est clairement orienté ACTION et BUT (démarche de conception le plus efficace). La valeur Business représente les bénéfices qui se dégagent de l’ action : Il justifie toutes les fonctionnalités d’un point de vue Business, et oblige le Product Owner et les équipes à s’interroger systématiquement sur la valeur de chaque fonctionnalité
  • 33. Attributs d’une U.S. Libellé court de la fonction. Une phrase d’ action à l’infinitif. Exemples : «Voir les commandes», «Choisir un produit», «imprimer les factures», ... etc. Numéro d’identification unique Description libre ou structurée (“User Voice” ou liste d’actions élémentaires) Titre ID Description Type Etat Taille Priorité
  • 34. Attributs d’une U.S. User (administrateur, utilisateur, etc.) ou Technique (vue développeur, bug, etc.) Créee, Acceptée, Estimée, Planifiée, En cours, Terminée Selon l’évaluation faîte lors du planning pocker Classement selon taille / valeur Titre ID Description Type Etat Taille Priorité
  • 35. INVEST’ir dans une bonne histoire Indépendante | éviter les dépendances Négociable | elle peut être discutée avec l’ équipe chargée de la réalisation. Il n’est pas nécessaire d’inclure tous les détails Valeur | elle est source de valeur pour le client ou l’utilisateur. Estimable | elle peut être estimée par l’ équipe de réalisation avec un risque d’erreur faible. Size (Taille) | Des petites histoires qui peuvent se combiner. Elle doit pouvoir être conçue, développée et testée au sein d’une itération. Testable | Un test démontre que l’histoire correspond bien aux besoins du client
  • 37. Je suis un client, je veux payer avec ma MasterCard ... INVEST ? not INVEST ? Je suis un client, je veux payer en ligne … ◻ avec ma CB (Mastercard, Visa, etc.) ◻ avec Paypal N’est pas Indépendante
  • 38. Une boîte de dialogue permet aux utilisateurs d’éditer la liste des imprimantes. La boîte de dialogue permet aux utilisateurs d’ajouter ou de supprimer des imprimantes. Un utilisateur peut ajouter une imprimante par une recherche automatique ou manuelle par le biais d’ une adresse DNS ou d’une adresse IP. Une recherche avancée optionnelle permet de filtrer les imprimantes par adresse IP ou par le masque de réseau INVEST ? not INVEST ? Je suis un utilisateur, je peux ajouter une imprimante afin d’y avoir accès depuis n’importe quel logiciel de mon système ◻ Recherche automatique ◻ Recherche manuelle (IP ou DNS) ◻ Autres solutions ? Difficilement négociable, manque de flexibilité
  • 39. De la valeur pour le client Je suis RH, je veux Qualifier la liste des candidats afin de la réduire et y retrouver facilement les profils correspondants à différents critères ◻ Attribuer une note ◻ Associer un tag ◻ Marquer l’état (à conserver, rejetté, entretien, etc.) De la valeur pour l’utilisateur Je suis demandeur d’ emploi, je veux rechercher un emploi par poste et par région afin de trouver une offre correspondant à mes besoins. INVEST ? not INVEST ?
  • 40. Non estimable, le développeur ne maîtrise pas le domaine technique EPIC ! Non estimable, le développeur ne maîtrise pas le domaine fonctionnel Je suis Commercial, je veux suivre la marge net mensuelle de mes ventes afin de ... INVEST ? not INVEST ? Je suis Médecin, je veux accéder aux informations de mon patient sur DXCARE Je suis Chômeur, je recherche un emploi ...
  • 41. EPIC ! Je suis vendeur je veux gérer mes objets en vente ... INVEST ? not INVEST ? Découper en données opérationnelles Je suis vendeur, je veux créer une fiche produit afin de vendre un objet Je suis vendeur, je peux ajouter plusieurs photos afin d’améliorer la visibilité de mon produit Je suis vendeur, je veux supprimer ma fiche afin de neplus être contacté une fois ma venteeffectuée.
  • 42. Détailler en données opérationnelles EPIC ! Je suis Joueur je veux jouer en ligne contre un max d’ autres joueurs INVEST ? not INVEST ? Je suis joueur, je veux lister les rooms multiplayeurs et voir le nombre de joueurs connectés afin de rejoindre la room la plus fréquentée
  • 43. Rédiger des informations Vérifiables Je suis utilisateur et je ne veux pas attendre ... INVEST ? not INVEST ? En tant qu’utilisateur je veux recharger la page en moins de 1 seconde 95% du temps
  • 44. 6 stratégies Pour avoir des User Stories efficaces
  • 45. 1.) Par étapes d’ un Workflow L’utilisateur accomplit une tâche selon un workflow bien établi. On découpe les stories par étapes qui seront développées de façon incrémentale. source : http://www.qualitystreet.fr/
  • 46. 2.) Par scénarios On obtient une User Story pour le scénario principal, le cas où tout se passe bien, on en a d’ autres pour les cas d’erreurs ou les scénarios alternatifs : quand il se passe A ; quand il se passe B source : http://www.qualitystreet.fr/
  • 47. 3.) Par opérations Souvent le mode de décomposition le plus évident … Le CRUD (create, Retrieve, Update, Delete) est un bon exemple ; il est souvent utile de découper ou d’ en faire deux en même temps…créer un compte, le consulter, le modifier et le supprimer. source : http://www.qualitystreet.fr/
  • 48. 4.) Par Format ou type de données On joue sur le type d’objet (ex : compte titres, devises, images, messages en français, anglais, espagnol…) source : http://www.qualitystreet.fr/
  • 49. 5.) Par type d’ entrée, de sortie ou de configuration Des variations d’un point de vue matériel ou non, selon les configurations mais aussi en termes de moyens de saisie. Cela peut se jouer aussi au niveau de l’interface… source : http://www.qualitystreet.fr/
  • 50. 6.) Par persona Cette fois-ci, on décompose les user stories en fonction du rôle et de celui qui va utiliser le produit, le fameux « en tant que… ». Pour cela, on peut s’ appuyer le user story mapping, une activité menée au début du projet pour définir le backlog de produit et la roadmap produit. source : http://www.qualitystreet.fr/
  • 51. Évaluer la taille Comment juger de la compléxité d’une User Story (avant de les plannifier)
  • 52. Taille et répartition Pour planifier les sprint, il faudra répartir l’effort nécessaire à la production en fonction de la capacité de l’équipe Il faut donc connaître la taille de l’ effort nécessaire pour chaque User Story "Ça dépend"... Oui, ça évidemment, on vous demande de répondre par OUI ou par NON, alors forcement : "ça dépend", ça dépasse !
  • 53. La taille Elle est exprimée en Story Point. C’est une valeur arbitraire qui permet de calculer l’effort à fournir pour la réaliser et non le temps nécessaire à sa réalisation Pour aller de Rome à Paris, la question de la durée du voyage va dépendre de la vélocité du moyen de transport choisi ... la distance, elle, ne change pas.
  • 54. Une mesure relative ... Pour démarrer :● Prendre une User Story de référence, depréférence petite et connue ou déjàexpérimentée par les développeurs;● lui attribuer une valeur basse (1, 2 ou 3Story Point) ● Traiter les autres Users Stories enappliquant des valeurs relatives (-2, +1, etc.) Comme il s’agit de déterminer la compléxité d’une User Story, il est plus simple de la calculer en valeur relative : “beaucoup plus simple, plus facile, plus difficile, beaucoup plus difficile”
  • 55. … et exponentielle ! Nous cherchons à évaluer un ordre de complexité. plus le scénario est gros, moins l'évaluation est précise. 0.5 1 2 3 5 8 13 20 40
  • 56. La méthode d’évaluation ... Problème : le premier qui parle influence les autres ... Je suis RH, je veux Qualifier la liste des candidats afin de la réduire et y retrouver facilement les profils correspondants à différents critères Quelle taille ? 5 jours ! Ha oui, 5 c’est bien Pareil Pas mieux Peut-être 6 ... … pour être sûr
  • 57. … version Planning Pocker ! En utilisant des cartes, sorties en même temps, chacun donne librement sa propre estimation, basée sur sa propre compréhension de la story Je suis RH, je veux Qualifier la liste des candidats afin de la réduire et y retrouver facilement les profils correspondants à différents critères Quelle taille ? 5 3 8 5 13
  • 58. ce qui permet la discussion Si les écarts sont trop importants, on lance un débat autour des extrèmes pour comprendre les différents points de vu, puis un nouveau tour est lancé jusqu’au concensus. Je suis RH, je veux Qualifier la liste des candidats afin de la réduire et y retrouver facilement les profils correspondants à différents critères 3 et 13 : justifiez ! 5 3 8 5 13 Blah blah blah blah blah blah blah Blah blah blah blah blah blah blah
  • 59. Prioriser Ordonner les Users Stories (avant de les plannifier)
  • 60. Fixer les priorités Fixer les priorités consiste généralement à classer les Users Stories selon la valeur apportée au projet Nécessaire Souhaitable Si possible Priorité
  • 61. Critères objectifs de priorité 13 5 1313 Même taille Valeur différente Taille différente Même Valeur Priorité
  • 62. Plannifier Enfin ! Lancer la production des sprints
  • 63. 1. Définir la durée d’un sprint Les sprints doivent avoir une durée fixe. La durée est définie en fonction : - de vos besoins en réactivité - des besoins en montée en puissance de l’équipe Les sprints peuvent avoir une durée de 1 à 5 semaines. Comment choisir ? les sprints courts sont bénéfiques. Ils autorisent l'entreprise à être “agile”, c'est-à-dire à changer souvent de direction. Sprint court = cycle de feedback court = des livraisons plus fréquentes = plus de feedback des clients = moins de temps passé à courir dans la mauvaise direction = apprendre et améliorer plus rapidement, etc. les longs sprints sont bien aussi. L'équipe a plus temps pour monter en puissance, ils ont plus de temps pour récupérer des problèmes et parvenir tout de même à atteindre le but du sprint, il y a moins de surcharge en terme de réunions de planning de sprint, de démonstrations, etc. Conclusion : il n’y a pas de règles. faîtes des tests au début.
  • 64. 2. Définir la taille d’un sprint La taille est déterminée en Story points et dépend de la capacité de production de l’équipe pour la durée du sprint fixé. Ce calcul se résume ainsi : Jours-hommes disponibles multipliés par le facteur de focalisation (c’est à dire la capacité pleine de travail). Comment calculer ? Exemple : ● Durée des sprint : 3 semaines, soit 15 jours. ● Taille de l’équipe : 3 développeurs dont 1 à ⅔ temps , soit : 15+15+10 = 40 jours hommes. ● Facteur de focalisation : Des perturbations externes et des réunions sont prévues pendant ce sprint, soit une estimation de 40% de capacité pleine de travail Résultat : 40 Jours homme * 40% = 16 Jours
  • 65. 3. Créer le plan de Sprint 3 5 8 SPRINT 1 - 16 pts 5 32 SPRINT 2 - 15 pts 5 SPRINT 3 - 13 pts 85 2 Cette US dépasse la capacité du sprint 1, elle est reportée au sprint suivant
  • 66. Les cérémonies Un rythme qui “force” la communication...
  • 67. Rythme des sprints SPRINT 1 SPRINT 2 SPRINT 3 SPRINT 4 Sprint backlog Démo Rétrospective Production Daily meeting
  • 68. Daily meeting Une réunion courte, en début de journée (pendant le café ?), de préférence debout (appellée aussi standing meeting) ... c’est une réunion “informelle“ qui doit maintenir le lien au sein de l’équipe. Les membres de l’équipe ont la parole. L’ objectif est de soulever les éventuels obstacles rencontrés et de les consigner dans le Backlog des problèmes. Les 3 questions que chaque membre de l’équipe expose : - Qu’ai-je fait hier ? - Que vais-je faire aujourd’hui ? - Quels sont les obstacles que j’ai rencontré ?
  • 69. Sprint Review (démo) Une réunion importante puisqu’elle consiste à présenter le produit partiel réalisé pendant le sprint. Déroulement : - Démo de ce qui a été fait (et fini) - Mise à jour du Backlog : revue des priorités, ce qui permettra de définir le contenu du prochain sprint L’équipe prépare la réunion et fait la présentation du produit au Product Owner Le scrumaster organise la mise à jour du Backlog
  • 70. Rétrospective Cette réunion, en équipe uniquement, permet de faire le point sur le Backlog des problèmes rencontrés durant le sprint et de définir un plan d’action pour corriger ces problèmes. Objectif : Amélioration Continue Le backlog des problèmes est consolidé Un plan d’actions d’amélioration est défini et mis à jour
  • 71. Mesurer Connaître la vélocité pour améliorer sa capacité à anticiper l’avenir
  • 72. Estimation de la vélocité 92 80 64 48 32 16 s1 s2 s3 s4 s5 s6 s7A faire Storypoints Sprints Vélocité idéale
  • 73. Mesure de la vélocité 92 80 64 48 32 16 s1 s2 s3 s4 s5 s6 s7A faire Storypoints Sprints Vélocité réelle Plus lent Plus rapide Projection réelle
  • 75. Début du sprint TODO PROGRESS DONE :o) 5 3 3 1 8 5 2 5 1 5 5 5 ADMIN11 FRONT16MIGRATION 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants Story Tâches
  • 76. Sprint en cours TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 FRONT16MIGRATION Les tâches, puis les stories migrent vers Done Certaines tâches peuvent être remises à plus tard De nouvelles tâches peuvent apparaître en cours de prod Le Burndown chart est mis à jour quotidiennement 5 2
  • 77. Fin du Sprint TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 FRONT16 Cette Story n’est pas terminée, elle ne sera pas présentée lors de la démo 2 MIGRATION
  • 79. Trop de tâches TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 FRONT16MIGRATION 2 Besoin de supprimer des éléments du Sprint Backlog
  • 80. Trop d’ imprévus TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 FRONT16MIGRATION 2 Attention : l’ accumulation de tâches non plannifiées peuvent tuer le Sprint
  • 81. Manque de tâches TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 MIGRATION 2 Besoin d’ajouter des éléments du Sprint Backlog FRONT16
  • 82. Respect des priorités TODO PROGRESS DONE :o) 1 2 3 4 5 Sprint 3 Objectif : Présenter la béta ! Non planifiés Suivants 5 3 3 1 8 5 5 1 5 5 5 ADMIN11 FRONT16 MIGRATION 2 Attention : L’équipe néglige les tâches prioritaires
  • 83. Vous avez 10 projets ? Peut-on travailler sur plusieurs projets en simultané ?
  • 84. Oui ! Pour le backlog, aucun soucis : Mais attention : il faudra calculer de manière plus précise votre facteur de focalisation pour chaque projet, imputé nécessairement par la production sur les autres projets au sein d’un même Sprint ! Projet 1 Projet 2 … etc.
  • 85. Exemple multi-projets SPRINT 1 (44 points) SPRINT 2 (44 points) SPRINT 3 (44 points) SPRINT 4 Sprint backlog Démo Rétrospective Production Daily meeting Projet 1 Projet 2 Projet 3 Focus = 15 % Focus = 30 % Focus = 15 % Taille équipe : 3 développeurs Focus équipe : 60% Taille Sprint : 2 semaines Capacité Sprint = 30jh * 60% = 18 jours, soit : 9 + 4,5 + 4,5 SI 1 sp = 3h, la capacité est donc de 22 + 11 + 11, soit 44 SP par sprint CAPACITÉ : Planning :
  • 86. Et les contrats ? Est-ce que les méthodes agiles sont adaptées aux prestataires de services ?
  • 87. Les 2 types de contrats : Au forfait Le forfait est par nature antinomique avec les méthodes agiles … mais rien n’empêche de décomposer un forfait en lots, équivalent à vos incréments. Attention à bien définir le périmètre fonctionnel en amont pour garantir au fournisseur (le développeur) qu’il ne rognera pas sa marge. A la régie C’est la méthode la plus naturelle, mais qui nécessite une relation de confiance forte. Définir le périmètre peut également être une bonne idée pour garantir au client qu’il ne dépensera pas plus que nécessaire.
  • 88. Paradoxes des contrats En régie : plus le projet avance, moins la valeur perçue par le client est forte. Le développement devrait donc prendre fin lorsque le coût dépasse la valeur marginale acquise. Avec le mode forfait, le coût est négocié d’avance. Ainsi, plus le développeur travaille (pour une valeur moindre), plus il rogne sa marge. source : http://blog.xebia.fr/
  • 89. Découpage par lots C’est une alternative ... En définissant des budgets par lots on peut lier anticipation et engagement avec la flexibilité des méthodes agiles
  • 91. Des concepts pour aller plus loin Le Story Mapping : Il s’agit d’une représentation à 2 dimensions et plus riche de celle offerte par le Backlog de produit. En horizontal : les usages, en vertical : les priorités. Kanban : Un outil plus souple que SCRUM … et pourquoi ne pas le mélanger avec SCRUM ? Behaviour Driven Development : Compléter les stories en expliquant les comportements : Given When Then Les Personas : Rédaction de fiches utilisateurs précises et détaillées. Les personas évitent de parler en terme de “panel” et permettent une approche plus personnifier des fonctions. Definition of Done : Définition du “fini”, pour les stories, les sprint et les releases afin de s’assurer que toute l’équipe suive un même niveau de qualité.
  • 92. RESSOURCES Les méthodes Agiles expliquées www.qualitystreet.fr/ www.agiliste.fr/ henrik-kniberg.developpez.com/livre/scrum-xp henrik-kniberg.developpez.com/mattias-skarin/livre/scrum-kanban La culture Agile http://blog.xebia.fr/category/agilite www.areyouagile.com/ Contrat Agile http://www.contrat-agile.org/ www.scrum.org