L'Agilité - breakfast IDC devops, 18 septembre 2014

L'Agilité - breakfast IDC devops, 18 septembre 2014

• 1.
  Vous avez dit« agile » ? 18 septembre 2014 -­‐ Xavier Warzee Breakfast IDC « Devops »
• 2.
  Xavier Warzee •Web : http://www.scrumconseil.fr • Twitter : @xwarzee • LinkedIn : http://www.linkedin.com/in/xwarzee • Email : xwarzee@scrumconseil.fr
• 3.
  Pourquoi l’Agilité ?
• 4.
  POURQUOI L’AGILE AUJOURD’HUI ?
• 6.
  Etude « Chaos Report » du Standish Group 1994 1996 1998 2000 2002 2004 2006 2008 Succès 16% 27% 26% 28% 34% 29% 35% 32% 60% 50% 40% 30% 20% 10% Dépassement 53% 33% 46% 49% 51% 53% 46% 44% Échec 31% 40% 28% 23% 15% 18% 19% 24% 0%
• 7.
  Quelques chiffres… 18% 53% 29% Réussite des projets informa@ques Echec Hors délai ou budget Succès 7% 13% 16% 19% 45% Fonc@onnalités u@lisées dans les produits Fréquemment Souvent Parfois Rarement Jamais Source: Standish Group 2004
• 8.
  Constat en 2012 ! 16% 53% 31% 1994 2012 – Cycle en V 14% 57% 29% 2012 -­‐ Agile 42% 9% 49% Succès Hors délai ou budget Échec
• 12.
  Généra^on Y ou la soif de collaborer !
• 13.
  Un état d’esprit COMMENT PASSER À UNE POSTURE AGILE ?
• 15.
  Ac^vités séquen^elles vs. parallèles Exigences Concep^on Code Test Source : “The New New Product Development Game” par Takeuchi et Nonaka. Harvard Business Review, Janvier 1986. ...Les équipes agile font un peu de tout, tout le temps Plutôt que de faire toute une discipline d'un coup...
• 16.
  Décider le plus tard possible Livraisons incrémentales Livraisons itéra@ves
• 17.
  Enjeux de l’agilité
• 18.
  Critères de succès > agile vs classique Critères de succès classique : Aleindre l’état souhaité • Essayer de prévoir à chaque étape toutes les possibilités • Planifier dans les détails • Définir un processus prédic^f Critères de succès agile : Aleindre un bon niveau d’adapta^on au contexte • Considérer les changements dans un projet comme naturels • Inspecter, à chaque étape, l’état d’un projet et s’adapter • Pas de leaders, tout membre de l’équipe contribue ! • Facilitateurs, supporteurs plutôt qu’experts ou autorités !
• 19.
  Améliora^on con^nue -­‐ Rétrospec^ves • Inspecter les résultats d’une itéra^on • Adapter les pra^ques en fonc^on des objec^fs de la prochaine itéra^on, de la composi^on de l’équipe, … Figer des bonnes pra^ques ? Dangereux ! • Focus sur des tâches à faire • moins d’an^cipa^on sur l’impact de nos ac^ons !!! • Perte de vue globale Figer un processus ? Risqué ! • Demander aux équipes de développement de définir les pra^ques adaptées à une itéra^on donnée Solu^on : Équipe auto-­‐ organisée
• 20.
  L’Agilité > un changement de perspec^ve ! Approche Traditionnell e orientée plan Approche Agile orientée vision Fixes : Fonc@onnalités Coûts Délais Variables : Coûts Délais Fon@onnalités
• 21.
  Partager les valeurs du Manifeste Agile Personnes et Processus et ou^ls interac^ons > Logiciel qui fonc^onne S'adapter au Suivre un plan changement > Source : www.agilemanifesto.org > Documenta^on Négocia^on à par^r d'un contrat Collabora^on avec le client >
• 22.
  QUELLE APPROCHE AGILE ADOPTER ?
• 23.
  Kanban dans le logiciel Ø Workflow visuel – Limita^on du TAF (Travail A FAIRE) – Flot mesuré et op^misé – Règles explicites (défini^on de ”Done”, TAF limités, etc) Introduc^on par David Anderson en 2004 Backlog Dev Done orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur UAT Deploy 5 3 2 3 orem ipsum dolor sit amet, co nse ctetur FLOW Avg lead time:1 2 days orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur
• 24.
  Scrum : la mêlée et les 3 piliers • La transparence – Honnêteté sur l'avancement et les problèmes – Une défini^on claire et partagée de « Done » • L'inspec^on – Tests fréquents de solu^ons par le biais de feedback – Les feedback sont fournis par des vrais u^lisateurs et clients • L'adapta^on – Finalisa^on du produit basée sur les feedback et les buts à aleindre – Ajustement du process de Scrum dès que nécessaire
• 25.
  Lean startup & Agilité Palo IT 2012 ©
• 26.
  La démarche « Lean Startup » Palo IT 2012 © Idées Développer Apprendre / Améliorer Mesurer Données Produit
• 27.
  DEVOPS
• 28.
  L’agilité au niveau management Le travail est organisé en cycle court Le management n’interrompt pas l’équipe pendant un cycle L’équipe rend des comptes au client, pas au manager L’équipe es^mes le temps qu’il lui faut L’équipe décide du travail qu’elle peut faire en un cycle L’équipe décide comment faire le travail pendant un cycle L’équipe mesure ses propres performance Les objec^fs à aleindre sont définis avant le départ de chaque cycle Les objec^fs sont définis par des usages du produit : ‘user stories’ Chercher à systéma^quement lever les obstacles
• 29.
  Références • Organisa^ons : – L’Agile Alliance : hlp://www.agilealliance.org – La Scrum Alliance : hlp://www.scrumalliance.org – L’Ins^tut Agile : hlp://www.ins^tut-­‐agile.fr – Le French Scrum User Group : hlp://www.frenchsug.org • Conférences – Le Scrum Day : hlp://www.scrumday.fr – Agile France : hlp://www.conference-­‐agile.fr – Lean Kanban France : hlp://www.leankanban.fr – Agile Games France : hlp://www.agilegamesfrance.fr