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