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

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

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

Construire SAproposition agile

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

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

Les rôles

Les rôles agiles – La base« Product Owner » responsable du contenu fonctionnel« ScrumMaster » facilitateur en l’agilité une équipe de développeurs

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

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.

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

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)

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

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

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

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’

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é

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)

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

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

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

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.

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 ? »

à 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

la qualité« Orange Agile »

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.

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

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

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

Outils pour l’agilité

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

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

Faire un backlog produit

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

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

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

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

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

Bonne route ! merci

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

by atnantes on Oct 14, 2011

Accessibility

Upload Details

Usage Rights

1 Embed 1,228

Statistics

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