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
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).
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
relase – Valable pour évaluer l'avancement – Quantifier la valeur métier des user stories • Burndown à 2 échelles – Complexité réalisée – Valeur métier réalisée – 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) 0 20 40 60 80 100 120 0 50 100 150 200 250 300 1 2 3 4 5 6 7 8 Story points Valeur
– 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
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
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
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 j, pb de lissage • Noter les évènements sur le burndown – Sanity check (et correction à apporter) 0 50 100 150 200 250 Optimiste Pessimiste
à faire pessimiste en points) – Suppression/ajouts pour visualiser l’évolution du périmètre • Evaluation d'une vélocité, pb lissage • Date d'aterissage à chaque sprint review -200 -100 0 100 200 300 400 3 pires 3 dernières 3 meilleures Suppr - Ajouts
• 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
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
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)
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) ?
pierre_fauvel
wunderbar
tcmktdev
c0rp_mdm
pictoria
hdn_tocci
.png){kind=icon}
newmo
kenjisugiura
ashisuto_career
chiemitaki
matsuritechnologies
400f
hrm
holman
philhawksworth
3n
chrisshort
eitanlees
ddemaree
trishagee
caitiem20
rocio
samanthasiow
yeseniaperezcruz
marktimemedia
![www.clubagile.org Pour Poursuivre • Email : [email protected] • Twitter :](https://files.speakerdeck.com/presentations/bac6a5a076db01303b6712313940e31d/slide_36.jpg){kind=link}