Your SlideShare is downloading. ×
0
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
Introduction a l_agilite_iut_lyon_1_decembre2011
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 a l_agilite_iut_lyon_1_decembre2011

1,661

Published on

Présentation "Introduction aux méthodes agiles" préparée par Alfred Almendra et Agnès Crépet. …

Présentation "Introduction aux méthodes agiles" préparée par Alfred Almendra et Agnès Crépet.
Présentée le 13/12/2011 à l'Université Lyon 1, IUT

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,661
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
64
Comments
0
Likes
0
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
  • voilà, dans le slide, ma propositon de conluc simple!
  • Transcript

    • 1. <ul>Introduction à l'agilité </ul><ul>IUT Lyon 1 - décembre 2011 @agnes_crepet   @AlfredAlmendra </ul>
    • 2. <ul>Qui sommes-nous? </ul><ul>Alfred Almendra Coach agile Architecte SOA   CARA Lyon </ul><ul>Agnès Crépet Java/JEE Architecte   Java User Groups Leader: Duchess France & LyonJUG   Fait partie de l'équipe organistrice de la conférence MIX-IT (Java, Agilité...)   Co-fondatrice du podcast Cast-IT (Java, Agilité...) </ul>
    • 3. <ul>Sommaire </ul><ul><ul><li>Préambule
    • 4. Théorie
    • 5. Pratiques
    • 6. Méthodes
    • 7. Concrètement
    • 8. Plus de concret !
    • 9. Conclusion
    • 10. Informations diverses
    • 11. Annexes </li></ul></ul>
    • 12. <ul><ul><li>Préambule </li></ul></ul><ul><ul><li>Théorie
    • 13. Pratiques
    • 14. Méthodes
    • 15. Concrètement
    • 16. Plus de concret !
    • 17. Conclusion
    • 18. Informations diverses
    • 19. Annexes </li></ul></ul>
    • 20. <ul>Préambule </ul><ul>Spinning Dancer (Nobuyuki Kayahara, web designer) </ul>
    • 21. <ul>Préambule </ul><ul>Notre cerveau est bogué ! </ul><ul>...mais nous sommes maintenant avertis ! Psychologie cognitive : les (nombreux) biais du cerveau </ul><ul>Ancrage </ul><ul>Confirmation d'hypothèse </ul><ul>Conformisme </ul><ul>Dunning-Kruger </ul><ul>Halo </ul><ul>Dissonance cognitive </ul><ul>Perception sélective </ul><ul>... </ul>
    • 22. <ul>Préambule </ul><ul>Personne n’est parfait = tout le monde est imparfait </ul><ul>On peut se tromper, mais on doit s’améliorer </ul><ul>L’erreur peut venir du développeur, mais pas uniquement. Tous les acteurs du projet peuvent se tromper ... </ul><ul>@Morendil Responsable de l' institut-agile.fr </ul><ul>&quot;Il n’existe pas de bug qui ne soit issu du cerveau humain. La conception c’est tout ce qui permet de prévenir ou contourner les bugs du cerveau (outil, méthode, design pattern, modélisation, schéma, doc, wiki, commentaire dans le code, …)&quot;  (Mix-IT 2011) </ul><ul>&quot;Une erreur de spécification est une forme de bug. Un utilisateur, un décideur et un responsable métier ont aussi le droit de se tromper.&quot;  (Responsable métier chez Boiron) </ul>
    • 23.  
    • 24. <ul>Préambule </ul><ul>Les besoins métier évoluent dans le temps, même pendant la vie d'un projet </ul><ul>On doit savoir et pouvoir s’adapter au changement... </ul><ul>Vocabulaire pour la suite de la présentation : Equipe = tous les acteurs du projet                  pas uniquement les développeurs REX = retour d'expérience </ul>
    • 25. <ul>Besoin d’une rupture </ul><ul>La méthode en cascade On travaille l'un après l'autre : la moindre erreur coûte cher </ul>
    • 26. <ul>Besoin d’une rupture </ul><ul>Le cycle en V On ajoute à la cascade de l'anticipation et du travail simultané </ul>
    • 27. <ul>Besoin d’une rupture </ul><ul>Organisation contrainte et peu adaptée à l'inconnu... ...l'innovation, la découverte, l'incertitude, l'amélioration continue </ul><ul>Ces méthodes prédictives répondent à certains contextes... ...mais pas à tous </ul>
    • 28. <ul>Besoin d’une rupture </ul><ul>Constat : encore à notre époque, les projets informatiques ne finissent pas souvent comme on le souhaite... Nous souhaitons tous améliorer ces chiffres ! </ul>
    • 29. <ul>Rapide historique </ul><ul>Certains principes existent depuis longtemps IHM révolutionnée par Internet depuis 2000 ! </ul>
    • 30. <ul><ul><li>Préambule </li></ul></ul><ul><ul><li>Théorie </li></ul></ul><ul><ul><li>Pratiques
    • 31. Méthodes
    • 32. Concrètement
    • 33. Plus de concret !
    • 34. Conclusion
    • 35. Informations diverses
    • 36. Annexes </li></ul></ul>
    • 37. <ul>Les 4 valeurs </ul><ul>L’agilité c'est 4 valeurs et 12 principes rédigés en 2001 (Manifeste Agile) Ce n’est pas une méthode, mais plutôt un savoir-être C'est du bon sens issu de 17 retours d’expériences d'experts L’équipe : communicante et auto-organisée, pas uniquement les développeurs : CdP, métier, analystes, … L’application : fonctionnelle/utilisable, plutôt que des docs à rallonge, pas à jour Le client : collaborant, investi tout au long du projet, pas uniquement concerné par un contrat et une recette L’acceptation du changement : flexibilité (de l’équipe, des outils, des méthodes et des mentalités), et non pas suivre un plan initial dans une structure rigide </ul>
    • 38. <ul>Les 12 principes </ul><ul>Autour de l’application et de la valeur fonctionnelle : </ul><ul>1. Satisfaire le client en livrant tôt et régulièrement des logiciels utiles (cf. Scrum) 3. Livrer fréquemment une application fonctionnelle avec une tendance pour la période la plus courte (de 2 semaines à 2 mois par itération) 7. Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet (i.e. c’est le meilleur indicateur qualitatif). </ul>
    • 39. <ul>Les 12 principes </ul><ul>Concernant l’acception du changement : </ul><ul>2. Le changement est bienvenu, même tardivement dans le développement, ce qui constitue un avantage compétitif pour le client (cf. ergonomie et expérience utilisateur) </ul><ul>Concernant le client : </ul><ul>4. Les “gens de l’art” (i.e. métier) et les développeurs doivent collaborer quotidiennement au projet (cf. XP) </ul>
    • 40. <ul>Les 12 principes </ul><ul>Autour de l’équipe et de l’organisation : </ul><ul>5. Bâtissez le projet autour de personnes motivées. Donnez-leur l’environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail. 6. La méthode la plus efficace pour transmettre l’information est une conversation en face à face. 8. Rythme de développement durable (à l’infini !) : commanditaires, développeurs, utilisateurs. 11. Les meilleurs architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent. </ul>
    • 41. <ul>Les 12 principes </ul><ul>Concernant la qualité (“5ème valeur !?” ou plutôt savoir-faire, art) </ul><ul>9. Attention continue à l’excellence technique et à la qualité de la conception (pérennité, dette technique). 10. La simplicité est essentielle : c-a-d l’art de maximiser la qualité de travail à ne pas faire. (cf. éliminer le gaspillage Lean, Kanban) 12. A intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens. (cf. amélioration continue, et rétrospectives sur tout). </ul>
    • 42. <ul>4 valeurs et 12 principes </ul>
    • 43. <ul><ul><li>Préambule
    • 44. Théorie </li></ul></ul><ul><ul><li>Pratiques </li></ul></ul><ul><ul><li>Méthodes
    • 45. Concrètement
    • 46. Plus de concret !
    • 47. Conclusion
    • 48. Informations diverses
    • 49. Annexes </li></ul></ul>
    • 50. <ul>Itératif, incrémental, adaptatif </ul><ul>Monalisa selon Jeff Patton On diminue considérablement le risque d’effet tunnel Dans chaque itération : mini cycle en V, XP, Kanban, ... </ul>
    • 51. <ul>Itératif, incrémental, adaptatif </ul><ul>Et l’adaptatif... Les besoins se précisent voire évoluent continuellement Pendant le projet, même quand on croit toucher au but </ul>
    • 52. <ul>Itératif, incrémental, adaptatif </ul><ul>Les besoins évoluent aussi après la mise en production (la maintenance est-elle un mythe ? une stagnation ?) Jean-François Jagodzinski @jfjago a remplacé le terme projet par processus de fabrication (cf. Kanban) </ul>
    • 53. <ul>Les jeux </ul><ul>Ludiques : donc participation volontaire et motivée Augmentent la créativité, la collaboration, le taux d'apprentissage Cadre et règles faciles à comprendre : donc focus sur l’objectif </ul><ul><ul><li>Exemples de valeurs et objectifs : auto organisation, communication, collaboration, productivité, ... </li></ul></ul><ul>Alexandre Boutin (@agilex) président du CARA Bientôt un agile game en France ? en 2012 ? Agile Games à Boston, Agile4Play en Allemagne </ul>
    • 54. <ul>Les jeux et les étapes du projet </ul><ul>Extrait du calendrier du CARA Lyon (OUI, c'est de la PUB !)  </ul>
    • 55. <ul>Auto-organisation et travail collaboratif </ul><ul>XP : Pair-P., TDD, work space Tests croisés, revues de code Daily meetings (stand up) Répartition et alternance des expertises, wiki, post-it, proximité user/dév </ul><ul>Rôles figés (CP, Architecte, ...) Réunions stériles Les docs à rallonge (mails, CR) </ul><ul>Entreprise gérée en mode Open Space (ut7 AgileInnovation 2011) </ul><ul>Ateliers Open Space </ul><ul>Rétrospective personnelle synthétique </ul>
    • 56. <ul>La marge de manoeuvre </ul><ul>Renoncer à des fonctionnalités pour tenir les délais : oui et non </ul><ul>     Ne pas réaliser des fonctionnalités non rentables      c’est gagner du temps, de l’argent et de l’énergie. </ul><ul>Tout projet, agile ou non, possède 4 leviers dépendants de ses contraintes et objectifs : </ul><ul><ul><li>les fonctionnalités
    • 57. le coût
    • 58. le délai
    • 59. les ressources </li></ul></ul>
    • 60. <ul>Côté organisationnel </ul><ul>Pilotage par les risques </ul><ul><ul><li>la réussite n’est pas garantie, mais l’éventuel échec est découvert plus tôt </li></ul></ul><ul>Visibilité </ul><ul><ul><li>oui sur l’avancement vers l’objectif
    • 61. non dans le détail (exploration, challenge, adaptation) </li></ul></ul><ul>Ordonnancement (plutôt que priorisation, cf. Scrum été 2011) Indicateurs </ul><ul><ul><li>qualitatifs : satisfaction, image, analyse de la valeur (AFAV.eu)
    • 62. quantitatifs : taux d'utilisation, valeur ajoutée progressive, ROI </li></ul></ul><ul>Contrats de sous-traitance : à essayer ! </ul><ul><ul><li>Ex :  http://contrat-agile.org/  (Xebia, Cellenza, Alerion, LCA) </li></ul></ul><ul>Offshore : complexe, peu de réussites notables </ul>
    • 63. <ul>L'oignon agile De l'agilité à tous les étages ! </ul>
    • 64. <ul>Côté fonctionnel métier </ul><ul>Identifier la valeur ajoutée : l'utilisabilité </ul><ul>&quot;Si j’avais demandé aux gens ce qu'ils voulaient, ils m’auraient réclamé un meilleur cheval.&quot;  [Henry Ford] </ul><ul>En pratique : fréquence/usage/volumétrie </ul><ul>&quot;L’ergonomie est au fonctionnel ce que l’agilité est à l’organisationnel&quot; </ul><ul>Ergonomie, User eXperience (UX), interaction design (IxD) </ul><ul>...découverte, tentatives, affinage du besoin </ul><ul>Faire tester souvent les utilisateurs </ul><ul>...questionner, observer, inviter à verbaliser les tâches </ul>
    • 65. <ul>Côté technique </ul><ul>Qualité et industrialisation </ul><ul><ul><li>TDD, PIC, refactoring, déploiement continu
    • 66. Pair programming, revues de code, … </li></ul></ul><ul>TDD = Test Driven Development (Test First !) </ul><ul><ul><li>Le TU = Test Unitaire c’est le quoi (les spécs en langage informatique).
    • 67. Le code c’est le comment. Coder c’est essayer une tentative pour satisfaire les TU (et donc les spécs). </li></ul></ul><ul>Force de proposition </ul><ul><ul><li>collaboration + capitalisation + motivation </li></ul></ul><ul>Tendances </ul><ul><ul><li>Artisan Programmeur (Software Craftsmanship, 2009, Robert C. Martin)
    • 68. Refactoring : sessions de Code Retreat (c3f  http://coderetreat.org/ )
    • 69. Devops (collaboration entre Développements et Opérations)
    • 70. Cloud (service externalisé) </li></ul></ul>
    • 71. <ul>Agilité et UML </ul><ul>Comment documenter / modéliser un besoin ?   2 approches semblent opposées :    </ul><ul><ul><li>l'approche Model-Driven (OMG) </li></ul></ul><ul><ul><ul><li>modélisation UML très poussée
    • 72. génération automatique de code </li></ul></ul></ul><ul>   </ul><ul><ul><li>l'approche agile </li></ul></ul><ul><ul><ul><li>production rapide de code opérationnel (mieux que la doc)
    • 73. minimiser la modélisation en amont </li></ul></ul></ul>
    • 74. <ul>Agilité et UML </ul><ul>La modélisation agile peut-elle exister ?   L'agilité se passe de plus en plus d'UML   Boiron a décidé néanmoins de garder UML : </ul><ul><ul><li>Traçabilité des exigences
    • 75. Analyse d'impact d’un changement
    • 76. Contrainte de validation pharmaceutique
    • 77. Communication inter et intra équipe </li></ul></ul><ul>  Stratégie Boiron pour pour la modélisation: </ul><ul><ul><li>Pas trop de doc
    • 78. Un peu d'UML </li></ul></ul>
    • 79. <ul><ul><li>Préambule
    • 80. Théorie
    • 81. Pratiques </li></ul></ul><ul><ul><li>Méthodes </li></ul></ul><ul><ul><li>Concrètement
    • 82. Plus de concret !
    • 83. Conclusion
    • 84. Informations diverses
    • 85. Annexes </li></ul></ul>
    • 86. <ul>Survol des principales méthodes </ul><ul>Scrum, XP, UP, Lean SD, Kanban, Puma (RAD), Crystal clear, Xbreed (XP + Scrum) L’agilité c’est s’approprier ce qui a de la valeur pour nous, et abandonner ce qui n’en a pas. Pour plus de méthodes et d’éléments de comparaison   </ul><ul><ul><li>PUMA (sur rad.fr) : Proposition pour l'Unification des Méthodes Agiles  </li></ul></ul><ul>  </ul><ul><ul><li>http://institut-agile.fr/  : plus de 60 pratiques agiles en ligne ! </li></ul></ul>
    • 87. <ul>Barry Boehm article A Spiral Model of Software Development and Enhancement (1986) </ul>
    • 88. <ul>Première version opérationnelle publiée par James Martin en 1991 sous le nom de RAD (développement rapide d'applications) Niveau de planification stratégique ajouté par Jean-Pierre Vickoff </ul>
    • 89. <ul>UP en quelques mots </ul><ul>Le processus UP (abréviation de Unified Processus) a été créé par les mêmes personnes qu'UML (Rumbaugh, Booch et Jacobson) en 1997.   UP répond aux exigences fondamentales préconisées par les créateurs d’UML :    </ul><ul><ul><li>une méthode de développement doit être guidée par les besoins des utilisateurs  </li></ul></ul><ul>  </ul><ul><ul><li>elle doit être centrée sur l’architecture logicielle  </li></ul></ul><ul>  </ul><ul><ul><li>elle doit être itérative et incrémentale  </li></ul></ul><ul>  Centré cas d’utilisation (Use Case) </ul>
    • 90. <ul>Phases RUP </ul>
    • 91. <ul>Scrum en quelques mots </ul><ul>Scrum est un processus agile qui permet de produire la plus grande valeur métier dans la durée la plus courte Du logiciel qui fonctionne est produit à chaque « sprint » (2 à 4 semaines) = timebox Le métier définit les priorités. L'équipe s'organise elle-même pour déterminer la meilleure façon de produire les exigences les plus prioritaires A chaque fin de sprint : release déployable et testable par les utilisateurs finaux Deux rôles importants dans l’équipe Scrum : Product Owner et Scrum Master </ul>
    • 92. <ul>Product Owner (PO) Définit les fonctionnalités du produit Définit les priorités dans le backlog en fonction de la valeur « métier » Ajuste les fonctionnalités et les priorités à chaque itération si nécessaire Teste les releases Accepte ou rejette les résultats </ul><ul>Scrum Master (SM) Vulgarise les valeurs et les pratiques de Scrum Contribue à améliorer les outils et les pratiques de l’ingénierie Facilite une coopération poussée entre tous les rôles et fonctions Protège l'équipe des interférences extérieures Met l’accent sur la créativité et la gestion autonome des membres </ul>
    • 93. <ul>Scrum </ul><ul>Temps fixe des itérations, itération de refactoring, visibilité sur 1 ou 2 itérations Attention d'éviter les goulots d'étranglement (spécs d'avance) Présence PO : spécification, développement, recette </ul>
    • 94. <ul>Scrum </ul><ul>L'équipe, les rôles, l'organisation Métaphores </ul><ul><ul><li>BTP : CP, architecte, MOA, MOE </li></ul></ul><ul><ul><ul><li>Contrôle, prédictif </li></ul></ul></ul><ul><ul><li>Rugby : SM, PO, TM </li></ul></ul><ul><ul><ul><li>Lâché prise, créativité </li></ul></ul></ul><ul>Stakeholder : parties prenantes Chicken and pig </ul>
    • 95. <ul>Scrum : activités, collaboration </ul>
    • 96. <ul>Scrum : stand up (daily meeting) </ul><ul>3 questions : </ul><ul><ul><li>qu'avez-vous fait hier ?
    • 97. qu'allez-vous faire aujourd'hui ?
    • 98. qu'est-ce qui bloque l'avancement ? </li></ul></ul><ul>Tout le monde parle </ul><ul><ul><li>pas uniquement les développeurs </li></ul></ul><ul>Time-boxing </ul><ul><ul><li>pas uniquement aux stand-up </li></ul></ul>
    • 99. <ul>Scrum : vélocité, burndown chart </ul><ul>Trop lent : répartition par expertise Trop vite : capitalisation des connaissances </ul><ul>Inputs : mou et rythme soutenable </ul><ul>Michel Goldenberg </ul>
    • 100. <ul>XP (eXtreme Programming) </ul><ul>Adaptée aux équipes réduites avec des besoins changeants But principal : réduire les coûts du changement Valeurs : communication, simplicité, feedback, courage, respect Pratiques : planning poker, TDD et  intégration continue, refactoring, programmation en binôme, n'optimiser qu'à la toute fin </ul>
    • 101. <ul>Lean </ul><ul>TPS (Toyota Production System) : baptisé Lean par le MIT en 1980 Le Lean c'est l'élimination des pertes , c-a-d du travail qui n'apporte aucune valeur métier à un produit ou à un service. D'abord présent dans l'industrie, la santé, les services, etc... Lean Software Development  : le Lean dans le développement logiciel Lean IT : application du Lean aux systèmes d'information Lean Startup : application du Lean au modèle d'entreprise Objectif : Générer la valeur ajoutée maximale au moindre coût et au plus vite. C’est donc bien une méthode agile ! Parfait pour la gouvernance, mais pas uniquement </ul>
    • 102. <ul>Lean SD (oui, LSD !) </ul><ul>Modèle itératif et agile mettant en avant 7 principes : 1. Eliminer les gaspillages </ul><ul><ul><li>Tout ce qui n'apporte pas de valeur au produit. La valeur étant définie du point de vue de l'utilisateur. </li></ul></ul><ul>2. Améliorer l'apprentissage 3. Retarder l'engagement 4. Livrer aussi vite que possible 5. Donner le pouvoir à l'équipe 6. Intégrer la qualité dès la conception 7. Considérer le produit dans sa globalité </ul>
    • 103. <ul>Amélioration continue (PDCA, Lean A3) </ul>
    • 104. <ul>Dimensionner et maîtriser les stocks Simplifier visuellement le suivi et la planification Parfait pour une TMA, mais pas uniquement </ul>
    • 105. <ul>Définition de &quot;terminé&quot; ( http://www.scrumalliance.org ) </ul>
    • 106. <ul><ul><li>Préambule
    • 107. Théorie
    • 108. Pratiques
    • 109. Méthodes </li></ul></ul><ul><ul><li>Concrètement </li></ul></ul><ul><ul><li>Plus de concret !
    • 110. Conclusion
    • 111. Informations diverses
    • 112. Annexes </li></ul></ul>
    • 113. <ul>Difficultés </ul><ul>Participation active des métiers ou d’un panel d’utilisateurs Soutien engagé et permanent des décideurs, du client, du payeur Acceptation du changement, de l’erreur, de la critique : tout le monde est concerné Autoriser l’erreur c’est donner le droit et la chance de l’amélioration (pour soi et les autres) L’humain n’aime pas le changement, donc freine consciemment ou inconsciemment jusqu’à sa propre amélioration </ul>
    • 114. <ul>Quelques clés de réussite </ul><ul>Proximité (même bureau ou workspace, offshore compliqué) Qualités humaines : collaboration, motivation, remise en cause, reconnaissance de la valeur d’autrui Forte IHM plutôt que batchs techniques et contraints Innovation, exploration des besoins Nouveaux développements ou refonte d’applications existantes, plutôt que dans l’embarqué </ul>
    • 115.  
    • 116. <ul>Quelques clés de réussite </ul><ul>Projet de taille moyenne : ni trop court (au moins quelques semaines ou mois), ni trop gros (moins de 10 personnes) </ul>
    • 117. <ul>Quelques clés de réussite </ul>
    • 118. <ul>Michael Sahota </ul>
    • 119. <ul>Liens avec l'assurance qualité </ul><ul>ISO / CMMi : dire ce qu'on va faire, et faire ce qu'on a dit </ul><ul><ul><li>prédictif : plutôt pas agile </li></ul></ul><ul>ITIL : bonnes pratiques pour gérer le SI </ul><ul><ul><li>support : incident, problème, changement, configuration
    • 120. service : capacité, disponibilité, continuité des services, contrats de service
    • 121.   infrastructure, sécurité, ... </li></ul></ul><ul><ul><li>&quot;compatible Kanban&quot; </li></ul></ul><ul>DevOps : alternative ? </ul>
    • 122. <ul>Outillage </ul><ul>CheckStyle </ul><ul>Hudson </ul>
    • 123. <ul><ul><li>Préambule
    • 124. Théorie
    • 125. Pratiques
    • 126. Méthodes
    • 127. Concrètement </li></ul></ul><ul><ul><li>Plus de concret ! </li></ul></ul><ul><ul><li>Conclusion
    • 128. Informations diverses
    • 129. Annexes </li></ul></ul>
    • 130. <ul>Retours d’expériences </ul><ul>Trop cher </ul><ul><ul><li>admettons à court terme, mais beaucoup plus rentable (investissement)
    • 131. non à moyen/long terme, suivi du ROI régulièrement (pour s’arrêter à temps) </li></ul></ul><ul>“ Scrum (ou l'agilité) ne fonctionne pas ou n’a pas fonctionné dans mon contexte” </ul><ul><ul><li>la méthode est-il bien utilisée ? dur au départ, mais ensuite on s'améliore </li></ul></ul><ul>Exemples d’indicateurs : </ul><ul><ul><li>est-ce que PO et CP parlent de leurs problèmes aux stand up ?
    • 132. est-ce que l’estimation du RAF est collégiale ?
    • 133. est-ce que les rétrospectives identifient des actions d’amélioration pour d’autres personnes que les développeurs ? </li></ul></ul><ul>DSI Boiron qui témoigne : comment faire sans l’agilité ?      est-ce qu’il y a mieux ? </ul>
    • 134. <ul>Exemple de mise en oeuvre </ul><ul>La DSI des laboratoires Boiron a introduit en 2007 les méthodes agiles </ul><ul><ul><li>Pour les projets de refonte du Système d’information sur la base d’architectures contemporaines (JEE, ESB, MDM, etc.) </li></ul></ul><ul><ul><li>Intérêts : </li></ul></ul><ul><ul><ul><li>introduire des demandes d’évolutions en cours de projet
    • 135. faciliter l’acceptation des nouvelles solutions informatiques par les utilisateurs finaux </li></ul></ul></ul><ul><ul><li>Premier « vrai » déploiement sur un des plus gros projets de la DSI </li></ul></ul><ul><ul><ul><li>ARPEGE : 8700 jours </li></ul></ul></ul><ul><ul><li>Agilité chez BOIRON ? </li></ul></ul><ul><ul><ul><li>Un mix d’UP, XP et de Scrum / Kanban
    • 136. Le tout mélangé avec de la teinture mère d’Arnica Montana ! </li></ul></ul></ul>
    • 137. <ul>Pratiques et outillages &quot;agiles&quot; </ul><ul>Processus itératif et incrémental Recette Utilisateur à chaque fin d’itération Stand-up quotidien / Tableau post-it Gestion des exigences Développement par les tests (JUNIT, DBUNIT, Mockito) Refactoring régulier (par les patterns) Bug Tracker (JIRA) Intégration Continue (Maven 2, Jenkins, Nexus) </ul>
    • 138. <ul>Exemple de mise en oeuvre </ul><ul>Des itérations d’un mois calendaire Mais cela peut varier en fonction des phases du projet       Un sprint est à durée fixe en Scrum        Kanban Des recettes utilisateurs à chaque fin d’itération En période pré-production : recette toutes les 2 / 3 semaines Recette Utilisateur ARPEGE – Boiron Janvier 2010 </ul>
    • 139. <ul>Une itération </ul>
    • 140. <ul>Backlog de produit  </ul><ul>Les exigences, les activités </ul><ul><ul><li>En UP : Use Case (Boiron)
    • 141. En XP : User stories </li></ul></ul><ul>Une entrée du backlog de produit est un Use Case UML (inspiré d’UP) </ul><ul><ul><li>Un Use Case peut se dérouler sur 1 ou 2 itérations </li></ul></ul><ul>                  en Scrum                 en Kanban Leurs priorités sont revues à chaque itération </ul><ul><ul><li>Définies par le Product Owner
    • 142. Mais également par le reste de l’équipe (différent de Scrum) </li></ul></ul>
    • 143. <ul>Exemple de backlog Boiron </ul><ul>A chaque Use Case sont associées deux attributs : </ul><ul><ul><li>Une estimation en points arbitraires (on ne parle pas encore de jours)
    • 144. Et une priorité (métier, risque technique identifié) </li></ul></ul><ul>La liste peut évoluer au cours du projet, suite aux recettes utilisateur en fin d’itération Perfectible : chiffrage initial </ul>
    • 145. <ul>Exemple de mise en oeuvre </ul><ul>Comment planifier une itération ? </ul>
    • 146. <ul>Exemple de mise en oeuvre </ul><ul>Vie du backlog de l’itération L'estimation du reste à faire est ajustée tous les jours (Stand-up / JIRA) </ul><ul><ul><li>Mise à jour du travail restant quand il est mieux connu </li></ul></ul><ul>N'importe qui peut ajouter, supprimer, changer la liste des tâches en stand-up Si un travail n'est pas clair, définir une tâche avec plus de temps et la décomposer après </ul><ul>Changement en cours d’itérations </ul><ul>Estimation du reste à faire </ul><ul>Scrum </ul><ul>Utilisation de Burndown Charts avec mise à jour quotidienne </ul><ul>Boiron </ul><ul>(comme Kanban) </ul><ul>Utilisation de JIRA (quotidien) + AUGEO (semaine/mois) </ul>
    • 147. <ul><ul><li>Préambule
    • 148. Théorie
    • 149. Pratiques
    • 150. Méthodes
    • 151. Concrètement
    • 152. Plus de concret ! </li></ul></ul><ul><ul><li>Conclusion </li></ul></ul><ul><ul><li>Informations diverses
    • 153. Annexes </li></ul></ul>
    • 154. <ul>Les méthodes agiles, pas 1 miracle! </ul>
    • 155. <ul>Conclusion </ul><ul>Les méthodes agiles ne sont pas la formule magique pour réussir un projet !   C'est une révolution de la communication entre les personnes   Comment réussir à mettre en place un processus agile ? </ul><ul><ul><li>Les personnes de l’équipe doivent s’approprier la méthode. Mieux que de l’imposer !
    • 156. Appliquer les pratiques agiles qui semblent  pragmatiques et adaptées à votre contexte </li></ul></ul><ul>  </ul><ul>« Ne pas développer de dépendance spécifique à une arme ou à une école de combat » </ul><ul>Miyamoto Musachi, Samouraï du XVIIième siècle </ul>
    • 157. <ul><ul><li>Préambule
    • 158. Théorie
    • 159. Pratiques
    • 160. Méthodes
    • 161. Concrètement
    • 162. Plus de concret !
    • 163. Conclusion </li></ul></ul><ul><ul><li>Informations diverses </li></ul></ul><ul><ul><li>Annexes </li></ul></ul>
    • 164. <ul>Liens </ul><ul>Conférences : CARA Lyon, SUG, Scrum Days, Mix-IT, ALE, SoftShake, Agile Grenoble, Agile Tour, Agile France, Devops, XP Days, Agile Open Days </ul><ul>http://www.agileforall.com : tous les projets peuvent adopter au moins quelques pratiques agiles, ce qui les rendrait meilleurs. </ul><ul>http://www.agilealliance.org/ </ul><ul>http://referentiel.institut-agile.fr/  : 1 fiche par pratique Agile ! </ul><ul>Club Agile Rhône-Alpes :  http://www.clubagilerhonealpes.org/ </ul>
    • 165. <ul>Ken Schwaber 3 livres sur Scrum Agile and Iterative Development : A Manager’s Guide de Craig Larman   Agile Estimating and Planning de Mike Cohn   Agile Retrospectives d'Esther Derby et Diana Larsen   Agile Software Development Ecosystems de Jim Highsmith Des articles chaque semaine sur  http://www.scrumalliance.org/ </ul><ul>Bibliographie </ul>
    • 166.  
    • 167.  
    • 168. <ul><ul><li>Préambule
    • 169. Théorie
    • 170. Pratiques
    • 171. Méthodes
    • 172. Concrètement
    • 173. Plus de concret !
    • 174. Conclusion
    • 175. Informations diverses </li></ul></ul><ul><ul><li>Annexes </li></ul></ul>
    • 176.  
    • 177. <ul>Annexes </ul><ul>Attention aux enquêtes et à leurs interprétations... Enquête de http://drdobbs.com en 2007, avec les critères ordonnés suivants : Quality, Scope, Staff, Time, Money </ul>
    • 178. <ul>Annexes </ul>
    • 179. <ul>Annexes </ul>
    • 180. <ul>Source </ul><ul>Certains Slides (Scrum) sont issus d’une présentation de Mike Cohn sous license libre http://www.mountaingoatsoftware.com/ </ul>

    ×