Introduction à l'agilité iut lyon 1 sept2013

Introduction à l'agilité

IUT Lyon 1 - septembre 2013

@agnes_crepet @AlfredAlmendra

Alfred [email protected]@gmail.com Freelance Scrum Master Coach agile Architecte Java/SOA CARA Lyon

Agnès Crépet@[email protected] Java/JEE Architecte & Java Champion Laboratoires Boiron Ninja Squad Java User Groups Leader: Duchess France & LyonJUG Co-fondatrice de la conférence MIX-IT (Java, Agilité...)

Mais vous faites un métier formidable!

Une chance : la richesse des communautés!

Une chance : la richesse des communautés!

Sommaire

●Préambule●Théorie●Pratiques●Méthodes●Concrètement●Plus de concret !●Conclusion●Informations diverses●Annexes

●Préambule●Théorie●Pratiques●Méthodes●Concrètement●Plus de concret !●Conclusion●Informations diverses●Annexes

Préambule

Spinning Dancer (Nobuyuki Kayahara, web designer)

La gestion de projet classique (prédictive)

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?

Besoin d’une rupture sur les méthodes de gestion de projets

La méthode en cascadeOn travaille l'un après l'autre : la moindre erreur coûte cher

Besoin d’une rupture

Le cycle en VOn ajoute à la cascade de l'anticipation et du travail simultané

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

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 !

●Préambule●Théorie●Pratiques●Méthodes●Concrètement●Plus de concret !●Conclusion●Informations diverses●Annexes

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-êtreC'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

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).

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)

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.

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).

●Préambule●Théorie●Pratiques●Méthodes●Concrètement●Plus de concret !●Conclusion●Informations diverses●Annexes

Itératif, incrémental, adaptatif

Monalisa selon Jeff Patton

On diminue considérablement le risque d’effet tunnelDans chaque itération : mini cycle en V, XP, Kanban, ...

Itératif, incrémental, adaptatifEt l’adaptatif...Les besoins se précisent voire évoluent continuellementPendant le projet, même quand on croit toucher au but

●Préambule●Théorie●Pratiques●Méthodes●Concrètement●Plus de concret !●Conclusion●Informations diverses●Annexes

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 !

Rapide historique

Certains principes existent depuis longtemps

IHM révolutionnée par Internet depuis 2000 !

Scrum en quelques motsScrum 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

ScrumL'équipe, les rôles, l'organisation

Métaphores● BTP : CP, architecte, MOA, MOE

○ Contrôle, prédictif● Rugby : SM, PO, TM

○ Lâché prise, créativité

Stakeholder : parties prenantesChicken and pig

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

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

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

Scrum : vélocité, burndown chart

Inputs : mou et rythme soutenable

XP (eXtreme Programming)Adaptée aux équipes réduites avec des besoins changeantsBut principal : réduire les coûts du changementValeurs : communication, simplicité, feedback, courage, respect

Pratiques : planning poker, TDD et intégration continue, refactoring, programmation en binôme, n'optimiser qu'à la toute fin

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 logicielLean IT : application du Lean aux systèmes d'informationLean 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

Dimensionner et maîtriser les stocksSimplifier visuellement le suivi et la planificationParfait pour une TMA, mais pas uniquement

●Préambule●Théorie●Pratiques●Méthodes●Concrètement●Plus de concret !●Conclusion●Informations diverses●Annexes

Côté techniqueQualité 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é)

Outillage

CheckStyle

Hudson

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 fonctionnelce 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

Des inconvénients?

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 projetOuvert 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 !

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 !

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

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 contraintsInnovation, exploration des besoins

Nouveaux développements ou refonte d’applications existantes, plutôt que dans l’embarqué

●Préambule●Théorie●Pratiques●Méthodes●Concrètement●Plus de concret !●Conclusion●Informations diverses●Annexes

Voir vidéo d'Agnès Crépet et Cyril Lacôte - 30 minutesRetour d'expérience sur l'agilité chez Boironhttp://clacote.free.fr/Interviews : DSI - Product Owner - CP - Développeurs, etc.

Exemple de mise en oeuvreLa 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

Pratiques et outillages "agiles"

Processus itératif et incrémentalRecette Utilisateur à chaque fin d’itérationStand-up quotidien / Tableau post-itGestion des exigencesDéveloppement par les tests (JUNIT, DBUNIT, Mockito)Refactoring régulier (par les patterns)Bug Tracker (JIRA)Intégration Continue (Maven, Jenkins, Nexus)

Agilité, modélisation et UMLLa 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 exigencesAnalyse d'impact d’un changementContrainte de validation pharmaceutiqueCommunication inter et intra équipe

Stratégie Boiron pour pour la modélisation:

Pas trop de docUn peu d'UML

Voir :http://www.slideshare.net/agnes_crepet/modelisation-agile-03122011

Exemple de mise en oeuvreDes 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 UtilisateurBoiron Janvier 2010

Une itération

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)

Exemple de mise en oeuvreComment planifier une itération ?

Exemple de mise en oeuvreVie 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 Chartsavec mise à jour quotidienne

Boiron(comme Kanban)

Utilisation de JIRA (quotidien)

●Préambule●Théorie●Pratiques●Méthodes●Concrètement●Plus de concret !●Conclusion●Informations diverses●Annexes

Les méthodes agiles, pas 1 miracle!

ConclusionLes 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

●Préambule●Théorie●Pratiques●Méthodes●Concrètement●Plus de concret !●Conclusion●Informations diverses●Annexes

Vous voulez aller plus loin

Aller au CARA!En plus leurs réunions sontsur le campus de la DOUAhttp://lyon.clubagilerhonealpes.org/

D’autres conférences : Scrum Days, Mix-IT, ALE, SoftShake, Agile Grenoble, Agile Tour, Agile France, XP Days, Agile Open Days, ...

Prochaine soirée Agile le 1 octobre!

Ressourceshttp://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.orgLe site de référence XP, qui propose une excellente présentation de la méthode http://www.xprogramming.comsite 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.comsite de William Wake. Nombreux articles sur les pratiques concrètes de XP (les tests unitaires avec Java, le Planning Game, etc).

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/blogsDes blogs d'agilistes! http://lyon.clubagilerhonealpes.org/Groupe Lyonnais du Club Agile Rhône-Alpes

BibliographieL'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

Ken Schwaber3 livres sur Scrum

Agile and Iterative Development :A Manager’s Guide de Craig Larman Agile Estimating andPlanning de Mike Cohn Agile Retrospectivesd'Esther Derby et Diana Larsen Agile Software DevelopmentEcosystems de Jim Highsmith

Des articles chaque semaine sur http://www.scrumalliance.org/

Bibliographie

●Préambule●Théorie●Pratiques●Méthodes●Concrètement●Plus de concret !●Conclusion●Informations diverses●Annexes

Source

Certains Slides (Scrum) sont issus d’une présentation de Mike Cohn sous license libre

http://www.mountaingoatsoftware.com/