SlideShare une entreprise Scribd logo
Introduction à l'agilité IUT Lyon 1 - décembre 2011 @agnes_crepet   @AlfredAlmendra
Qui sommes-nous? Alfred Almendra Coach agile Architecte SOA    CARA Lyon Agnès Crépet Java/JEE Architecte   Java User Groups Leader: Duchess France & LyonJUG    Fait partie de l'équipe organistrice de la conférence MIX-IT (Java, Agilité...)   Co-fondatrice du podcast Cast-IT (Java, Agilité...)
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)
Préambule Notre cerveau est bogué ! ...mais nous sommes maintenant avertis ! Psychologie cognitive : les (nombreux) biais du cerveau Ancrage Confirmation d'hypothèse Conformisme Dunning-Kruger Halo Dissonance cognitive Perception sélective ...
Préambule Personne n’est parfait = tout le monde est imparfait On peut se tromper, mais on doit s’améliorer L’erreur peut venir du développeur, mais pas uniquement. Tous les acteurs du projet peuvent se tromper ...  @Morendil Responsable de l' institut-agile.fr "Il n’existe pas de bug qui ne soit issu du cerveau humain. La conception c’est tout ce qui permet de prévenir ou contourner les bugs du cerveau (outil, méthode, design pattern, modélisation, schéma, doc, wiki, commentaire dans le code, …)"  (Mix-IT 2011) "Une erreur de spécification est une forme de bug. Un utilisateur, un décideur et un responsable métier ont aussi le droit de se tromper."  (Responsable métier chez Boiron)
 
