Des KPIs plus intelligents pour de meilleures dï¿?cisions (1/3)

Parmi les nombreuses questions auxquelles les managers doivent répondre lorsqu'ils pilotent un projet, il y en a 2 récurrentes auxquelles XQual peut grandement faciliter la réponse :

• Où en sommes-nous dans notre progression ?
• Cette version est-elle prête pour la mise en production ?

Beaucoup de managers ne s'appuient guère plus que sur des burn-down charts ou des fever charts, une liste de livrables dûs et de jalons cibles, et le "ressenti" de l'équipe.
Bien souvent, la question d'un manager sur "Comment le projet progresse-t-il ?" est comprise comme "Livrons-nous assez vite pour livrer dans les temps (et si possible dans le périmètre et le budget prévus) ?".

Ce n'est pas tout à fait le même angle.

La seconde question porte sur le "respect des délais", tandis que la première porte sur le "périmètre, la qualité, la maintenabilité et le délai".

Plutôt que de nous concentrer uniquement sur l'estimation du travail restant, nous devrions mesurer et traiter les questions suivantes :
À tout moment, vous connaissez la couverture de votre Application/Solution/Release/Sprint en termes de périmètre, de tests, de qualité et de documentation.

Quel que soit votre cycle de livraison et votre stratégie de test, vous pouvez disposer du même niveau d'information. Vous pouvez répondre aux questions ci-dessus avec des métriques documentées. Vous pouvez prendre des décisions (par exemple ajouter des ressources, adapter le périmètre, adopter une approche de test moins risquée...) pendant le projet.

Vous pouvez également prendre la bonne décision au moment de la mise en production : il ne s'agit plus seulement de savoir "avons-nous traité tout ce qui était demandé ?", mais "livrons-nous le bon périmètre avec une qualité suffisante et serons-nous capables de le supporter et de le maintenir ?"

Périmètre

Dans ce qui suit, nous prendrons l'exemple d'un projet agile - bien que cela s'applique de la même façon à un projet en processus unifié, en cycle en V, etc.

Chaque story passe par 3 étapes :

• New : vous avez identifié le titre de la story, vous savez qui peut aider à affiner le besoin
• Ack : vous avez défini comment les demandeurs et/ou utilisateurs valideront qu'elle répond à leurs besoins
• Approved : tout le monde semble comprendre la même chose et vous avez capturé les informations détaillées (par exemple les règles de calcul, la structure de l'IHM, les données d'entrée et de sortie...)

Au début de chaque Sprint, il est recommandé d'avoir 100% du backlog du Sprint identifié ou défini et éventuellement détaillé dans une certaine mesure. Au moins quelques conversations 3 devraient avoir eu lieu entre toutes les parties prenantes lors du Sprint planning.

Lorsque vous utilisez XQual, vous gérez les Stories comme des "exigences" XQual. Pour chaque Story, il y a une exigence.

Dans un tel contexte agile, l'une des nombreuses pratiques consiste à créer un SUT (System Under Test, système sous test) par Sprint (par exemple "my solution v1.0s5" pour le Sprint 5 de la V1.0). Vous liez ensuite les exigences (les Stories dans notre exemple) au SUT. Cela définit le périmètre du sprint.


Vous obtenez alors la couverture de base des exigences comme indicateur. Il s'agit du nombre de exigences (dans cet exemple des "Stories") qui doivent être implémentées dans le SUT (ici "pendant le Sprint"). Dans notre exemple, nous avons lié 10 exigences à ce SUT et nous avons une couverture de base des exigences de 100%.

Comme cela ne reflète pas toujours la réalité, XQual permet de "corriger" manuellement ce niveau de couverture. Par exemple, vous pourriez indiquer que vous prévoyez en fait d'obtenir 20 Stories dans le Sprint, ce qui donne une couverture des exigences actuelle de 50% - autrement dit, il vous manque encore 10 Stories. C'est déjà mieux que le résultat de la couverture de base des exigences. Nous appelons cela la couverture corrigée des exigences.


Mais cela répond encore mal à notre question : "Où en sommes-nous dans la couverture de notre périmètre ?" Car dans un tel cas, nous ne savons pas si l'une de ces stories peut effectivement être conçue et développée. Il s'agit néanmoins d'une métrique utile mais insuffisamment précise. La couverture corrigée des exigences ne soutient pas bien notre processus de décision.

En revanche, la couverture pondérée des exigences d'XQual est déterminée automatiquement en fonction du statut et de la priorité de chaque exigence. À mesure que l'équipe de développement fait progresser les exigences à travers les conversations et les ateliers de confirmation avec les autres parties prenantes, la couverture pondérée des exigences progresse elle aussi automatiquement en temps réel.

