Your SlideShare is downloading. ×
Introduction aux méthodes agiles
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Introduction aux méthodes agiles

4,304
views

Published on

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

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


0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,304
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
191
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. RelationsComplexes CompliquésChaotiques Simples 8/75
  • 9. RelationsComplexes Compliqués AgileChaotiques Simples Classique 9/75
  • 10. Des équipiers en forme de T 10/75http://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éambuleDébut du tour d’horizon des méthodes agiles 12/75
  • 13. APPROCHES DÉTERMINISTES 13/75
  • 14. Modèle en cascade (Waterfall) 14/75http://www.commentcamarche.net/contents/genie-logiciel/cycle-de-vie.php3
  • 15. Cycle en V 15/75http://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/75http://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/75http://www.agitar.com/solutions/why_unit_testing.html
  • 22. Approches empiriques MÉTHODES AGILES 22/75http://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 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. 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. 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 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. 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/75http://www.versionone.com/state_of_agile_development_survey
  • 33. Répartition des méthodes (sondage) 33/75http://www.versionone.com/state_of_agile_development_survey
  • 34. SCRUM 34/75http://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 dacceptation 40/75
  • 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. 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 OwnerPriorité : 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/75http://www.xqa.com.ar/visualmanagement
  • 47. Définition de « fini » 47/75
  • 48. Burndown • Suivi du reste à faire (pas du consommé) 48/75http://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. XPEXTREME 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• Sattaquer 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 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. 13 pratiques interdépendantes 61/75
  • 62. Test Driven Development (TDD) 62/75http://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/75http://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/75www.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. RelationsComplexes Compliqués AgileChaotiques Simples Classique 72/75
  • 73. Des équipiers en forme de T 73/75http://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.comQUESTIONS ?