Préambule 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... Vocabulaire pour la suite de la présentation : Equipe = tous les acteurs du projet                  pas uniquement les développeurs REX = retour d'expérience
Besoin d’une rupture La méthode en cascade On travaille l'un après l'autre : la moindre erreur coûte cher
Besoin d’une rupture Le cycle en V On 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 !
Rapide historique Certains principes existent depuis longtemps IHM révolutionnée par Internet depuis 2000 !
Préambule Théorie Pratiques
Méthodes
Concrètement
Plus de concret !
Conclusion
Informations diverses
Annexes
Les 4 valeurs 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
Les 12 principes 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).
4 valeurs et 12 principes
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 tunnel Dans chaque itération : mini cycle en V, XP, Kanban, ...
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
Itératif, incrémental, adaptatif Les besoins évoluent aussi après la mise en production (la maintenance est-elle un mythe ? une stagnation ?) Jean-François Jagodzinski @jfjago a remplacé le terme projet par processus de fabrication (cf. Kanban)
Les jeux Ludiques : donc participation volontaire et motivée Augmentent la créativité, la collaboration, le taux d'apprentissage Cadre et règles faciles à comprendre : donc focus sur l’objectif Exemples de valeurs et objectifs : auto organisation, communication, collaboration, productivité, ... Alexandre Boutin (@agilex) président du CARA Bientôt un agile game en France ? en 2012 ? Agile Games à Boston, Agile4Play en Allemagne
Les jeux et les étapes du projet Extrait du calendrier du CARA Lyon (OUI, c'est de la PUB !) 
Auto-organisation et travail collaboratif XP : Pair-P., TDD, work space Tests croisés, revues de code Daily meetings (stand up) Répartition et alternance des expertises, wiki, post-it, proximité user/dév Rôles figés (CP, Architecte, ...) Réunions stériles Les docs à rallonge (mails, CR) Entreprise gérée en mode Open Space (ut7 AgileInnovation 2011) Ateliers Open Space Rétrospective personnelle synthétique
La marge de manoeuvre Renoncer à des fonctionnalités pour tenir les délais : oui et non      Ne pas réaliser des fonctionnalités non rentables      c’est gagner du temps, de l’argent et de l’énergie. Tout projet, agile ou non, possède 4 leviers dépendants de ses contraintes et objectifs : les fonctionnalités
le coût
le délai
les ressources
Côté organisationnel Pilotage par les risques la réussite n’est pas garantie, mais l’éventuel échec est découvert plus tôt Visibilité oui sur l’avancement vers l’objectif
non dans le détail (exploration, challenge, adaptation) Ordonnancement (plutôt que priorisation, cf. Scrum été 2011) Indicateurs qualitatifs : satisfaction, image, analyse de la valeur (AFAV.eu)
quantitatifs : taux d'utilisation, valeur ajoutée progressive, ROI Contrats de sous-traitance : à essayer ! Ex :  http://contrat-agile.org/  (Xebia, Cellenza, Alerion, LCA) Offshore : complexe, peu de réussites notables
L'oignon agile De l'agilité à tous les étages !
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
Côté technique Qualité et industrialisation TDD, PIC, refactoring, déploiement continu
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 (c3f  http://coderetreat.org/ )
Devops (collaboration entre Développements et Opérations)
Cloud (service externalisé)
Agilité et UML Comment documenter / modéliser un besoin ?   2 approches semblent opposées :    l'approche Model-Driven (OMG) modélisation UML très poussée
génération automatique de code    l'approche agile production rapide de code opérationnel (mieux que la doc)
minimiser la modélisation en amont
Agilité et UML La modélisation agile peut-elle exister ?   L'agilité se passe de plus en plus d'UML   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
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 !
Barry Boehm article A Spiral Model of Software Development and Enhancement (1986)

Contenu connexe

Tendances

Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?
Pyxis Technologies
 
Le role du coach Agile et son apport pour le projet
Le role du coach Agile et son apport pour le projetLe role du coach Agile et son apport pour le projet
Le role du coach Agile et son apport pour le projet
Franck Beulé
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de Scrum
Pyxis Technologies
 
2015 - Mon 4x4 agile : bien commencer sa "transformation agile"
2015 - Mon 4x4 agile : bien commencer sa "transformation agile"2015 - Mon 4x4 agile : bien commencer sa "transformation agile"
2015 - Mon 4x4 agile : bien commencer sa "transformation agile"
Emilie Esposito
 
La valeur d’affaires: L’indicateur qui peut changer le succès des projets
La valeur d’affaires: L’indicateur qui peut changer le succès des projetsLa valeur d’affaires: L’indicateur qui peut changer le succès des projets
La valeur d’affaires: L’indicateur qui peut changer le succès des projets
Pyxis Technologies
 
Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
Pitié, ne construisez pas le nouveau pont Champlain en Agilité...Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
Pyxis Technologies
 
La gestion de projet en mode Agile : quelle réalité opérationnelle?
La gestion de projet en mode Agile : quelle réalité opérationnelle?La gestion de projet en mode Agile : quelle réalité opérationnelle?
La gestion de projet en mode Agile : quelle réalité opérationnelle?
Christa Dabilly
 
J'ai 2 jours pour lancer mon projet agile
J'ai 2 jours pour lancer mon projet agileJ'ai 2 jours pour lancer mon projet agile
J'ai 2 jours pour lancer mon projet agile
keurvet
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
Pyxis Technologies
 
Introduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jourIntroduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jour
Renaud BROSSE
 
Agilité et la gestion du changement mboisvert - 15 octobre 2013
Agilité et la gestion du changement   mboisvert - 15 octobre 2013Agilité et la gestion du changement   mboisvert - 15 octobre 2013
Agilité et la gestion du changement mboisvert - 15 octobre 2013
Pyxis Technologies
 
Formation agile - Certification Professional Scrum Product Owner
Formation agile - Certification Professional Scrum Product OwnerFormation agile - Certification Professional Scrum Product Owner
Formation agile - Certification Professional Scrum Product Owner
NovUp
 
Agilité du point de vue de la gouvernance
Agilité du point de vue de la gouvernanceAgilité du point de vue de la gouvernance
Agilité du point de vue de la gouvernance
Pyxis Technologies
 
Formation Agile Scrum
Formation Agile ScrumFormation Agile Scrum
Formation Agile Scrum
Mohamed IBN ELAZZOUZI
 
Grille de lecture des méthodes agiles
Grille de lecture des méthodes agilesGrille de lecture des méthodes agiles
Grille de lecture des méthodes agiles
Xavier Warzee
 
2015 - L'agilité au service de l'innovation
2015 - L'agilité au service de l'innovation2015 - L'agilité au service de l'innovation
2015 - L'agilité au service de l'innovation
Emilie Esposito
 
Le rôle de l’architecte Agile - Mathieu Boisvert
Le rôle de l’architecte Agile - Mathieu BoisvertLe rôle de l’architecte Agile - Mathieu Boisvert
Le rôle de l’architecte Agile - Mathieu Boisvert
Pyxis Technologies
 
L'agilité pour gérer la complexité en TI
L'agilité pour gérer la complexité en TIL'agilité pour gérer la complexité en TI
L'agilité pour gérer la complexité en TI
Etienne Laverdière
 

Tendances (20)

Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?Comment être agile dans un contexte non lié aux TI ?
Comment être agile dans un contexte non lié aux TI ?
 
Le role du coach Agile et son apport pour le projet
Le role du coach Agile et son apport pour le projetLe role du coach Agile et son apport pour le projet
Le role du coach Agile et son apport pour le projet
 
Introduction aux méthodes agiles
Introduction aux méthodes agilesIntroduction aux méthodes agiles
Introduction aux méthodes agiles
 
Impacts de l'adoption de Scrum
Impacts de l'adoption de ScrumImpacts de l'adoption de Scrum
Impacts de l'adoption de Scrum
 
Methodes agile
Methodes agileMethodes agile
Methodes agile
 
2015 - Mon 4x4 agile : bien commencer sa "transformation agile"
2015 - Mon 4x4 agile : bien commencer sa "transformation agile"2015 - Mon 4x4 agile : bien commencer sa "transformation agile"
2015 - Mon 4x4 agile : bien commencer sa "transformation agile"
 
La valeur d’affaires: L’indicateur qui peut changer le succès des projets
La valeur d’affaires: L’indicateur qui peut changer le succès des projetsLa valeur d’affaires: L’indicateur qui peut changer le succès des projets
La valeur d’affaires: L’indicateur qui peut changer le succès des projets
 
Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
Pitié, ne construisez pas le nouveau pont Champlain en Agilité...Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
Pitié, ne construisez pas le nouveau pont Champlain en Agilité...
 
La gestion de projet en mode Agile : quelle réalité opérationnelle?
La gestion de projet en mode Agile : quelle réalité opérationnelle?La gestion de projet en mode Agile : quelle réalité opérationnelle?
La gestion de projet en mode Agile : quelle réalité opérationnelle?
 
J'ai 2 jours pour lancer mon projet agile
J'ai 2 jours pour lancer mon projet agileJ'ai 2 jours pour lancer mon projet agile
J'ai 2 jours pour lancer mon projet agile
 
Agile du point de vue d'un PMP
Agile du point de vue d'un PMPAgile du point de vue d'un PMP
Agile du point de vue d'un PMP
 
Introduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jourIntroduction à l'Agilité - Cours complet 1 jour
Introduction à l'Agilité - Cours complet 1 jour
 
Agilité et la gestion du changement mboisvert - 15 octobre 2013
Agilité et la gestion du changement   mboisvert - 15 octobre 2013Agilité et la gestion du changement   mboisvert - 15 octobre 2013
Agilité et la gestion du changement mboisvert - 15 octobre 2013
 
Formation agile - Certification Professional Scrum Product Owner
Formation agile - Certification Professional Scrum Product OwnerFormation agile - Certification Professional Scrum Product Owner
Formation agile - Certification Professional Scrum Product Owner
 
Agilité du point de vue de la gouvernance
Agilité du point de vue de la gouvernanceAgilité du point de vue de la gouvernance
Agilité du point de vue de la gouvernance
 
Formation Agile Scrum
Formation Agile ScrumFormation Agile Scrum
Formation Agile Scrum
 
Grille de lecture des méthodes agiles
Grille de lecture des méthodes agilesGrille de lecture des méthodes agiles
Grille de lecture des méthodes agiles
 
2015 - L'agilité au service de l'innovation
2015 - L'agilité au service de l'innovation2015 - L'agilité au service de l'innovation
2015 - L'agilité au service de l'innovation
 
Le rôle de l’architecte Agile - Mathieu Boisvert
Le rôle de l’architecte Agile - Mathieu BoisvertLe rôle de l’architecte Agile - Mathieu Boisvert
Le rôle de l’architecte Agile - Mathieu Boisvert
 
L'agilité pour gérer la complexité en TI
L'agilité pour gérer la complexité en TIL'agilité pour gérer la complexité en TI
L'agilité pour gérer la complexité en TI
 

Similaire à Introduction a l_agilite_iut_lyon_1_decembre2011

Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013
agnes_crepet
 
#1 définition
#1 définition#1 définition
#1 définition
agnes_crepet
 
Iut lyon 1 introduction à l'agilité - 20 juin 2012
Iut lyon 1   introduction à l'agilité - 20 juin 2012Iut lyon 1   introduction à l'agilité - 20 juin 2012
Iut lyon 1 introduction à l'agilité - 20 juin 2012
agnes_crepet
 
Agilité, Tests Et Industrialisation
Agilité, Tests Et IndustrialisationAgilité, Tests Et Industrialisation
Agilité, Tests Et Industrialisation
PHPPRO
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
agnes_crepet
 
Devops, un tour d'horizon - Eutelsat 2018
Devops, un tour d'horizon -  Eutelsat 2018Devops, un tour d'horizon -  Eutelsat 2018
Devops, un tour d'horizon - Eutelsat 2018
Ludovic Piot
 
Infiltré dans une ample transformation agile
Infiltré dans une ample transformation agileInfiltré dans une ample transformation agile
Infiltré dans une ample transformation agile
Pierre Fauvel
 
Feeback scrumday2015
Feeback scrumday2015Feeback scrumday2015
Feeback scrumday2015
SAGNON Joel
 
Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - Introduction
Tremeur Balbous
 
01- Cadres et outils-Methodes agiles.pptx
01- Cadres et outils-Methodes agiles.pptx01- Cadres et outils-Methodes agiles.pptx
01- Cadres et outils-Methodes agiles.pptx
SteevePaladin
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Pyxis Technologies
 
Partie 1 Besoins
Partie 1 BesoinsPartie 1 Besoins
Partie 1 Besoins
pistesil
 
L'industriel n'est pas là ou le croit !
L'industriel n'est pas là ou le croit !L'industriel n'est pas là ou le croit !
L'industriel n'est pas là ou le croit !
reporter4change
 
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
Adrien Blind
 
Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)
Blackbird
 
Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020
NimeOps
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilité
Christophe Addinquy
 
Du Manifeste Agile à Scrum
Du Manifeste Agile à ScrumDu Manifeste Agile à Scrum
Du Manifeste Agile à Scrum
Xavier Warzee
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logiciel
Majid CHADAD
 
Grosjean Agile User Experience XP DAY France 2009
Grosjean Agile User Experience XP DAY France 2009Grosjean Agile User Experience XP DAY France 2009
Grosjean Agile User Experience XP DAY France 2009
Jean Claude GROSJEAN
 

Similaire à Introduction a l_agilite_iut_lyon_1_decembre2011 (20)

Introduction à l'agilité iut lyon 1 sept2013
Introduction à l'agilité   iut lyon 1 sept2013Introduction à l'agilité   iut lyon 1 sept2013
Introduction à l'agilité iut lyon 1 sept2013
 
#1 définition
#1 définition#1 définition
#1 définition
 
Iut lyon 1 introduction à l'agilité - 20 juin 2012
Iut lyon 1   introduction à l'agilité - 20 juin 2012Iut lyon 1   introduction à l'agilité - 20 juin 2012
Iut lyon 1 introduction à l'agilité - 20 juin 2012
 
Agilité, Tests Et Industrialisation
Agilité, Tests Et IndustrialisationAgilité, Tests Et Industrialisation
Agilité, Tests Et Industrialisation
 
Agilite togo jug_final
Agilite togo jug_finalAgilite togo jug_final
Agilite togo jug_final
 
Devops, un tour d'horizon - Eutelsat 2018
Devops, un tour d'horizon -  Eutelsat 2018Devops, un tour d'horizon -  Eutelsat 2018
Devops, un tour d'horizon - Eutelsat 2018
 
Infiltré dans une ample transformation agile
Infiltré dans une ample transformation agileInfiltré dans une ample transformation agile
Infiltré dans une ample transformation agile
 
Feeback scrumday2015
Feeback scrumday2015Feeback scrumday2015
Feeback scrumday2015
 
Les méthodes Agiles - Introduction
Les méthodes Agiles - IntroductionLes méthodes Agiles - Introduction
Les méthodes Agiles - Introduction
 
01- Cadres et outils-Methodes agiles.pptx
01- Cadres et outils-Methodes agiles.pptx01- Cadres et outils-Methodes agiles.pptx
01- Cadres et outils-Methodes agiles.pptx
 
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
Le rôle de l'analyste d'affaires et la place de la documentation dans un proc...
 
Partie 1 Besoins
Partie 1 BesoinsPartie 1 Besoins
Partie 1 Besoins
 
L'industriel n'est pas là ou le croit !
L'industriel n'est pas là ou le croit !L'industriel n'est pas là ou le croit !
L'industriel n'est pas là ou le croit !
 
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
DevOps à l'échelle: ce que l'on a fait, ce que l'on a appris chez Societe Gen...
 
Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)Introduction à Scrum et aux méthodes agiles (v1.0)
Introduction à Scrum et aux méthodes agiles (v1.0)
 
Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020Meetup DevOps / WebOps Nîmes 20161020
Meetup DevOps / WebOps Nîmes 20161020
 
