Transcript Initiation aux méthodes Agiles

Découvrir l’Agilité
© 2011 Chris Ozanne et Arnaud Pasquiers
Arnaud Pasquiers
– Consultant indépendant
– Twigly Technologies : logiciel de gestion des temps
– Pratique l’Agilité depuis deux ans
Chris Ozanne
– Consultant indépendant
– Spécialisé en architecture et développement JEE et
méthodes Agiles
– Certifié Scrum Master depuis quatre ans
© 2011 Chris Ozanne et Arnaud Pasquiers
QU'EST-CE QUE L'AGILITÉ ?
© 2011 Chris Ozanne et Arnaud Pasquiers
Agile
• Approche réactive et itérative d’organisation
de travail
• Focalisée sur la fonctionnalité et satisfaction
client
• Construit en adéquation avec les capacités
et limites humaines
© 2011 Chris Ozanne et Arnaud Pasquiers
Pourquoi Agile ?
• En réaction des problèmes avec des
approches ‘traditionnelles’ :
Besoins
Spécifications
Conception
Code
Test
© 2011 Chris Ozanne et Arnaud Pasquiers
Les constats
• Les meilleures idées ne viennent pas
forcément au début du projet
– Il est plus facile de construire par étape que tout
imaginer dès le début
• Les besoins peuvent évoluer pendent le
projet
• Le formalisme n’est pas naturel
• Chiffrages et Reste à Faire sont difficiles à
évaluer
© 2011 Chris Ozanne et Arnaud Pasquiers
Un projet informatique… la réalité
• On ne sait pas estimer la charge restante
100%
% Complété
T
© 2011 Chris Ozanne et Arnaud Pasquiers
Problèmes avec cascade
• Les méthodes prédictives fonctionnent bien,
à condition d’avoir:
– Stabilité et prévisibilité
– Communication et compréhension parfaite
– Choix parfaits dès le départ
 Aucun humain!
© 2011 Chris Ozanne et Arnaud Pasquiers
Agile : Un juste milieu
Très réactive
Peu focalisé,
aucune maitrise
Absence de
méthode
Réactivité
Peu réactive
Focalisation
Objectifs clairs
Méthodes
prédictives
© 2011 Chris Ozanne et Arnaud Pasquiers
Agile : Une catégorie de méthodes
• ‘Agile’ regroupe plusieurs méthodologies :
– Scrum
– Extreme Programming (XP)
– DSDM
– Crystal
–…
• Notion officialisée en 2001 avec le Manifeste
Agile
© 2011 Chris Ozanne et Arnaud Pasquiers
Le manifeste Agile
Personnes et
interactions
Plutôt que
Processus et outils
Un produit opérationnel
Plutôt que
Documentation
exhaustive
Collaboration
avec le client
Plutôt que
Négociation d'un contrat
Adaptation au
changement
Plutôt que
Suivi d'un plan
© 2011 Chris Ozanne et Arnaud Pasquiers
Le manifeste Agile
• Libérer le génie humain
Personnes et interactions
Plutôt que
Processus et outils
pour l’auto-organisation dans un contexte qu’il
peut maîtriser :
Documentation
• La taille
de l’équipe
est
Un produit
opérationnel
Plutôt
que limitée
exhaustive
• le domaine du problème est limité
Collaboration
Plutôt que
Négociation d'un contrat
avec
le
client
Petites équipes autogérées
Portée fonctionnelle restreinte à un moment donné
Adaptation au
Garder un rythme de
travail
soutenable
Suivi d'un plan
Plutôt
que
changement
Avancement par itération
© 2011 Chris Ozanne et Arnaud Pasquiers
Le manifeste Agile
Personnes et interactions
Expression des besoins
Plutôt que
Processus et outils
Conception
Un produit opérationnel
Collaboration
avec le client
Adaptation au
changement
Documentation
exhaustive
Plutôt Développement
que
Tests, recette & debugage
Plutôt que
Négociation d'un contrat
Plutôt que
Suivi d'un plan
© 2011 Chris Ozanne et Arnaud Pasquiers
Les
solutions Agiles
Le manifeste
Agile
Personnes et interactions
Plutôt que
Processus et outils
Expression
de besoins
Conception
Un produit opérationnel
Collaboration
avec le client
i
Adaptation au
1
changement
Documentation
Plutôt que
Développement exhaustive
Plutôt que
Tests,
recette Négociation
& debuggage d'un contrat
i
2
i
3
i
n
Plutôt que
Suivi d'un plan
© 2011 Chris Ozanne et Arnaud Pasquiers
Les
solutions Agiles
Le manifeste
Agile
• Toujours focalisées sur le produit final
Une
vision commune
l’équipe
Plutôtpour
que
Personnes
et interactions
Processus et outils
 la satisfaction du client
