Une introduction aux méthodes agiles : introduction, historique et manifeste agile, Scrum, XP, Kanban.

1. Introduction aux méthodes agiles
Guillaume Collic
gcollic@gmail.com

2. Qui suis-je ?
Acteur de l’agilité
Pro | Asso
2/75

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

4. Préambule
ÊTRE AGILE ?
4/75

5. C’est quoi être Agile ?
• Énormément de réponses possibles, suivant
l’angle et le prisme choisi, la plupart
complémentaires
Agilité
Bien être et valeurs
(prévention de risques psycho-sociaux au travail)
…
…
Faire les bonnes choses
(satisfaction client)
…
…
Faire les choses efficacement
(productivité)
5/75

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

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

8. Relations
Complexes Compliqués
Chaotiques Simples
8/75

9. Relations
Complexes Compliqués
Agile
Chaotiques Simples
Classique
9/75

10. Des équipiers en forme de T
10/75
http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf

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

12. Fin du préambule
Début du tour d’horizon
des méthodes agiles
12/75

13. APPROCHES DÉTERMINISTES
13/75

14. Modèle en cascade (Waterfall)
14/75
http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php3

15. Cycle en V
15/75
http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php3

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

17. Effet « Tunnel »
• X mois sans visibilité
– « Nuit polaire »
17/75
http://www.projectcartoon.com

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

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

20. Marge de manœuvre : 4 axes
• Périmètre
– Fixe
• Délai
– Fixe
• Coût
– Fixe
• Qualité
–?
20/75

21. Coût des anomalies
21/75
http://www.agitar.com/solutions/why_unit_testing.html

22. Approches empiriques
MÉTHODES AGILES
22/75
http://agileconsulting.blogspot.com

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

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

25. Historique
25/75

26. Les 4 valeurs
Nous reconnaissons que les éléments à droite ont
de la valeur, mais nous privilégions ceux à gauche
Individus et
Processus et outils
interactions
Un produit Documentation exhaustive
opérationnel
Collaboration Négociation du contrat
avec le client
Adaptation au Suivi d'un plan
changement 26/75

27. 12 principes
1. Satisfaire le client
2. Accueillir le changement
3. Livrer fréquemment
4. Travailler quotidiennement avec les utilisateurs ou leur
représentants
5. Créer un environnement qui soutienne l’équipe
6. Communiquer en face à face
7. Mesurer l’avancement sur un logiciel opérationnel
8. Avoir un rythme de développement soutenable
9. Porter une attention continue à l'excellence technique
10. Minimiser la quantité de travail inutile
11. Avoir une équipe auto-organisée pour faire émerger les solutions
12. Inspecter et s’adapter régulièrement
27/75

28. 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
Délai Coût
28/75

29. L’agilité en 2 slides (1/2)
Expression des besoins
Conception
Développement
Tests, recette & debugage
À 50% du temps total, le client ne voit statistiquement
que 10% de son application.
Et il ne sait pas dans quel état elle est.
29/75

30. L’agilité en 2 slides (2/2)
Backlog, user stories Expression de besoins
Simplicité, refactoring Conception
TDD, acceptance Développement
Demos, reviews Tests, recette & debuggage
i1 i2 i3 i4 i5 in
À chaque itération, le produit est 100% fonctionnel.
30/75

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

32. Bénéfices de l’adoption (sondage)
32/75
http://www.versionone.com/state_of_agile_development_survey

33. Répartition des méthodes (sondage)
33/75
http://www.versionone.com/state_of_agile_development_survey

34. SCRUM
34/75
http://www.edupics.com

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

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

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

38. Cycle de vie d’un projet Scrum
38/75

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

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

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

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

43. Discussions et décisions
Périmètre : Product Owner
Priorité : Product Owner Coût : l’équipe
43/75

44. Estimation par planning poker
44/75

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

46. Scrum Board
46/75
http://www.xqa.com.ar/visualmanagement

47. Définition de « fini »
47/75

48. Burndown
• Suivi du reste à faire (pas du consommé)
48/75
http://www.scrumalliance.org/articles/55

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

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

51. Rétrospective
• Ateliers d’amélioration continue
– Introspection
– Adaptation
51/75

52. Cycle de vie d’un projet Scrum
52/75

53. XP
EXTREME PROGRAMMING
53/75

54. Principes
• Pousse à l’extrême les bonnes pratiques
d’ingénierie logicielle
– Scrum n’aborde pas le sujet
• 5 Valeurs
• 13 Pratiques
54/75

55. 5 Valeurs
• Communication
• Simplicité
• Feedback
• Courage
• Respect
55/75

56. Communication
56/75

57. Simplicité
• Minimiser la quantité de travail inutile
• …
57/75

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

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

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

61. 13 pratiques interdépendantes
61/75

62. Test Driven Development (TDD)
62/75
http://www.flickr.com/photos/agileinaction/66281384

63. Intégration continue (1/2)
63/75

64. Intégration continue (2/2)
64/75

65. Collective code ownership
• Qui est responsable de cette partie du code ?
65/75
http://www.flickr.com/photos/resilence/93774842/

66. Une méthode complète
• Un cycle de vie
• Des rôles
– Client, développeur, coach, tracker, …
66/75
www.extremeprogramming.org

67. KANBAN
67/75

68. 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. 69/75

70. CONCLUSION
70/75

71. Mash-up
• Adapter les approches et les pratiques au
contexte
• Les combiner
71/75

72. Relations
Complexes Compliqués
Agile
Chaotiques Simples
Classique
72/75

73. Des équipiers en forme de T
73/75
http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf

74. Pour aller plus loin
• Livres
– Scrum, Claude Aubry
– Kanban pour l’IT, Laurent Morisseau
– eXtreme Programming Explained, Kent Beck
74/75

75. @gcollic / gcollic@gmail.com / guillaumecollic.com
QUESTIONS ?