Aborder la transition vers l'agilité
Aborder la transition vers l'agilitéAborder la transition vers l'agilité
Aborder la transition vers l'agilité
 
Du Manifeste Agile à Scrum
Du Manifeste Agile à ScrumDu Manifeste Agile à Scrum
Du Manifeste Agile à Scrum
 
Cycle de développement du logiciel
Cycle de développement du logicielCycle de développement du logiciel
Cycle de développement du logiciel
 
Grosjean Agile User Experience XP DAY France 2009
Grosjean Agile User Experience XP DAY France 2009Grosjean Agile User Experience XP DAY France 2009
Grosjean Agile User Experience XP DAY France 2009
 

Plus de agnes_crepet

Iut agile lyon 20 nov. 2013 - bdd
Iut agile lyon   20 nov. 2013 - bddIut agile lyon   20 nov. 2013 - bdd
Iut agile lyon 20 nov. 2013 - bdd
agnes_crepet
 
#10 convergence
#10 convergence#10 convergence
#10 convergence
agnes_crepet
 
#12 rétrospective et roti
#12 rétrospective et roti#12 rétrospective et roti
#12 rétrospective et roti
agnes_crepet
 
#2 gestion de projet
#2 gestion de projet#2 gestion de projet
#2 gestion de projet
agnes_crepet
 
