Le document présente une introduction à l'agilité, soulignant l'importance de la collaboration, de la flexibilité et de l'adaptation aux changements tout au long d'un projet. Il décrit les valeurs et principes du manifeste agile, ainsi que diverses méthodes telles que Scrum, XP, et Lean, qui visent à améliorer l'efficacité et la qualité du développement logiciel. Enfin, il aborde des clés de réussite pour la mise en œuvre de l'agilité, notamment l'importance du soutien des décideurs et de la participation active des métiers.

1. Introduction à l'agilité IUT Lyon 1 - décembre 2011 @agnes_crepet @AlfredAlmendra

2. Qui sommes-nous? Alfred Almendra Coach agile Architecte SOA CARA Lyon 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é...)

3. Sommaire Préambule

4. Théorie

5. Pratiques

6. Méthodes

7. Concrètement

8. Plus de concret !

9. Conclusion

10. Informations diverses

11. Annexes

12. Préambule Théorie

13. Pratiques

14. Méthodes

15. Concrètement

16. Plus de concret !

17. Conclusion

18. Informations diverses

19. Annexes

20. Préambule Spinning Dancer (Nobuyuki Kayahara, web designer)

21. Préambule Notre cerveau est bogué ! ...mais nous sommes maintenant avertis ! Psychologie cognitive : les (nombreux) biais du cerveau Ancrage Confirmation d'hypothèse Conformisme Dunning-Kruger Halo Dissonance cognitive Perception sélective ...

22. Préambule Personne n’est parfait = tout le monde est imparfait On peut se tromper, mais on doit s’améliorer L’erreur peut venir du développeur, mais pas uniquement. Tous les acteurs du projet peuvent se tromper ... @Morendil Responsable de l' institut-agile.fr "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, …)" (Mix-IT 2011) "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." (Responsable métier chez Boiron)

24. Préambule Les besoins métier évoluent dans le temps, même pendant la vie d'un projet On doit savoir et pouvoir s’adapter au changement... Vocabulaire pour la suite de la présentation : Equipe = tous les acteurs du projet pas uniquement les développeurs REX = retour d'expérience

25. Besoin d’une rupture La méthode en cascade On travaille l'un après l'autre : la moindre erreur coûte cher

26. Besoin d’une rupture Le cycle en V On ajoute à la cascade de l'anticipation et du travail simultané

27. Besoin d’une rupture Organisation contrainte et peu adaptée à l'inconnu... ...l'innovation, la découverte, l'incertitude, l'amélioration continue Ces méthodes prédictives répondent à certains contextes... ...mais pas à tous

28. Besoin d’une rupture Constat : encore à notre époque, les projets informatiques ne finissent pas souvent comme on le souhaite... Nous souhaitons tous améliorer ces chiffres !

29. Rapide historique Certains principes existent depuis longtemps IHM révolutionnée par Internet depuis 2000 !

30. Préambule Théorie Pratiques

31. Méthodes

32. Concrètement

33. Plus de concret !

34. Conclusion

35. Informations diverses

36. Annexes

37. Les 4 valeurs 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

38. Les 12 principes Autour de l’application et de la valeur fonctionnelle : 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).

39. Les 12 principes Concernant l’acception du changement : 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) Concernant le client : 4. Les “gens de l’art” (i.e. métier) et les développeurs doivent collaborer quotidiennement au projet (cf. XP)

40. Les 12 principes Autour de l’équipe et de l’organisation : 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.

41. Les 12 principes Concernant la qualité (“5ème valeur !?” ou plutôt savoir-faire, art) 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).

42. 4 valeurs et 12 principes

43. Préambule

44. Théorie Pratiques Méthodes

45. Concrètement

46. Plus de concret !

47. Conclusion

48. Informations diverses

49. Annexes

50. Itératif, incrémental, adaptatif Monalisa selon Jeff Patton On diminue considérablement le risque d’effet tunnel Dans chaque itération : mini cycle en V, XP, Kanban, ...