Vous pouvez désormais répondre avec confiance à la question : "à 50% du temps écoulé du sprint, nous avons 70% de notre périmètre qui est défini - nous sommes dans la zone verte sur cet aspect" ou "à 2 jours avant la revue de sprint, nous avons couvert 80% du périmètre ! Nous devons repousser 2 Stories au Sprint suivant".

Exemple chiffré

Imaginons un cas où un SUT est couvert par une seule exigence.
- Si l'exigence est au statut New (il s'agit d'une story critique qui a été identifiée), sa couverture serait de 100%*10%=10%
- Lorsque l'exigence passe à Ack, la couverture progresse et devient 100%*35%=35%
- Lorsque l'exigence passe à Approved, sa couverture devient 100%*100%=100%

Comme vous pouvez le constater, 10%, 35% et 100% seraient des poids personnalisables que nous pouvons affecter à chaque statut.

Le même système de pondération peut être utilisé pour chaque priorité. En effet, il est logique d'accorder plus de poids aux exigences de haute priorité qu'à celles de priorité basse.

Imaginons que vous choisissiez d'utiliser les paramètres de pondération suivants :


Ensuite, si nous reprenons notre exemple avec 10 exigences (où il nous en manque encore 10, donc la couverture corrigée des exigences est de 50%), chacune ayant un statut et une priorité différents, nous pourrions avoir le cas suivant :


Sur l'ensemble des exigences que nous avons, nous obtenons une couverture globale des exigences de 42%.
Voici comment elle est calculée :

Cela signifie une couverture pondérée des exigences de 50%*42%=21%

Au fil du temps, la couverture pondérée progressera, en fonction du nombre d'exigences rattachées au SUT et du statut et de la priorité de chaque exigence.

Imaginons que nous ayons un sprint avec 14 user stories. Nous n'attendons pas d'autres user stories, donc la couverture corrigée des exigences est de 100%. Toutes les stories sont au moins au statut New, vous pourriez obtenir un profil de progression comme celui présenté en Figure 5. Dans cet exemple, on peut voir qu'à 50% de la durée du sprint, nous avons atteint 75% de couverture pondérée des exigences et que le nombre d'exigences reste stable depuis le début du sprint.

Vous pouvez non seulement gérer votre risque de couverture des exigences pendant le projet, mais aussi vérifier qu'elle est couverte à 100% à la fin du sprint.



Prenons maintenant un cas moins favorable. Imaginons que le product owner soit en retard dans la définition du backlog. Il/elle propose un nombre limité de user stories au début du Sprint, en s'attendant à en proposer davantage pendant le sprint - certes... nous convenons que ce n'est pas une bonne pratique lorsqu'on pratique l'agilité de type Scrum. Au jalon de mi-sprint, la situation est que seulement 40% du périmètre est prêt pour l'implémentation et qu'il manque encore certaines stories.



Que décideriez-vous dans une telle situation ?
Les pratiques que vous pourriez adopter face à un tel risque (définition tardive du périmètre et progression lente de sa définition) dépendent beaucoup du contexte du projet et de la culture de l'organisation.

Dans ce cas, nous pourrions donc : - envisager de réduire le périmètre comme en Figure 7 (en repoussant certaines user stories au Sprint suivant) pour avoir une chance de livrer quelque chose de valeur et avec la bonne qualité. - Vous pourriez également mobiliser davantage de ressources pour traiter davantage de stories... si vous disposez de telles ressources en milieu de sprint (attention : cette action a des limites, rappelez-vous que 3 femmes ne peuvent pas travailler ensemble pour mettre au monde un bébé en seulement 3 mois).

Conclusion sur notre exemple

Quelles que soient vos décisions, compte tenu de vos contraintes, ce qui est important ici, c'est de disposer d'un outil pour mesurer et gérer vos risques concernant le périmètre. C'est un Smart KPI. Tout manager tirerait grand bénéfice à obtenir ce KPI, en temps réel.
XQual calcule cela pour vous, par SUT, par Dossier de SUT... Cela fonctionne donc pour un produit, une application, un Sprint, une Release ou un Programme.

Aucune organisation ne ressemble à une autre. Par conséquent, les poids personnalisables que nous avons utilisés dans ce livre blanc ne sont que des exemples. XQual permet de définir vos propres poids. Les valeurs par défaut proposées par XQual sont toutefois adaptées à la plupart des organisations.

Différentes organisations pourront exploiter et utiliser ce KPI à différents niveaux ou instances de gouvernance : chef de projet, release manager, responsable QA/UAT, CTO et même au niveau du CEO.