#11 rex
#11 rex#11 rex
#11 rex
agnes_crepet
 
#5 management
#5 management#5 management
#5 management
agnes_crepet
 
#4 pratiques techniques
#4 pratiques techniques#4 pratiques techniques
#4 pratiques techniques
agnes_crepet
 
#6 transition agile
#6 transition agile#6 transition agile
#6 transition agile
agnes_crepet
 
#9 processus continu de fabrication
#9 processus continu de fabrication#9 processus continu de fabrication
#9 processus continu de fabrication
agnes_crepet
 
#7 méthodes
#7 méthodes#7 méthodes
#7 méthodes
agnes_crepet
 
#8 jeux sérieux
#8 jeux sérieux#8 jeux sérieux
#8 jeux sérieux
agnes_crepet
 
Introduction à l'agilité numélink - 24 mai 2012 - #0 debut
Introduction à l'agilité   numélink - 24 mai 2012 - #0 debutIntroduction à l'agilité   numélink - 24 mai 2012 - #0 debut
Introduction à l'agilité numélink - 24 mai 2012 - #0 debut
agnes_crepet
 
Introduction à l'agilité numélink - 24 mai 2012 - #11 rex
Introduction à l'agilité   numélink - 24 mai 2012 - #11 rexIntroduction à l'agilité   numélink - 24 mai 2012 - #11 rex
Introduction à l'agilité numélink - 24 mai 2012 - #11 rex
agnes_crepet
 
