Introduction aux méthodes agiles

8 738 vues

Publié le

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

0 commentaire
6 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
8 738
Sur SlideShare
0
Issues des intégrations
0
Intégrations
299
Actions
Partages
0
Téléchargements
432
Commentaires
0
J’aime
6
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Introduction aux méthodes agiles

  1. 1. Introduction aux méthodes agiles Guillaume Collic gcollic@gmail.com
  2. 2. Qui suis-je ? Acteur de l’agilitéPro | Asso 2/75
  3. 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. 4. PréambuleÊTRE AGILE ? 4/75
  5. 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. 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. 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. 8. RelationsComplexes CompliquésChaotiques Simples 8/75
  9. 9. RelationsComplexes Compliqués AgileChaotiques Simples Classique 9/75
  10. 10. Des équipiers en forme de T 10/75http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf
  11. 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. 12. Fin du préambuleDébut du tour d’horizon des méthodes agiles 12/75
  13. 13. APPROCHES DÉTERMINISTES 13/75
  14. 14. Modèle en cascade (Waterfall) 14/75http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php3
  15. 15. Cycle en V 15/75http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php3
  16. 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. 17. Effet « Tunnel » • X mois sans visibilité – « Nuit polaire » 17/75http://www.projectcartoon.com
  18. 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. 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. 20. Marge de manœuvre : 4 axes• Périmètre – Fixe• Délai – Fixe• Coût – Fixe• Qualité –? 20/75
  21. 21. Coût des anomalies 21/75http://www.agitar.com/solutions/why_unit_testing.html
  22. 22. Approches empiriques MÉTHODES AGILES 22/75http://agileconsulting.blogspot.com
  23. 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. 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. 25. Historique 25/75
  26. 26. Les 4 valeursNous reconnaissons que les éléments à droite ontde 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 dun plan changement 26/75
  27. 27. 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 à lexcellence 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
  28. 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. 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. 30. L’agilité en 2 slides (2/2)Backlog, user stories Expression de besoinsSimplicité, 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. 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. 32. Bénéfices de l’adoption (sondage) 32/75http://www.versionone.com/state_of_agile_development_survey
  33. 33. Répartition des méthodes (sondage) 33/75http://www.versionone.com/state_of_agile_development_survey
  34. 34. SCRUM 34/75http://www.edupics.com
  35. 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. 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. 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. 38. Cycle de vie d’un projet Scrum 38/75
  39. 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. 40. User Stories (1/2)• Nom (Valeur métier)• En tant que <rôle>• Je veux <action>• Afin de <but>• Critères dacceptation 40/75
  41. 41. User Stories (2/2)• Ecrites par le Product Owner• Très simples• Focalisées sur lutilisateur final – valeur métier apportée• Critères dacceptations – 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. 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. 43. Discussions et décisions Périmètre : Product OwnerPriorité : Product Owner Coût : l’équipe 43/75
  44. 44. Estimation par planning poker 44/75
  45. 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. 46. Scrum Board 46/75http://www.xqa.com.ar/visualmanagement
  47. 47. Définition de « fini » 47/75
  48. 48. Burndown • Suivi du reste à faire (pas du consommé) 48/75http://www.scrumalliance.org/articles/55
  49. 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. 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. 51. Rétrospective• Ateliers d’amélioration continue – Introspection – Adaptation 51/75
  52. 52. Cycle de vie d’un projet Scrum 52/75
  53. 53. XPEXTREME PROGRAMMING 53/75
  54. 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. 55. 5 Valeurs• Communication• Simplicité• Feedback• Courage• Respect 55/75
  56. 56. Communication 56/75
  57. 57. Simplicité• Minimiser la quantité de travail inutile• … 57/75
  58. 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. 59. Courage• Sattaquer aux problèmes tout de suite – ne pas les laisser « pourrir »• Redévelopper si nécessaire• Appliquer les valeurs XP 59/75
  60. 60. Respect• Une personne na 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. 61. 13 pratiques interdépendantes 61/75
  62. 62. Test Driven Development (TDD) 62/75http://www.flickr.com/photos/agileinaction/66281384
  63. 63. Intégration continue (1/2) 63/75
  64. 64. Intégration continue (2/2) 64/75
  65. 65. Collective code ownership • Qui est responsable de cette partie du code ? 65/75http://www.flickr.com/photos/resilence/93774842/
  66. 66. Une méthode complète • Un cycle de vie • Des rôles – Client, développeur, coach, tracker, … 66/75www.extremeprogramming.org
  67. 67. KANBAN 67/75
  68. 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. 69/75
  70. 70. CONCLUSION 70/75
  71. 71. Mash-up• Adapter les approches et les pratiques au contexte• Les combiner 71/75
  72. 72. RelationsComplexes Compliqués AgileChaotiques Simples Classique 72/75
  73. 73. Des équipiers en forme de T 73/75http://newcdn.flamehaus.com/Valve_Handbook_LowRes.pdf
  74. 74. Pour aller plus loin• Livres – Scrum, Claude Aubry – Kanban pour l’IT, Laurent Morisseau – eXtreme Programming Explained, Kent Beck 74/75
  75. 75. @gcollic / gcollic@gmail.com / guillaumecollic.comQUESTIONS ?

×