Priorisation Agile
Auteur : Mike Griffiths
Source : Agile Prioritisation
Date : 15/07/2011
Traducteur : Fabrice Aimetti
Date : 21/07/2011
Traduction :
Toutes les méthodes agile utilisent des systèmes de priorisation. Même si la terminologie varie - Scrum parle par exemple d'un "backlog produit", FDD d'une "liste de features" et DSDM d'une "liste d'exigences priorisées" - le concept reste le même. Le projet fonctionne grâce à une liste hiérarchisée d'éléments pour lesquels on peut discerner une valeur métier.
La priorisation est nécessaire car elle permet d'adapter le périmètre pour satisfaire les objectifs budgétaires ou calendaires, tout en conservant un ensemble utile de fonctionnalités (Version Minimale Commercialisable[1])
La priorisation fournit également un cadre pour décider s'il faut et quand intégrer les changements. En demandant au métier "Dites-moi une chose qui est plus importante qu'une autre ?" puis en insérant ce nouveau changement à l'endroit approprié dans la liste des travaux priorisés, il est possible d'intégrer les changements.
Ça vaut la peine d'expliquer que même si les méthodes agiles offrent une grande flexibilité grâce à la capacité d'accepter les changements de dernière minute, ils ne peuvent pas plier les lois du temps et de l'espace. Donc, si le budget et le calendrier de votre projet prévoit de consommer entièrement le périmètre actuel, alors ajouter un nouveau changement va inévitablement forcer une feature de priorité inférieure à passer en dessous de la limite de ce que nous comptons livrer. Donc, oui, nous pouvons accepter les changements de dernière minute ... mais seulement aux dépens des éléments de plus faible priorité.
Une unique liste des travaux priorisés simplifie également la visibilité sur le reste à faire. Au lieu de séparer les demandes de changement, corrections d'anomalie et nouvelles features, les gens obtiennent une vue complète et claire du reste à faire en les combinant dans une seule liste priorisée. Beaucoup d'équipes passent à côté de ce point en conservant des budgets pour les demandes de changement et les corrections d'anomalie. Cela trouble la vélocité ; une unique liste priorisée du travail à faire, indépendamment de l'origine de ce travail, offre une meilleure transparence et un meilleur axe de négociation.
Derrière chaque système de priorisation se cache une personne qui priorise
La manière dont nous allons obtenir les priorités (et utiliser un système de priorisation) varie d'une méthode à l'autre - et parfois d'un projet à l'autre - en se basant sur ce qui fonctionne pour l'entreprise. Un système de priorisation simple consiste à étiqueter chaque élément avec"Priorité 1", "Priorité 2", "Priorité 3", etc. Bien que simple, le problème avec ce système est que tout a tendance à prendre la "Priorité 1" - ou qu'au minimum trop de choses sont étiquetées "Priorité 1" pour être réellement efficace. Il est rare qu'un représentant du métier demande une nouvelle fonctionnalité et dise qu'il s'agit d'une Priorité 2 ou 3, car il sait qu'une faible priorité peut passer en dessous de la limite. Les priorités "élevée", "moyenne" et "basse" subissent le même sort. Sans une raison argumentée et partagée de ce qui définit une priorité "élevée", nous nous retrouvons avec un trop grand nombre de priorité "élevée" et donc avec un manque de véritable priorité.
DSDM a popularisé le système de priorisation MoSCoW, qui tire son nom des premières lettres de ses étiquettes "Must..."[2], "Should..."[3], "Could..."[4], "Wouldn't"[5]. Avec MoSCoW, il est plus facile d'argumenter. Les "Must-have" sont des exigences fondamentales pour la viabilité du système ; sans elles, le système ne fonctionne pas ou n'a aucune valeur. Les "Should-have" sont des exigences importantes ; par définition, nous en avons besoin pour que le système fonctionne correctement ; si elles sont absentes, alors le produit se révèlera probablement coûteux ou lourd à utiliser. Les "Could-have" apportent une valeur ajoutée tangibles, et les "Wouldn't-have" sont des exigences dûment enregistrées mais qui auront peu de chances d'être traitées[6].
Une approche que j'ai vu bien fonctionner est de donner des billets de Monopoly aux sponsors du produit, égalant le budget du projet, et en leur demandant de les répartir parmi les features du système. C'est utile pour obtenir une priorité générale sur les composants du système mais ne poussez pas trop loin son usage en cherchant à l'appliquer à des activités perçues comme ayant une fable valeur ajoutée comme la documentation, donc réservez son usage aux features métier.
Si vous n'avez pas de billets du Monopoly à disposition, la méthode des 100 points, initialement créée par Dean Leffingwell et Don Widrig pour les cas d'utilisation, peut être utilisée à la place. C'est un système de vote où l'on donne 100 points à chaque partie prenante qu'elle peut utiliser pour voter en faveur des exigences les plus importantes. La façon dont ils distribuent les 100 points les concerne : 20 ici, 10 là ou alors carrément 100 sur une seule exigence si c'est leur seule priorité.
Le Modèle de priorisation des exigences[7], créé par Karl Wiegers, est une méthode mathématique plus rigoureuse pour calculer la priorité. On évalue le bénéfice, la perte, le coût et le risque sur une échelle relative de 1 à 9 (faible vers élevé) pour chaque feature proposée. Les clients évaluent le score du bénéfice à disposer de la feature, le score de la perte à ne pas en disposer. Les développeurs évaluent le coût pour produire cette feature et le risque associé à sa production. Après avoir enregistré les scores de toutes les features, la priorité relative de chaque feature est calculée en considérant le pourcentage pondéré de souhait de chaque feature. Pour plus de détails et un lien vers un exemple, voir First Things First: Prioritizing Requirements de Karl ; pour une analyse plus complète des modèles mathématiques sur la priorisation des exigences, jetez un coup d'œil à l'article US-CERT .
Pas de système comme système
A la fin de la journée, c'est la priorité des features qui compte, pas le système de priorisation utilisé. Parfois, arbitrer sur le système de priorisation peut nuire en prenant trop de temps à en discuter. Pour cette raison, je suis personnellement fan de tout simplement demander au métier de lister les features par ordre de priorité. Pas de catégorie 1, 2, ou 3 ; pas de élevé, moyen ou bas; pas de must-have, etc. mais plutôt une simple liste (dans Excel ou un outil agile de gestion des exigences). Cela supprime les catégories sur lesquelles les gens ont tendance à faire une fixation et à débattre et focaliser les discussions sur les priorités.
Conclusion
Faites preuve de créativité par tous les moyens et essayez différents systèmes pour que le métier s'engage à établir les priorités. Il n'y a pas de moyen unique et parfait pour systématiquement affecter une priorité ; essayez plutôt de diagnostiquer les problèmes survenant dans le processus de priorisation, que ce soit un "manque d'implication" ou "trop de priorité 1", puis expérimentez des approches telles que les billets de Monopoly, MoSCoW ou une simple liste pour vous aider si les problèmes ne peuvent pas être résolus par le dialogue. L'objectif est de comprendre comment les features interagissent les unes par rapport aux autres plutôt que d'attribuer une étiquette. En maintenant une liste flexible d'exigences priorisées et en ayant la possibilité de revisiter les priorités, nous maintenons l'objectif de l'agilité de livrer l'ensemble des features de plus haute valeur ajoutée dans le temps et le budget disponibles.
A l'origine, j'ai écrit cet article pour Gantthead.com, paru en avril 2011 ici .
[1] Minimum Marketable Release
[2] NdT : Viable
[3] NdT : Essentiel
[4] NdT : Confort
[5] NdT : Luxe
[6] NdT : on dit même qu'il s'agit de la zone d'optimisation budgétaire du client
[7] NdT : voir l'article traduit : Première chose à faire, prioriser les exigences
