De l'agilité pour mon projet, pour quoi faire ?

1,708 views
1,383 views

Published on

Les développeurs ne sont pas tous des individus mal rasés, travaillant la nuit et jonchant leur sillage de boites de soda et d'emballages de pizzas.
L'agilité ne se réduit pas à des hurluberlus cherchant à couvrir chaque centimètre carré des murs de post-it multicolores.
Et d'ailleurs, l'agilité, qu'est-ce que c'est vraiment ?
Est-ce une nouvelle mode qu'il me faudra subir et passera à mon grand soulagement ? Ou est-ce une véritable réponse à la sclérose et l'inefficacité qui gangrènent nos projets ?
Au long de cette présentation, nous allons découvrir ensemble ce qu'est réellement l'agilité, en quoi il peut vous aider à réaliser des projets qui déchirent tout en y prenant plaisir ! Depuis les principes de base (adaptation aux changements, collaboration et transparence) jusqu'aux pratiques telles que le test-driven développement, le pair-programming, l'intégration continue, etc. nous iront à la rencontre des fondamentaux de l'univers agile.
Enfin, nous dérouleront un jour dans la vie du développeur agile pour comprendre comment les choses se passent. Réellement.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,708
On SlideShare
0
From Embeds
0
Number of Embeds
348
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

De l'agilité pour mon projet, pour quoi faire ?

  1. 1. De l’agilité pour mon projet… POUR QUOI FAIRE ??
  2. 2. Qui sommes-nous ? Martin Mouterde Christophe Addinquy
  3. 3. Agilité… … un mot qui fait peur
  4. 4. Agilité… Méthode Religion Valeurs Révolution Marketing framework de gestion de projet Plus de spec … un mot qui fait peur
  5. 5. C’était pas bien avant ? 5 PROBLÈMES DU CYCLE EN V
  6. 6. Cycle en V : Le rappel
  7. 7. Cycle en V, Problème 1 : Le partage d’info
  8. 8. Pb 1 : Le partage d’info - de proche en proche - 1 étape = 1 document
  9. 9. Sol 1 : Le partage d’info - Level 1 : Diffusée à tous - Level 2 : Un seul support d’échange
  10. 10. Cycle en V, Problème 2 : Le Flux Stocké
  11. 11. Pb 2 : Le Flux Stocké - 6 mois de spécifications à faire - Verdict dans 1 an Solution - des itérations plus courtes
  12. 12. Cycle en V, Problème 3 : Les chiffrages 3j 5j +/- 1 j 8j +/- 3 j
  13. 13. Pb 3 : Le Chiffrage - Chiffrage = évaluation + risque 3j +/- 1 j 8j 5j +/- 4 j - Estimation = Engagement ?? +/- 3 j
  14. 14. Sol 3 : Le Chiffrage • Limiter le périmètre • 30% d’erreur sur 500 ou sur 10 ?
  15. 15. Cycle en V, Problème 4 : La Collaboration
  16. 16. Pb 4 : Collaboration Un contrat pour les soumettre tous  Erreur du prestataire => $  Retard du prestataire => $  Erreur du demandeur => $ +$ + $ + retard
  17. 17. Sol 4 : Collaboration - Level 1 : Partager les Erreurs - Level 2 : Permettre le changement du plan
  18. 18. Cycle en V, Problème 5 : Créer de la Valeur
  19. 19. Pb 5 : Créer de la valeur
  20. 20. Sol 5 : Créer de la valeur - Level 1 : Faire les choses importantes d’abord - Level 2 : Accepter d’abandonner la non valeur
  21. 21. La domination du Processus La croyance dans la sacro-sainte documentation Respecter les règles ou le contrat est le plus important Faut suivre le plan : ton boulot, c’est de ramer !
  22. 22. 2001
  23. 23. Et concrètement ? L’EXEMPLE DE SCRUM
  24. 24. Scrum : la posologie Un planning meeting au début du sprint Un daily meeting chaque jour, de préférence le matin Une revue de sprint (démo) à la fin de celui-ci Une rétrospective, une fois le sprint terminé
  25. 25. 3 artefacts principaux Product backlog Sprint backlog (task board) Burndown chart
  26. 26. 3 Rôles
  27. 27. Et les grosses boîtes ? LA METHODE GOOGLE
  28. 28. La Méthode Google - Plus qu’une méthode, une culture • • • • • Pas de hiérarchie Turnover projet Cultive l’excellence La règle des 20% Pas de roadmap
  29. 29. La Méthode Google - Plus qu’une méthode, une culture • Product Manager • Evaluation par les pairs • Incitation financière Et ça marche ?
  30. 30. La Méthode Google - Quelques limites • Pas de planification • Petite équipe • Le projet adWords - Scrum en homéopathie
  31. 31. Extreme Programming Kanban L’agilité, c’est aussi… < Votre méthode agile ici >
  32. 32. Et moi là dedans ? LA PLACE DU DÉVELOPPEUR ?
  33. 33. Développeur : un savoir-faire important !  L’excellence technique pour livrer régulièrement  Une architecture guidée par le besoin et non par des « recettes toutes faites ».  Des choix technologiques créatifs et raisonnés qui ajoutent de la valeur  Des pratiques de craftmanship : TDD, ATDD, refactoring, Domain Driven Design, etc…
  34. 34. Une journée dans la vie du développeur agile…
  35. 35. « Je viens d’arriver, je dépile 2 ou 3 trucs que j’avais mis de côté hier soir avant que le reste de l’équipe arrive » Note à moi-même : refactor « extract interface » du service métier
  36. 36. « 10:00 … daily meeting time ! »
  37. 37. Je viens de terminer la dernière tâche d’une « user story », nous décidons de la valider dès ce matin avec le Product Owner et de lui montrer le passage des cas de test.
  38. 38. « Démo OK avec le Product Owner … il faut dire que les acceptance tests passaient déjà… »
  39. 39. « La story suivante n’est pas évidente : besoin d’une petite design session pour faire émerger la bonne archi »
  40. 40. « Maintenant, place au code : en pair programming, avec TDD ! »
  41. 41. « 8 heures de travail intense : l’heure de rentrer. Le rythme soutenable, c’est important ! »
  42. 42. Alors, tu commences quand ??
  43. 43. Questions
  44. 44. Merci ! martin.mouterde@zenika.com http://www.infoq.com/fr/author/Martin-Mouterde christophe.addinquy@zenika.com @addinquy http://freethinker.addinq.uy

×