Retours sur 4 ansd’industrialisation de l’agilité        Rémy Génin - Orange           Octobre 2010
Les pièges
Les pièges qu’on connait bien …• le scope fonctionnel va changer pendant le  projet, donc  o l’engagement sur un périmètre...
Les pièges liés à l’agilité• product owner  pas assez disponible, pas assez compétent, non-  légitimé• des moyens insuffis...
Construire      SAproposition agile
La proposition « Orange Agile »• part de l’existant• précise les choses• inclut l’environnement Orange, qui  o est complex...
Diffuser l’information et accompagner :                                         Un centre d’expertiseUn centre d’expertise...
Les rôles
Les rôles agiles – La base« Product Owner »  responsable du contenu fonctionnel« ScrumMaster »  facilitateur en l’agilité ...
Rôles – les compléments utiles– le Coach agile=> Aide le ScrumMaster à mettre/maintenir un bon niveau d’agilité– le CP => ...
Le coach agileCoach agile• aide ponctuellement et régulièrement le ScrumMaster à  mettre et maintenir un bon niveau d’agil...
HumilitéCoach agile et ScrumMaster• Ne sont pas des « gourous »  Ils ne donnent pas de leçon• Ils ne sont pas des « supéri...
Zoom sur les développeurs- un expert par technologie fondatrice de l’appli- non spécialisés sur une seule partie, plutôt p...
Zoom sur le testeur (1/2)Le testeur- a pour fonction d’implémenter les tests fonctionnels (« How to verify ») fournis par ...
Zoom sur le testeur (2/2)Les tests peuvent soit :- être gérés dans un backlog spécifique- faire l’objet d’un statut dans l...
Le déroulement   du projet
Une autre façon d’aborder le projetHabituellement, on définit le scope fonctionnel, puis on cherche à déterminerla charge,...
TTM – Les jalons d’un projet agile        Etude                         Conception                            Développemen...
Charte du projet - la trade-off matrix• En une page, la charte pose les     •   But et contexte du projet, en 30 secondes ...
Le déroulement du projet agileInitialisation   o Workshop physique, à la fin de l’étude     Les acteurs du projet doivent ...
Le « processus Scrum » - L’explorationPhase de Préparation & ExplorationPréparer l’organisation du projet    ● rédiger le ...
Démarrer un projet par une formation• Un projet démarre ?  => 2 jours de formations pour tout le monde     afin que chacun...
Catégories de projet  et labellisation
Les catégories de projets agilesLes contextes de certains projets ne permettent pas toujours d’appliquertout ce que l’agil...
Les catégories de projets agiles3 catégories de projets agiles permettent d’utiliser uneproposition agile cohérente et ada...
Pourquoi un label ?Lorsque l’agilité est bien appliquée,• les qualités technique et fonctionnelle sont grandes• le métier ...
à propos du « Agile cow-boy »le « agile cowboy »(qui prend l’agilité commeprétexte pour faire n’importe quoi)conduit à des...
la qualité« Orange Agile »
DoD … les Definition of DoneexemplesTâche unitaire      User story             Sprint• Compilation       • Conception mise...
Une qualification au fil de l’eauPour pouvoir certifier le bon fonctionnement del’application en permanence, il devientind...
Les KPI agilesUn certain nombre de KPI issus du mode classique ne sont plus pertinentspour mesurer la performance d’un pro...
Documentation : l’utile, mais pas plusEn tant que vecteur fort de la communication entre les services et équipesqui se suc...
Outils pour l’agilité
Un système qualité adapté,                                                  appuyé par l’outilTous les principes qualité s...
Les outils : Backlog
Les outils : Storyboard
Les outils : Reporting
Les outils – Gestion documentaire
Les outils - HudsonHudson est un portail centralisant les informations techniques.C’est en général le « chapeau » de l’int...
Faire un backlog produit
backlog produit :                            des specs progressivesPour le démarrage du projet, on demande 2niveaux de pré...
backlog produit :                                          des specs progressivesPendant l’exploration, le PO va détailler...
A propos des« cérémonies »
A propos des « cérémonies »Les réunions qui ponctuent les sprints sont engénéral appelées « cérémonies »Drôle de nom ! (po...
A propos du stand-upOn met à jour le « reste à faire » de chaque tâche en coursL’estimation et les ré-estimations : heures...
A propos de la rétrospective• Moment de grande subjectivité :   o chacun exprime son ressenti   o chaque avis compte et do...
Bonne route !    merci
Prochain SlideShare
Chargement dans…5
×

Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilité chez orange

4 744 vues

Publié le

Sur la base de la proposition standard Scrum+XP (sur laquelle je ne reviens pas), je passe en revue ce que nous avons vu fonctionner ou échouer sur le terrain. Cela inclut un certain nombre de choses très concrètes sur la façon de mettre en pratique des propositions Scrum souvent peu détaillées, comme « il faut faire un backlog produit ».

1 commentaire
2 j’aime
Statistiques
Remarques
  • Bonjour,
    Dans le cadre d'un projet innovant, nous recherchons un Coordinateur Agile(H/F), poste en CDI basé à Nantes.
    Merci de me contacter pour plus d'informations : widad.ramzi@consortnt.fr.
    Cordialement.
    Widad Ramzi
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
Aucun téléchargement
Vues
Nombre de vues
4 744
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1 469
Actions
Partages
0
Téléchargements
118
Commentaires
1
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilité chez orange

  1. 1. Retours sur 4 ansd’industrialisation de l’agilité Rémy Génin - Orange Octobre 2010
  2. 2. Les pièges
  3. 3. Les pièges qu’on connait bien …• le scope fonctionnel va changer pendant le projet, donc o l’engagement sur un périmètre figé est une utopie o les specs trop détaillées avant de démarrer sont ineptes• la formulation en H/J crée un engagement implicite. préférez les points de complexité• une stratégie métier qui change en cours de route
  4. 4. Les pièges liés à l’agilité• product owner pas assez disponible, pas assez compétent, non- légitimé• des moyens insuffisants pas de ScrumMaster, pas de testeur, pas d’automatisation• les règles de base non respectées « pas de rétrospective ! pas le temps »• adaptabilité ne veut pas dire « je fais ce que je veux ». la rigueur est incontournable retour
  5. 5. Construire SAproposition agile
  6. 6. La proposition « Orange Agile »• part de l’existant• précise les choses• inclut l’environnement Orange, qui o est complexe o contient un grand nombre de contraintes
  7. 7. Diffuser l’information et accompagner : Un centre d’expertiseUn centre d’expertise est là pour vous aider et vous accompagner dans toutce qui touche l’agilité : - Présentations (multiples au besoin) - Formations - Trouver un ScrumMaster - Faire monter en compétence un ScrumMaster - Coacher le projet - Faire un audit ponctuelUn site intranet pour centraliser l’information et les documents partagés, desFAQ, des fiches pratiques, des explications détailléesUne communauté avec des forums par rôle agileUn « mode d’emploi » informatisé en préparation retour
  8. 8. Les rôles
  9. 9. Les rôles agiles – La base« Product Owner » responsable du contenu fonctionnel« ScrumMaster » facilitateur en l’agilité une équipe de développeurs
  10. 10. Rôles – les compléments utiles– le Coach agile=> Aide le ScrumMaster à mettre/maintenir un bon niveau d’agilité– le CP => Pilote global aspects administratifs, production des documents demandés, gestion des interfaces, passage des jalons, reporting => s’occupe d’insérer l’application dans le SI (métrologie, intégration, exploitation)– le testeur => possède des compétences de développeur => a pour fonction d’implémenter et automatiser les tests fonctionnels– le manager => supérieur hiérarchique => décideur : tranche si l’équipe / le CP n’en ont pas le pouvoir
  11. 11. Le coach agileCoach agile• aide ponctuellement et régulièrement le ScrumMaster à mettre et maintenir un bon niveau d’agilité sur le projet.Activités :• 1 réunion par sprint, pour passer en revue le « ScrumMaster assistant » (évalue le niveau d’agilité de l’équipe).• Prise de contact régulière avec le ScrumMaster• Participation aux cérémonies tous les 2 à 5 sprints• Présence plus forte les 3 premiers mois (mise en place), le temps pour l’équipe d’acquérir les bons réflexes.
  12. 12. HumilitéCoach agile et ScrumMaster• Ne sont pas des « gourous » Ils ne donnent pas de leçon• Ils ne sont pas des « supérieurs hiérarchiques »• Ils sont des « panneaux indicateurs », des « reminders » qui rappellent les règles d’un arbitre neutre : l’agilité.• Humilité : ce n’est pas eux qui ont créé l’agilité, ils ne font que la propager.• Ils n’imposent pas : il faut convaincre, et répéter beaucoupLe SCRUMMASTER DOIT ETRE D’ABORD SCRUMMASTER
  13. 13. Zoom sur les développeurs- un expert par technologie fondatrice de l’appli- non spécialisés sur une seule partie, plutôt pluridisciplinaires- n’hésitent pas à travailler en binômes pour : o répartir les compétences techniques et fonctionnelles de manière homogène o renforcer la qualité, le respect des normes, l’écriture des tests o partager toutes les décisions de conception (« stop the line »)- ont le droit de demander et recevoir de l’aide- n’inventent plus les specs, mais vont voir le PO à la moindre question fonctionnelle- l’équipe travaille à un rythme durable (sans pression constante forte)
  14. 14. Zoom sur le testeur (1/2)Le testeur- a pour fonction d’implémenter les tests fonctionnels (« How to verify ») fournis par le PO pour chaque User story- possède des compétences de développeur- l’implémentation des TF se fait pendant l’itération, ce qui oblige les développeurs à une conception préalable :-)- automatise ces tests, qui sont exécutés chaque nuit- alerte les développeurs de chaque régression fonctionnelle pour correction immédiate, ce qui permet de contrôler la non-régressionCompétences très spécifiques- les tests fonctionnels doivent le plus possible - tester les règles métier (oblige à faire une conception orientée métier) - être décorrelés de l’IHM, grâce à - des tests d’intégration (directement dans le langage de l’appli) - des « spécifications exécutables » (Fitnesse).- Les tests IHM seront automatisés via Selenium ou QuickTestPro
  15. 15. Zoom sur le testeur (2/2)Les tests peuvent soit :- être gérés dans un backlog spécifique- faire l’objet d’un statut dans le cycle de vie d’une storyDans les 2 cas, on peut utiliser le kanban pour fluidifier le travailou identifier les goulots d’étranglementLe testeur participe aux cérémonies de l’équipe, comme membreà part entière.Penser à garder les petites stories de test pour la fin du sprint,pour avoir une chance de tout livrer à la fin du sprint. retour
  16. 16. Le déroulement du projet
  17. 17. Une autre façon d’aborder le projetHabituellement, on définit le scope fonctionnel, puis on cherche à déterminerla charge, la date de livraison et le budget.Orange Agile propose une approche différente :Stratégie changeante + priorités métier changeantes + réorgs= socle fonctionnel stable sur 8 mois, pas plusConséquence :- une release normale durera environ 8 mois une release rapide durera 3 à 4 mois- une équipe doit faire 7 personnes (5 à 9) (préconisation agile)Donc on a le budget et la date de livraison !!!La mission : réaliser la valeur métier la plus pertinente avec !
  18. 18. TTM – Les jalons d’un projet agile Etude Conception Développement Déploiement Généralisation opportunité d’opportunité T-1 T0 T1 T2 T3 T4 Pré Pré- Etude Exploration Développement itératif & ité Validation Stabilisation Clôture du T3a opportunité étude d’opportunité qualification dans les sprints de la Projet S1 release S3 S4 S5 S6 Revue Revue de Technique Stabilisation S2 T1x T1c Quelques Toutes les Pouvoir partir en production pendant les pratiques pratiques développements, sur demande du métier mé agiles agiles Prononcé Prononcé pour la T1x : qualification utilisateurs suppriméT1a, T1b supprimés premiè première mise en d’exploitabilité T1c : conditions d’exploitabilité OK production prononcé GO prononcé non utilisé dans un projet agile inclus dans le déroulement de chaque sprint La 1ère MEP « ouvre la voie ». On pourra refaire d’autres MEP facilement. d’
  19. 19. Charte du projet - la trade-off matrix• En une page, la charte pose les • But et contexte du projet, en 30 secondes fondements du projet, partagés • Utilisateurs / Clients destinataires par tous • Avantages / bénéfices métier escomptés Elle est entérinée à l’unanimité • Fonctionnalités principales par vote à main levée • Dates principales connues (contraintes) (Trade-off incluse). • Contraintes identifiées (charge, perf, etc) • Risques majeurs identifiés • Comment mesurer que l’objectif a été atteint ?• La « trade-off matrix » ou « matrice des compromis » Fixe Ferme Pourrait Changera changer sûrement ! identifie LA contrainte du projet. Scope fonctionnel L’utopie du « tout-figé » au Planning démarrage (date de livraison + Coûts / budget + contenu fonctionnel) Ressources est révolue ! Qualité
  20. 20. Le déroulement du projet agileInitialisation o Workshop physique, à la fin de l’étude Les acteurs du projet doivent se rencontrer, créer la relation humaine o Démarrage du projet, avec • la charte du projet • la PS (proposition de solution, 2 à 3 pages; très synthétique; valide la faisabilité de la demande fonctionnelle)Exploration (le mûrissement en mode classique) o préparation proprement dite, gérée comme un projet Scrum o 2 sprints de calibrage, pour : • Rôder le fonctionnement dans un mode opérationnel • Déterminer une estimation de la vélocitéProduction (post T1) o sprints de développement normaux o dernier(s) : finalisation / accompagnement & qualification o en option : garder un sprint à blanc (pas une provision)
  21. 21. Le « processus Scrum » - L’explorationPhase de Préparation & ExplorationPréparer l’organisation du projet ● rédiger le PMP. ● se synchroniser avec les acteurs externes ● inclure les utilisateurs (un panel, un forum de feedback …) ● sélectionner les pratiques agiles qui seront utilisées ● fixer les règles de codage ● déterminer les DoD ● définir les modes de communication ● définir la durée d’un sprint Agilité Technique ● former les acteurs du projet et Fonctionnel sensibiliser leur hiérarchie
  22. 22. Démarrer un projet par une formation• Un projet démarre ? => 2 jours de formations pour tout le monde afin que chacun partent sur de bonnes bases afin que chacun partent sur les mêmes bases => 2 jours de formations complémentaires dédiées au Product Owner retour
  23. 23. Catégories de projet et labellisation
  24. 24. Les catégories de projets agilesLes contextes de certains projets ne permettent pas toujours d’appliquertout ce que l’agilité propose.Afin de cadrer et d’aider au mieux tous les projets désirant utiliser autantque possible l’agilité, il existe désormais des catégories de projetspermettant officiellement d’utiliser l’agilité à la mesure de ce qui estpossible routière sportive Formule 1
  25. 25. Les catégories de projets agiles3 catégories de projets agiles permettent d’utiliser uneproposition agile cohérente et adaptée quel que soit lecontexte• routière : contexte peu favorable. projet non agile, mais qui choisit néanmoins d’utiliser les valeurs agiles, les itérations courtes et les rôles agiles.• sportive : projet à volonté affirmée, mais à maturité agile faible. certaines pratiques sont optionnelles.• formule 1 : utilise correctement toutes les pratiques agiles.
  26. 26. Pourquoi un label ?Lorsque l’agilité est bien appliquée,• les qualités technique et fonctionnelle sont grandes• le métier et les utilisateurs finaux fournissent un feedback régulier et les itérations courtes permettent de garantir la pertinence fonctionnelle de l’application• les tests automatisés certifient le bon fonctionnement du début à la finUN PROJET VRAIMENT AGILE NE PEUT PAS ECHOUER.• Les coaches du Centre d’Expertise Agile accordent ou non le label à chaque fin d’itération.• Il s’agit de s’assurer que les gens ne font pas « n’importe quoi » sur le dos de l’agilité.• On donne des objectifs atteignables aux projets• on crée un réflexe managérial : « Agile ? as-tu un label ? »
  27. 27. à propos du « Agile cow-boy »le « agile cowboy »(qui prend l’agilité commeprétexte pour faire n’importe quoi)conduit à des catastrophespires qu’un cycle en V figéSi on n’a pas les prérequispour commencer, il ne faut pas commencer ! retour
  28. 28. la qualité« Orange Agile »
  29. 29. DoD … les Definition of DoneexemplesTâche unitaire User story Sprint• Compilation • Conception mise à • Démo faite sur les• Refactoring jour User stories • Tests fonctionnels « vraiment• Tests unitaires terminées » en local • Guide util/Admin • Doc de specs• Intégration • Intégration fonctionnelles mis à• Tests sur • Impact jour intégration OK exploitabilité •… • Validation PO • Affichage < 3 sec.
  30. 30. Une qualification au fil de l’eauPour pouvoir certifier le bon fonctionnement del’application en permanence, il devientindispensable d’automatiser les tests techniques etfonctionnels et de les passer tous les jours 15 tests 40 tests 80 tests
  31. 31. Les KPI agilesUn certain nombre de KPI issus du mode classique ne sont plus pertinentspour mesurer la performance d’un projet.Pour les projets VRAIMENT agiles (au moins « Sportives »), les KPI agiles sont :● Vélocité : mesure et stabilité de la capacité de production de l’équipe● Tests fonctionnels : les « how to verify » sont automatisés et OK● Objectifs métier : la contrainte « Fixe » de la TradeOff matrix annoncée au T0, confirmée au T1, est respectée. Les objectifs mesurables de la charte sont atteints● Qualité technique : les normes sont respectées, les tests techniques sont tous OK, la couverture de tests technique est >= 80%, aucun bug issu du travail de l’équipe● Note d’agilité de 3,5 sur 5 (moyenne pertinente du « ScrumMaster assistant ») et au moins 3 sur les critères obligatoires de la catégorie du projet● Satisfaction métier + utilisateurs finaux : minimum 3 (intervalle 0 à 5) Les exceptions (test non automatisable par exemple) sont tolérées si elles sont validées par l’équipe, le coach et le Pole Agile
  32. 32. Documentation : l’utile, mais pas plusEn tant que vecteur fort de la communication entre les services et équipesqui se succèdent sur un projet, la doc est indispensablePMP (Plan de Management de Projet)Toutes les stratégies, l’organisation du projet et ses spécificités sont dans lePMP, y compris les contraintes d’exploitabilitéLes documents d’architectureDAT, DAF, DAL : architectures technique, fonctionnelle, logicielleSpécifications fonctionnellesIl reste indispensable d’avoir ce document à jour.Proposition : le PO le met à jour à chaque fin de sprint.L’exploitabilité (pour que l’application survive à son équipe de dev)Guides d’install, utilisateurs, administrateurs technique et fonctionnel, lesdescriptions (alimentées au fil des développements) des sauvegardes,supervision, ordonnancement, gestion des erreurs retour
  33. 33. Outils pour l’agilité
  34. 34. Un système qualité adapté, appuyé par l’outilTous les principes qualité sont conservés.Seule leur mise en œuvre a été adaptée au contexte agileLa réelle simplification vient de l’outil :• pour gérer le projet (exigences, scope fonctionnel, risques, actions, etc)• pour gérer le backlog produit• pour gérer l’historisation et la traçabilité de manière automatique• pour gérer le quotidien de l’équipe (backlog de sprint, stories, taches)• pour générer automatiquement le reporting utile• pour stocker tout élément documentaire (wiki)• pour gérer les tests et leur liens aux stories et aux exigences• pour centraliser les informations en un seul endroit• pour faciliter le partage entre des sites distants• Avec le serveur d’intégration, on suit les couvertures de test, respect des normes, indice de complexité du code, détection de duplication, etc
  35. 35. Les outils : Backlog
  36. 36. Les outils : Storyboard
  37. 37. Les outils : Reporting
  38. 38. Les outils – Gestion documentaire
  39. 39. Les outils - HudsonHudson est un portail centralisant les informations techniques.C’est en général le « chapeau » de l’intégration continue.On y trouve notamment :- Le résultat du dernier build- Les résultats des tests techniques- La couverture de tests- Des propositions de refactoring- Le résultat du contrôle de respect des normes, etc … retour
  40. 40. Faire un backlog produit
  41. 41. backlog produit : des specs progressivesPour le démarrage du projet, on demande 2niveaux de précision : les Thèmes et les EpicsCela donne les grandes lignes de l’investissement(SOX).
  42. 42. backlog produit : des specs progressivesPendant l’exploration, le PO va détailler un seul niveausupplémentaire : les user stories Thèmes, epics et user stories auront une priorité métier et une note de complexité technique (en points) retour
  43. 43. A propos des« cérémonies »
  44. 44. A propos des « cérémonies »Les réunions qui ponctuent les sprints sont engénéral appelées « cérémonies »Drôle de nom ! (pour certains)La raison : elles suivent toutes un « cérémonial »,et ont une structure bien définie.Toutes les cérémonies sont timeboxées.Le PO participe à toutes, même au standup !
  45. 45. A propos du stand-upOn met à jour le « reste à faire » de chaque tâche en coursL’estimation et les ré-estimations : heures ou ½ jour1h, 2h, 3h, 4h, puis 1 jour, 1,5 jours, 2 jours (pas plus !)Autre possibilité :Utiliser l’avancement de la story en %Rappel : un Stand-up NEST PAS• n’est pas un tribunal• n’est pas un moment pour les reproches et remontrances• n’est pas un lieu pour les conversations ou les débats• n’est pas un moment de reporting
  46. 46. A propos de la rétrospective• Moment de grande subjectivité : o chacun exprime son ressenti o chaque avis compte et doit être respecté• On peut utiliser un lieu inhabituel au projet (dehors ?)• Les actions d’amélioration : attention à leur nombre. Il est essentiel que toutes les actions priorisées et retenues soient vraiment réalisées à la fin du sprint => Le ScrumMaster y veille ! retour
  47. 47. Bonne route ! merci

×