Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilité chez orange
description
Transcript of Agile Tour Nantes 2011 - Rémy génin - retours d'expérience sur 4 ans d'agilité chez orange
Retours sur 4 ans d’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 ownerpas assez disponible, pas assez compétent, non-légitimé
• des moyens insuffisantspas 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
ConstruireSA
proposition 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’expertise
Un centre d’expertise est là pour vous aider et vous accompagner dans tout ce 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 ponctuel
Un site intranet pour centraliser l’information et les documents partagés, des FAQ, des fiches pratiques, des explications détaillées
Une communauté avec des forums par rôle agile
Un « mode d’emploi » informatisé en préparationretour
Les rôles
Les rôles agiles – La base
« Product Owner »responsable du contenu fonctionnel
une équipe de développeurs
« 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=> 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 agile
Coach 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 beaucoup
Le 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égression
Compé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 story
Dans les 2 cas, on peut utiliser le kanban pour fluidifier le travail
ou identifier les goulots d’étranglement
Le 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éroulementdu projet
Une autre façon d’aborder le projet
Habituellement, on définit le scope fonctionnel, puis on cherche à déterminer la 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 plus
Conséquence :
- une release normale durera environ 8 moisune 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 Etude Etude Etude
dddd’’’’opportunitopportunitopportunitopportunitééééConceptionConceptionConceptionConception DDDDééééveloppementveloppementveloppementveloppement DDDDééééploiementploiementploiementploiement GGGGéééénnnnééééralisationralisationralisationralisation
T-1 T0 T1 T2 T4
StabilisationStabilisationStabilisationStabilisation Clôture du Clôture du Clôture du Clôture du
ProjetProjetProjetProjetT3a
Revue de Revue de Revue de Revue de StabilisationStabilisationStabilisationStabilisation
S6 S5 S4 S3
Validation Validation Validation Validation
de la de la de la de la
releasereleasereleaserelease
T1c
Revue Revue Revue Revue
TechniqueTechniqueTechniqueTechnique
Quelques Quelques Quelques Quelques
pratiques pratiques pratiques pratiques
agilesagilesagilesagiles
Toutes les Toutes les Toutes les Toutes les
pratiques pratiques pratiques pratiques
agilesagilesagilesagiles
T1x
T3
S1
S2
T1x : qualification utilisateursT1x : qualification utilisateursT1x : qualification utilisateursT1x : qualification utilisateurs
T1c : conditions dT1c : conditions dT1c : conditions dT1c : conditions d’’’’exploitabilitexploitabilitexploitabilitexploitabilitéééé OKOKOKOK
GO prononcGO prononcGO prononcGO prononcéééé
PrononcPrononcPrononcPrononcéééé pour la pour la pour la pour la
premipremipremipremièèèère mise en re mise en re mise en re mise en
productionproductionproductionproductionT1a, T1b supprimT1a, T1b supprimT1a, T1b supprimT1a, T1b supprimééééssss
� non utilisé dans un projet agile
� inclus dans le déroulement de chaque sprint
ExplorationExplorationExplorationExploration DDDDééééveloppement itveloppement itveloppement itveloppement itéééératif & ratif & ratif & ratif &
qualification dans les sprintsqualification dans les sprintsqualification dans les sprintsqualification dans les sprints
PrPrPrPréééé----
éééétudetudetudetude
Etude Etude Etude Etude
dddd’’’’opportunitopportunitopportunitopportunitéééé
Pouvoir partir en production pendant les Pouvoir partir en production pendant les Pouvoir partir en production pendant les Pouvoir partir en production pendant les
ddddééééveloppements, sur demande du mveloppements, sur demande du mveloppements, sur demande du mveloppements, sur demande du méééétiertiertiertier
La 1La 1La 1La 1èèèèrererere MEP MEP MEP MEP «««« ouvre la voieouvre la voieouvre la voieouvre la voie »»»». On pourra refaire d. On pourra refaire d. On pourra refaire d. On pourra refaire d’’’’autres MEP facilement.autres MEP facilement.autres MEP facilement.autres MEP facilement.
Charte du projet - la trade-off matrix
• En une page, la charte pose les fondements du projet, partagés par tous
Elle est entérinée à l’unanimitépar vote à main levée (Trade-off incluse).
• La « trade-off matrix » ou « matrice des compromis »
identifie LA contrainte du projet.
L’utopie du « tout-figé » au démarrage (date de livraison + budget + contenu fonctionnel) est révolue !
• But et contexte du projet, en 30 secondes
• Utilisateurs / Clients destinataires
• Avantages / bénéfices métier escomptés
• Fonctionnalités principales
• Dates principales connues (contraintes)
• Contraintes identifiées (charge, perf, etc)
• Risques majeurs identifiés
• Comment mesurer que l’objectif a été atteint ?
�Qualité
�Coûts / Ressources
�Planning
�Scope fonctionnel
Changera sûrement !
Pourrait changer
FermeFixe
Le déroulement du projet agile
Initialisation
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’exploration
Phase de Préparation & Exploration
Pré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
● former les acteurs du projet et sensibiliser leur hiérarchie
AgilitéTechniqueFonctionnel
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 agiles
Les contextes de certains projets ne permettent pas toujours d’appliquer tout ce que l’agilité propose.
Afin de cadrer et d’aider au mieux tous les projets désirant utiliser autant que possible l’agilité, il existe désormais des catégories de projets permettant officiellement d’utiliser l’agilité à la mesure de ce qui est possible
routière sportiveFormule 1
Les catégories de projets agiles
3 catégories de projets agiles permettent d’utiliser une
proposition agile cohérente et adaptée quel que soit le
contexte
• 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 fin
UN 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é comme
prétexte pour faire n’importe quoi)
conduit à des catastrophes pires qu’un cycle en V figé
Si on n’a pas les prérequis
pour commencer, il ne faut pas commencer !
retour
la qualité
« Orange Agile »
exemples
DoD … les Definition of Done
Tâche unitaire
• Compilation
• Refactoring
• Tests unitaires en local
• Intégration
• Tests sur intégration OK
User story
• Conception mise àjour
• Tests fonctionnels
• Guide util/Admin
• Intégration
• Impact exploitabilité
• Validation PO
• Affichage < 3 sec.
Sprint
• Démo faite sur les User stories « vraiment terminées »
• Doc de specsfonctionnelles mis àjour
• …
Pour pouvoir certifier le bon fonctionnement de l’application en permanence, il devient indispensable d’automatiser les tests techniques et fonctionnels et de les passer tous les jours
Une qualification au fil de l’eau
15 tests
�40 tests
�
80 tests
�
Les KPI agiles
Un certain nombre de KPI issus du mode classique ne sont plus pertinents
pour 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 plus
En tant que vecteur fort de la communication entre les services et équipes qui se succèdent sur un projet, la doc est indispensable
PMP (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, logicielle
Spé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’outil
Tous les principes qualité sont conservés.Seule leur mise en œuvre a été adaptée au contexte agile
La 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 - Hudson
Hudson 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 progressives
Pour le démarrage du projet, on demande 2 niveaux de précision : les Thèmes et les Epics
Cela donne les grandes lignes de l’investissement (SOX).
backlog produit : des specs progressives
Pendant l’exploration, le PO va détailler un seul niveau supplé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 en gé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-up
On met à jour le « reste à faire » de chaque tâche en cours
L’estimation et les ré-estimations : heures ou ½ jour
1h, 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 N'EST 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