Bonjour la commu,
Je suis dans une structure publique qui fait appel à une ESN pour les compétences techniques de l’équipe. Les contrats de prestation mentionnent l’usage de métriques pour s’assurer de la qualité du travail fourni par cette partie de l’équipe. Avez-vous des idées d’indicateurs (qui font du sens et apportent aussi de la valeur à l’équipe…) permettant in fine de statuer sur la qualité du travail réalisé ?
La config de l’équipe est complexe car les devs prestataires sont partie intégrante de l’équipe SCRUM.
L’équipe :
2 testeurs (fonctionnels et peu techniques)
1 PO
3 dev fullstack externes
1 Scrum master
Merci pour votre aide,
N’hésitez pas à poser des questions si vous avez besoin d’éclaircissement
A ce que je sache, il n’y a pas d’indicateur reconnu aujourd’hui qui puisse statuer sur la qualité. J’aurais deux pistes à donner et une mise en garde.
Pistes :
Accelerate et DORA (pas l’exploratrice ) sont les fruits d’études statistiques annuelles et mettent en avant certaines pratiques et métriques. Parmi les métriques, il y a les 4 clés : temps moyen de restauration de service, taux d’échec de changement, temps de cycle de livraison, fréquence de livraison. Les pratiques permettraient l’amélioration de ces quatre métriques ce qui permet l’amélioration de la performance organisationnelle (parts de marché, satisfaction des utilisateurs, chiffre d’affaire…). Le framework SPACE et le programme de recherche DevEx s’inscrivent dans la continuité de DORA.
Il existe différentes communautés et normes autour de la qualité logicielle :
Mise en garde : La valorisation de métriques peut très souvent produire des comportements inattendus. Dans un premier temps, je te recommande mon article qui donne quelques explications et différents liens à explorer sur le sujet.
Bonjour William,
Je souhaitais tout d’abord te remercier pour ta réponse et les différents pointeurs qui vont être le fruit de nouvelles trouvailles pour moi !! Ton article me fait me poser encore plus de questions…
Voici ci dessous mes quelques pistes de réflexion qui font suite a ton message.
Au demeurant, la grande question qui me vient, dans mon contexte, est la suivante : dans le cadre d’un projet de développement logiciel, qu’attendons nous d’une prestation externe technique dans un cadre agile ? Que payons nous ? Un ensemble de fonctionnalités, un résultat sans le détail des fonctionnalités ou seulement une prestation professionnelle sans objectif de résultat ?
Un ensemble de fonctionnalités me semble aller à l’encontre de l’adaptabilité, fondement de l’agilité.
Un résultat sans le détail des fonctionnalités, me semble plus intéressant bien qu’il faudrait être prêt à fréquemment contractualiser à chaque fois que l’équipe s’engage. (Dans scrum, ce serait à chaque itération/sprint)
Une prestation professionnelle sans objectif de résultat me semble être possible que par une confiance mutuelle (et donc non quantifiable, ni contractualisable) qui s’établit puis s’entretient tout au long de la vie du projet.
Je manque encore de biblio sur le sujet mais je suis dit que ce partage pouvait être intéressant.
) sont les fruits d’études statistiques annuelles et mettent en avant certaines pratiques et métriques. Parmi les métriques, il y a les 4 clés : temps moyen de restauration de service, taux d’échec de changement, temps de cycle de livraison, fréquence de livraison. Les pratiques permettraient l’amélioration de ces quatre métriques ce qui permet l’amélioration de la performance organisationnelle (parts de marché, satisfaction des utilisateurs, chiffre d’affaire…). Le framework 
Ton article me fait me poser encore plus de questions…