Introduction à l'agilité numélink - 24 mai 2012 - #10 convergen
Introduction à l'agilité   numélink - 24 mai 2012 - #10 convergenIntroduction à l'agilité   numélink - 24 mai 2012 - #10 convergen
Introduction à l'agilité numélink - 24 mai 2012 - #10 convergen
agnes_crepet
 
Introduction à l'agilité numélink - 24 mai 2012 - #9 processus
Introduction à l'agilité   numélink - 24 mai 2012 - #9 processusIntroduction à l'agilité   numélink - 24 mai 2012 - #9 processus
Introduction à l'agilité numélink - 24 mai 2012 - #9 processus
agnes_crepet
 
Introduction à l'agilité numélink - 24 mai 2012 - #8 jeux
Introduction à l'agilité   numélink - 24 mai 2012 - #8 jeuxIntroduction à l'agilité   numélink - 24 mai 2012 - #8 jeux
Introduction à l'agilité numélink - 24 mai 2012 - #8 jeux
agnes_crepet
 
Introduction à l'agilité numélink - 24 mai 2012 - #7 méthodes
Introduction à l'agilité   numélink - 24 mai 2012 - #7 méthodesIntroduction à l'agilité   numélink - 24 mai 2012 - #7 méthodes
Introduction à l'agilité numélink - 24 mai 2012 - #7 méthodes
agnes_crepet
 
Introduction à l'agilité numélink - 24 mai 2012 - #6 transition
Introduction à l'agilité   numélink - 24 mai 2012 - #6 transitionIntroduction à l'agilité   numélink - 24 mai 2012 - #6 transition
Introduction à l'agilité numélink - 24 mai 2012 - #6 transition
agnes_crepet
 

Plus de agnes_crepet (20)

Iut agile lyon 20 nov. 2013 - bdd
Iut agile lyon   20 nov. 2013 - bddIut agile lyon   20 nov. 2013 - bdd
Iut agile lyon 20 nov. 2013 - bdd
 
#10 convergence
#10 convergence#10 convergence
#10 convergence
 
#12 rétrospective et roti
#12 rétrospective et roti#12 rétrospective et roti
#12 rétrospective et roti
 
#2 gestion de projet
#2 gestion de projet#2 gestion de projet
#2 gestion de projet
 
#11 rex
#11 rex#11 rex
#11 rex
 
#5 management
#5 management#5 management
#5 management
 
#4 pratiques techniques
#4 pratiques techniques#4 pratiques techniques
#4 pratiques techniques
 
#6 transition agile
#6 transition agile#6 transition agile
#6 transition agile
 
#9 processus continu de fabrication
#9 processus continu de fabrication#9 processus continu de fabrication
#9 processus continu de fabrication
 
#7 méthodes
#7 méthodes#7 méthodes
#7 méthodes
 
#8 jeux sérieux
#8 jeux sérieux#8 jeux sérieux
#8 jeux sérieux
 
#3 etapes projet
#3 etapes projet#3 etapes projet
#3 etapes projet
 
#13 annexes
#13 annexes#13 annexes
#13 annexes
 
Introduction à l'agilité numélink - 24 mai 2012 - #0 debut
Introduction à l'agilité   numélink - 24 mai 2012 - #0 debutIntroduction à l'agilité   numélink - 24 mai 2012 - #0 debut
Introduction à l'agilité numélink - 24 mai 2012 - #0 debut
 
