Vous êtes sur la page 1sur 159

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

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

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 ?

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

L'AGILIT AUJOURD'HUI

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

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

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

LE CYCLE EN V, TRADITIONNEL, ET WATERFALL


Mais qu'est ce qui ne fonctionne
pas avec ce modle ?

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

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

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

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 9

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.

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

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.
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 11

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 12

BNFICES PROPOSS PAR L'AGILIT

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

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

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

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 !

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

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

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

Source : http://www.leanprimer.com/downloads/lean_primer.pdf
http://www.fabrice
aimetti.fr/dotclear/index.php?post/2011/08/24/LeanPrimer

LES PILIERS DU LEAN : RESPECT DES PERSONNES

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

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
Source : http://www.leanprimer.com/downloads/lean_primer.pdf
http://www.fabriceaimetti.fr/dotclear/index.php?post/2011/08/24/LeanPrimer

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

ELIMINER LES SOURCES DE GASPILLAGE

Source : Mary Poppendieck, Lean Software Development

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

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

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

LEAN, XP, SCRUM, KANBAN

LEAN

Extreme
Programming
Pratiques d'ingnierie
logicielles

SCRUM
Framework de
dveloppement logiciel

KANBAN
Systme de gestion
de flux de production

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

DES FAONS DE FAIRE PLUS OU MOINS NORMATIVES

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

LES VALEURS DE XP

Communication
Simplicit
Feedback
Courage
Respect
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 23

LES VALEURS DE SCRUM

Transparence
Inspection
Adaptation

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

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)

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

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

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

DU DVELOPPEMENT ITRATIF : ATELIER "COIN TOSS"

atelier
"
"COIN TOSS

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

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.
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 28

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

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

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

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

WORKSHOP

: "OFFING THE OFFSITE CUSTOMER"

atelier
ffsite"
"Offing the o

Source : James Shore


http://jamesshore.com/Presentations/OffingTheOffsiteCustomer.html
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 31

MODES DE COMMUNICATION

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

MISE EN PLACE D'UN PROJET SCRUM

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

LES ACTEURS SCRUM


Pig & Chicken

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


fondamental diffrent.

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

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)

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

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 36

L'QUIPE

inspir de
http://www.leanessays.com/2011/02/beforetherewasmanagement.html
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 37

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/

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

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/

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

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

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

ATELIER : "PRUNE THE TREE"

atelier
ee"
" P r u n e th e tr

Source : http://innovationgames.com/prunetheproducttree/
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 41

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

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

DFINITION DU BESOIN

Source : Mountain Goat Software


http://www.mountaingoatsoftware.com/system/presentation/file/119/CohnADP09IntroductiontoUserStories.pdf

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

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

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

ITERATING VERSUS INCREMENTING

Source : Jeff Patton


http://www.agileproductdesign.com/blog/dont_know_what_i_want.html
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 45

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.

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

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/
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 47

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

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

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 49

USER STORIES

Source : Mountain Goat Software


http://www.mountaingoatsoftware.com/system/presentation/file/119/CohnADP09IntroductiontoUserStories.pdf
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 50

USER STORIES

Lors des conversations autour des


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

Source : Mountain Goat Software


http://www.mountaingoatsoftware.com/system/presentation/file/119/CohnADP09IntroductiontoUserStories.pdf
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 51

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/
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 52

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

Source : Mountain Goat Software


http://www.mountaingoatsoftware.com/system/presentation/file/119/CohnADP09IntroductiontoUserStories.pdf

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

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 54

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.

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

USER STORIES & PERSONAS

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

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)

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

PRODUCT BACKLOG ICEBERG

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

PRODUCT BACKLOG

Prioris par le Product Owner, reprioris en dbut de


chaque sprint, ou tout moment

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

ATELIER : DFINIR UN BACKLOG

atelier
Backlog

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

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

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

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 ?

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

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

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

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 ?)

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

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

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

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.

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

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)

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

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

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

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 ?

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

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.

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

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

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

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.

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

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

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

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.

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

ATELIER : PLANNING POKER ET WALL PLANNING POKER

ateliers
ker
Planning Po
g P o ker
Wall Plannin

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

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.

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

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

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

PLANIFICATION DE RELEASES

Source : Mountain Goat Software


http://www.mountaingoatsoftware.com/system/presentation/file/51/bayXP_070320_PlanningAgileProjects.pdf

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

PLANIFICATION DE RELEASES
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.

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

PLANIFICATION DE RELEASES

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

PLANIFICATION DE RELEASES

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

RELEASE PLANIFICATION

Source :
http://blog.crisp.se/mattiasskarin/tags/teams/
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 82

ATELIER : "MARSHMALLOW CHALLENGE"

atelier
allenge"
h
c
w
o
ll
a
m
h
" Ma r s

