Événements

1. Événements PMI : Conférence "SCRUM, plus qu’une méthode, un état d’esprit" à Lyon le 24 mars 2011, INSA.

2. Le 5 avril Mix-IT, ... DES IDEES POUR TOUT DE SUITE !25 speakers ... Mardi 5 Avril ... Lyon ... 200 participants !

3. Les indicateurs agiles

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

5. Focus de l’agilité • The Agile Executive • http://theagileexecutive.com/2010/07/22/the-devops-triangle/

6. Focus de l’agilité/Lean Connaissance Amélioration continue Partenaires / Clients Équipe

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

8. Indicateurs Agiles quel point de vue ? Alignement aux principes agiles Déroulement du Projet Projet / Process Création de Valeur pour le Business

9. 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 productowner, 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

10. Les indicateurs par domaine Par groupe et pour chaque domaine, identifier les indicateurs qui seraient pertinents pour votre projet

11. Le projet vu de l’extérieur. Indicateurs…

12. … sur l’avancement vu par le client ?

13. Valeur produite • Indicateur parfois dévoyé: • Burndown de 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)

14. … sur la satisfaction du client ?

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

16. … sur les bugs injectés ?

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

18. Le facteur humain. Indicateurs…

19. … sur l’épanouissement de l’équipe ?

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

21. … sur le rythme de travail ?

22. Respect d'un rythme "sustainable" • Nbre d'heures sup • Stabilité du nombre d'heures travaillées dans l'itération

23. La réalisation : indicateurs…

24. … sur l’avancement ?

25. Avancement (1/2) • Indicateurs contestables • Charge consommée • Reste à faire psychologique • Simplement : le taskboard • 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)

26. Avancement (2/2) • Au niveau release • Burndown (Reste à 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

27. … sur la productivité ?

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

29. L’ingéniérie. Indicateurs…

30. … sur la qualité de l’ingéniérie ?

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

32. … sur l’environnement technique ?

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

34. Conclusion

35. Si vous deviez sélectionner 3 indicateurs pour votre projet ?

36. Si vous deviez sélectionner 2 indicateurs pour votre projet ?

37. Si vous deviez sélectionner 1 indicateur pour votre projet ?

38. 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) ?