Introduction à l'agilité numélink - 24 mai 2012 - #11 rex
Introduction à l'agilité   numélink - 24 mai 2012 - #11 rexIntroduction à l'agilité   numélink - 24 mai 2012 - #11 rex
Introduction à l'agilité numélink - 24 mai 2012 - #11 rex
 
Introduction à l'agilité numélink - 24 mai 2012 - #10 convergen
Introduction à l'agilité   numélink - 24 mai 2012 - #10 convergenIntroduction à l'agilité   numélink - 24 mai 2012 - #10 convergen
Introduction à l'agilité numélink - 24 mai 2012 - #10 convergen
 
Introduction à l'agilité numélink - 24 mai 2012 - #9 processus
Introduction à l'agilité   numélink - 24 mai 2012 - #9 processusIntroduction à l'agilité   numélink - 24 mai 2012 - #9 processus
Introduction à l'agilité numélink - 24 mai 2012 - #9 processus
 
Introduction à l'agilité numélink - 24 mai 2012 - #8 jeux
Introduction à l'agilité   numélink - 24 mai 2012 - #8 jeuxIntroduction à l'agilité   numélink - 24 mai 2012 - #8 jeux
Introduction à l'agilité numélink - 24 mai 2012 - #8 jeux
 
Introduction à l'agilité numélink - 24 mai 2012 - #7 méthodes
Introduction à l'agilité   numélink - 24 mai 2012 - #7 méthodesIntroduction à l'agilité   numélink - 24 mai 2012 - #7 méthodes
Introduction à l'agilité numélink - 24 mai 2012 - #7 méthodes
 
Introduction à l'agilité numélink - 24 mai 2012 - #6 transition
Introduction à l'agilité   numélink - 24 mai 2012 - #6 transitionIntroduction à l'agilité   numélink - 24 mai 2012 - #6 transition
Introduction à l'agilité numélink - 24 mai 2012 - #6 transition
 

