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