Prioriser les features

[((/dotclear/public/photos/.dean-leffingwell_t.jpg|Dean Leffingwell|L|Dean Leffingwell))|/dotclear/public/photos/dean-leffingwell.jpg]J’ai traduit l’article ++[« Prioritizing Features »|http://scalingsoftwareagility.wordpress.com/2010/04/08/prioritizing-features/|en]++ de Dean Leffingwell. Ça a été difficile compte tenu des termes économiques utilisés mais ça reste tout de même intéressant à lire :-)%%% > Dans le dernier ++[billet|http://scalingsoftwareagility.wordpress.com/2010/04/02/estimating-features/|en]++, je décrivais un système d’estimation des features qui sera dans mon prochain ++[livre|http://scalingsoftwareagility.wordpress.com/agile-requirements-the-book/|en]++. Ce billet, prioriser les features, le complète. Ensemble, ils fournissent une stratégie raisonnable pour estimer le coût et le délai d’une feature, et une démarche systématique pour sélectionner en premier les features qui offriront la plus grande valeur ajoutée, basée sur le coût du retard. Si cela vous intéresse, vous pouvez aussi parcourir les billets de la catégorie ++[Big Picture|http://scalingsoftwareagility.wordpress.com/category/big-picture/|en]++ et la catégorie ++[Agile Requirements|http://scalingsoftwareagility.wordpress.com/category/agile-requirements/|en]++.%%% > %%% > __Introduction__%%% > %%% > Un des plus grands défis auxquels sont confrontés toutes les équipes logicielles, est de prioriser le développement et la livraison aux clients. C’est certainement un défi pour toutes les équipes agiles au début et à la fin de chaque itération, et il prend encore plus d’envergure lorsqu’il s’agit de prioriser les features à l’échelle d’un programme. Là, chaque petite décision peut avoir de gros impacts sur le coût de développement et l’opportunité de livrer rapidement de la valeur.%%% > %%% > Il y a un certain nombre de raisons pour lesquelles la priorisation reste un problème difficile :%%% > %%% > 1. Les clients sont apparemment peu enclins à prioriser les features. C’est peut-être tout simplement parce qu’ils  »veulent tout », ce qui est compréhensible ; ou peut-être qu’ils ne sont pas sûrs de ce que sont les priorités relatives ; ou peut-être qu’ils ne peuvent pas se mettre d’accord entre eux.%%% > %%% > 2. Les Product managers sont, souvent, encore plus réticents. Peut-être parce que s’ils pouvaient  »obtenir toutes les features », ils n’auraient rien à prioriser et plus important encore, ils auraient la garantie de recevoir toute la valeur finale $$Il y avait une bande dessinée Dilbert sur ce sujet. Le développeur dit au client, « s’il vous plaît dites-moi quelles sont vos priorités pour que je sache sur quoi ne pas travailler. »$$%%% > %%% > 3. Quantifier la valeur est extrêmement difficile. Certaines features sont purement et simplement « obligatoires » pour rester compétitives ou conserver des parts de marché. Comment peut-on quantifier l’impact de maintenir des parts de marché, une feature à la fois ?%%% > %%% > Pour nous aider, nous sommes souvent tenter d’estimer un retour sur investissement (~ROI) par feature, en prédisant l’augmentation probable des revenus lorsqu’une feature est disponible. Bien entendu, la détermination du ROI est très probablement une fausse science, de même qu’aucune boule de cristal ne peut prédire des revenus futurs, surtout lorsque vous vous basez sur une estimation des revenus par feature. Cette situation est aggravée par le fait que l’analyste qui fait le travail est susceptible de développer un intérêt personnel pour voir la feature développée. De plus, un product manager ou un analyste métier va probablement insister sur le ROI de ses propres features, sinon ils n’auraient pas travaillé dessus.%%% > %%% > Pourtant, en agile, le défi de la priorisation est immuable – nous admettons d’emblée que nous ne pouvons pas mettre en œuvre (ni même  »découvrir ») l’ensemble des besoins potentiels. Après tout, nous avons fixé la qualité, les ressources et le planning de livraison. Par conséquent, la seule variable d’ajustement dont nous disposons est le périmètre. Une prorisation efficace devient donc une pratique et un art obligatoire qui doivent être maîtrisés par chaque équipe agile.%%% > %%% > Bien sûr, la priorisation des exigences n’est pas un nouveau problème. Un certain nombre d’auteurs ont décrit des mécanismes raisonnables pour prioriser. Nos favoris sont :%%% > %%% > –  »Agile Estimating and Planning » (Cohn, 2006)%%% > –  »Software Requirements » (Wiegers, 1999)%%% > –  »Software by Numbers » (Deene et Cleland-Huang, 2004).%%% > %%% > Pour ceux pour qui ce sujet est potentiellement un facteur déterminant de réussite ou d’échec, nous vous préconisons aussi de prendre connaissance de ces travaux. Même si nous allons adopter une approche différente dans ce livre, il n’y a certainement pas une seule bonne façon de prioriser et les équipes bénéficieront ainsi de perspectives différentes sur ce problème unique.%%% > %%% > __Valeur / Effort en tant que ROI proxy – Une Première Approximation__ > %%% > Comme nous l’avons évoqué plus haut, nous avons traditionnellement essayé de prioriser le travail en essayant de comprendre le retour sur investissement relatif, qui est le rapport entre le rendement potentiel (la valeur) et l’effort (le coût du développement) pour une feature. Au moins, le modèle était simple :%%% > %%% > ((/dotclear/public/traductions/relative-roi.png|Relative ROI||Relative ROI))%%% > %%% > Si nous pouvions simplement établir la valeur et le coût d’une feature – sinon en termes absolus, du moins par rapport à d’autres features – alors nous aurions un moyen de prioriser fondé sur l’économie. Après tout, qui ne souhaiterait pas livrer une feature de ROI supérieur avant une feature de ROI inférieur ? Cela semble être totalement intuitif et (apparemment) du bon sens économique.%%% > %%% > __Quel est le problème avec notre ROI proxy Valeur / Effort ?__%%% > %%% > Bien que basé sur un cadre économique très complet, il s’avère que le ROI relatif (comme nous l’avons trop simplement défini ci-dessus) n’est pas un indicateur adéquat pour prioriser la valeur à livrer. Tout récemment, un point de vue plus réfléchi et plus rigoureux économiquement parlant pour prioriser la valeur à livrer ( »planification du travail » en terminologie de flux) a été exprimé dans les  »Principles of Product Development Flow » de Reinertsen (Celeritas Publishing, 2010), et que nous avons déjà présenté dans un précédent billet. Ces principes décrivent les méthodes de planification du travail basé sur les mathématiques et les principes d’économie du « lean product development ».%%% > %%% > Nous allons utiliser ces principes pour décrire une meilleure méthode de priorisation des features. En le faisant, nous allons découvrir une faille profondément enracinée dans notre hypothèse de départ – l’hypothèse selon laquelle un projet avec un grand ROI relatif devrait naturellement être prioritaire sur un projet de plus petit ROI.%%% > %%% > Au lieu de cela, nous allons comprendre la manière dont l’économie de notre programme peut être considérablement affectée par la  »planification ». Par exemple, le bénéfice potentiel pour une feature de ROI particulièrement élevé pourrait être moins sensible à un retard de calendrier qu’une feature de ROI inférieur. Dans ce cas,  »la feature de ROI inférieur devrait être développée en premier », suivie de la feature de plus grand ROI. Ce n’est pas intuitif, mais nous allons voir que cela respecte une logique économique.%%% > %%% > __La priorisation des features basée sur le coût du retard.__%%% > %%% > Puisque prioriser la valeur à livrer est le principal moteur économique, nous aurons besoin d’un modèle plus sophistiqué pour produire de meilleurs rendements. Pour construire le modèle, nous allons faire un petit détour par quelques-uns des principes fondamentaux de la théorie des files d’attente. Après tout, comme nous l’avons décrit dans un autre billet, prioriser la valeur à livrer dans le développement logiciel n’est qu’un cas particulier de la théorie des files d’attente. Ainsi, l’application de ces principes devrait créer une base solide pour la prise de décisions critiques.%%% > %%% > __Introduction au coût du retard__%%% > %%% > Comme le souligne Reinertsen, « si vous ne quantifiez qu’une seule chose, quantifiez le coût du retard » $$Principle of Product Development Flow:E3$$, donc nous devrons être en mesure d’estimer le CdR (NdT : Coût du Retard ~ CoD) dans le cadre de notre approche plus concrètement économique. (Je vous donnerai plus de détails bientôt). Heureusement, nous n’avons pas  »seulement » qu’une seule chose à quantifier, et comme nous avons déjà esquissé une stratégie d’estimation, nous serons réellement en mesure de quantifier  »deux » choses, l »’estimation de l’effort d’une feature », comme nous l’avons décrit dans le dernier billet, et le  »Coût du Retard ». Nous devrions ainsi avoir ce dont nous avons besoin.%%% > %%% > Dans « Product Development Flow », Reinertsen décrit trois méthodes pour prioriser le travail basées sur la théorie économique du Coût du Retard.%%% > %%% > __Le travail le plus rapide en premier__%%% > %%% > Lorsque le coût du retard est équivalent pour deux features, réaliser le  »travail le plus rapide » (le plus petit dans notre cas) produit les meilleurs rendements économiques, comme illustré dans la figure ci-dessous :%%% > %%% > ((/dotclear/public/traductions/shortest-job-first.png|Shortest Job First||Shortest Job First))%%% > %%% > L’impact est manifestement important : réaliser le plus petit travail a des retombées économiques  »bien meilleures » que réaliser le plus gros travail en premier. Nous arrivons donc à notre première conclusion :%%% > %%% >  »Si deux features ont le même Coût du Retard, réalisez la plus rapide d’abord. »%%% > %%% > __Le Coût du Retard le plus important en premier__%%% > %%% > Si la quantité de travail est sensiblement la même, alors la seconde approche illustre l’effet de prioriser des travaux avec le coût du retard le plus important. Encore une fois, la théorie économique est convaincante comme l’indique la figure ci-dessous.%%% > %%% > ((/dotclear/public/traductions/high-delay-cost-first.png|High Delay Cost First||High Delay Cost First))%%% > %%% > Bien sûr, cela a un sens intuitif dans ce cas aussi (même si l’intuition ne nous a pas toujours conduit à la conclusion correcte). Car si le Coût du Retard est une approximation de la valeur, et qu’une feature a plus de valeur qu’une autre et que l’on doit produire le même effort, alors on doit réaliser la première; nous le savions déjà avec notre ROI proxy Valeur / Effort. Nous avons donc notre seconde conclusion :%%% > %%% >  »Si deux features ont le même effort, réalisez le travail avec le coût du retard le plus important ».%%% > %%% > __Le travail pondéré le plus rapide en premier__%%% > %%% > Maintenant que nous avons vu l’impact, nous comprenons que ces deux conclusions sont tout à fait raisonnables lorsque la taille ou le coût du retard des deux features sont comparables. Bien sûr, nous ne sommes pas ici en train de fabriquer des gadgets. Le coût du retard et l’effort de développement des différentes features logicielles sont très variables. De plus, ils ont souvent de faibles voire aucunes corrélations (c’est-à-dire que certains travaux à forte valeur ajoutée sont faciles à faire et d’autres sont difficiles); c’est la même chose pour un logiciel. Dans le cas où le coût du retard et l’effort pour une feature sont très variables, alors la meilleure rentabilité est atteinte lorsque nous les développons dans l’ordre du  »Travail pondéré le plus rapide en premier ».%%% > %%% > Dans ce cas, nous calculons le poids de la priorité relative d’un travail en divisant le coût du retard par l’estimation de sa taille. Si les coûts du retard et les tailles varient beaucoup, alors les écarts de rendement peuvent être énormes, comme l’illustre la figure ci-dessous.%%% > %%% > ((/dotclear/public/traductions/weighted-shortest-job-first.png|Weighted Shortest Job First||Weighted Shortest Job First))%%% > %%% > Voilà donc l’approche que nous privilégions pour le développement de logiciels :%%% > %%% >  »Si deux features sont de tailles et de coûts du retard différents, traitez la feature pondérée la plus rapide en premier. »%%% > %%% > __Estimer le Coût du Retard__%%% > %%% > Cela semble être un modèle de décision prometteur pour la priorisation des features. Il est basé sur de solides théories économiques et est tout à fait rationnel une fois que vous le comprenez. Toutefois, nous avons exclu un petit élément – comment fait-on pour calculer le coût du retard pour une feature ? Si nous n’y prenons pas garde, nous pourrions tomber dans le piège que nous avons mentionné plus haut – passer trop de temps à calculer des estimations de la taille des features – ainsi qu’à calculer le coût du retard – pourrait conduire à trop de gaspillage et à un risque de partialité de la part de ceux qui font le travail. Nous avons donc besoin de quelque chose de plus simple.%%% > %%% > Nous suggérons que la coût du retard – si essentiel à nos critères de décision – soit à son tour, le regroupement de trois attributs d’une feature, dont chacun peut être estimé assez facilement, si on la compare à d’autres features. Ce sont la  »valeur utilisateur », la  »valeur temps », et la  »valeur découverte de l’information ».%%% > %%% > – la  »valeur utilisateur » est tout simplement la  »valeur potentielle » de la feature aux yeux de l’utilisateur. Les product managers ont souvent une bonne perception de la valeur relative d’une feature, (« ils préfèrent ceci plutôt que cela ») même quand il est impossible de déterminer une valeur absolue. Et puisque nous sommes intéressés par cette forme de priorisation, une valeur utilisateur relative est ce qu’il nous faut.%%% > %%% > – la  »valeur temps » est une autre estimation relative; basée sur la façon dont la valeur utilisateur décroît au fil du temps. De nombreuses features offrent une meilleure valeur quand elles sont livrées au début, discriminantes sur leurs marchés, et de moindre valeur lorsque les features sont banalisées. Dans certains cas, la valeur temps est au mieux modeste (« mettre en œuvre la norme d’ergonomie avec l’image de marque de la nouvelle entreprise »). Dans d’autres cas, la valeur temps est extrême (« mettre en œuvre le nouveau protocole de test avant la prochaine saison des achats de rentrée scolaire »), et bien sûr il y a aussi les entre deux (« supporter les serveurs 64 bits »).%%% > %%% > – la  »valeur découverte de l’information » ajoute une dernière dimension – qui témoigne du fait que nous faisons réellement de la R&D logicielle. Notre monde comporte à la fois des risques et des opportunités. Certaines features sont plus ou moins à valeur ajoutée pour nous selon qu’elles nous aident à débloquer ces mystères, atténuer les risques et à exploiter de nouvelles opportunités. Par exemple, faire passer l’authentification des utilisateurs par un nouveau service web, pourrait être un effort risqué pour un fournisseur de logiciels qui ne l’a jamais fait par le passé, mais imaginez les opportunités que cette nouvelle feature pourrait générer.%%% > %%% > Avec ces trois critères de valeur, la valeur utilisateur, la valeur temps et la valeur découverte de l’information, nous avons les dernières pièces de notre puzzle sur la priorisation.%%% > %%% > __Matrice d’évaluation de la priorisation des features__%%% > %%% > Maintenant, nous pouvons intégrer toutes ces informations dans une matrice d’évaluation que nous pouvons utiliser pour établir les priorités relatives d’une feature, et qui se base à la fois sur l’effort et le coût du retard. Un exemple est donné dans le tableau ci-dessous :%%% > %%% > ((/dotclear/public/traductions/evaluation-matrix.png|Evaluation Matrix||Evaluation Matrix))%%% > Légende :%%% > Échelle de pondération : 10 le plus haut et 1 le plus bas%%% > La pondération est le rapport entre le Coût total du retard et l’Effort%%% > %%% > Dans notre exemple, il est intéressant de noter que la Feature B – le travail avec la plus haute valeur utilisateur (8)  »et » la feature de plus grand effort (1.3=8/6) – est en réalité le travail qui a la pondération la  »plus faible » et qu’elle devrait donc être développée en  »dernier ». La feature qui a la valeur utilisateur la plus faible (Feature 1) est en réalité celle qui génère le  »meilleur » retour sur investissement lorsqu’elle est développée  »en premier ». Ne vous fiez pas à votre intuition ! %%% > %%% > __Toutes les priorisations sont locales et temporelles__%%% > %%% > Reinertsen a également signalé une autre subtile implication de la planification par le « travail pondéré le plus rapide en premier ». La priorité devrait être basée sur le coût du retard, qui est une propriété  »globale » de la feature, et l’effort, qui est une propriété  »locale » de l’équipe qui développe la feature. En d’autres termes, un travail avec une valeur relative faible peut exiger peu de ressources d’une équipe donnée, et peut donc par conséquent être développée avant une autre feature de plus grande priorité, si cette feature exige davantage de ressources pour cette équipe. Cela signifie que toutes les priorités sont par nature locales $$Principle of Product Development Flow:F18$$.%%% > %%% > Cela va parfois à l’encontre de la façon dont nous faisons les choses, par exemple lorsqu’une Direction fixe une priorité globalement pour un projet et qui doit être appliquée dans toutes les équipes. Dans ce cas, une tâche moins prioritaire pour un projet de haute priorité peut avoir préséance sur une tâche prioritaire pour une feature de priorité moindre. Et la disponibilité des ressources limitées n’entrent même pas dans l’équation. Nous voyons aujourd’hui que cette approche n’a tout simplement pas de sens économique.%%% > %%% > En outre, nous constatons que notre modèle est très sensible à l’élément temps –  »les priorités changent rapidement à l’approche des échéances ». Par exemple : « développer le nouveau protocole de test avant la prochaine saison des achats de rentrée scolaire » pourrait avoir une valeur temps de « 1 à 2 » en hiver avant le début de l’année scolaire prochaine, mais pourrait facilement monter à « 10 » en Mai de l’année suivante.%%% > %%% > On peut tirer une conclusion de ce qui précède, à savoir que les priorités doivent être déterminées au niveau local, et le plus tard possible dans la prise de responsabilité. C’est le moment où nous pouvons le mieux évaluer le coût du retard ainsi que les ressources disponibles pour travailler sur la feature.%%% > %%% > Heureusement, dans notre modèle, nous priorisons les features lors de chaque planification de Release. Par conséquent, la cadence établie pour notre release nous sera très utile ici, tant que nous prenons le temps de  »revoir les priorités » à chaque planification.%%% > %%% > Quand nous faisons cela, nous pouvons être sûrs que nos priorités sont à jour, qu’elles tiennent bien compte de la disponibilité réelle des ressources et du coût du retard réel, tout en étant fondée sur de solides fondamentaux économiques.%%% > %%% > __Définir la valeur discriminante – le Modèle de Kano de la Satisfaction Client__%%% > %%% > Avec ses collègues, Noriaki Kano, un expert dans le domaine de la gestion de la qualité et la satisfaction client, a développé un modèle pour la satisfaction client qui remettait en cause de nombreuses croyances traditionnelles. Plus précisément, le modèle de Kano conteste l’idée que la satisfaction client est atteinte en équilibrant les investissements à travers les divers attributs d’un produit ou d’un service. Au contraire, la satisfaction du client peut être optimisé en mettant l’accent sur les  »features discriminantes », ces « excitateurs » et « attracteurs » qui augmentent la satisfaction et la fidélité des clients au-delà de ce que demanderait proportionnellement un investissement. Le modèle de Kano est illustré dans la figure ci-dessous :%%% > %%% > ((/dotclear/public/traductions/kano-model.png|Kano Model||Kano Model))%%% > %%% > Le modèle illustre trois types de features :%%% > %%% > – Features fondamentales (obligatoires) – des features qui doivent être présentes pour avoir une solution viable.%%% > – Features linéaires – features pour lesquelles l’investissement est directement proportionnel au résultat. Plus vous investissez, plus la satisfaction est grande.%%% > – Excitateurs et Attracteurs. Ce sont des features qui différencient la solution de la concurrence. Ils fournissent les plus grandes opportunités de satisfaction et fidélité de la part du client.%%% > %%% > L’idée principale du modèle de Kano est la position et la forme des courbes inférieure et supérieure.%%% > %%% > La forme de la courbe de  »base » est révélatrice. Jusqu’à ce qu’une feature soit simplement « présente », l’investissement est proportionnel au résultat, mais la satisfaction reste faible jusqu’à ce qu’un seuil soit atteint. Par la suite, cependant, les investissements supplémentaires produisent moins de résultat proportionnellement. Le point central de cette courbe donne lieu à ce qui est souvent décrit comme la Minimum Marketable Feature (MMF). En d’autres termes, pour que la solution soit considérée comme viable, elle doit contenir l’ensemble des MMFs. Toutefois, l’amélioration d’une MMF ne produira pas un résultat proportionnel.%%% > %%% > La position et la forme de la courbe  »excitateurs et attracteurs » racontent le contraire. Parce que ces features sont uniques, irrésistibles et discriminantes, même un petit investissement (la zone à gauche) suscite toujours l’intérêt du client et une satisfaction potentielle. Des investissements supplémentaires produisent encore plus, et un investissement proportionnellement important produit une satisfaction encore plus élevée. C’est là où nous disposons du meilleur effet de levier pour notre investissement.%%% > %%% > __Prioriser les Features selon leurs Valeurs Discriminantes__%%% > %%% > Étant donné que nous avons déjà décrit un modèle de priorisation à part entière avec le « travail pondéré le plus rapide en premier », la question se pose de savoir quels sont les avantages supplémentaires que nous pouvons tirer de la pensée de Kano ? Il y a trois notions stratégiques à garder :%%% > %%% > Premièrement, lorsque les features sont déjà en concurrence sur un marché existant, les équipes doivent placer une valeur utilisateur relativement élevée (et donc un coût du retard relativement élevé) sur les features nécessaires pour atteindre un niveau équivalent  »minimal ». Cela nous conduit à la règle n°1:%%% > %%% >  »Règle n°1 de la Valeur Discriminante – Investir dans des MMFs, mais ne jamais surinvestir dans une feature qui est déjà banalisée. »%%% > %%% > Par la suite, l’orientation stratégique devrait nous amener à accorder une plus grande valeur utilisateur aux  »features discriminantes » – celles qui vont « exciter et attirer » les utilisateurs, celles pour lesquelles des solutions compétitives n’existent pas, et celles pour lesquelles un investissement supplémentaire produit un résultat non linéaire. Ce qui nous amène à la règle n°2 :%%% > %%% >  »Règle n°2 de la Valeur Discriminante – Stimuler l’innovation en ayant le courage d’investir dans les « excitateurs et attracteurs ». »%%% > %%% > Enfin et plus subtilement, quand nous sommes forcés de nous engager dans des guerres de features avec des concurrents qui en disposent peut-être déjà,  »il n’est peut être pas raisonnable de mettre tous nos investissements dans les MMFs ». Après tout, nos concurrents vont aussi continuer à investir; qu’est ce qui nous fait penser que nous pouvons rattraper le retard ? Au lieu de cela, il peut être préférable de se concentrer sur une catégorie restreinte de MMFs et, au contraire, d’investir un certain montant sur les « excitateurs » –  »même si nous n’avons pas atteint l’équivalence complète sur les features fondamentales ».%%% > %%% > L’expérience a montré que les clients peuvent être relativement patients avec les développeurs quand a) ils peuvent raisonnablement anticiper la date d’apparition des MMFs adéquates et b) voir se concrétiser la promesse de valeur discriminante des « excitateurs » que l’équipe traite en premier dans le backlog. Cela nous amène à notre troisième et dernière règle de priorisation des features :%%% > %%% >  »Règle n°3 de la Valeur Discriminante – Si les ressources ne le permettent pas et que vous ne pouvez pas rivaliser avec les règles actuelles du jeu, changez le jeu. »%%% > %%% > __ »Résumé »__%%% > %%% > Dans ce billet, nous avons fourni une méthode pour prioriser les fonctionnalités basées sur un Coût du Retard pondéré. Ce n’est pas si différent des modèles antérieurs, et elle intègre des attributs d’estimation de taille (coût), de rendement potentiel et d’ajustements pour risques (découverte de l’information). Nous avons également décrit le modèle de Kano qui nous a conduit à ajuster de façon appropriée nos investissements dans des « excitateurs et attracteurs ». Ce n’est peut être que du bon sens, ou peut-être du bon sens étayé par les réelles, mais subtiles, théories économiques sur les flux de développement d’un produit.%%% > %%% > Vos commentaires sont les bienvenus.%%%  »Traduction référencée dans le wiki ++[Traductions agiles|http://www.fabrice-aimetti.fr/dokuwiki/doku.php/start|fr]++ »%%% %%% __Feedback :__%%% * Blog People In Action : ++[« Notre revue de presse (13/04/2010) »|http://blog.piaction.com/2010/04/people-in-action-revue-de-presse-13042010/|fr]++%%% %%%

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *