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. Retours sur 4 ans
d’industrialisation de l’agilité
Rémy Génin - Orange
Octobre 2010

2. Les pièges

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. 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. Construire
SA
proposition agile

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. 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éparation
retour

8. Les rôles

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

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

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 beaucoup
Le SCRUMMASTER DOIT ETRE D’ABORD SCRUMMASTER

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

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

16. Le déroulement
du projet

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

21. 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 Agilité
Technique
● former les acteurs du projet et Fonctionnel
sensibiliser leur hiérarchie

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. Catégories de projet
et labellisation

24. 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 sportive
Formule 1

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

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

27. à 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

28. la qualité
« Orange Agile »

29. DoD … les Definition of Done
exemples
Tâ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. Une qualification au fil de l’eau
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
15 tests 40 tests 80 tests

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

32. 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 le
PMP, y compris les contraintes d’exploitabilité
Les documents d’architecture
DAT, DAF, DAL : architectures technique, fonctionnelle, logicielle
Spécifications fonctionnelles
Il 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, les
descriptions (alimentées au fil des développements) des sauvegardes,
supervision, ordonnancement, gestion des erreurs retour

33. Outils pour
l’agilité

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

35. Les outils : Backlog

36. Les outils : Storyboard

37. Les outils : Reporting

38. Les outils – Gestion documentaire

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

40. Faire un backlog produit

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

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

43. A propos des
« cérémonies »

44. 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 !

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

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. Bonne route !
merci