11. Préambule
Chacun sa vision des choses!
De plus 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…
Existe t’il une méthode de gestion de projet qui prend en
compte ces problématiques?
12. Besoin d’une rupture sur les méthodes
de gestion de projets
La méthode en cascade
On travaille l'un après l'autre : la moindre erreur coûte cher
13. Besoin d’une rupture
Le cycle en V
On ajoute à la cascade de l'anticipation et du travail simultané
14. 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
15. 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 !
17. Les 4 valeurs de l’Agilité
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
18. Les 12 principes du Manifeste Agile
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).
19. 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)
20. 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.
21. 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).
23. 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, ...
24. 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
26. 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 !
28. Scrum en quelques mots
Scrum est un processus agile qui permet de produire la plus
grande valeur métier dans la durée la plus courte
Du logiciel qui fonctionne est produit à chaque « sprint » (2 à 4
semaines) = timebox
Le métier définit les priorités. L'équipe s'organise elle-même
pour déterminer la meilleure façon de produire les exigences
les plus prioritaires
A chaque fin de sprint : release déployable et testable par les
utilisateurs finaux
Deux rôles importants dans l’équipe Scrum : Product Owner et
Scrum Master
30. Product Owner (PO)
Définit les fonctionnalités du produit
Définit les priorités dans le backlog en
fonction de la valeur « métier »
Ajuste les fonctionnalités et les
priorités à chaque itération si
nécessaire
Teste les releases
Accepte ou rejette les résultats
Scrum Master (SM)
Vulgarise les valeurs et les pratiques
de Scrum
Contribue à améliorer les outils et les
pratiques de l’ingénierie
Facilite une coopération poussée
entre tous les rôles et fonctions
Protège l'équipe des interférences
extérieures
Met l’accent sur la créativité et la
gestion autonome des membres
31. Scrum
Temps fixe des itérations, itération de refactoring, visibilité sur
1 ou 2 itérations
Attention d'éviter les goulots d'étranglement (spécs d'avance)
Présence PO : spécification, développement, recette
32. Scrum : stand up (daily meeting)
3 questions :
●qu'avez-vous fait hier ?
●qu'allez-vous faire aujourd'hui ?
●qu'est-ce qui bloque l'avancement ?
Tout le monde parle
●pas uniquement les développeurs
Time-boxing
●pas uniquement aux stand-up
34. XP (eXtreme Programming)
Adaptée aux équipes réduites avec des besoins changeants
But principal : réduire les coûts du changement
Valeurs : communication, simplicité, feedback, courage, respect
Pratiques : planning poker, TDD et intégration continue, refactoring,
programmation en binôme, n'optimiser qu'à la toute fin
35. Lean
TPS (Toyota Production System) : baptisé Lean par le MIT en 1980
Le Lean c'est l'élimination des pertes, c-a-d du travail qui n'apporte aucune
valeur métier à un produit ou à un service.
D'abord présent dans l'industrie, la santé, les services, etc...
Lean Software Development : le Lean dans le développement logiciel
Lean IT : application du Lean aux systèmes d'information
Lean Startup : application du Lean au modèle d'entreprise
Objectif : Générer la valeur ajoutée maximale au moindre coût et au plus vite.
C’est donc bien une méthode agile !
Parfait pour la gouvernance, mais pas uniquement
36. Dimensionner et maîtriser les stocks
Simplifier visuellement le suivi et la planification
Parfait pour une TMA, mais pas uniquement
38. Côté technique
Qualité et industrialisation
● TDD, Intégration/déploiement continue, refactoring
● 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).
● 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)
● Refactoring : sessions de Code Retreat (cf http://coderetreat.org/)
● Devops (collaboration entre Développements et Opérations)
● Cloud (service externalisé)
40. 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
42. Certains efforts sont demandés
L'équipe doit faire preuve de courage, honnêteté,
transparence, visibilité, engagement, respect...
Valeurs pas toujours faciles à partager:
Responsabilité collective de la réussite du projet
Ouvert au changement
On a hélas parfois tendance :
à ne s'occuper que de son propre terrain
à ne pas s'impliquer dans les problèmes
de son voisin pour l'aider à les résoudre
S'améliorer c'est d'abord sortir de sa zone de confort !
43. Certains efforts sont demandés
Collaboration active et impliquée du client, de l'utilisateur
Le client : "Pourquoi je dois m'impliquer?"
"Ce que je veux est pourtant simple !"
Lâcher-prise du manager
Préférer un management horizontal !
Moins de hiérarchie marquée !
Le rôle du manager est fortement
remis en cause !
44. Attention aux dérives
Le daily meeting n’est pas du flicage : il s’agit de
piloter les risques en identifiant les blocages
quotidiens
La vélocité n’est pas un engagement de
productivité : elle sert à estimer le périmètre
réalisable dans la prochaine itération
Le sprint burndown chart n’est pas un indicateur
de productivité : il permet de visualiser le reste à
faire sur le périmètre initial de l’itération en
cours
45. Quelques clés de réussite
Proximité (même bureau ou workspace, offshore compliqué)
Qualités humaines : collaboration, motivation, remise en cause,
reconnaissance de la valeur d’autrui
Forte IHM plutôt que batchs techniques et contraints
Innovation, exploration des besoins
Nouveaux développements ou refonte d’applications
existantes, plutôt que dans l’embarqué
47. Voir vidéo d'Agnès Crépet et Cyril Lacôte - 30 minutes
Retour d'expérience sur l'agilité chez Boiron
http://clacote.free.fr/
Interviews : DSI - Product Owner - CP - Développeurs, etc.
48. Exemple de mise en oeuvre
La DSI des laboratoires Boiron introduit en 2008 les méthodes agiles
Pour les projets de refonte du Système d’information sur la base d’
architectures contemporaines (JEE, ESB, MDM, etc.)
Intérêts :
introduire des demandes d’évolutions en cours de projet
faciliter l’acceptation des nouvelles solutions informatiques par les
utilisateurs finaux
Premier « vrai » déploiement sur un projets critique (10.000 jours)
Agilité chez BOIRON ?
Un mix d’UP, XP et de Scrum / Kanban
49. Pratiques et outillages "agiles"
Processus itératif et incrémental
Recette Utilisateur à chaque fin d’itération
Stand-up quotidien / Tableau post-it
Gestion des exigences
Développement par les tests (JUNIT, DBUNIT, Mockito)
Refactoring régulier (par les patterns)
Bug Tracker (JIRA)
Intégration Continue (Maven, Jenkins, Nexus)
50. Agilité, modélisation et UML
La modélisation agile peut-elle exister ?
L'agilité se passe généralement de documentations volumineuses
et de plus en plus d'UML
Mais Boiron a décidé néanmoins de garder UMl
Traçabilité des exigences
Analyse d'impact d’un changement
Contrainte de validation pharmaceutique
Communication inter et intra équipe
Stratégie Boiron pour pour la modélisation:
Pas trop de doc
Un peu d'UML
Voir :
http://www.slideshare.net/agnes_crepet/modelisation-agile-03122011
51. Exemple de mise en oeuvre
Des itérations d’un mois calendaire
Mais cela peut varier en fonction des phases du projet
Un sprint est à durée fixe en Scrum
Kanban
Des recettes utilisateurs
à chaque fin d’itération
En période pré-production :
recette toutes les 2 / 3 semaines
Photo : Recette Utilisateur
Boiron Janvier 2010
53. Backlog de produit
Les exigences, les activités
En UP : Use Case (Boiron)
En XP : User stories
Une entrée du backlog de produit est un Use Case UML
(inspiré d’UP)
Un Use Case peut se dérouler sur 1 ou 2 itérations
en Scrum en Kanban
Leurs priorités sont revues à chaque itération
Définies par le Product Owner
Mais également par le reste de l’équipe (différent de
Scrum)
55. Exemple de mise en oeuvre
Vie du backlog de l’itération
L'estimation du reste à faire est ajustée tous les
jours (Stand-up / JIRA)
Mise à jour du travail restant quand il est mieux
connu
N'importe qui peut ajouter, supprimer, changer la liste des tâches en stand-up
Si un travail n'est pas clair, définir une tâche avec plus de temps et la
décomposer après
Changement en cours d’itérations Estimation du reste à faire
Scrum Utilisation de Burndown Charts
avec mise à jour quotidienne
Boiron
(comme Kanban) Utilisation de JIRA (quotidien)
58. Conclusion
Les méthodes agiles ne sont pas la formule magique pour
réussir un projet !
C'est une révolution de la communication entre les personnes
Comment réussir à mettre en place un processus agile ?
●Les personnes de l’équipe doivent s’approprier la méthode.
Mieux que de l’imposer !
●Appliquer les pratiques agiles qui semblent pragmatiques et
adaptées à votre contexte
« Ne pas développer de dépendance spécifique à une arme ou
à une école de combat »
Miyamoto Musachi, Samouraï du XVIIième siècle
60. Vous voulez aller plus loin
Aller au CARA!
En plus leurs réunions sont
sur le campus de la DOUA
http://lyon.clubagilerhonealpes.org/
D’autres conférences : Scrum Days, Mix-IT, ALE, SoftShake, Agile Grenoble,
Agile Tour, Agile France, XP Days, Agile Open Days, ...
62. Ressources
http://www.agileforall.com : tous les projets peuvent adopter au moins quelques
pratiques agiles, ce qui les rendrait meilleurs.
http://www.agilealliance.org/
Présentations de Claude Aubry (voir son Introduction à l'Agilité pour l'Inra) :
http://www.aubryconseil.com/media
http://www.extremeprogramming.org
Le site de référence XP, qui propose une excellente présentation de la
méthode
http://www.xprogramming.com
site XP de Ron Jeffries. Articles très intéressants sur la méthode (rubrique "XP
Magazine"), ainsi qu'une liste des frameworks xUnit disponibles pour divers
langages ("XP downloads").
http://www.xp123.com
site de William Wake. Nombreux articles sur les pratiques concrètes de XP (les
tests unitaires avec Java, le Planning Game, etc).
63. Ressources
http://institut-agile.fr/
Le site de l'institut agile (Laurent Bossavit)
et son référentiel : http://referentiel.institut-agile.fr/
http://henrik-kniberg.developpez.com/livre/scrum-xp/
"Scrum et XP depuis les Tranchées"
Comment nous appliquons Scrum
http://www.clubagilerhonealpes.org/blogs
Des blogs d'agilistes!
http://lyon.clubagilerhonealpes.org/
Groupe Lyonnais du Club Agile Rhône-Alpes
64. Bibliographie
L'Extreme Programming (avec deux études de cas),
Jean-Louis Bénard, Laurent Bossavit, Régis Medina,
Dominic Williams, chez Eyrolles, 2002.
Extreme Programming Explained : Embrace Change,
Kent Beck,
Addison-Wesley, 1999.
Extreme Programming Installed,
Ron Jeffries, Ann Anderson et Chet Hendrickson,
Addison-Wesley, 2000.
Planning Extreme Programming,
Ron Jeffries, Ann Anderson et Chet Hendrickson,
Addison-Wesley, 2000.
Refactoring : Improving the Design of Existing Code,
Martin. Fowler,
Addison-Wesley, 1999
65. Ken Schwaber
3 livres sur Scrum
Agile and Iterative Development :
A Manager’s Guide de Craig Larman
Agile Estimating and
Planning de Mike Cohn
Agile Retrospectives
d'Esther Derby et Diana Larsen
Agile Software Development
Ecosystems de Jim Highsmith
Des articles chaque semaine sur http://www.scrumalliance.org/
Bibliographie
