Histoire d'un chef de projet qui adopte l'agilité

Histoire d'un chef de projet qui adopte l'agilité, conférence donnée au Project Management Institute (PMI), chapitre Auvergne,

Transcript

1. AGILITE : HISTOIRE D’UN CHEF DE PROJET QUI ADOPTE L’AGILITE PMI - Auvergne
2. Personnages Jacques Le directeur des études de l'entreprise Y Paul Un chef de projet informatique de l'entreprise Y Nicolas Un scrum master au sein de l’entreprise Z, ami de Paul Pierre Un coach agile L’équipe Les membres de l’équipe du projet X La communauté Les chefs de projet de l’entreprise Y
3. DANS LE BUREAU DE JACQUES
5. Mon rêve pour l’avenir L’IT et les équipes métier travaillent main dans la main Le processus de développement autorise une quantité raisonnable de changements Les meilleures décisions sont prises, les conceptions les plus simples sont adoptées. Mes projets me rapportent un bénéfice plus tôt.
6. 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Améliorer la qualité Intégrer les changements Motiver les équipes de développement Accélérer le time to market Réduire les risques Motif du recours à l'agilité French Scrum User Group 2011
7. Moins de 1 ans; 34% Entre 1 ans et 3 ans; 38% Plus de 3 ans; 28% Ancienneté de l'adoption French Scrum User Group 2011
8. Ne sait pas; 18% A titre expérimental; 15% Sur un projet pilote stratégique; 26% En cours de généralisation; 22% Généralisée; 19% Profondeur de l'adoption French Scrum User Group 2011
9. 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Amélioration de la qualité Satisfaction des utilisateurs Augmenter la productivité Respect des délais Fréquence des mises en production Respect des budgets Impact constaté de l'adoption de l'agilité French Scrum User Group 2009 Ne sait pas Dégradation Pas de changement Légère amélioration Amélioration sensible
10. SUR LE WEB
11. Manifeste pour le développement Agile de logiciels 2001 Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser : Les individus et leurs interactions plus que les processus et les outils Des logiciels opérationnels plus qu’une documentation exhaustive La collaboration avec les clients plus que la négociation contractuelle L’adaptation au changement plus que le suivi d’un plan Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
12.  Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.  Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.  Un logiciel opérationnel est la principale mesure d’avancement.
13.  Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.  Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.  La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
14.  Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites- leur confiance pour atteindre les objectifs fixés.  Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
15.  Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.  La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.  Les meilleures architectures, spécifications et conceptions émergent d'équipes auto- organisées.  À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
16. AVEC NICOLAS, SUR LE PLATEAU DE SON PROJET
18. LES RÔLES DANS SCRUM http://emmanuelchenu.blogspot.com/
19. Sprint Planning Meeting Daily Meeting Démo Rétrospecti ve LES RITUELS & ARTEFACTS SCRUM
20. LES ACTIVITÉS DES ITÉRATIONS SE CHEVAUCHENT Itération N+1 Itération N -1 Itération N Construction Préparation des user stories Construction Préparation des user stories Construction Acceptance au fil de l’eau Correction des defects Version N-1 Acceptance au fil de l’eau Correction des defects Version N Version N+1
21. USER STORIES  En tant que responsable marketing  Je peux avoir une vue sur l’origine des connections au site  Afin de mieux cibler mes campagnes de publicité
22. DÉCOUPAGE EN USER STORIES Un découpage vertical, de bout en bout  I(ndependant)  N(egociable)  V(aluable)  E(stimatable)  S(mall)  T(estable) + Des user stories homogènes en terme de priorité
23. CRITÈRES D’ACCEPTANCE  Si je suis responsable marketing, j’ai accès à l’origine des connections (pays, entreprise, CSP)  Si je ne suis pas responsable marketing, je n’ai pas accès à cette information  Cette information est conservée par jour sur les 12 derniers mois, par semaine sur les 24 mois antérieurs, par mois ensuite  Je peux l’exporter sous excel
24. -20 30 80 130 180 230 280 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Reste à faire du Sprint Idéal Réel
25. -200 -100 0 100 200 300 400 Projections moyenne des 3 pires sprints moyennes des 3 dernièrs sprints moyenne des 3 meilleurs sprints Suppr - Ajouts
26. 0 20 40 60 80 100 120 1 2 3 4 5 6 7 8 Indicateurs d'avancement du projet % Story Points % Valeur métier
27. SUR LE PLATEAU DE SON PROJET, AVEC SON COACH
28. Qu'est-ce qui vous fait dire que votre projet marchera mieux s'il est fait en agile ?
29. Disons que l'on pense arriver à faire seulement les 2/3 de ce que vous demandez. Qu'est-ce que l'on fait et qu'est-ce que l'on ne fait pas ?
30. L'équipe ne doit pas ne parler qu’au Scrum Master mais se parler. Le Scrum Master n’affecte pas les tâches, l’équipe s’affecte les tâches.
31. Avec votre management visuel je n'y vois rien. Trop de tâches. Des tâches répétant toujours le même pattern, sans information spécifique.
32. Le burndown est plat, vous êtes clairement en retard par rapport à ce que vous aviez prévu en début de sprint. Qu'est-ce que vous faites ?
33. Indépendamment de ce que nous découvrons, nous comprenons et nous croyons sincèrement que chacun a fait du mieux qu'il pouvait, compte tenu de ce qu'il savait à l'époque, de ses compétences et de ses prérogatives, des ressources disponibles et de la situation du moment. (The Prime Directive, Norman Kerth)
34. Il ne se passe rien dans votre rétrospective, les problèmes racine ne sont pas évoqués, les tensions ne sont pas résolues.
35. On n’ajuste plus la qualité pour garantir le délai, le budget, le périmètre. On ajuste maintenant le périmètre pour garantir la qualité, le délai, le budget.
36. La confiance repose sur la transparence (annoncer les mauvaises nouvelles) et l'atteinte continuelle d'objectifs à court termes (annoncer les bonnes nouvelles)
37. LORS DE LA PRESENTATION DE SON RETOUR D’EXPERIENCE
38. POUR FAIRE ÉMERGER L’ÉQUIPE  Elle prend forme progressivement, au début on la guide beaucoup, ensuite elle devient autonome : s’effacer progressivement  Leadership pour animer en entrainant plutôt que « command and control »  Laisser trouver l’équipe, même si parfois cela semble plus lent.
39. QUAND L’ÉQUIPE A ÉMERGÉ  L’équipe est autonome  Responsable, prend les problèmes à bras le corps.  Prend des initiatives  Soudée, joue collectif.  Il suffit alors de lui rappeler les enjeux et les contraintes, elle s’optimise pour tenir ses engagements  Du coup j’ai senti une espèce de manque : à quoi je sers ?
40. A QUOI JE SERVAIS ?  J’ai protégé l’équipe des interventions extérieures.  J’ai protégé le périmètre de chaque itération.  Une fois les problèmes identifiés, j’ai facilité leur résolution par les uns et les autres.  J’ai notamment facilité les relations avec l’extérieur du projet et avec le management.  J’ai enfin impulsé de l’énergie dans la transformation agile de l’équipe (et son maintien)
41. ET PUIS LE MÉTIER…  La participation du métier n’est pas une conséquence de la méthode mais un pré-requis. Il faut donc l’impliquer, et c’est un effort continu. Participation au réunion, manipuler l’application au fil de l’eau, …  Heureusement, nous tenions nos engagement, et nous démontrions. La confiance est la clef de la participation du métier, et de la possibilité d’avoir des arbitrages sereins.  Et puis, si on « accepte le changement », on ne n’accepte pas tout tout le temps.
42. PAS DE TOUT REPOS  Amélioration continue veut dire changement continu.  Remise en question potentielle de tout (pas tout à la fois).  Toujours aller de l’avant.  Des idées parfois surprenantes.  Des divergences d’opinion, des conflits naissants à résoudre.
43. ET… Oui, ca marche !
44. POUR ALLER PLUS LOIN  Agile manifesto : http://agilemanifesto.org/iso/fr/  Scrum Guide : http://www.scrum.org/scrumguides/  Scrum : Le guide pratique de la méthode agile la plus populaire - 2ème édition – Claude Aubry. ISBN : 2100563203  Gestion de projet agile – Veronique Messager Rota. ISBN: 2212127502  Agile Project Management with Scrum - Ken Schwaber. ISBN:073561993X;  Lean Software Development: An Agile Toolkit for Software Development Managers - Mary Poppendieck, Tom Poppendieck. ISBN:0321150783  http://henrik-kniberg.developpez.com/livre/scrum-xp/  Référentiel Agile : http://referentiel.institut-agile.fr/index_type.html  http://www.aubryconseil.com/  http://www.qualitystreet.fr/
46. RETURN ON TIME INVESTED 1 doigt = J’ai complêtement perdu mon temps. 2 doigts = Un peu mieux que 1 doigt 3 doigts = Je n’ai pas perdu mon temps mais j’aurais fait aussi bien tout seul. 4 doigts = Un peu moins que 5 doigts 5 doigts = J’ai vraiment découvert et appris beaucoup de choses.
47. Objectifs : la promotion et la diffusion des méthodes agiles dans la région Rhône-Alpes par tous moyens de communication et d’intervention : conférence, séminaire, rencontre, accompagnement, consulting, formation. Scrum, Kanban, Lean http://www.clubagilerhonealpes.org
48. Chaque printemps à Lyon Chaque automne à Grenoble Des rendez-vous réguliers Agile Innovation une au printemps à Lyon et une à l’automne à Grenoble. http://www.clubagilerhonealpes.org
49. Des rendez-vous réguliers Et 1 session participative mensuelle à Lyon pour vous aider dans votre transition vers l'agilité • pratiquer l'agilité (pour tous les profils) • échanger sur les retours d'expériences http://www.clubagilerhonealpes.org
50. POUR POURSUIVRE  Email : pierre.fauvel@alcyonix.com  Twitter : pierre_fauvel  Blog : pierrefauvel.wordpress.com