Post on 20-Nov-2014
description
Introduction aux méthodes agiles
Guillaume Collicgcollic@gmail.com
Qui suis-je ?
Acteur de l’agilité
Pro | Asso
2/75
Plan
• Introduction : c’est quoi être agile• Approches déterministes– Les méthodes « classiques »
• Approches empiriques– Les méthodes agiles
• Scrum• eXtreme Programming (XP)• Kanban• Questions
3/75
ÊTRE AGILE ?Préambule
4/75
C’est quoi être Agile ?
• Énormément de réponses possibles, suivant l’angle et le prisme choisi, la plupart complémentaires
5/75
Agilité
Faire les choses efficacement(productivité)
Bien être et valeurs(prévention de risques psycho-sociaux au travail)
Faire les bonnes choses(satisfaction client)
……
……
Pour moi et aujourd’hui,c’est de plus en plus
• Évoluer vers une organisation– plus organique– en petites structures auto-organisées– apprenantes– respectueuses de leur écosystème (gagnant-gagnant)
• Conséquences– De meilleur résultats– Un regain de sens dans le travail
• (Problème générationnel ?)
6/75
Et ça demande…
• Une ouverture d’esprit• Du courage
– Remettre en question nos modes de pensées– Réapprendre l’entreprise
• Dans notre contexte• Au bénéfices de toutes les parties prenantes
• Un lâcher prise– Manager
• mieux atteindre le « quoi » en contrôlant moins le « comment »– Acteur : avoir plus de pouvoir
• mais avec de grands pouvoirs viennent de grandes responsabilités
7/75
Relations
8/75
SimplesChaotiques
Complexes Compliqués
Relations
9/75
SimplesChaotiques
Complexes Compliqués
Classique
Agile
Des équipiers en forme de T
10/75http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf
Mais avant d’en arriver là…
• On commence souvent par mettre un pied dans des choses plus terre-à-terre– Réduire les problèmes techniques• Intégration continue• Tests unitaires, TDD, …
– Améliorer la visibilité et la priorisation (pilotage)• Management visuel• Incréments
– Etc, etc.
11/75
Fin du préambule
Début du tour d’horizondes méthodes agiles
12/75
APPROCHES DÉTERMINISTES
13/75
Modèle en cascade (Waterfall)
http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php314/75
Cycle en V
http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php315/75
Simple à mettre en œuvre
• Contrat simple– Tout est prévu précisément à l’avance• Qui / Quoi / Quand
• Approches connues et enseignées partout
16/75
Effet « Tunnel »
• X mois sans visibilité– « Nuit polaire »
http://www.projectcartoon.com17/75
Importance des documents écrits
• Causes– Délais long entre la création d’une étude et de son
utilisation– Spécialisation des gens = nombreux intermédiaires
• Sert de référence ultime– Du besoin– De la solution– De la validation– …
18/75
Facteurs de succès
• Le client sait exactement ce qu’il veut dès le départ
• Les besoins ne changent pas• L’équipe de réalisation sait parfaitement– Trouver les bonnes solutions techniques du
premier coup– Chiffrer la charge de travail en début de projet
• …
19/75
Marge de manœuvre : 4 axes
• Périmètre– Fixe
• Délai– Fixe
• Coût– Fixe
• Qualité– ?
20/75
Coût des anomalies
http://www.agitar.com/solutions/why_unit_testing.html21/75
L’approche scientifique
pour obtenir ces chiffres
n’est pas garantie
MÉTHODES AGILESApproches empiriques
http://agileconsulting.blogspot.com22/75
Constat
• Les spécifications ne sont pas complètement comprises tant que le projet n’est pas commencé
• Les utilisateurs ne savent ce qu’ils veulent qu’après avoir vu une première version de l’application
23/75
Caractéristiques
• Méthodes réactives et incrémentales d’organisation du travail
• Focalisées sur le produit et la satisfaction client
• Construit en adéquation avec les capacités et limites humaines
24/75
Historique
25/75
Les 4 valeursNous reconnaissons que les éléments à droite ont de la valeur, mais nous privilégions ceux à gauche
Processus et outilsIndividus et interactions
Documentation exhaustiveUn produit opérationnel
Négociation du contratCollaborationavec le client
Suivi d'un planAdaptation au changement
26/75
12 principes1. Satisfaire le client2. Accueillir le changement3. Livrer fréquemment4. Travailler quotidiennement avec les utilisateurs ou leur représentants5. Créer un environnement qui soutienne l’équipe6. Communiquer en face à face7. Mesurer l’avancement sur un logiciel opérationnel8. Avoir un rythme de développement soutenable9. Porter une attention continue à l'excellence technique10. Minimiser la quantité de travail inutile11. Avoir une équipe auto-organisée pour faire émerger les solutions12. Inspecter et s’adapter régulièrement
27/75
Marge de manœuvre : 4 axes
• Qualité– Fixe
• Car la dette technique comporte un fort taux d’intérêt !
• Priorisation suivant les 3 autres axes
Périmètre
CoûtDélai
28/75
L’agilité en 2 slides (1/2)
À 50% du temps total, le client ne voit statistiquement
que 10% de son application. Et il ne sait pas dans quel état elle est.
Expression des besoins
Conception
Développement
Tests, recette & debugage
29/75
L’agilité en 2 slides (2/2)
Expression de besoins
Conception
Développement
Tests, recette & debuggage
À chaque itération, le produit est 100% fonctionnel.
i1 i2 i3 ini5i4
Backlog, user stories
Simplicité, refactoring
TDD, acceptance
Demos, reviews
30/75
Facteurs de succès
• L’utilisateur est impliqué quotidiennement (ou son représentant)
• Le middle management soutient l’équipe auto-organisée
• Les pratiques sont adaptés au mode incrémental– Automatisation des tests car rejoués souvent– Code compréhensible car modifié souvent– …
• …
31/75
Bénéfices de l’adoption (sondage)
http://www.versionone.com/state_of_agile_development_survey32/75
Répartition des méthodes (sondage)
http://www.versionone.com/state_of_agile_development_survey33/75
SCRUM
http://www.edupics.com34/75
Rôle 1/3 : Product Owner
• Porteur de la vision globale du produit• Défini les priorités• Accepte ou rejette les livrables
35/75
Rôle 2/3 : Scrum Master
• Enlève les obstacles pour l’équipe• S’assure du respect de scrum• Serviteur de l’équipe : facilitateur
• Ce n’est pas un chef de projet
36/75
Rôle 3/3 : L’équipe
• Réalise le logiciel• Auto-organisée• Stable durant le sprint• Avec toute les compétences nécessaires pour
le sprint
37/75
Cycle de vie d’un projet Scrum
38/75
Product Backlog
• Liste du travail à effectuer– Chiffré imprécisément– Valeur ajoutée précisée– Sous forme de User Stories
Géré par le product owner
39/75
User Stories (1/2)
• Nom (Valeur métier)
• En tant que <rôle>• Je veux <action>• Afin de <but>
• Critères d'acceptation
40/75
User Stories (2/2)
• Ecrites par le Product Owner• Très simples• Focalisées sur l'utilisateur final– valeur métier apportée
• Critères d'acceptations– testable, définit le « Done »
• Laisse place à la discussion pour les détails– individus et interactions : une user story est une
promesse d’une rencontre future
41/75
Planification de sprint
• Choisir et s’engager, collectivement– L’objectif du sprint– Les user stories du Product Backlog embarquées dans le
Sprint Backlog• Découpées en tâches• Estimées en point, relativement à une user story de référence
42/75
Discussions et décisionsPérimètre : Product Owner
Coût : l’équipePriorité : Product Owner
43/75
Estimation par planning poker
44/75
Sprint
• Réalisation des éléments du Sprint Backlog– Product Owner disponible– Équipe focalisée et non perturbée
• Management visuel– Scrum Board– Burndown
45/75
Scrum Board
http://www.xqa.com.ar/visualmanagement46/75
Définition de « fini »
47/75
Burndown
• Suivi du reste à faire (pas du consommé)
http://www.scrumalliance.org/articles/5548/75
Mêlée quotidienne – Daily Scrum
• Auto-organisée, pas de micro-management• ~ 15 minutes• 3 questions par personnes– Qu’ai-je fais hier ?– Qu’est ce que je compte faire aujourd’hui ?– Quels obstacles je rencontre ?
49/75
Sprint Review et démonstration
• Démonstration de l’incrément réalisé• Toute l’équipe participe• Tout le monde peut y assister– Feedback venant alimenter le product backlog
• Informel• Revue du sprint backlog
50/75
Rétrospective
• Ateliers d’amélioration continue– Introspection– Adaptation
51/75
Cycle de vie d’un projet Scrum
52/75
EXTREME PROGRAMMINGXP
53/75
Principes
• Pousse à l’extrême les bonnes pratiques d’ingénierie logicielle– Scrum n’aborde pas le sujet
• 5 Valeurs• 13 Pratiques
54/75
5 Valeurs
• Communication• Simplicité• Feedback• Courage• Respect
55/75
Communication
56/75
Simplicité
• Minimiser la quantité de travail inutile• …
57/75
Feedback
• Avoir un retour, et l’avoir très vite– Réunions d’équipe quotidienne– Démos avec le clients– Tests unitaires– Tests d’acceptance automatisés– …
58/75
Courage
• S'attaquer aux problèmes tout de suite– ne pas les laisser « pourrir »
• Redévelopper si nécessaire• Appliquer les valeurs XP
59/75
Respect
• Une personne n'a pas moins ou plus de valeur qu’une autre
• Tout le monde a voie au chapitre et toutes les contributions sont bienvenues
60/75
13 pratiques interdépendantes
61/75
Test Driven Development (TDD)
http://www.flickr.com/photos/agileinaction/6628138462/75
Intégration continue (1/2)
63/75
Intégration continue (2/2)
64/75
Collective code ownership
• Qui est responsable de cette partie du code ?
http://www.flickr.com/photos/resilence/93774842/65/75
Une méthode complète
• Un cycle de vie
• Des rôles– Client, développeur, coach, tracker, …
www.extremeprogramming.org66/75
KANBAN
67/75
Succinctement
• Un méta-processus non-prescriptif– Ne décrit pas la méthode de travail à suivre
• Démarre à partir de la méthode de travail préexistante, avec ces rôles, ces artefacts, …
• Décrit comment l’améliorer
• En flux continu– Pas d’itérations, mais des cadences
• Contrairement à Scrum, le tableau n’est jamais vide
• Avec travail en cours (W.I.P.) limité• Avec amélioration continue pas à pas (kaizen)
68/75
69/75
CONCLUSION
70/75
Mash-up
• Adapter les approches et les pratiques au contexte
• Les combiner
71/75
Relations
72/75
SimplesChaotiques
Complexes Compliqués
Classique
Agile
Des équipiers en forme de T
73/75http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf
Pour aller plus loin
• Livres– Scrum, Claude Aubry– Kanban pour l’IT, Laurent Morisseau– eXtreme Programming Explained, Kent Beck
74/75
QUESTIONS ?@gcollic / gcollic@gmail.com / guillaumecollic.com