51. Itératif, incrémental, adaptatif Et l’adaptatif... Les besoins se précisent voire évoluent continuellement Pendant le projet, même quand on croit toucher au but

52. Itératif, incrémental, adaptatif 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)

53. Les jeux 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 Exemples de valeurs et objectifs : auto organisation, communication, collaboration, productivité, ... Alexandre Boutin (@agilex) président du CARA Bientôt un agile game en France ? en 2012 ? Agile Games à Boston, Agile4Play en Allemagne

54. Les jeux et les étapes du projet Extrait du calendrier du CARA Lyon (OUI, c'est de la PUB !)

55. Auto-organisation et travail collaboratif 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 Rôles figés (CP, Architecte, ...) Réunions stériles Les docs à rallonge (mails, CR) Entreprise gérée en mode Open Space (ut7 AgileInnovation 2011) Ateliers Open Space Rétrospective personnelle synthétique

56. La marge de manoeuvre Renoncer à des fonctionnalités pour tenir les délais : oui et non Ne pas réaliser des fonctionnalités non rentables c’est gagner du temps, de l’argent et de l’énergie. Tout projet, agile ou non, possède 4 leviers dépendants de ses contraintes et objectifs : les fonctionnalités

57. le coût

58. le délai

59. les ressources

60. Côté organisationnel Pilotage par les risques la réussite n’est pas garantie, mais l’éventuel échec est découvert plus tôt Visibilité oui sur l’avancement vers l’objectif

61. non dans le détail (exploration, challenge, adaptation) Ordonnancement (plutôt que priorisation, cf. Scrum été 2011) Indicateurs qualitatifs : satisfaction, image, analyse de la valeur (AFAV.eu)

62. quantitatifs : taux d'utilisation, valeur ajoutée progressive, ROI Contrats de sous-traitance : à essayer ! Ex : http://contrat-agile.org/ (Xebia, Cellenza, Alerion, LCA) Offshore : complexe, peu de réussites notables

63. L'oignon agile De l'agilité à tous les étages !

64. Côté fonctionnel métier Identifier la valeur ajoutée : l'utilisabilité "Si j’avais demandé aux gens ce qu'ils voulaient, ils m’auraient réclamé un meilleur cheval." [Henry Ford] En pratique : fréquence/usage/volumétrie "L’ergonomie est au fonctionnel ce que l’agilité est à l’organisationnel" Ergonomie, User eXperience (UX), interaction design (IxD) ...découverte, tentatives, affinage du besoin Faire tester souvent les utilisateurs ...questionner, observer, inviter à verbaliser les tâches

65. Côté technique Qualité et industrialisation TDD, PIC, refactoring, déploiement continu

66. Pair programming, revues de code, … TDD = Test Driven Development (Test First !) 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). Force de proposition collaboration + capitalisation + motivation Tendances 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é)

71. Agilité et UML Comment documenter / modéliser un besoin ? 2 approches semblent opposées : l'approche Model-Driven (OMG) modélisation UML très poussée

72. génération automatique de code l'approche agile production rapide de code opérationnel (mieux que la doc)

73. minimiser la modélisation en amont

74. Agilité et UML 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 : Traçabilité des exigences

75. Analyse d'impact d’un changement

76. Contrainte de validation pharmaceutique

77. Communication inter et intra équipe Stratégie Boiron pour pour la modélisation: Pas trop de doc

78. Un peu d'UML

79. Préambule

80. Théorie

81. Pratiques Méthodes Concrètement

82. Plus de concret !

83. Conclusion

84. Informations diverses

85. Annexes

86. Survol des principales méthodes 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 PUMA (sur rad.fr) : Proposition pour l'Unification des Méthodes Agiles http://institut-agile.fr/ : plus de 60 pratiques agiles en ligne !

87. Barry Boehm article A Spiral Model of Software Development and Enhancement (1986)