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 : [email protected]
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% Dépassement 53% 33% 46% 49% 51% 53% 46% 44% Échec 31% 40% 28% 23% 15% 18% 19% 24%
0%
10%
20%
30%
40%
50%
60%
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
14%
57%
29%
2012 – Cycle en V
42%
49%
9%
2012 -‐ Agile
Succès
Hors délai ou budget Échec
Généra^on Y ou la soif de collaborer !
COMMENT PASSER À UNE POSTURE AGILE ?
Un état d’esprit
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...
Exigences Concep^on Code Test
Ac^vités séquen^elles vs. parallèles
Décider le plus tard possible
Palo IT 2012 © 16
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^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 !
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
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
Processus et ou^ls Personnes et interac^ons >
Suivre un plan S'adapter au changement >
Source : www.agilemanifesto.org
Documenta^on Logiciel qui fonc^onne >
Négocia^on à par^r d'un contrat
Collabora^on avec le client >
QUELLE APPROCHE AGILE ADOPTER ?
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
FLOW Avg lead time: days 12
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
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
Lean startup & Agilité
Palo IT 2012 ©
La démarche « Lean Startup »
Palo IT 2012 ©
Développer
Mesurer
Apprendre /Améliorer
Idées
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^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