Téléchargé 823 fois
Téléchargé parGuillaume Collic
Introduction aux méthodes agiles
Le document présente une introduction aux méthodes agiles, en expliquant leurs principes fondamentaux et en les contrastant avec des approches classiques. Il aborde divers cadres agiles tels que Scrum, Extreme Programming (XP) et Kanban, tout en soulignant l'importance de l'engagement des utilisateurs et de l'adaptabilité en cours de projet. Enfin, il souligne les bénéfices de l'agilité, notamment l'amélioration de la satisfaction client et l'efficacité opérationnelle.
Introduction aux méthodes agiles
- 1. Introduction aux méthodesagiles 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.
- 5. C’est quoi êtreAgile ? • É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 etaujourd’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 enforme de T 10/75 http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf
- 11. Mais avant d’enarriver 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ébutdu 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 à mettreen œ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écificationsne 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éactiveset 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 Nousreconnaissons 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 2slides (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 2slides (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 vied’un projet Scrum 38/75
- 39. Product Backlog • Listedu 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 planningpoker 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 etdé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éliorationcontinue – Introspection – Adaptation 51/75
- 52. Cycle de vied’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 laquantité de travail inutile • … 57/75
- 58. Feedback • Avoir unretour, 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 auxproblèmes tout de suite – ne pas les laisser « pourrir » • Redévelopper si nécessaire • Appliquer les valeurs XP 59/75
- 60. Respect • Une personnen'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.
- 62. Test Driven Development(TDD) 62/75 http://www.flickr.com/photos/agileinaction/66281384
- 63.
- 64.
- 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-processusnon-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.
- 70. CONCLUSION 70/75
- 71. Mash-up • Adapter lesapproches et les pratiques au contexte • Les combiner 71/75
- 72. Relations Complexes Compliqués Agile Chaotiques Simples Classique 72/75
- 73. Des équipiers enforme de T 73/75 http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf
- 74. Pour aller plusloin • 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 ?