Pratiques de Lagilite 2 1 15

PRATIQUES DE L'AGILIT
PABLO PERNOT SMARTVIEW

http://www.areyouagile.com
https://speakerdeck.com/u/pablopernot
http://www.smartview.fr
http://convergenc.es
Ce travail est sous licence :

Creative Commons AttributionShareAlike 3.0 Unported License
@pablo
p e rn o t
version 2.1.15 dcembre 2012
PROGRAMME
JOUR 1
Les raisons et origines de l'agilit, valeurs & principes

Filiation et comparaison des principales mthodes
agiles : Lean, XP, Scrum, KanBan
La pense LEAN
Respect des personnes
Amlioration continue
Pratiques d'estimation et de planification

Estimation, Planification
Cycle de vie / Itrations
Conception mergente
Ateliers : Planning poker, Wall planning poker,

Marshmallow challenge
Pratiques quotidiennes et Pilotage

Visualisation et "radiateurs" d'information
Les burndown/up charts
Les standups
SCRUM
Aperu de Scrum,
Les acteurs de Scrum
Dveloppement itratif
Timebox
Communication, interaction
Atelier : Scrum from hell
Pratiques de fin d'itration et de cycle

Les revues
Les rtrospectives
Atelier : Coin Toss, Offing the offsite

Pratiques d'expression du besoin
Dlivrer de la valeur
Les User Stories
Personas
Backlog
Notion de "fini"
JOUR 2
Atelier : Speedboat
EXTREME PROGRAMMING
Ateliers : Prune the tree, Openended specifications,

Backlog
Les pratiques d'ingnierie

Dette technique
Feeback
Tests automatiss
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 2
PROGRAMME
JOUR 3
EXTREME PROGRAMMING
Pratiques d'ingnierie (suite)
Refactoring
Pair programming
Intgration continue
Atelier : XP Game
KANBAN
Une marque de maturit ?
Evolution de certaines pratiques

Mise en oeuvre de Kanban
Visualiser le flux
Classes de service
Dbats autour de Kanban
Atelier : KanBan Game
Pratiques de l'entreprise agile

Passage l'agilit, Conduite du changement
Scalabilit, Management, Contractualisation
Atelier : leadership
Conclusion
PRSENTATIONS
Connaissez vous les mthodes agiles ? Avezvous lu des livres sur les mthodes
agiles ?
Votre organisation implmentetelle dj une mthode agile ? Comment travaillez vous
actuellement sur vos projets ? Pourquoi marchentils ? Pourquoi chouentils ?
Quels sont les problmes auxquels vous tes rgulirement confronts ? Avez vous
cherch des pistes d'amliorations ?
Pourquoi souhaitezvous implmenter l'agilit au sein de votre organisation ?
L'AGILIT AUJOURD'HUI
LES RAISONS DE L'AGILIT

Le fameux rapport Chaos du Standish Group...
Principales causes des checs

Mauvaise comprhension du besoin : 51%
Estimation et planification dficiente : 48%
Technologies mal matrises : 45%
Facteurs clefs du succs
Implication des utilisateurs
Soutien par le management
Objectifs business clair
Primtre optimis
Un constat svre
64% des fonctionnalits dveloppes
sont peu ou pas utilises...
Source : http://www.cs.nmt.edu/~cs328/reading/Standish.pdf
LE CYCLE EN V, TRADITIONNEL, ET WATERFALL

Mais qu'est ce qui ne fonctionne
pas avec ce modle ?
LA FIN DU CYCLE EN V CLASSIQUE

L'immuabilit des spcifications et des besoins fonctionnels
Ce qui sera dlivr sera en partie obsolte,
pensez aux marines ! **
L'effet tunnel !
Feedback trop tardif : toute modification
va coter trs cher
La sectorisation des intervenants
Les quipes s'incriminent entre elles
Insatisfaction des quipes
On oublie o se trouve la valeur du projet et on se concentre sur le respect

la lettre des spcifications (or elles sont souvent mal comprises, et surtout
elles changent !) et de la documentation
On ne dlivre pas assez de valeur au client
Ncessit de documenter de faon dtaille tous les lments du projet
** Source : Mary Poppendieck, Lean Software Development, an agile toolkit
4 VALEURS AGILES
Pour rpondre ce problme est cr en 2001 le manifeste Agile. Rdige par 17
experts qui se dressent contre l'chec des cycles en cascade, Il propose 4 valeurs
fondamentales, et 12 principes
La ractivit face au changement plutt que le

suivi d'un plan
linteraction avec les personnes plutt que les
processus et les outils
un
produit
oprationnel
documentation plthorique
plutt
quune
La collaboration avec le client plutt que la

ngociation de contrat
On parle de rituels, la photo du manifeste parait mystique, mais ce n'est pas une secte ! )
http://fr.wikipedia.org/wiki/Manifeste_agile
LES 12 PRINCIPES DE L'AGILIT

Notre premire priorit est de satisfaire le client en livrant tt et rgulirement des
logiciels utiles.
Le changement est accept, mme tardivement dans le dveloppement. Les processus
agiles exploitent le changement comme avantage comptitif pour le client.
Livrer frquemment une application fonctionnelle, toutes les deux semaines deux mois,
avec une tendance pour la priode la plus courte.
Les experts mtier et les dveloppeurs doivent collaborer quotidiennement au projet.
Btissez le projet autour de personnes motives. Donnez leur l'environnement et le
soutien dont elles ont besoin, et croyez en leur capacit faire le travail.
La mthode la plus efficace pour transmettre l'information est une conversation en face
face.
LES 12 PRINCIPES DE L'AGILIT

Un logiciel fonctionnel est la meilleure unit de mesure de la progression du projet.
Les processus agiles promeuvent un rythme de dveloppement soutenable.
Commanditaires, dveloppeurs et utilisateurs devraient pouvoir maintenir le rythme
indfiniment.
Une attention continue l'excellence technique et la qualit de la conception amliore
l'agilit.
La simplicit l'art de maximiser la quantit de travail ne pas faire est essentielle.
Les meilleures architectures, spcifications et conceptions sont issues d'quipes qui
s'autoorganisent.
intervalle rgulier, l'quipe rflchit aux moyens de devenir plus efficace, puis accorde
et ajuste son comportement dans ce sens.
LES MTHODES AGILES SONT MATURES

Plusieurs mthodes : XP, SCRUM, LEAN, etc.
Plus de 10 ans d'exprience
Une mthodologie reconnue :
par Google, Yahoo, Nokia, Microsoft, IBM, Oracle, MySpace, Adobe...
En 2008, l'tude du drdobbs.com indique que 69% des entreprises font de l'agile, et
parmi celles qui ne font pas d'agile, 15% d'entre elles estiment dmarrer l'anne suivante
* Etude Agile Adoption Rate Survey Results: February 2008 http://www.ambysoft.com/surveys/agileFebruary2008.html

** 3rd Annual Survey 2008 "The state of Agile development http://pm.versionone.com/whitepaper_AgileSurvey2008.html
BNFICES PROPOSS PAR L'AGILIT
POURQUOI CELA MARCHE ?

Priorit ce qui a le plus de valeur, ce qui est le plus important
Dmarche itrative, incrmentale et adaptative
Des interactions et de la communication
Un outillage compact et rapidement assimilable
De la visibilit
De la motivation et de la satisfaction dans les quipes
Un produit oprationnel trs tt
Une ractivit face au changement
MAIS CE N'EST PAS
L'absence de rgle :
La discipline est indispensable
Les processus sont indispensables
L'absence de documentation
Il faut des spcifications si elles ont de la valeur
Magique
Cela ne fonctionne pas dans tous les contextes
Il n'y a pas de checklist Scrum !
LA PENSE
LEAN
Le modle de production Toyota