Introduction a l_agilite_iut_lyon_1_decembre2011

  • 1. Introduction à l'agilité IUT Lyon 1 - décembre 2011 @agnes_crepet   @AlfredAlmendra
  • 2. Qui sommes-nous? Alfred Almendra Coach agile Architecte SOA   CARA Lyon Agnès Crépet Java/JEE Architecte   Java User Groups Leader: Duchess France & LyonJUG   Fait partie de l'équipe organistrice de la conférence MIX-IT (Java, Agilité...)   Co-fondatrice du podcast Cast-IT (Java, Agilité...)
  • 20. Préambule Spinning Dancer (Nobuyuki Kayahara, web designer)
  • 21. Préambule Notre cerveau est bogué ! ...mais nous sommes maintenant avertis ! Psychologie cognitive : les (nombreux) biais du cerveau Ancrage Confirmation d'hypothèse Conformisme Dunning-Kruger Halo Dissonance cognitive Perception sélective ...
  • 22. Préambule Personne n’est parfait = tout le monde est imparfait On peut se tromper, mais on doit s’améliorer L’erreur peut venir du développeur, mais pas uniquement. Tous les acteurs du projet peuvent se tromper ... @Morendil Responsable de l' institut-agile.fr "Il n’existe pas de bug qui ne soit issu du cerveau humain. La conception c’est tout ce qui permet de prévenir ou contourner les bugs du cerveau (outil, méthode, design pattern, modélisation, schéma, doc, wiki, commentaire dans le code, …)"  (Mix-IT 2011) "Une erreur de spécification est une forme de bug. Un utilisateur, un décideur et un responsable métier ont aussi le droit de se tromper."  (Responsable métier chez Boiron)
  • 23.  
  • 24. Préambule 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... Vocabulaire pour la suite de la présentation : Equipe = tous les acteurs du projet                  pas uniquement les développeurs REX = retour d'expérience
  • 25. Besoin d’une rupture La méthode en cascade On travaille l'un après l'autre : la moindre erreur coûte cher
  • 26. Besoin d’une rupture Le cycle en V On ajoute à la cascade de l'anticipation et du travail simultané
  • 27. 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
  • 28. 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 !
  • 29. Rapide historique Certains principes existent depuis longtemps IHM révolutionnée par Internet depuis 2000 !
  • 37. Les 4 valeurs 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
  • 38. Les 12 principes 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).
  • 39. 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)
  • 40. 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.
  • 41. 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).
  • 42. 4 valeurs et 12 principes
  • 50. 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, ...
  • 51. 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
  • 52. Itératif, incrémental, adaptatif Les besoins évoluent aussi après la mise en production (la maintenance est-elle un mythe ? une stagnation ?) Jean-François Jagodzinski @jfjago a remplacé le terme projet par processus de fabrication (cf. Kanban)
  • 53. Les jeux Ludiques : donc participation volontaire et motivée Augmentent la créativité, la collaboration, le taux d'apprentissage Cadre et règles faciles à comprendre : donc focus sur l’objectif Exemples de valeurs et objectifs : auto organisation, communication, collaboration, productivité, ... Alexandre Boutin (@agilex) président du CARA Bientôt un agile game en France ? en 2012 ? Agile Games à Boston, Agile4Play en Allemagne
  • 54. Les jeux et les étapes du projet Extrait du calendrier du CARA Lyon (OUI, c'est de la PUB !) 
  • 55. Auto-organisation et travail collaboratif XP : Pair-P., TDD, work space Tests croisés, revues de code Daily meetings (stand up) Répartition et alternance des expertises, wiki, post-it, proximité user/dév Rôles figés (CP, Architecte, ...) Réunions stériles Les docs à rallonge (mails, CR) Entreprise gérée en mode Open Space (ut7 AgileInnovation 2011) Ateliers Open Space Rétrospective personnelle synthétique
  • 56. La marge de manoeuvre Renoncer à des fonctionnalités pour tenir les délais : oui et non      Ne pas réaliser des fonctionnalités non rentables      c’est gagner du temps, de l’argent et de l’énergie. Tout projet, agile ou non, possède 4 leviers dépendants de ses contraintes et objectifs : les fonctionnalités
  • 60. Côté organisationnel Pilotage par les risques la réussite n’est pas garantie, mais l’éventuel échec est découvert plus tôt Visibilité oui sur l’avancement vers l’objectif
  • 61. non dans le détail (exploration, challenge, adaptation) Ordonnancement (plutôt que priorisation, cf. Scrum été 2011) Indicateurs qualitatifs : satisfaction, image, analyse de la valeur (AFAV.eu)
  • 62. quantitatifs : taux d'utilisation, valeur ajoutée progressive, ROI Contrats de sous-traitance : à essayer ! Ex :  http://contrat-agile.org/  (Xebia, Cellenza, Alerion, LCA) Offshore : complexe, peu de réussites notables
  • 63. L'oignon agile De l'agilité à tous les étages !
  • 64. 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
  • 65. Côté technique Qualité et industrialisation TDD, PIC, refactoring, déploiement continu
  • 66. 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).
  • 67. 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)
  • 68. Refactoring : sessions de Code Retreat (c3f  http://coderetreat.org/ )
  • 69. Devops (collaboration entre Développements et Opérations)
  • 71. Agilité et UML Comment documenter / modéliser un besoin ?   2 approches semblent opposées :    l'approche Model-Driven (OMG) modélisation UML très poussée
  • 72. génération automatique de code    l'approche agile production rapide de code opérationnel (mieux que la doc)
  • 74. Agilité et UML La modélisation agile peut-elle exister ?   L'agilité se passe de plus en plus d'UML   Boiron a décidé néanmoins de garder UML : Traçabilité des exigences
  • 76. Contrainte de validation pharmaceutique
  • 77. Communication inter et intra équipe   Stratégie Boiron pour pour la modélisation: Pas trop de doc
  • 86. 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 !
  • 87. Barry Boehm article A Spiral Model of Software Development and Enhancement (1986)
  • 88. Première version opérationnelle publiée par James Martin en 1991 sous le nom de RAD (développement rapide d'applications) Niveau de planification stratégique ajouté par Jean-Pierre Vickoff
  • 89. UP en quelques mots Le processus UP (abréviation de Unified Processus) a été créé par les mêmes personnes qu'UML (Rumbaugh, Booch et Jacobson) en 1997.   UP répond aux exigences fondamentales préconisées par les créateurs d’UML :    une méthode de développement doit être guidée par les besoins des utilisateurs    elle doit être centrée sur l’architecture logicielle    elle doit être itérative et incrémentale    Centré cas d’utilisation (Use Case)
  • 91. 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
  • 92. 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
  • 93. 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
  • 94. Scrum L'é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 prenantes Chicken and pig
  • 95. Scrum : activités, collaboration
  • 96. Scrum : stand up (daily meeting) 3 questions : qu'avez-vous fait hier ?
  • 98. qu'est-ce qui bloque l'avancement ? Tout le monde parle pas uniquement les développeurs Time-boxing pas uniquement aux stand-up
  • 99. Scrum : vélocité, burndown chart Trop lent : répartition par expertise Trop vite : capitalisation des connaissances Inputs : mou et rythme soutenable Michel Goldenberg
  • 100. 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
  • 101. 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
  • 102. Lean SD (oui, LSD !) Modèle itératif et agile mettant en avant 7 principes : 1. Eliminer les gaspillages Tout ce qui n'apporte pas de valeur au produit. La valeur étant définie du point de vue de l'utilisateur. 2. Améliorer l'apprentissage 3. Retarder l'engagement 4. Livrer aussi vite que possible 5. Donner le pouvoir à l'équipe 6. Intégrer la qualité dès la conception 7. Considérer le produit dans sa globalité
  • 104. Dimensionner et maîtriser les stocks Simplifier visuellement le suivi et la planification Parfait pour une TMA, mais pas uniquement
  • 105. Définition de "terminé" ( http://www.scrumalliance.org )
  • 113. Difficultés Participation active des métiers ou d’un panel d’utilisateurs Soutien engagé et permanent des décideurs, du client, du payeur Acceptation du changement, de l’erreur, de la critique : tout le monde est concerné Autoriser l’erreur c’est donner le droit et la chance de l’amélioration (pour soi et les autres) L’humain n’aime pas le changement, donc freine consciemment ou inconsciemment jusqu’à sa propre amélioration
  • 114. 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é
  • 115.  
  • 116. Quelques clés de réussite Projet de taille moyenne : ni trop court (au moins quelques semaines ou mois), ni trop gros (moins de 10 personnes)
  • 117. Quelques clés de réussite
  • 119. Liens avec l'assurance qualité ISO / CMMi : dire ce qu'on va faire, et faire ce qu'on a dit prédictif : plutôt pas agile ITIL : bonnes pratiques pour gérer le SI support : incident, problème, changement, configuration
  • 121.   infrastructure, sécurité, ... "compatible Kanban" DevOps : alternative ?
  • 127. Concrètement Plus de concret ! Conclusion
  • 130. Retours d’expériences Trop cher admettons à court terme, mais beaucoup plus rentable (investissement)
  • 131. non à moyen/long terme, suivi du ROI régulièrement (pour s’arrêter à temps) “ Scrum (ou l'agilité) ne fonctionne pas ou n’a pas fonctionné dans mon contexte” la méthode est-il bien utilisée ? dur au départ, mais ensuite on s'améliore Exemples d’indicateurs : est-ce que PO et CP parlent de leurs problèmes aux stand up ?
  • 132. est-ce que l’estimation du RAF est collégiale ?
  • 133. est-ce que les rétrospectives identifient des actions d’amélioration pour d’autres personnes que les développeurs ? DSI Boiron qui témoigne : comment faire sans l’agilité ?      est-ce qu’il y a mieux ?
  • 134. Exemple de mise en oeuvre La DSI des laboratoires Boiron a introduit en 2007 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
  • 135. faciliter l’acceptation des nouvelles solutions informatiques par les utilisateurs finaux Premier « vrai » déploiement sur un des plus gros projets de la DSI ARPEGE : 8700 jours Agilité chez BOIRON ? Un mix d’UP, XP et de Scrum / Kanban
  • 136. Le tout mélangé avec de la teinture mère d’Arnica Montana !
  • 137. 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 2, Jenkins, Nexus)
  • 138. 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 Recette Utilisateur ARPEGE – Boiron Janvier 2010
  • 140. Backlog de produit  Les exigences, les activités En UP : Use Case (Boiron)
  • 141. 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
  • 142. Mais également par le reste de l’équipe (différent de Scrum)
  • 143. Exemple de backlog Boiron A chaque Use Case sont associées deux attributs : Une estimation en points arbitraires (on ne parle pas encore de jours)
  • 144. Et une priorité (métier, risque technique identifié) La liste peut évoluer au cours du projet, suite aux recettes utilisateur en fin d’itération Perfectible : chiffrage initial
  • 145. Exemple de mise en oeuvre Comment planifier une itération ?
  • 146. 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) + AUGEO (semaine/mois)
  • 152. Plus de concret ! Conclusion Informations diverses
  • 154. Les méthodes agiles, pas 1 miracle!
  • 155. 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 !
  • 156. 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
  • 164. Liens Conférences : CARA Lyon, SUG, Scrum Days, Mix-IT, ALE, SoftShake, Agile Grenoble, Agile Tour, Agile France, Devops, XP Days, Agile Open Days http://www.agileforall.com : tous les projets peuvent adopter au moins quelques pratiques agiles, ce qui les rendrait meilleurs. http://www.agilealliance.org/ http://referentiel.institut-agile.fr/  : 1 fiche par pratique Agile ! Club Agile Rhône-Alpes :  http://www.clubagilerhonealpes.org/
  • 165. 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
  • 166.  
  • 167.  
  • 176.  
  • 177. Annexes Attention aux enquêtes et à leurs interprétations... Enquête de http://drdobbs.com en 2007, avec les critères ordonnés suivants : Quality, Scope, Staff, Time, Money
  • 180. Source Certains Slides (Scrum) sont issus d’une présentation de Mike Cohn sous license libre http://www.mountaingoatsoftware.com/

Notes de l'éditeur

  1. voilà, dans le slide, ma propositon de conluc simple!