http://marshmallowchallenge.com/Welcome.html

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

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

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

RADIATEURS D'INFORMATION

Source : SCRUM & XP FROM THE TRENCHES


http://www.crisp.se/henrik.../ScrumAndXpFromTheTrenches.pdf
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 85

RADIATEURS D'INFORMATION

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

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).

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

BURNDOWN CHARTS

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

BURNDOWN & BURNUP CHARTS

Un burndown de points tches et un burnup de points


"story" qui se croisent.
Une bonne pratique.
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 89

BURNDOWN CHARTS

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

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 ?

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

PRATIQUE QUOTIDIENNE : LE "DAILY SCRUM"

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.

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

PRATIQUE QUOTIDIENNE : LE "DAILY SCRUM"


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.
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 93

ATELIER : "SCRUM FROM HELL"

atelier
Hell"
" S c r u m fr o m

Source : http://xp123.com/g4p/0410b/index.htm
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 94

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

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

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 96

ATELIER : "RETROSPECTIVE : SPEED BOAT"


atelier
b o at
d
e
e
p
s
&
e
iv
R tr o s p e c t

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

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...
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 98

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 !

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

PRATIQUES D'INGENIERIE : EXTREME PROGRAMMING


Scrum et XP devraient dans
la pluspart des projets
informatiques tre
indissociables

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

DETTE TECHNIQUE
Astrix chez les
hlvtes, Uderzo &
Goscinny

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

DETTE TECHNIQUE

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

FEEDBACK : COT DU CHANGEMENT

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

FEEDBACK, FEEDBACK

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

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

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

SIMPLICIT
YAGNI

You ain't gonna need it


KISS
Keep it simple stupid
DRY
Dont repeat yourself
Fail Fast

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

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 ?

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

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 108

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

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

FOCUS SUR DES PRATIQUES : REFACTORING

Extreme Programming Explained, embrace change, Kent Beck

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

FOCUS SUR DES PRATIQUES : REFACTORING

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

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

FOCUS SUR DES PRATIQUES : REFACTORING

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 112

FOCUS SUR DES PRATIQUES : REFACTORING

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 113

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

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

FOCUS SUR DES PRATIQUES : INTGRATION CONTINUE

Il est ncessaire de dployer


une plateforme d'intgration
continue de type
Jenkins/Hudson, Sonar, TFS,
etc.
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 115

FOCUS SUR DES PRATIQUES : INTGRATION CONTINUE

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

ATELIER "XP GAME"

atelier
"X P G am e"

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

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 ?

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

KANBAN
Visualiser le flux
Limiter le travail en cours (Work in Progress)
Grer le flux
Focus sur la qualit

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

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 120

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 121

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 122

VISUALISER LE FLUX

http://www.slideshare.net/yyeret/explainingcumulativeflowdiagramscfd

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

VISUALISER LE FLUX

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

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

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

http://blog.akshaydhavle.com/2008/12/cumulativeflowdiagrams/

VISUALISER LE FLUX

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

VISUALISER LE FLUX
Mieux !

http://www.slideshare.net/yyeret/explainingcumulativeflowdiagramscfd

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

VISUALISER LE FLUX : DFINITION DE CLASSE DE SERVICE

http://www.slideshare.net/deimos/davidandersonkanbanatqcon
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 128

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 129

ATELIER : KANBAN GAME

atelier
me"
"K an b an G a

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

TRANSITION AGILE EN ENTREPRISE : ADAPT

Awareness
Desir
Ability
Promotion
Transfer

L'agile est avant tout un


processus de conduite du
changement

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

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

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

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 133

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

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

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

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

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 ).

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

GRER LE CHANGEMENT

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

GRER LE CHANGEMENT

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

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 139

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)
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 140

MONEY FOR NOTHING

Source : http://agile2008toronto.pbworks.com/MoneyForNothingAndYourChangesForFree(JeffSutherland)
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 141

LE PROJET PILOTE ?

Source : Mountain Goat Software


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.

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

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 143

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 144

ATELIER "LEADERSHIP"

atelier
"
"Leadership

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

RESPONSABILIT

Christopher Avery Responsability Process

http://www.christopheravery.com/responsibilityprocess
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 146

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/

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

SCALABILIT : SCRUM DE SCRUM

Source : Mountain Goat Software


http://www.mountaingoatsoftware.com/system/presentation/file/30/RedistributableIntroToScrum.ppt

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

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/
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 149

PRODUCT OWNER DANS L'ENTREPRISE

Source :http://www.romanpichler.com/blog/roles/scalingtheproductowner/
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 150

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

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

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

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

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

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

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)

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

RESSOURCES : LIVRES

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

RESSOURCES : LIVRES

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

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
Creative Commons AttributionShareAlike 3.0 Unported License Pablo Pernot pablo@smartview.fr @pablopernot 158

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