Amlioration continue
Respect des personnes
Remettre tout en cause
Embrasser le changement
Source : http://www.leanprimer.com/downloads/lean_primer.pdf
La base de la mthode Toyota est de ne

pas se satisfaire du statu quo, vous devez
constamment vous poser la question :
Pourquoi faisonsnous a ? .
Source : http://www.fabrice
aimetti.fr/dotclear/index.php?post/2011/08/24/LeanPrimer
Taiichi Ohno
19121990
Une philosophie
Respect des employs
Une utilisation de toutes
les comptences des employs
Donner des responsabilits et avoir
confiance dans les employs
Source : Mary Poppendieck, Lean Software Development
http://www.fabrice
aimetti.fr/dotclear/index.php?post/2011/08/24/LeanPrimer
LES PILIERS DU LEAN : RESPECT DES PERSONNES
LES PILIERS DU LEAN : AMLIORATION CONTINUE

Allez & Observez
Plein de mots japonais pour briller en socit (ou faire

consultant)
Kaizen
ShuHaRi
Valeur
Gaspillage
Petits ajustements incessants
Kaizen : amlioration continue

Gemba : L o se trouve la ralit
Muda : forme de gaspillage
Kanban : fiche, tiquette
Yokoten : Diffusion horizontale des connaissances
Jidoka : automatisation avec une touche humaine
Obeya : grande salle (war room des projets agiles...)
http://fr.wikipedia.or
g/wiki/Roue_de_De
ming
http://www.fabriceaimetti.fr/dotclear/index.php?post/2011/08/24/LeanPrimer
ELIMINER LES SOURCES DE GASPILLAGE
Source : Mary Poppendieck, Lean Software Development
PRINCIPES LEAN
Optimiser le systme dans son

ensemble
Approche long terme.
Management visuel simple
Travailler en mode flux

Cycle court
Livrer rapidement
Visibilit rgulire
Responsabiliser l'quipe
Technologie prouve
Construire de la qualit intrinsque

Rsoudre les problmes
Dcider le plus tard possible

Reporter la dcision
"Last Responsible Moment"
Eliminer les gaspillages
Montrer le plus tt possible
Lisser le travail
Matriser les standards
LEAN, XP, SCRUM, KANBAN
LEAN
Extreme
Programming
Pratiques d'ingnierie
logicielles
SCRUM
Framework de
dveloppement logiciel
KANBAN
Systme de gestion
de flux de production
DES FAONS DE FAIRE PLUS OU MOINS NORMATIVES
LES VALEURS DE XP
Communication
Simplicit
Feedback
Courage
Respect
LES VALEURS DE SCRUM
Transparence
Inspection
Adaptation
ABORDER L'AGILIT ET SA MISE EN OEUVRE
SHU : Apprendre les fondamentaux

HA : Trouver les exceptions, trouver de nouvelles approches
RI : Tout redevient permis (on oublie la rgle initiale, qui est digre)
HUM HUM
Habituellement
A ce moment dans la formation
on m'indique que c'est un peu
le monde des bisounours
l'agile...
passons la pratique
a des choses plus concrtes
DU DVELOPPEMENT ITRATIF : ATELIER "COIN TOSS"
atelier
"
"COIN TOSS
DU DVELOPPEMENT ITRATIF
http://www.sao.corvallis.or.us/drupal/files/The%20New%20New%20Product%20Development%20Game.pdf
Source: The New New Product Development Game, Hirotaka Takeuchi and Ikujiro Nonaka,
Harvard Business Review, January 1986.
QU'EST CE QU'UNE "BOITE DE TEMPS" ? (TIMEBOX)

La rptition
d'une cadence bien matrise
Yesterday weather ?
http://martinfowler.com/bliki/Yester
daysWeather.html
LES TIMEBOXES DANS SCRUM
Sprint
Habituellement entre 2 et 4 semaines.
Sprint Planning Meeting
Pour 2 3 semaines de sprint : gnralement 1 journe,
dont la moiti pour dfinir le contenu du sprint,
et l'autre moiti pour dfinir comment les fonctionnalits
slectionnes vont tre dveloppes.
Sprint review
Gnralement 4h< (la moiti de la dure du Sprint Planning Meeting). Plutt 1 2h.
Sprint retrospective
Gnralement 4h< (la moiti de la dure du Sprint Planning Meeting). Plutt 1 2h.
Daily Scrum
15Mn
WORKSHOP
: "OFFING THE OFFSITE CUSTOMER"
atelier
ffsite"
"Offing the o
Source : James Shore

http://jamesshore.com/Presentations/OffingTheOffsiteCustomer.html
MODES DE COMMUNICATION
MISE EN PLACE D'UN PROJET SCRUM
LES ACTEURS SCRUM

Pig & Chicken
Entre les parties prenantes (stakeholders) et l'quipe Scrum, l'engagement est

fondamental diffrent.
LE "PRODUCT OWNER"
Dcide des fonctionnalits du produit

