L'Agilité - breakfast IDC devops, 18 septembre 2014

L'Agilité - breakfast IDC devops, 18 septembre 2014
Vous avez dit « agile » ? 18 septembre 2014 -‐ Xavier Warzee Breakfast IDC « Devops »
Xavier Warzee • Web : http://www.scrumconseil.fr • Twitter : @xwarzee • LinkedIn : http://www.linkedin.com/in/xwarzee • Email : xwarzee@scrumconseil.fr
Pourquoi l’Agilité ?
POURQUOI L’AGILE AUJOURD’HUI ?
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%
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
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
Généraôn Y ou la soif de collaborer !
Un état d’esprit COMMENT PASSER À UNE POSTURE AGILE ?
Ac^vités séquenêlles vs. parallèles Exigences Concepôn 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...
Décider le plus tard possible Livraisons incrémentales Livraisons itéra@ves
Enjeux de l’agilité
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ôn 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 !
Amélioraôn con^nue -‐ Rétrospec^ves • Inspecter les résultats d’une itéraôn • Adapter les pra^ques en foncôn des objec^fs de la prochaine itéraôn, de la composiôn de l’équipe, … Figer des bonnes pra^ques ? Dangereux ! • Focus sur des tâches à faire • moins d’an^cipaôn sur l’impact de nos acôns !!! • 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ôn donnée Soluôn : Équipe auto-‐ organisée
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
Partager les valeurs du Manifeste Agile Personnes et Processus et ou^ls interacôns > Logiciel qui foncônne S'adapter au Suivre un plan changement > Source : www.agilemanifesto.org > Documentaôn Négociaôn à par^r d'un contrat Collaboraôn avec le client >
QUELLE APPROCHE AGILE ADOPTER ?
Kanban dans le logiciel Ø Workflow visuel – Limitaôn du TAF (Travail A FAIRE) – Flot mesuré et op^misé – Règles explicites (définiôn de ”Done”, TAF limités, etc) Introducôn 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
Scrum : la mêlée et les 3 piliers • La transparence – Honnêteté sur l'avancement et les problèmes – Une définiôn claire et partagée de « Done » • L'inspecôn – Tests fréquents de soluôns par le biais de feedback – Les feedback sont fournis par des vrais u^lisateurs et clients • L'adaptaôn – Finalisaôn du produit basée sur les feedback et les buts à aleindre – Ajustement du process de Scrum dès que nécessaire
Lean startup & Agilité Palo IT 2012 ©
La démarche « Lean Startup » Palo IT 2012 © Idées Développer Apprendre / Améliorer Mesurer Données Produit
DEVOPS
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
Références • Organisaôns : – 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

Check these out next

L'Agilité - breakfast IDC devops, 18 septembre 2014

Recommandé

Contenu connexe

Présentations pour vous(20)

En vedette(20)

Similaire à L'Agilité - breakfast IDC devops, 18 septembre 2014(20)

Plus de Xavier Warzee(20)

Dernier(20)

L'Agilité - breakfast IDC devops, 18 septembre 2014