Fonctionnalités vs. stories

Je réalise que, jusqu’à aujourd’hui, la différence entre fonctionnalités et stories n’était pas clair dans mon esprit et qu’il s’agit d’une différence fondamentale. Une fonctionnalité est un groupe de stories liées donnant un ensemble de fonctions que les utilisateurs finaux s’attendent à avoir toutes ensemble à la fois. Par exemple, redimensionner un tableau de type en-ligne¹ est une fonctionnalité (remarque : ceci représente la possibilité de redimensionner les colonnes et les lignes dans des tableaux - essayez donc dans Word²). Dans un premier temps, vous aurez probablement une seule story pour le redimensionnement des tableaux de type en-ligne, mais cela devrait s’avérer à être trop gros à estimer. Par conséquent vous allez la scinder en trois stories, redimensionnement des colonnes, redimensionnement des lignes et redimensionnement du tableau lui-même.

Nous avons maintenant trois stories - trois choses différentes à développer qui ajouteront de la valeur au produit et qui pourront être faites relativement rapidement (nous pensons que la plus grosse de ces stories devrait prendre une journée à développer). Il y a de la valeur à être capable de redimensionner les colonnes mais pas en ce qui concerne les lignes ou le tableau lui-même - le redimensionnement des colonnes permet aux utilisateurs de distribuer l’espace entre les colonnes plus facilement afin que le tableau ait un aspect plus joli. Cela couvre 90% des cas d’utilisation de redimensionnement de ce type de tableau - les personnes redimensionnent rarement l’ensemble du tableau ou la hauteur des lignes, généralement ils veulent juste faire en sorte que la largeur des colonnes soient ajustées au mieux aux données présentes à l’intérieur. En dépit de cela, livrer cette seule story aux utilisateurs provoquerait de la confusion et des plaintes au support parce que cette livraison entraîne une attente dans l’esprit des utilisateurs de pouvoir redimensionner les tableaux alors ils se demandent pourquoi ils ne peuvent pas redimensionner les lignes ou le tableau ?

La fonctionnalité, c’est les trois stories réunies ensemble, et c’est la capacité à pouvoir livrer sans entraîner de confusion chez nos utilisateurs, nous voulons vraiment être certain que ces trois stories seront terminées avant la livraison - toutefois nous pouvons toujours la livrer à nos utilisateurs internes dans le cadre du programme “tiens-mets-toi-çà-sous-la-dent” ou aux beta testeurs avant que nous ayons les trois, il y a donc une certaine valeur à faire une seule de ces trois stories.

Il y a deux avantages clés à scinder les fonctionnalités de cette manière. Tout d’abord, cela rend l’estimation plus facile et plus précise - les choses qui prennent du temps ont tendance à être difficile à estimer. Deuxièmement, cela nous permet de suivre plus précisément nos progrès sur la fonctionnalité. Une des premières règles de suivi de l’avancée d’un projet est que vous ne devez suivre que les tâches terminées et non les tâches terminées partiellement car les personnes ne sont vraiment pas bonnes pour estimer quand est-ce qu’ils auront terminés. Avec des stories de taille réduite vous pouvez suivre l’avancée du projet simplement en vous basant sur le nombre de stories terminées sans perdre en précision.

Scindez les stories reste toutefois quelque chose d’assez difficile parce que vous devez être certain qu’elles continuent à avoir de la valeur. Récemment, nous avons eu une story dont l’objectif était de développer une panneau de propriétés quelconque qui devait faire partie intégrante d’une boîte de dialogue plus importante. Malheureusement, nous avons livré la story du panneau avant la story sur la boîte de dialogue, nous avions donc développer un panneau que l’utilisateur n’était pas capable d’accéder. Ce fût même pire, nous avons perdu du temps à créer une boîte de dialogue juste pour ce panneau parce que nous pensions qu’il était nécessaire - nous aurions dû remarquer le peu de valeur de cette story et poser la question au client avant de commencer - nous aurions probablement fais d’abord la story de la création de la boîte de dialogue, donnant ainsi immédiatement de la valeur pour la story du panneau.

Auteur : Adrian Sutton
Source : Features vs Stories
Date de parution originale : 18 Mai 2006

Traducteur : Nicolas Mereaux
Date de traduction : 09/08/2016

Ce(tte) oeuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.