Dcide des dates de disponibilit des versions et de leurs contenus
Responsable de la valeur du produit
Priorise les fonctionnalits du produit en fonction de leurs valeurs ajoutes,
du retour sur investissement, de leurs valeurs
Accepte ou rejette les rsultats produits par l'quipe
Il doit tre lgitime et avoir assez de pouvoir pour pouvoir trancher quand
cela est ncessaire (ce n'est pas un comit, c'est une seule personne)
Il doit tre disponible et impliqu sur le projet (prsence lors du sprint
planning meeting, de la dmo, de la rtrospective, des daily scrum)
L'QUIPE
Gnralement entre 5 et 9 membres (3 et 4 c'est bien, mais l'quipe doit

tre assez autonome (crossfunctionnality)
Htrogne (elle mle architecte, dveloppeur, testeur, analystes,
graphistes, etc.)
Donne son accord aux objectifs de chaque itration
Spcifie les rsultats raliser, elle s'engage et est responsable
Fonctionne de manire empirique et a le droit de faire tout ce qu'elle
souhaite pour atteindre l'objectif de l'itration
Autonome, elle fonctionne en autogestion
L'agile pense que nous sommes intelligents
Stable
Prsente les rsultats du travail de chaque itration au Product Owner
Il s'agit de rsultats d'quipe
L'QUIPE
inspir de
http://www.leanessays.com/2011/02/beforetherewasmanagement.html
L'QUIPE : MODLE DE TUCKMAN

Forming (formation de l'quipe)
Dcouverte et formation de l'quipe, dfinition des objectifs,
Storming
Confrontation et affrontement
Norming
L'quipe apprend travailler ensemble
Performing
L'quipe fonctionne comme une unit trs performante
http://en.wikipedia.org/wiki/Tuckman's_stages_of_group_development
http://www.areyouagile.com/2010/12/managementagilelemodeletannenbaumschmidt/
L'QUIPE : MODLE DE TANNENBAUM & SCHMIDT

1. Le manager dcide et annonce la dcision
2. Le manager dcide et vend la dcision au groupe
3. Le manager prsente la dcision avec des ides gnrales et invite la rflexion
4. Le manager suggre une dcision et invite la rflexion
5. Le manager prsente la situation, coute les suggestions et dcide
6. Le manager prsente la situation, dfini les contraintes et demande lquipe de
dcider
7. Le manager permet lquipe didentifier le problme, dvelopper les options, dcider
de la solution. Le manager est inform des contraintes par lquipe.
http://www.businessballs.com/tannenbaum.htm
http://www.areyouagile.com/2010/12/managementagilelemodeletannenbaumschmidt/
LE "SCRUMMASTER"
S'assure que Scrum est bien appliqu

S'assure que l'quipe est oprationnelle et productive (et en bonne sant)
Facilite la coopration entre les diffrents acteurs (de l'quipe scrum ou
des parties prenantes)
S'assure que rien ne gne l'avance du travail, le cas chant essaye de
trouver la solution pour lever les blocages, obstacles visibles ou invisibles.
Rduit au maximum les perturbations extrieures avec l'quipe Scrum
Communique avec le management
S'assure que la qualit du produit n'est jamais remise en cause
ATELIER : "PRUNE THE TREE"
atelier
ee"
" P r u n e th e tr
Source : http://innovationgames.com/prunetheproducttree/
DLIVRER DE LA VALEUR
La force de Scrum et de l'agile est de dlivrer d'abord et avant toute chose ce qui a le
plus de valeur (retour sur investissement). Cette valeur peuttre dans certains cas
estime (en monnaie).
Le Product Owner dfinit dans un premier temps une vision, une pope concernant le
produit. Puis il dcline features/thmes, cas d'utilisation ou histoires d'utilisateurs (User
Story).
r
Brainsto
ming s
uvelle
o
n
e
n
u
ur
version
DFINITION DU BESOIN
Source : Mountain Goat Software

http://www.mountaingoatsoftware.com/system/presentation/file/119/CohnADP09IntroductiontoUserStories.pdf
ATELIER : "OPEN ENDED SPECIFICATIONS"
atelier
ations"
ic
if
c
e
p
s
d
e
d
"O p en en
Source :
The power of openended requirements
http://blog.crisp.se/davidbarnholdt/2009/02/18/1234986060000.html
ITERATING VERSUS INCREMENTING
Source : Jeff Patton

http://www.agileproductdesign.com/blog/dont_know_what_i_want.html
USER STORIES
Les histoires utilisateurs (user story) ne sont pas des cas d'utilisations (use case)
Une user story (histoire utilisateur) est une exigence logicielle formule en une ou
plusieurs phrases dans le langage de tous les jours ou celui li au mtier de lutilisateur.
Les user stories sont utilises dans le dveloppement logiciel dit Agile comme
spcifications (en mme temps que les tests dacceptance). Le formalisme est limit un
carte de type postit. (wikipedia)
Les User Story encouragent ne pas entrer dans le dtail tant que cela n'est pas
ncessaire.
USER STORIES
Ron Jeffries propose une rgle des 3C pour grer les User Story
Card
L'histoire est crite sur une carte de taille assez rduite.
Ces fiches peuvent tre annotes (estimation, etc.)
Conversation
Les dtails de l'histoire seront exprims lors de conversation avec le
Product Owner
Confirmation
Des tests d'acceptation sont consigns avec l'histoire pour valider
qu'elle a t ralise correctement.
Source : Ron Jeffries
http://xprogramming.com/articles/expcardconversationconfirmation/
USER STORIES
Une User Story se base sur la syntaxe suivante :
En tant que <rle>,
je peux <besoin>
de faon <bnfice>
Une bonne user story sera : compacte, testable, estimable, portera de la valeur,
ngociable, indpendante.
Elle sera comprise par toute la population qui gravite autour et dans le projet
USER STORIES : L'ACRONYME "INVEST"

I
N
V
E
S
T
Independant (indpendante)
Negotiable(ngotiable)
Valuable (avec de la valeur)
Estimable
Sized to fit (assez petite)
Testable
USER STORIES

USER STORIES
Lors des conversations autour des

User Story , cellesci pourront tre
redfinies en Story plus fines.

USER STORIES
Dcouper les user stories :

Workflow steps (par tape)
Business rule variations (par rgle mtiers)
Major effort (par taille d'effort)
Simple / Complex (approche du simple au complexe)
Variations in data (variations dans les donnes)
Data entry methods (faon d'intgrer les donnes)
Defer performance (retarde la question des performances)
Operations (CRUD) (par oprations)
Break out a spike (analyser une piste)
Source :
http://www.richardlawrence.info/2009/10/28/patternsforsplittinguserstories/
USER STORIES & TESTS D'ACCEPTATION

Lors des conversations autour des User Story il faudra prciser les tests
d'acceptation qui permettront de valider en partie que la Story a bien t ralise

ECRIRE LES ATDD AVEC DU GHERKIN

Le Gherkin est un langage trs simple pour formaliser et unifier l'criture de vos tests d'acceptation.
D'autant qu'il pourra terme tre utilis par des outils qui vont permettre d'automatiser ces tests, ou du
moins fournir facilement une enveloppe de tests (specflow, cucumber, jbehave, etc.)
Etant donn la page d

'accueil du site avec u
n bouton enregistrez
Quand je clique sur le
vous
bouton enregistrez vo
u
s
Alors j'arrive sur le form

ulaire d'enregistremen
t
Etant donn le formula
ire d'enregistrement
Quand je m'enregistre
Alors je reois un ema
il de demande de con
firmation
Et cet email contient u
n lien de confirmation
Etant donn un lie
n dynamique sur
une page de con
d'enregistrement
firmation
Quand j'accde la p
age mon enregistreme
nt est confirm
Alors je reois un ema
il de confirmation d'en
registrement
Et je peux dsormais
me connecter au site
USER STORIES & PERSONAS

Il est souvent bienvenu de dfinir et de discuter des rles (on dit des "personas" /
personnages) du projet.
Certains poussent le vice les nommer, fabriquer des photos, dcrire leur caractre.
L'utilisateur devient rel : on commence concevoir le produit comme une rponse un
vrai besoin, une vraie ncessit.
Pour cela ne dites donc plus systmatiquement l'utilisateur mais le responsable
des ventes , la personne qui voyage beaucoup , etc.
USER STORIES & PERSONAS
DFINITION DU BESOIN : LE PRODUCT BACKLOG

La liste de tous les besoins exprims
que le Projet a pour cible
Une rencontre entre les besoins mtiers et
le point de vue technique
Exprim de faon mettre en vidence la
valeur apporte par chaque composant
(User Story)
PRODUCT BACKLOG ICEBERG
PRODUCT BACKLOG
Prioris par le Product Owner, reprioris en dbut de

chaque sprint, ou tout moment
ATELIER : DFINIR UN BACKLOG
atelier
Backlog
NOTION DE "FINI" / DONE

Cette notion a pour objectif de fixer le niveau de qualit attendu, et ce dans tous les cas
de figure. C'est une condition pour dire qu'une user story est finie.
Cette notion doit tre partage et connue de tous (au mieux on l'affiche sur les radiateurs
d'informations !)
Gnralement elle est partage (au moins un tronc commun) entre les diffrents projets,
au niveau de l'entreprise
Cette notion est trs lie la notion de test (unitaire et d'acceptation) mais il faut la traiter
de faon verticale : pas uniquement le ct code, ou architecture, ou ergonomique, etc.
La notion de done implique plusieurs couches : technique, mtiers, IHM,
documentation, etc
NOTION DE "FINI" / DONE

Dfinissez les rles d'un projet
Quelle serait la notion de fini pour chacun de ces rles ?
Quelle serait la notion de fini sur le projet Scrum de cette quipe ?
PRATIQUES DU DEV. ITRATIF : LES ITRATIONS OU SPRINTS

On parlera de Sprint ou d'itration
Il dure entre 2 semaines ou 1 mois selon les quipes, mais sa dure ne varie plus dans
un mme projet.
Une dure de 2 semaines facilite la prise en main de Scrum car elle donne de la visibilit
intervalle resserr.
Il faut dcomposer les tches de faon ce qu'elles durent un jour maximum pour
assurer de la visibilit sur l'avancement
Si en cours de Sprint l'quipe souhaite changer la priorit (sortir une story, en intgrer
une nouvelle en provenance du Product Backlog) c'est toujours le Product Owner qui
aura le dernier mot
Concernant le Sprint Backlog c'est l'quipe qui s'autoorganise
LE SPRINT PLANNING
Le Sprint Planning permet de dfinir le Sprint Backlog
Le Sprint Backlog est un sous ensemble du Product Backlog
Le Sprint Backlog correspond un accord mutuel entre le Product Owner et l'quipe
mais c'est le Product Owner qui a le dernier mot.
Le Sprint Planning se dcoupe en deux tapes
Dfinition du contenu du Sprint
(quoi ?)
Estimation et dcoupage en tches du contenu du Sprint
(comment ?)
LE SPRINT PLANNING : QUOI ?
En fonction de la dernire revue de sprint, de la dernire rtrospective, d'autres

informations, le ScrumMaster aura pris soin de sensibiliser le Product Owner valider
ou reprioriser le Product Backlog avant cette runion
Le Product Owner prsente le Product Backlog l'quipe
L'quipe estime quelles user story (dans l'ordre des priorits) elle est susceptible
d'intgrer (la vlocit est une indication forte). Elle s'engagera l dessus
L'quipe peut proposer et justifier un ordonnancement du
Product Backlog diffrent mais c'est le Product Owner qui
aura le dernier mot.
On peut dans cette phase estimer les User Story qui ne le
sont pas encore (on va travailler gnralement sur 60/70%
du Product Backlog)
On n'assigne jamais une User Story l'quipe, c'est l'quipe
qui dfinit son propre potentiel et qui s'autoorganisera
quand l'affectation des tches
LE SPRINT PLANNING : QUOI ?

Objectif
Cette premire partie de Sprint Planning est aussi le moment o l'on dfini le but du
Sprint, son Leitmotiv, son objectif, sa cible. Par exemple : Mise en uvre du systme
de rservation en ligne des croisires ou Ralisation des changes entre le site web
et l'ERP concernant les rservations en lignes
Cet objectif doit tre l'lment indispensable atteindre pour que l'on puisse considrer
que le sprint est une russite.
Si des arbitrages doivent avoir lieu durant le Sprint, c'est souvent l'objectif du print qui
permettra de faire pencher la balance.
Engagement
La fin de cette premire partie de Sprint Planning se conclue avec l'engagement de
l'quipe sur un primtre.
LE SPRINT PLANNING : COMMENT ?
La seconde partie du Sprint Planning consiste dcouper les User Story en tches.
Il est ncessaire de discuter du contenu de chaque Story et de l'intrt de chaque
tche
Il ne faut pas oublier les tches de spcifications, de documentation, de test, etc. Tout
ce qui est ncessaire pour la Story soit acheve
convenablement (voir la notion de done (fini)).
On peut ajouter des tches sans Story (bugs, etc.) mais
essayez plutt d'ajouter des Story de type process ou
system (afin que la vlocit reste au plus juste)
LE SPRINT PLANNING : COMMENT ?
Les tches sont estimes (ou pas) en heures selon la maturit de l'quipe (on peut se
passer de l'estimation).
On peut aussi estimer les tches en point (avec un nouveau planning poker, mais c'est
relativement rare et trs chronophage)
L'estimation d'une tche en heure ne devrait pas dpasser 1 jour de faon pouvoir
rapidement dtecter les drives le cas chant
ITRATION : FIN EXCEPTIONNELLE ? DE STABILISATION ? SPRINT 0 ?

Le Sprint peuttre annul
Il n'a plus de valeur !
Il est impossible de le russir
Seul le Product Owner peut annoncer l'annulation et la fin du Sprint (mais l'quipe ou le
management peuvent essayer de le convaincre)
Les user stories estimes finies sont audites
Tous les user stories non acheves sont replaces dans le Product Backlog
Existe des sprint de stabilisation ?
Qu'est ce qu'un Sprint 0 ?
PRATIQUES D'ESTIMATION
L'estimation est collective, c'est l'quipe qui la ralise mais en conversant avec le
Product Owner et le Scrummaster
L'estimation est exprime en story point partir d'un planning poker, soit exprims
en jour idaux . Je prconise le planning poker car toute notion de dure (jour) vient
troubler la rflexion. Des fois on utilise mme des points animaux ou des tailles de
teeshirt...
L'estimation est relative : une story par rapport aux autres (triangulation)
Attention de bien prendre en compte tout ce qui a t prvu par done
En fonction de l'estimation ralise sur des story il se peut que le Product Owner re
priorise son Product Backlog
Estimation de la complexit, de la dure des tches accomplir, de la prise de risque,
etc.
PRATIQUES D'ESTIMATION
Point de Story
Mesure un effort
Relatifs jamais absolus
Difficile faire comprendre au management
Jours idaux
Mesure une dure
Devraient tre relatifs
les jours ideaux : ne pas

utiliser ! juste un rappel
historique.
Plus aiss expliquer aux personnes externes

On les raccroche trop une notion de calendrier
LE "PLANNING POKER"
Chaque personne possde un jeu de planning poker

Le Product Owner dcrit la Story devant tre estime
On discute de la story
Tout le monde propose sa mise simultanment
Si toutes les estimations convergent, c'est ok
Si les estimations ne convergent pas, les discussions
reprennent, notamment entre les deux personnes
ayant les plus grands carts de point.
LE "PLANNING POKER"
Ca marche
Car ceux sont les gens qui raliseront la tche

qui l'estiment !
Le planning poker ncessite que l'on justifie
les points que l'on attribue
Propose un talonnage assez rduit qui limite
les erreurs (si une Story est trop grosse, on la
dcoupe en plusieurs Story)
Les valeurs sont relatives
Les valeurs sont prdfinies (on ne chipote
pas...)
Tout le monde a son mot dire (parmi l'quipe)
C'est rigolo
UNE ALTERNATIVE LE "WALL PLANNING POKER"
On positionne les stories par comparaison en colonne sur un mur

On affecte les points ensuite
C'est trs rapide et on oubli toute
valeur numrique !
Mais l'investissement n'est pas
forcment gal entre tous les
participants
Ma recommandation : faire des wall
planning poker hors des sprints
planning pour faire des estimations
assez loin dans le temps ou initier
un projet, utiliser le planning poker
lors des sprint planning.
ATELIER : PLANNING POKER ET WALL PLANNING POKER
ateliers
ker
Planning Po
g P o ker
Wall Plannin
PRATIQUE DE PLANIFICATION : LA "VLOCIT"

Est calcule la fin du sprint (itration)
C'est la somme des points des Story qui ont t acceptes pour la dmo
La rgularit de la courbe de la vlocity est signe du respect de la qualit, ou de la
stabilit de l'environnement (et la stabilit de l'environnement mne au respect de la
qualit)
Si on dcide de rompre
avec la qualit pour
amliorer la vlocit (fin
des tests, etc.) on va
amliorer
celleci
temporairement
puis
dcliner vers un noyau
foutu . C'est la notion de
dette technique.
PLANIFICATION DE RELEASES
Une version de produit une release et un product backlog

Une release contient plusieurs sprints (itrations)
Chaque sprint possde une vlocit
La vlocit est une valeur (non relative une dure comme jour ou heure) que l'on
dduit en additionnant la vlocit de chaque story (nous verrons comment nous
calculons la vlocit plus loin)
Chaque sprint est timebox (disons 3 semaines)
L'quipe est sense tre prenne et donc la vlocit devrait donc peu ou proue rester
la mme par sprint

http://www.mountaingoatsoftware.com/system/presentation/file/51/bayXP_070320_PlanningAgileProjects.pdf
On sait donc calculer le nombre de sprints ncessaires pour atteindre la fin de la release.
La fin de la release cela peut tre
Le Product Backlog est vide (rarement le cas...)
Une date prdfinie
La fin du budget
Assez de valeur produite
Etc.
RELEASE PLANIFICATION
Source :
http://blog.crisp.se/mattiasskarin/tags/teams/
ATELIER : "MARSHMALLOW CHALLENGE"
atelier
allenge"
h
c
w
o
ll
a
m
h
" Ma r s
http://marshmallowchallenge.com/Welcome.html
RADIATEURS D'INFORMATION
Ils permettent de suivre de faon collective, interactive, et simple l'avance du sprint, et

du projet
Ils engagent et motivent l'quipe
La mise jour est quasi en temps rel
Ils doivent tre visibles par tous (autant par l'quipe que par les parties prenantes).
Toutes les informations clefs sont rassembles en un seul lieu
Ps : attention aux coups de vent, aux mnages le soir, aux postit dfectueux que l'on
retrouve au sol...
Astuce : prendre en photo le radiateur au jour le jour
Source : SCRUM & XP FROM THE TRENCHES

http://www.crisp.se/henrik.../ScrumAndXpFromTheTrenches.pdf
BURNDOWN CHARTS
Les burndown charts montrent l'avancement du projet
Il existe 2 types de burndown chart : celui de la release, celui du sprint
Celui de la release se base sur les points de story
Celui du sprint peut se baser :
Sur les heures
Sur les points affects aux tches
Sur le nb de tches restantes
L'avance du projet est collective
Les burndown charts doivent tre visibles par tous (autant par l'quipe que par les parties
prenantes).
BURNDOWN CHARTS
BURNDOWN & BURNUP CHARTS
Un burndown de points tches et un burnup de points

"story" qui se croisent.
Une bonne pratique.
BURNDOWN CHARTS
PRATIQUE QUOTIDIENNE : LE "DAILY SCRUM"
Il dure ~ 15 mn, il a lieu tous les jours, tout le monde est dbout (standup meeting),
chacun y rpond 3 questions
Qu'est ce que
tu as ralis hier ?
Quelles sont tes
tches aujourd'hui ?
Estce que
quelque chose te gne
dans la ralisation
de tes tches ?
Ou "Daily Standup"
Il donne de la visibilit toute l'quipe sur l'ensemble des travaux intervalles rguliers
Il devrait se drouler systmatiquement la mme heure et dans le mme lieu
C'est l'outil de l'quipe, le ScrumMaster, le Product Owner sont optionnels. Le
ScrumMaster doit cependant s'assurer que le Daily Scrum se droule comme convenu
mais il doit se faire discret lors du StandUp. Le Product Owner peut profiter de ce moment
pour suivre l'avancement du projet. Les parties prenantes peuvent assister mais ne
doivent pas intervenir. Seuls les membres de l'quipe peuvent parler.
Il faut trouver un lieu tranquille mais proche des radiateurs d'informations
Le Daily Scrum se droule imprativement debout.

Il amliore la communication et permet d'viter d'autres runions (mais son sujet ne doit
pas dvier).
Chacun doit s'exprimer brivement car le Daily Scrum est Timebox 15mn.
Attention de ne pas dvier sur des conversations annexes (rglement d'un point
technique complexe, modification des priorits, etc.), ni de rgler lors du point les
problmes, il s'agit de les reprer pour les rgler ultrieurement.
Chacun s'engage, car l'quipe est responsable. On ne fait pas de compte rendu au
Product Owner ou au ScrumMaster (d'ailleurs ces deux rles ne sont peuttre pas
prsents)
Ce n'est pas non plus le lieu des rglements de compte (l'quipe doit comprendre qu'elle
doit s'unir pour russir)
Par moment quand un Daily Scrum drape le ScrumMaster peut se tourner face au mur
et appuyant ses mains contre celuici ( spread eagle ) pour indiquer que ce qui se
droule est inutile et n'est pas le but du Daily Scrum.
ATELIER : "SCRUM FROM HELL"
atelier
Hell"
" S c r u m fr o m
Source : http://xp123.com/g4p/0410b/index.htm
REVUE DE SPRINT
On prsente le rsultat du Sprint (toutes les User Story acheves)

C'est le moment durant lequel le Product Owner et les parties prenantes (stakeholders)
inspectent le produit en dtails en fonction de l'objectif du Sprint et la vision du produit et
prennent les dcisions d'adaptation ncessaires la russite de l'objectif du projet.
Il peut y avoir de nombreux invits cette occasion
Il faut prparer la runion (scnariser) et rappeler les objectifs du Sprint en premier lieu
A la fin de la dmo on peut calculer la vlocit effective du Sprint et donc rajuster le plan
de release
A la fin de la dmo le Product Backlog est actualis (User Story acheves, nouvelles User
Story mergentes, anomalies, etc.)
Les BurndownChart sont rinitialiss ou remis jour
RTROSPECTIVE
Elle est l pour amliorer les processus

(identifier les axes d'amlioration, capitaliser sur les bonnes pratiques), faire un tat des
lieux du sprint qui vient de s'achever
Comment amliorer les choses ?
Qu'est ce qui a bien fonctionn ?
Qu'est ce qui a mal fonctionn ?
Comment rsoudre les problmes que nous voyons apparatre ?
Il faut prparer une rtrospective (la prparation peut durer aussi
longtemps que la rtrospective ellemme)
C'est le ScrumMaster qui va faciliter et organiser cette runion
C'est le ScrumMaster qui devrait savoir si une amlioration est rellement ncessaire ou
pas, il ne va pas choisir mais il sera un arbitre dterminant.
A la fin de la rtrospective on a un plan d'action
ATELIER : "RETROSPECTIVE : SPEED BOAT"

atelier
b o at
d
e
e
p
s
&
e
iv
R tr o s p e c t
LES 5 POURQUOI
L'obstacle n'est pas toujours celui que l'on croit : Concept des 5 pourquoi
Le Washington Monument s'rode et la firme responsable du ciment ne russit pas
en trouver la cause ( root cause analysis ).
Pourquoi le btiment se dsagrgetil ?
Parce que l'on y applique trop de produits chimiques
Pourquoi appliqueton trop de produits chimiques ?
Pour nettoyer les crottes de pigeons !
Pourquoi y atil autant de pigeons ?
Car ils mangent les insectes sur le btiment !
Pourquoi yatil autant d'insectes ?
A cause de la lumire !
Solution : Rduire les horaires d'clairages du
Monument...
QUELQUES QUESTIONS
Faites 2 groupes et travaillez chacun sur ces deux sujets avec l'aide des "5
pourquoi", observons les rsultats
Il y a souvent trop de recettes raliser la fin de chaque sprint !
Le product owner n'est pas assez prsent avec l'quipe !
Le dailystand up n'est jamais achev !
Il n'y a pas assez de dveloppeurs/testeurs dans l'quipe !
On dpend trop de dveloppeurs externes l'quipe !
On travaille sur trop de projets !
PRATIQUES D'INGENIERIE : EXTREME PROGRAMMING

Scrum et XP devraient dans
la pluspart des projets
informatiques tre
indissociables
DETTE TECHNIQUE
Astrix chez les
hlvtes, Uderzo &
Goscinny
DETTE TECHNIQUE
FEEDBACK : COT DU CHANGEMENT
FEEDBACK, FEEDBACK
SIMPLICIT
La complexit ne doit pas simposer

Le Mythe de lultragnrique
Optimisations de performance inutiles
Etc.
Cest la simplicit qui doit simposer
pas la facilit !
Diffrence : la qualit nest pas ngociable !
Mais
On favorise lmergence
SIMPLICIT
YAGNI
You ain't gonna need it

KISS
Keep it simple stupid
DRY
Dont repeat yourself
Fail Fast
COURAGE & RESPECT
Quel niveau de confiance jaccorde mes partenaires ?

De 1 5
1 : je nai aucune confiance
5 : jai une confiance aveugle
Comment je juge le niveau de confiance que maccordent mes partenaires ?
A quel point suisje laise pour parler mes partenaires des problmes et points de
blocage que je rencontre ?
Vous tes Scrummaster l'un des membres de l'quipe vient voir pour expliquer qu'il ne
supporte plus une personne de l'quipe pour telle ou telle raison, quel serait votre
positionnement ?
FOCUS SUR DES PRATIQUES : PAIR PROGRAMMING

Ides reues
Les managers voient cela comme une perte de temps
Les dveloppeurs ont t duqus pour travailler de faon isole

Certains Senior pensent que travailler ainsi va les ralentir, ou que cela va compliquer
les choses
Mais il apparat que :
Cela facilite le transfert de connaissance (sans que chacun perde sa spcialit)
La qualit du code est drastiquement amliore (c'est la meilleure revue possible) :
beaucoup d'anomalies pernicieuses chronophages dtectes ensuite
les dbutants sont incorpors sans problme
La productivit est a minimum gale, souvent meilleure
Les gens ont plaisir faire du pair programming
FOCUS SUR DES PRATIQUES : TESTS AUTOMATISS
Un dveloppement est moderne et mature si il automatise ses tests

Permet d'avoir des garanties sur la qualit du code
Permet aux dveloppeurs de se partager le code sans risque, sans crainte
Les tests peuvent servir de documentation
Erirra ne recnava
Test Driven Development
Dfinir l'object
Ecrire le test et le faire chouer
Ecrire le code
Le test fonctionne
Le TDD propose une alliance

entre
les deux lments pour lesquels
on observe le plus de rticence
sur le terrain de la part des
dveloppeurs
conceptualiser et dcouper son
dveloppement
faire des tests
Un exemple de Test Driven Development propos par pytddmon

http://www.youtube.com/watch?v=sD6qzJNQEpE
FOCUS SUR DES PRATIQUES : REFACTORING
Extreme Programming Explained, embrace change, Kent Beck
Refactoriser c'est changer un logiciel de faon ce que comportement ne varie pas mais
que sa structure interne soit meilleure
On ne dcide pas de refactoriser, c'est un travail sousjacent, constant.
Penser le code comme devant/pouvant tre revis
Ne pas dvelopper des choses inutiles
Ne pas dvelopper des choses trop complexes
L'un des objectifs du refactoring est de rendre le code plus lisible, plus comprhensible,
plus abordable pour le dveloppeur suivant
Modularisez !
void printOwing(double amount)

{
printBanner()
//print details
WriteLine("name:" + _name)
WriteLine("amount" + amount)
http://www.refactoring.com/catalog/index.html
Inline Method,
Replace method with method object
Hide delegate
etc..
void printOwing(double amount)

{
printBanner()
printDetails(amount)
}
void printDetails(double amount)
{
WriteLine("name:" + _name)
WriteLine("amount" + amount)
}
"Refactoring Tips by Martin Fowlers", Igor Crvenov
Quand refactoriser ?
Quand vous ajoutez une fonction

Quand vous corrigez une anomalie
Quand vous fates une revue de code
... Et avant de refactoriser il faut une solide suite de tests pour ne pas introduire
d'anomalies
Quand ne pas refactoriser ?
Quand le code est dans un trop mauvais tat et qu'il faut tout reprendre
Quand une deadline approche et que l'effort de refactorisation n'a plus assez de
valeur
"Refactoring Tips by Martin Fowlers", Igor Crvenov
FOCUS SUR DES PRATIQUES : INTGRATION CONTINUE

Quelques rgles :
n1 : la premire des priorits est de rparer le build cass

Pas de fatalit ! Rigueur !
Excution toutes les nuits !
A chaque commit de code !!
Attention la lenteur du build !!!
Gestion des versions avec des quipes multiples
http://www.infoq.com/articles/agileversioncontrol
Il est ncessaire de dployer

une plateforme d'intgration
continue de type
Jenkins/Hudson, Sonar, TFS,
etc.
ATELIER "XP GAME"
atelier
"X P G am e"
UNE MARQUE DE MATURIT ? KANBAN

David Anderson : "Scrum ne rgle pas tous les problmes, ni ne s'applique dans toutes
les situations" (estce vrai ?)
Peuton faire du scrum avec la "Care & Maintenance" ? Le support ? Le HelpDesk ?
Gestion des services IT ? Li "DevOps" ?
Pour embrasser l'intgralit de ce qui est ralis ?
KANBAN
Visualiser le flux
Limiter le travail en cours (Work in Progress)
Grer le flux
Focus sur la qualit
ht t p: /
MISE EN OEUVRE DE KANBAN
/ blog.
e/ hen
s
crisp.
r i kkn i
b e rg /
2009
/ 04/ 0
3/ 123
8795
5200
00. ht
ml
MISE EN OEUVRE DE KANBAN

Apprenez connaitre votre systme
Identifiez et priorisez vos sources
Dfinissez votre processus
Concevez votre tableau de flux
Dfinissez les limites
Dcidez des rles
Dcidez des runions
http://www.fabriceaimetti.fr/dotclear/public/traductions/demarrerenkanban.pdf
RUNIONS POUR KANBAN

Runion de dfinition, d'expression du besoin
Runion quotidienne
Runion d'apprentissage, d'amlioration continue et d'analyse du feedback
http://www.fabriceaimetti.fr/dotclear/public/traductions/demarrerenkanban.pdf
VISUALISER LE FLUX
http://www.slideshare.net/yyeret/explainingcumulativeflowdiagramscfd
VISUALISER LE FLUX
VISUALISER LE FLUX
Trop de travail faire signifie
probablement :
vous ne finissez pas ce qui
est engag
une tape ultrieure ne peut
pas intgrer votre travail
http://blog.akshaydhavle.com/2008/12/cumulativeflowdiagrams/
VISUALISER LE FLUX
VISUALISER LE FLUX
Mieux !
http://www.slideshare.net/yyeret/explainingcumulativeflowdiagramscfd
VISUALISER LE FLUX : DFINITION DE CLASSE DE SERVICE
http://www.slideshare.net/deimos/davidandersonkanbanatqcon
QUELQUES DBATS SUR KANBAN
Points de vigilance
Kanban estil "people friendly" ?

Kanban permetil un vritable changement ? N'estil pas trop statique, trop conforme ?
Kanban estil Scrum sans itration ?
Fautil avoir fait du scrum avant de passer Kanban ?

Estce que les estimations sont une perte de temps ?
David Anderson dcrit Kanban

comme "proposant un
changement volutif plutt qu'une
rvolution (comme agile)"
SoftwareEnginering Radio,
Podcast, Francfort, Germany
http://www.slideshare.net/deimos/davidandersonkanbanatqcon
ATELIER : KANBAN GAME
atelier
me"
"K an b an G a
TRANSITION AGILE EN ENTREPRISE : ADAPT
Awareness
Desir
Ability
Promotion
Transfer
L'agile est avant tout un

processus de conduite du
changement
MANAGEMENT & CONDUITE DU CHANGEMENT
En introduisant Scrum dans votre socit vous allez bousculer les habitudes, provoquer
le changement, attention d'tre attentif aux facteurs bloquants
GRER LE CHANGEMENT
L'agile, surtout Scrum, va mettre en vidence les problmes et les dysfonctionnement.

Il joue le rle d'un rvlateur. Il devient donc aussi une cible idale.
A chaque fois que vous abandonnez ou dtournez une pratique Scrum pour vous
conformer l'entreprise (ou pour faciliter son adoption) vous perdez de la valeur (vous
devenez des ScrumBut )
Il faut donc l'viter autant que possible
C'est toujours le signe d'une dfaillance de fonctionnement de
l'entreprise et autant s'attaquer la source
Ken Schwaber estime que seulement 35% des entreprises qui essayent
Scrum
russissent. Pourquoi les autres chouent ? Car elles refusent de rgler les problmes
que Scrum rend visibles.
Cependant
Un bon ScrumMaster est un ScrumMaster vivant, un ScrumMaster mort
GRER LE CHANGEMENT : MOTIVATION
C'est toujours plus simple de dmarrer avec un nouveau projet (que de reprendre un
projet avec des millions de lignes de code et une base clients norme)
Scrum apporte motivation et implication l'quipe (si ce n'est pas le cas cela le
ScrumMaster devrait s'alerter)
Se rferer l'tude : Enqute Nationale Mthodes Agiles Juin 2009

http://www.frenchsug.org/download/attachments/591296/Enqute_mthodes_agiles_2009_FrenchSUG.pdf?version=1
GRER LE CHANGEMENT : DIFFICULT
Se rferer l'tude : Enqute Nationale Mthodes Agiles Juin 2009

http://www.frenchsug.org/download/attachments/591296/Enqute_mthodes_agiles_2009_FrenchSUG.pdf?version=1
FACE AU STRESS
Ds que le stress va monter les bonnes pratiques et les bonnes volonts vont disparatre
et les mauvaises habitudes revenir au galop
Dans des phases de stress vous devez tre attentif ne pas :
Retomber dans un schma de type Waterfall
Retomber dans un schma de type commande et contrle (rappelez
vous l'quipe est autonome et autogre).
Se voiler la face et dire oui ce qui est impossible raliser dans les
conditions proposes (dure, quipe, etc.)
Cacher la ralit en se disant que cela va se rsoudre
La qualit ne doit jamais tre remise en cause ( j'arrte la documentation , j'arrte les
tests pour gagner du temps ).
GRER LE CHANGEMENT
GRER LE CHANGEMENT
CONTRACTUALISATION
Scrum fonctionne gnralement avec des contrats de type rgie (time & material)
La difficult est d'adapter les habitudes franaises du mode de contractualisation au
forfait (fixed price) la souplesse propose par Scrum.
C'est encore plus dur avec les appels d'offres publics
C'est souvent un risque que l'organisation dcide de prendre (de grer le forfait avec
SCRUM)
Mode dgrad : sans pouvoir se permettre de modifier le primtre mais
en exploitant la priorisation, les rtrospectives frquentent auprs du client
Mode trs dgrad : uniquement la partie ralisation sans ncessairement
que le client soit au courant (mais ce n'est plus vraiment du Scrum)
Le point de vue du juriste
http://www.staubassocies.com/fr/page5286methodesagiles.html
CONTRACTUALISATION : CONTRAT AVEC CHANGEMENT GRATUIT

Jeff Sutherland, l'un des pres de Scrum, propose le concept de changement gratuit
On dfinit un contrat avec un primtre et un prix fixe (forfait / fixed price).
On propose une enveloppe supplmentaire en mode rgie (time & material) qui sera
dclenche si la clause de changement gratuit choue.
On introduit une clause de changement gratuit
Pour que cette clause soit valide le client doit s'engager travailler avec l'quipe Scrum
(Product Owner ou autres). Si il ne respecte pas cette clause l'enveloppe
supplmentaire sera utilise en cas de variation.
Si il respecte cette rgle le client peut effectuer des changements dans le primtre :
Le changement des priorits est possible
Il peut enlever des features et en ajouter de nouvelles (estimation gale) la fin de
chaque sprint.
Source : http://agile2008toronto.pbworks.com/MoneyForNothingAndYourChangesForFree(JeffSutherland)
MONEY FOR NOTHING
Source : http://agile2008toronto.pbworks.com/MoneyForNothingAndYourChangesForFree(JeffSutherland)
LE PROJET PILOTE ?

http://blog.mountaingoatsoftware.com/fourattributesoftheidealpilotproject
Dont start with an initial learning

project that is of marginal
importance. Start on a project that is
absolutely critical to your company
otherwise it will be too difficult to
implement all the hard things Scrum
will ask of you .
Jim Highsmith, Agile Software
Development Ecosystems.
MANAGEMENT AGILE
Acteur du changement, initiateur, constructeur de l'organisation
Mne les questions de recrutement et de rtribution. Fournit les ressources.
Responsable des Product Owner (Donne son avis au Product Owner concernant la
stratgie et la vision du produit, et donne son avis au Product Owner sur l'organisation et
l'orientation du Product Backlog)
Vient aider les quipes pour supprimer les obstacles qui pourraient les gner.
Aide les ScrumMasters protger les quipes des perturbations extrieures
Il aide l'quipe si elle a un besoin ponctuel (support technique)
Coordinateur (entre diffrentes strates de la socit)
Source : Le rle du manager dans Scrum, Agile Gathering 2007
Traduit par Fabrice Aimetti
http://www.fabriceaimetti.fr/dotclear/public/mesdocuments/RoledesManagersEnScrum.pdf
MANAGEMENT AGILE
the Team will not begin to selforganize until everyone outside the Team stops
micromanaging them."
Pete Deemer, Manager 2.0: The Role of the Manager in Scrum
http://www.scrumalliance.org/articles/148managertheroleofthemanagerinscrum
Il ne doit plus y avoir de vision top / down . Le manager doit constamment rappeler
l'quipe qu'elle est le responsable (chassez la naturel il revient au galop ! Le muscle
memory de Ken Schwaber)
Le manager est plus un mentor qu'une nounou .
La gestion des individualits a disparu. Il faut revoir le plan de commissionnement au
niveau de l'quipe et du projet !
Source : Le rle du manager dans Scrum, Agile Gathering 2007

Traduit par Fabrice Aimetti
http://www.fabriceaimetti.fr/dotclear/public/mesdocuments/RoledesManagersEnScrum.pdf
ATELIER "LEADERSHIP"
atelier
"
"Leadership
RESPONSABILIT
Christopher Avery Responsability Process
http://www.christopheravery.com/responsibilityprocess
SCALABILIT : SCRUM DE SCRUM
Permet de rpondre aux problmatiques des projets avec plusieurs quipes.

Chaque jour aprs le Daily Scrum le reprsentant de chaque quipe s'assemble pour un
scrum de scrum .
Cela fonctionne comme un daily scrum mais avec un niveau d'analyse diffrent : qu'a fait
l'quipe, que faitelle aujourd'hui, quels problmes rencontretelle ? (Mike Cohn suggre
des meetings moins frquents mais plus long)
Le risque est que le reprsentant de chaque quipe ne soit pas en mesure de bien
dcrire l'activit de son quipe (mmoire, prcision, etc.)
Ken Schwaber prconise l'obligation toutes les quipes de fournir un rsultat lors des
revues de sprint et de l'intgrer de faon ce que le Product Owner puisse valider
convenablement le rsultat.
L'ide derrire les scrums de scrum est de dcentraliser chaque unit de productivit de
faon ce qu'elle s'autoorganise. Mais de recomposer une action globale au travers de
la mthode agile : inspection, adaptation, transparence.
Source : ken Schwaber, Mike Cohn
http://kenschwaber.wordpress.com/2010/07/27/theevolutionandimportanceofthescrumofscrums/
SCALABILIT : SCRUM DE SCRUM

http://www.mountaingoatsoftware.com/system/presentation/file/30/RedistributableIntroToScrum.ppt
PRODUCT OWNER DANS L'ENTREPRISE
Comme les "scrum de scrums", les product owners peuvent se synchroniser

rgulirement pour aborder les questions de stratgie plus globale.
Source :http://www.romanpichler.com/blog/roles/scalingtheproductowner/
PRODUCT OWNER DANS L'ENTREPRISE
Source :http://www.romanpichler.com/blog/roles/scalingtheproductowner/
QUELQUES RAPPELS : SCRUM MIND MAP
http://www.fabriceaimetti.fr/dotclear/index.php?post/2009/07/12/SmallandFunnyScrumMindmap
Droits : http://www.flickr.com/photos/agileinaction/
/ CC
BY 2.0
Creative
Commons
AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 151
Source : http://xp123.com/xplor/xp0202/
QUELQUES RAPPELS : XP SUR UNE PAGE
QUELQUES RAPPELS : POINTS DE VIGILANCE

Stabilit de l'quipe
Protection de l'quipe vis vis des parties prenantes (stakeholders)

Contractualisation
Responsabilisation du product owner et de l'quipe de dveloppement
Plus de chef de projet mais un ScrumMaster (facilitateur)
L'agile est simple apprhender mais il n'est pas simple dployer
RESSOURCES : LIENS
http://www.scrum.org/ EN
http://agileanarchy.wordpress.com/ (Tobias Mayer) EN

http://agilmanifesto.org EN
http://www.crisp.se/henrik.kniberg/KanbanvsScrum.pdf EN
http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf EN
http://www.mountaingoatsoftware.com (Mike Cohn) EN
http://leanovation.org/ & http://oanasagile.blogspot.fr/ (Oana Juncu) [Convergences !]

http://www.aubryconseil.com/ (Claude Aubry) FR
http://thierrycros.net/ (Thierry Cros) FR
http://blog.avoustin.com/ (Jrme Avoustin) FR [SmartView !]
http://www.youtube.com/watch?v=IyNPeTn8fpo (Ken Schwaber Scrum Google Talk) EN

http://flowchainsensei.wordpress.com/ (Bob Marshall) EN
http://xp123.com EN
http://xprogramming.com/ EN
RESSOURCES : LIENS
http://blog.crisp.se/henrikkniberg/2011/02/17/1297928460000.html (Lean from the trenches)

http://agilemanagement.net/ (David Anderson)
http://martinfowler.com/ (Martin Fowler)
http://www.exampler.com/ (Brian Marick)
http://www.jimhighsmith.com/ (Jim Highsmith)
RESSOURCES : LIVRES
RESSOURCES : LIVRES
RESSOURCES : OUTILS
Rappelez vous que rien ne vaut l'interaction, la visibilit, etc.

Le mur, les postit, la patafix, les tableaux blancs seront toujours vos meilleurs outils.
Les outils agiles devraient utiliss :
Pour consolider les informations
Pour ventuellement servir au sein d'quipes distribues
Outils
Redmine, Trac
Icescrum, Kunagi
Mingle (Thought works)
Rally software, Version One, Pivotal Tracker
Jira/Greenhopper (Atlassian)
Agile Zen, Kanbanery
QUESTIONS / RPONSES
PABLO PERNOT SMARTVIEW
http://www.areyouagile.com
https://speakerdeck.com/u/pablopernot
http://www.smartview.fr
http://convergenc.es
@pablo
p e rn o t
Ce travail est sous licence :

Creative Commons AttributionShareAlike
3.0 Unported
License 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 159
Creative Commons
AttributionShareAlike

Pratiques de Lagilite 2 1 15

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Pratiques de Lagilite 2 1 15

Hochgeladen von

Copyright:

Verfügbare Formate

PRATIQUES DE L'AGILIT

PABLO PERNOT SMARTVIEW

Ce travail est sous licence :

version 2.1.15 dcembre 2012

Les raisons et origines de l'agilit, valeurs & principes

Pratiques d'estimation et de planification

Ateliers : Planning poker, Wall planning poker,

Pratiques quotidiennes et Pilotage

Atelier : Scrum from hell

Pratiques de fin d'itration et de cycle

Atelier : Coin Toss, Offing the offsite

Ateliers : Prune the tree, Openended specifications,

Les pratiques d'ingnierie

Une marque de maturit ?

Evolution de certaines pratiques

Pratiques de l'entreprise agile

LES RAISONS DE L'AGILIT

Principales causes des checs

LE CYCLE EN V, TRADITIONNEL, ET WATERFALL

LA FIN DU CYCLE EN V CLASSIQUE

On oublie o se trouve la valeur du projet et on se concentre sur le respect

Ncessit de documenter de faon dtaille tous les lments du projet

** Source : Mary Poppendieck, Lean Software Development, an agile toolkit

La ractivit face au changement plutt que le

La collaboration avec le client plutt que la

LES 12 PRINCIPES DE L'AGILIT

LES 12 PRINCIPES DE L'AGILIT

LES MTHODES AGILES SONT MATURES

* Etude Agile Adoption Rate Survey Results: February 2008 http://www.ambysoft.com/surveys/agileFebruary2008.html

BNFICES PROPOSS PAR L'AGILIT

POURQUOI CELA MARCHE ?

MAIS CE N'EST PAS

Le modle de production Toyota

La base de la mthode Toyota est de ne

LES PILIERS DU LEAN : RESPECT DES PERSONNES

LES PILIERS DU LEAN : AMLIORATION CONTINUE

Plein de mots japonais pour briller en socit (ou faire

Kaizen : amlioration continue

ELIMINER LES SOURCES DE GASPILLAGE

Source : Mary Poppendieck, Lean Software Development

Optimiser le systme dans son

Management visuel simple

Travailler en mode flux

Construire de la qualit intrinsque

Dcider le plus tard possible

Eliminer les gaspillages

Montrer le plus tt possible

LEAN, XP, SCRUM, KANBAN

DES FAONS DE FAIRE PLUS OU MOINS NORMATIVES

LES VALEURS DE SCRUM

ABORDER L'AGILIT ET SA MISE EN OEUVRE

SHU : Apprendre les fondamentaux

DU DVELOPPEMENT ITRATIF : ATELIER "COIN TOSS"

QU'EST CE QU'UNE "BOITE DE TEMPS" ? (TIMEBOX)

LES TIMEBOXES DANS SCRUM

: "OFFING THE OFFSITE CUSTOMER"

Source : James Shore

MISE EN PLACE D'UN PROJET SCRUM

LES ACTEURS SCRUM

Entre les parties prenantes (stakeholders) et l'quipe Scrum, l'engagement est

Dcide des fonctionnalits du produit

Gnralement entre 5 et 9 membres (3 et 4 c'est bien, mais l'quipe doit

L'agile pense que nous sommes intelligents