Découper le projet autrement
Documentation
Un produitopérationnel
par fonctionnalité
Plutôt que
exhaustive
Organiser en cycles de développement réduits
 itérations
Collaboration
avec le client
Plutôt que
Négociation d'un contrat
Adaptation au
changement
Plutôt que
Suivi d'un plan
© 2011 Chris Ozanne et Arnaud Pasquiers
Les
solutions Agiles
Le manifeste
Agile
• Collaboration avec le client
que
Personnes
et interactions
Processus
et outils
Pourquoi
on veut desPlutôtcontrats
?
- Instaurer la confiance autrementDocumentation
Un produit- opérationnel
Plutôt que
Eviter les effets pervers
d’un contrat
exhaustive
Collaboration
avec le client
Plutôt que
Négociation d'un contrat
Adaptation au
changement
Plutôt que
Suivi d'un plan
© 2011 Chris Ozanne et Arnaud Pasquiers
Les
solutions
Agiles
Le manifeste Agile
• Adaptables
Plutôt que besoins
Personnes
et interactions
Processus et outils
Réactives
aux nouveaux
Réceptives aux nouvelles solutions
Documentation
Un produit opérationnel Plutôt que
exhaustive
- Prendre les décisions définitives le plus
tard possible
- De courtes itérations permettent de changer de
direction sans laisser des éléments à moitié fait
Collaboration
avec le client
Adaptation au
changement
Plutôt que
Négociation d'un contrat
Plutôt que
Suivi d'un plan
© 2011 Chris Ozanne et Arnaud Pasquiers
Agile : Planification
• L’estimation de charge est difficile, mais les
courtes itérations nous aident
– On est plus précis sur les petites tâches
– Feedback très rapide
– Plus facile à s’adapter face aux dérives, surprises
© 2011 Chris Ozanne et Arnaud Pasquiers
Exemple de méthode Agile
SCRUM
© 2011 Chris Ozanne et Arnaud Pasquiers
Scrum : Caractéristiques
• Produire le maximum de valeur pour le
minimum de coût
• Besoins capturés dans un backlog de produit
priorisé par une personne
• Cycles de développement de 2 à 4 semaines
(Sprints) ; équipes autogérées
• Mêlée quotidienne
© 2011 Chris Ozanne et Arnaud Pasquiers
Scrum : Les Acteurs
• Product Owner
– Porteur de la vision globale du produit
– Gère le Backlog du Produit
– Défini des priorités
– Accepte ou Rejette les livrables
© 2011 Chris Ozanne et Arnaud Pasquiers
Scrum : Les Acteurs
• Scrum Master
– Veille au bon fonctionnement de l’équipe
• Enlève les obstacles
– Gardien des pratiques de Scrum
– Serviteur de l’équipe - Facilitateur
– N’est pas un chef de projet !
© 2011 Chris Ozanne et Arnaud Pasquiers
Scrum : Les Acteurs
• L’équipe
– 5 à 9 personnes
– Autogérée ; les décisions sont prises
collectivement
– Contient toutes les compétences nécessaires
pour terminer le sprint
– Ne change pas pendant un Sprint
© 2011 Chris Ozanne et Arnaud Pasquiers
Le processus Scrum
Mêlée
Mêlée quotidienne
Estimation
quotidienne
Sprint
Burndown
Chart
Créer
unminutes,
Backlog
du
produit
•15
tous
les
jours
Visualisation
de l'état
du
projet
sous la forme
Planification
du
Sprint
Backlog
du produit
•Trois questions
pour chacun
d'un
tableau
•ParRevue
analogie
de
préférence
du
sprint
24 heures
•Les tâches
à faire
•Qu’avez-vous
fait
hier
•L'intuition
est
acceptable
!
Rétrospective
du
sprint
•Géré
par
le
Product
Owner
•Réunion
•Les
tâchesde
enl’équipe
cours : décisions collectives
•Qu’allez-vous
faire
aujourd’hui
•Planning
Poker
•Liste
de
tout
cepour
qui va
entrainer
du
•les tâches
•Définir
unterminées
objectif
le sprint
•Présentation
desleaders
nouveautés
•Quels
sont
vos
problèmes
•Eviter
l'influence
des
d'opinion
•Choisir
des
éléments
du
Backlog
de produit pour
travail
pour
l’équipe
•Uniquement
l’équipe
•Tout
le
monde
est
invité
•Collégialité
mettre
dans ledebacklog
sprint
•Constat
ce qui
adu
bien
oupas
moins
bien
•Appréciation
de
la
valeur
apportée
•Toute
l’équipe
participe
–de
juste
le Scrum
2
–
4
semaines
•Recherche
du
consensus,
et
la
propriété
•Chaque
élément
est
découpé
en
taches
•Mettre
à !jour
Backlog du Sprintqui sont
marché
dans le
l’organisation
Master
par
l’élément
collective
desheures
estimations
estimées
en
(max 2pour
jours)le Sprint ->
•Le •Informel
reste
à
faire
total
•Chiffré de
imprécise
•La conception
defaçon
haut niveau
est abordée
burndown
chart
•Les•User
tâches Stories
ne sont pas nominatives
Backlog
du sprint
Produit
© 2011 Chris Ozanne et Arnaud Pasquiers
Exemple de méthode Agile
EXTREME PROGRAMMING
© 2011 Chris Ozanne et Arnaud Pasquiers
Extreme Programming :
Caractéristiques
• Méthodologie de développement basée sur
des valeurs, principes et pratiques
• Propose des pratiques d’ingénierie comme
le binomage et TDD.
© 2011 Chris Ozanne et Arnaud Pasquiers
Extreme Programming :
Valeurs
• Communication
– Entre les membres de l’équipe
– Verbale
– Facilité par colocalisation de l’équipe
• Simplicité
– Cherche la solution la plus simple qui convient
au problème du jour.
• Le refactoring n’est pas un échec, mais une étape
normale !
© 2011 Chris Ozanne et Arnaud Pasquiers
Extreme Programming :
Valeurs
• Feedback
– Des tests unitaires, fonctionnels
– Du client
• Revue avec le client toutes les deux à trois semaines
– De l’équipe
• Grace à la communication continuelle
© 2011 Chris Ozanne et Arnaud Pasquiers
Extreme Programming :
Valeurs
• Courage
– De s’attaquer aux problèmes tout de suite
– D’appliquer les valeurs XP
– De jeter du code lorsque nécessaire
• Respect
– Tous les membres de l’équipe apportent
quelque chose, peu importe leurs années
d’expérience
© 2011 Chris Ozanne et Arnaud Pasquiers
Extreme Programming :
Pratiques
• Pair programming
– Partage des idées, bonnes pratiques
– Partage des expériences
– Partage des compétences
• Le code appartient à tout le monde
– Règles de codage
– Utilisation de patterns, métaphores
© 2011 Chris Ozanne et Arnaud Pasquiers
Extreme Programming :
Pratiques
• Tests
– Unitaires
– Intégration continue
– Test-driven development
• Conception incrémentale
© 2011 Chris Ozanne et Arnaud Pasquiers
QUESTIONS
© 2011 Chris Ozanne et Arnaud Pasquiers
Chris Ozanne
[email protected]
http://www.ozanneconsulting.com
Arnaud Pasquiers
[email protected]
http://www.twigly.com
© 2011 Chris Ozanne et Arnaud Pasquiers