2. Plan
• Focus de l’agilité
• De quels indicateurs parle-t-on ?
• Par grands domaines, quels indicateurs adopter :
• Le projet vu de l’extérieur
• Le facteur humain
• La réalisation
• La qualité de l’ingéniérie
• Conclusion
www.clubagile.org
3. Focus de l’agilité
The Agile Executive
http://theagileexecutive.com/2010/07/22/the-devops-triangle/
www.clubagile.org
5. Qu’est-ce qu’un indicateur ?
Définition « à la » CMMI
Un indicateur est une mesure d'un aspect d'un
projet.
Des seuils d'alertes (valeurs limites, nature et
amplitude des variations) permettent de
déterminer qu'une action est à mener (ou pas).
www.clubagile.org
6. Indicateurs Agiles quel point de vue ?
Alignement aux Déroulement du
principes agiles Projet
Projet / Process
Création de
Valeur pour le
Business
www.clubagile.org
7. Caractéristiques des indicateurs
• Indicateur sur la tenue des objectifs de l’agilité ou sur la mise
en œuvre des moyens intermédiaires pour les atteindre
– Moyens (livraison continue, communication avec le métier, …).
• Selon les étapes : Indicateurs au niveau release / au niveau itération / en
flux continu.
• Selon qui les consulte : L’équipe, le scrum master, le product owner, les
« stakeholders »
• Visuels / Quantitatifs
– Visuels : Les dérives visibles permettent de lancer un dialogue et de prendre
des décisions d’équipe.
– Quantitatifs: Ces indicateurs permettent d’indiquer un tendance
www.clubagile.org
8. Les indicateurs par domaine
Par groupe et pour chaque domaine, identifier les indicateurs qui
seraient pertinents pour votre projet
www.clubagile.org
9. Le projet vu de l’extérieur.
Indicateurs…
www.clubagile.org
11. Valeur produite
– Indicateur parfois dévoyé:
• Burndown de relase
– Valable pour évaluer l'avancement 300 120
250 100
– Quantifier la valeur métier des 200 80
user stories 150 60
• Burndown à 2 échelles 100
Story points
40
50 Valeur 20
– Complexité réalisée
0 0
– Valeur métier réalisée 1 2 3 4 5 6 7 8
– Idée : arrêter à 80% de la valeur
métier
• On ne compte que la valeur des
user stories entièrement terminées
et acceptées (démo + recette)
www.clubagile.org
12. … sur la satisfaction
du client ?
www.clubagile.org
13. Satisfaction client
– Qualitatif
• feedback à la démo
– Est-ce que le client prolonge le projet (SSII) ?
– Si les utilisateurs sont internes à l’entreprise
• Evaluation de l'utilisation de l'application
– Nb utilisateurs
– Temps gagné
– Si site internet
• activité du site
• business engendré
– Bref : les € gagnés
www.clubagile.org
15. Bugs
– Indicateurs contestables
• Nb de bugs produits par l'équipe de devt et nb de bugs
trouvés par l'équipe de recette
– Si la qualité s'améliore, on pénalise l'équipe de recette
– Si l'équipe de recette multiplie les bugs inutiles, on pénalise
l'équipe de devt
• Taux de défaut :
– Impression de somme des choux et des carottes : faute
d'ortographe vs pb de perfs vs algo complexe foireux
– Nombre de bugs par sévérité métier trouvés en
production
www.clubagile.org
18. Epanouissement de l'équpe
– Mauvais indicateurs :
• Le chef de département
passe et demande si ca va
– Question fermée
– Qualitatif : retours en
rétrospective
• Question ouverte : qu'est-ce
qui ne va pas.
• Réunion facilité (par le
scrum master)
• Retours “protégés” (on se
sent libre de parler)
– Quantitatif : niko-niko
www.clubagile.org
19. … sur le rythme
de travail ?
www.clubagile.org
20. Respect d'un rythme "sustainable"
– Nbre d'heures sup
– Stabilité du nombre d'heures travaillées dans
l'itération
www.clubagile.org
23. Avancement (1/2)
– Indicateurs contestables
• Charge consommée
• Reste à faire psychologique
– Simplement : le task board
• Affiche les travaux en cours pour
l’équipe et pour les personnes non
impliquées,
• Permet de s’assurer qu’il n’y a pas trop
de taches en cours (Work In Progress),
– Au niveau de l'itération
• Burndown (Reste à faire « pessimiste »
en heures idéales)
• Evaluation d'une velocité en hi par 250
Optimiste
j, pb de lissage 200
Pessimiste
• Noter les évènements sur le 150
burndown
– Sanity check (et correction à 100
apporter) 50
0
www.clubagile.org
24. Avancement (2/2)
– Au niveau release
• Burndown (Reste à
400
faire pessimiste en
300
points)
– Suppression/ajouts
200
pour visualiser 100
l’évolution du 0
périmètre -100
• Evaluation d'une -200
vélocité, pb lissage 3 pires 3 dernières
3 meilleures Suppr - Ajouts
• Date d'aterissage à
chaque sprint review
www.clubagile.org
26. Productivité
– Indicateurs contestables (dissuadent l’entraide)
• Productivité individuelle
• Productivité par spécialité
– Nb d'heures idéales / JH
• productivité, mais relative à la notion de temps idéal
– compte-t-on les bugs ? les estime t on tous ?
• Evolution (l'équipe se "forme" t'elle, gagne-t-elle en compréhension des technos, y a-t-il
un impact de la dette technique)
– Nb de story points / jh
– Nb de "points de valeur" / jh
• Evolution : l’équipe a-t-elle su progresser et livrer de plus en plus de valeur à budget égal
?
– Peut-on vraiment diviser par jh ?
• Compte-t-on les bugs ? les estime-t-on tous ?
• La productivité constatée montrera des baisses lors de certains évenements : l’arrivée
des nouveaux par exemple.
– Cycle time (pour la maintenance)
– Elimination des gaspillages
www.clubagile.org
28. … sur la qualité de
l’ingéniérie ?
www.clubagile.org
29. Métriques d'ingéniérie
– Nombre de fois où le build a été cassé (Objectif 0)
– Temps maximum mis pour réparer le build (Objectif 15min)
– Fréquence de commit par les développeurs (Une fois tous les 2 jours
minimum)
– Couverture du code par les tests automatisés (objectifs différenciés)
– Qualimétrie
• Complexité
– se donner un seuil max de complexité cyclomatique par méthode
• Couplage
– se donner un seuil max de couplage entre les classes de packages différents
• Duplication
– se donner un seuil max de % de duplication de code
• PMD/Checkstyle/Findbugs,
– n'activer que les règles utile, s'interdire toute violation d'une règle MAJEURE, se donner un
nombre max de violation de règle mineure
• Conventions de nommages
– seuil = 0 violation
• Respect des principes d’architecture
– seuil = 0 violation, faire évoluer les règles si cas particulier
www.clubagile.org
31. Environnement technique
– Remontées en retrospective
– Impact sur la productivité des outils et
frameworks techniques
– Temps qu’il faut à un développeur pour lancer
l’application suite à une modif dans l’ide (sans les
tests unitaires),
– Temps que mettent les différents builds (build de
base + TU, build avec les tests fonctionnels)
www.clubagile.org
33. Si vous deviez sélectionner 3 indicateurs
pour votre projet ?
www.clubagile.org
34. Si vous deviez sélectionner 2 indicateurs
pour votre projet ?
www.clubagile.org
35. Si vous deviez sélectionner 1 indicateur
pour votre projet ?
www.clubagile.org
36. Questions ouvertes
– Que dire de contrats basés sur des engagements
sur des indicateurs ?
– Que dire de la comparaison d’indicateurs entre les
différents projets d’une entreprise (ou même
d’autres entreprises) ?
www.clubagile.org