[fusion_builder_container hundred_percent="no" equal_height_columns="no" hide_on_mobile="small-visibility,medium-visibility,large-visibility" background_position="center center" background_repeat="no-repeat" fade="no" background_parallax="none" parallax_speed="0.3" video_aspect_ratio="16:9" video_loop="yes" video_mute="yes" border_style="solid"][fusion_builder_row][fusion_builder_column type="1_1" layout="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" border_position="all" spacing="yes" background_image="" background_repeat="no-repeat" padding_top="" padding_right="" padding_bottom="" padding_left="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="small-visibility,medium-visibility,large-visibility" center_content="no" last="no" min_height="" hover_type="none" link=""][fusion_text columns="" column_min_width="" column_spacing="" rule_style="default" rule_size="" rule_color="" hide_on_mobile="small-visibility,medium-visibility,large-visibility" class="" id=""]Dans un projet de développement informatique géré avec la méthode agile Scrum, des « user stories » de qualité, complètes et bien rédigées sont une condition sine qua non à sa réussite. En effet, l'équipe scrum va se baser entièrement sur ces « user stories » pour l'évaluation des fonctionnalités décrites et leur priorisation quant à leur intégration dans les différents sprints. La grille INVEST est un outil précieux permettant de juger selon un certain nombre de critères, la qualité d'une « user story ». Voyons donc comment obtenir une « user story invest ».
Lorsque l'on doit évaluer la qualité d'un produit, d'un écrit ou d'un outil, il faut pouvoir se baser sur des critères objectifs : c'est l'objet d'une user story invest. INVEST fourni une grille de lecture permettant d'évaluer la qualité d'une « user story » à partir de critères prédéfinis. En fonction de la correspondance ou non à ces critères, il pourra être nécessaire de la reformuler, voire d'y apporter des modifications en profondeur ou de la redécouper de façon plus fine.
Bill Wake a décrit dans un article en 2003 les critères INVEST permettant d'évaluer la qualité du découpage des fonctionnalités d'une application en « user stories ». Ils ont été développés par la suite dès 2004 par Mike Cohn dans son livre « User Stories Applied : For Agile Software Development » décrivant différentes façons d'améliorer les processus de conception et de réalisation d'un logiciel ou d'une application.
INVEST défini six critères de qualité permettant d'attester qu'une « user story » est bonne, bien écrite et détaillée. Il s'agit en fait d'un acronyme anglais : Independent, Negotiable, Valuable (ou Vertical), Estimable, Small et Testable. Détaillons maintenant ces six critères d'évaluation.
La « user story » doit être indépendante des autres afin de pouvoir être estimée efficacement, et surtout être développée à n'importe quel moment du projet. Une « user story » ne pouvant être développée que lorsqu'une autre est opérationnelle introduit une dépendance qui n'est pas souhaitable. Une « user story » indépendante pourra en revanche être traitée dans n'importe quel sprint.
Lorsque ce n'est pas possible, l'équipe de développement doit mettre en place un système de bouchons de façon à simuler l'existence du code qui ne sera écrit que pour d'autres « user stories », potentiellement dans un autre sprint.
La « user story » ne doit pas faire mention d'une quelconque solution technique. Elle doit réellement se contenter d'aspects fonctionnels. Les choix technologiques seront effectués par l'équipe de développement durant la phase de conception dans le sprint qui embarquera la « user story ». Par exemple, une « user story » qui utiliserait une description telle que « en tant qu'utilisateur connecté, lorsque j'écris dans un champ de formulaire au format texte et que je clique sur un bouton Rechercher, le tableau contenant les résultats de recherche est mis à jour » ne répond pas au critère. En effet, il est fait mention ici de solutions techniques (un champ texte, un bouton, un tableau). Une description plus générique, comme « un utilisateur connecté peut effectuer des recherches à partir d'un mot-clé », permet en revanche à l'équipe de développement de proposer plusieurs solutions et de choisir la plus adaptée. Les mots-clés pourraient être saisis, sélectionnés dans une liste, la recherche lancée automatiquement, les résultats présentés dans un tableau, mais aussi dans une liste… Les choix sont multiples en fonction de l'ergonomie définie pour l'ensemble de l'application et des choix techniques effectués précédemment.
Ce critère signifie que la « user story » doit amener une réelle plus-value à l'application du point de vue de l'utilisateur final. Il est très important de garder en tête que les « user stories » doivent être écrites uniquement dans le but de fournir une fonctionnalité à l'utilisateur final. La plus-value doit être réelle et visible. Par exemple, si une « user story » « réaliser le schéma de la base de données de la gestion des clients » pourrait avoir une valeur pour les développeurs, ce n'est absolument pas le cas pour l'utilisateur. Il n'a pas à connaître les détails techniques de la mise en place de l'application, et la création du schéma de la base de données, s'il est indispensable au fonctionnement de l'ensemble, importe peu à l'utilisateur qui ne le manipulera pas directement. En revanche, des « user stories » telles que « créer un nouveau client », « modifier un client existant », « transférer un client vers un autre compte » auront un sens pour l'utilisateur final et lui apporteront une réelle plus-value en termes fonctionnels. De plus, ces « user stories » pourront être redécoupées de façon à ce que leur mise en place puisse être incrémentale, et si besoin, répartie sur plusieurs sprints.
Pour répondre à ce critère de qualité, une « user story » doit être suffisamment détaillée et précise dans la description des fonctionnalités demandées. Une « user story » trop vague ne permettra pas une évaluation correcte. Des demandes regroupant trop de fonctionnalités ne permettront pas de quantifier correctement l'effort à fournir par l'équipe de développement. Par exemple, « gérer la commande client » est une demande beaucoup trop vague susceptible de représenter à elle seule un projet complet. Il est impératif que la « user story » définisse des critères de satisfaction précis et suffisamment restreints. Ce n'est qu'à ces conditions que l'équipe de développement sera en mesure de fournir une estimation réaliste et fiable de la complexité de la « user story » et de l'effort à fournir pour sa réalisation.
L'estimation de la durée de la réalisation de la « user story » ne doit pas dépasser quelques jours-hommes. Quelle que soit la durée d'un sprint et le nombre de membres de l'équipe de développement, il doit être possible de réaliser au moins six « user stories » lors de l'itération.
Le fait de réduire la taille des « user stories » permet de réduire également la durée de leur réalisation et de mieux gérer les priorités. Il est ainsi plus simple de déterminer lesquelles pourront être embarquées dans les sprints et à quel moment. Une « user story » courte et bien écrite peut également plus facilement être confiée à un développeur débutant, ou à un nouvel arrivant dans l'équipe. Il est également plus simple de créer des tests unitaires et d'intégration pour vérifier que le fonctionnement du code source produit correspond bien à ce qui est attendu dans la « user story invest ».
Enfin, avec des « user stories » courtes et détaillées, la progression des développements est bien plus nette. L'avancement se lit facilement sur le « scrum board », car les « user stories » courtes sont plus rapidement réalisées et testées. On obtient ainsi un projet vivant, avec une équipe dynamique, qui va de l'avant et qui est motivée par les réussites successives. Des « user stories » mal découpées, amenant des périodes de développements trop longues, peuvent être particulièrement préjudiciables pour l'équipe, qui à terme peut se démobiliser. La satisfaction même du client est améliorée, car les livraisons sont rapprochées, et les différentes fonctionnalités peuvent être testées et validées plus rapidement.
La « user story » doit être suffisamment claire et détaillée pour fournir un exemple complet comportant un jeu de données, induisant un comportement prévisible, reproductible et déterministe. Une description comme « le moteur de recherche doit être performant » n'est pas très utile. « Les résultats de recherche doivent s'afficher en moins de 2 secondes pour un nombre inférieur à 200 et à 4 secondes pour un nombre supérieur » donnera suffisamment d'éléments pour que la « user story » puisse être considérée comme testable.
D'autre part, si le rédacteur d'une « user story invest » n'est pas capable de décrire exactement de quelle façon celle-ci peut et doit être testée, c'est sans doute, qu'elle n'est pas suffisamment comprise ou précise, et qu'elle doit être retravaillée.
INVEST fourni une grille de lecture d'une « user story » afin de mesurer sa qualité au travers de 6 critères. En respectant ces critères, on s'assure qu'une « user story INVEST » est suffisamment bien écrite, détaillée et documentée pour être utilisable par l'équipe de développement. Pouvoir se baser sur des critères bien précis de qualité permet un découpage efficace, suffisamment fin, des « user stories » et une rédaction claire. En partant sur de bonnes bases, les sprints de développements seront beaucoup plus productifs que si l'équipe doit demander régulièrement des précisions.
Le logiciel agile Nutcache fourni tous les outils nécessaires à la gestion des « user stories ». N'hésitez pas à tester les différentes fonctionnalités gratuitement durant 14 jours.
[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]
Une user story invest ?
Lorsque l'on doit évaluer la qualité d'un produit, d'un écrit ou d'un outil, il faut pouvoir se baser sur des critères objectifs : c'est l'objet d'une user story invest. INVEST fourni une grille de lecture permettant d'évaluer la qualité d'une « user story » à partir de critères prédéfinis. En fonction de la correspondance ou non à ces critères, il pourra être nécessaire de la reformuler, voire d'y apporter des modifications en profondeur ou de la redécouper de façon plus fine.
Un peu d'histoire
Bill Wake a décrit dans un article en 2003 les critères INVEST permettant d'évaluer la qualité du découpage des fonctionnalités d'une application en « user stories ». Ils ont été développés par la suite dès 2004 par Mike Cohn dans son livre « User Stories Applied : For Agile Software Development » décrivant différentes façons d'améliorer les processus de conception et de réalisation d'un logiciel ou d'une application.
Les critères INVEST
INVEST défini six critères de qualité permettant d'attester qu'une « user story » est bonne, bien écrite et détaillée. Il s'agit en fait d'un acronyme anglais : Independent, Negotiable, Valuable (ou Vertical), Estimable, Small et Testable. Détaillons maintenant ces six critères d'évaluation.
Indépendance
La « user story » doit être indépendante des autres afin de pouvoir être estimée efficacement, et surtout être développée à n'importe quel moment du projet. Une « user story » ne pouvant être développée que lorsqu'une autre est opérationnelle introduit une dépendance qui n'est pas souhaitable. Une « user story » indépendante pourra en revanche être traitée dans n'importe quel sprint.
Lorsque ce n'est pas possible, l'équipe de développement doit mettre en place un système de bouchons de façon à simuler l'existence du code qui ne sera écrit que pour d'autres « user stories », potentiellement dans un autre sprint.
Négociable
La « user story » ne doit pas faire mention d'une quelconque solution technique. Elle doit réellement se contenter d'aspects fonctionnels. Les choix technologiques seront effectués par l'équipe de développement durant la phase de conception dans le sprint qui embarquera la « user story ». Par exemple, une « user story » qui utiliserait une description telle que « en tant qu'utilisateur connecté, lorsque j'écris dans un champ de formulaire au format texte et que je clique sur un bouton Rechercher, le tableau contenant les résultats de recherche est mis à jour » ne répond pas au critère. En effet, il est fait mention ici de solutions techniques (un champ texte, un bouton, un tableau). Une description plus générique, comme « un utilisateur connecté peut effectuer des recherches à partir d'un mot-clé », permet en revanche à l'équipe de développement de proposer plusieurs solutions et de choisir la plus adaptée. Les mots-clés pourraient être saisis, sélectionnés dans une liste, la recherche lancée automatiquement, les résultats présentés dans un tableau, mais aussi dans une liste… Les choix sont multiples en fonction de l'ergonomie définie pour l'ensemble de l'application et des choix techniques effectués précédemment.
Verticale
Ce critère signifie que la « user story » doit amener une réelle plus-value à l'application du point de vue de l'utilisateur final. Il est très important de garder en tête que les « user stories » doivent être écrites uniquement dans le but de fournir une fonctionnalité à l'utilisateur final. La plus-value doit être réelle et visible. Par exemple, si une « user story » « réaliser le schéma de la base de données de la gestion des clients » pourrait avoir une valeur pour les développeurs, ce n'est absolument pas le cas pour l'utilisateur. Il n'a pas à connaître les détails techniques de la mise en place de l'application, et la création du schéma de la base de données, s'il est indispensable au fonctionnement de l'ensemble, importe peu à l'utilisateur qui ne le manipulera pas directement. En revanche, des « user stories » telles que « créer un nouveau client », « modifier un client existant », « transférer un client vers un autre compte » auront un sens pour l'utilisateur final et lui apporteront une réelle plus-value en termes fonctionnels. De plus, ces « user stories » pourront être redécoupées de façon à ce que leur mise en place puisse être incrémentale, et si besoin, répartie sur plusieurs sprints.
Evaluable
Pour répondre à ce critère de qualité, une « user story » doit être suffisamment détaillée et précise dans la description des fonctionnalités demandées. Une « user story » trop vague ne permettra pas une évaluation correcte. Des demandes regroupant trop de fonctionnalités ne permettront pas de quantifier correctement l'effort à fournir par l'équipe de développement. Par exemple, « gérer la commande client » est une demande beaucoup trop vague susceptible de représenter à elle seule un projet complet. Il est impératif que la « user story » définisse des critères de satisfaction précis et suffisamment restreints. Ce n'est qu'à ces conditions que l'équipe de développement sera en mesure de fournir une estimation réaliste et fiable de la complexité de la « user story » et de l'effort à fournir pour sa réalisation.
Suffisamment petite (« small »)
L'estimation de la durée de la réalisation de la « user story » ne doit pas dépasser quelques jours-hommes. Quelle que soit la durée d'un sprint et le nombre de membres de l'équipe de développement, il doit être possible de réaliser au moins six « user stories » lors de l'itération.
Le fait de réduire la taille des « user stories » permet de réduire également la durée de leur réalisation et de mieux gérer les priorités. Il est ainsi plus simple de déterminer lesquelles pourront être embarquées dans les sprints et à quel moment. Une « user story » courte et bien écrite peut également plus facilement être confiée à un développeur débutant, ou à un nouvel arrivant dans l'équipe. Il est également plus simple de créer des tests unitaires et d'intégration pour vérifier que le fonctionnement du code source produit correspond bien à ce qui est attendu dans la « user story invest ».
Enfin, avec des « user stories » courtes et détaillées, la progression des développements est bien plus nette. L'avancement se lit facilement sur le « scrum board », car les « user stories » courtes sont plus rapidement réalisées et testées. On obtient ainsi un projet vivant, avec une équipe dynamique, qui va de l'avant et qui est motivée par les réussites successives. Des « user stories » mal découpées, amenant des périodes de développements trop longues, peuvent être particulièrement préjudiciables pour l'équipe, qui à terme peut se démobiliser. La satisfaction même du client est améliorée, car les livraisons sont rapprochées, et les différentes fonctionnalités peuvent être testées et validées plus rapidement.
Testable
La « user story » doit être suffisamment claire et détaillée pour fournir un exemple complet comportant un jeu de données, induisant un comportement prévisible, reproductible et déterministe. Une description comme « le moteur de recherche doit être performant » n'est pas très utile. « Les résultats de recherche doivent s'afficher en moins de 2 secondes pour un nombre inférieur à 200 et à 4 secondes pour un nombre supérieur » donnera suffisamment d'éléments pour que la « user story » puisse être considérée comme testable.
D'autre part, si le rédacteur d'une « user story invest » n'est pas capable de décrire exactement de quelle façon celle-ci peut et doit être testée, c'est sans doute, qu'elle n'est pas suffisamment comprise ou précise, et qu'elle doit être retravaillée.
Pour conclure sur l'user story INVEST
INVEST fourni une grille de lecture d'une « user story » afin de mesurer sa qualité au travers de 6 critères. En respectant ces critères, on s'assure qu'une « user story INVEST » est suffisamment bien écrite, détaillée et documentée pour être utilisable par l'équipe de développement. Pouvoir se baser sur des critères bien précis de qualité permet un découpage efficace, suffisamment fin, des « user stories » et une rédaction claire. En partant sur de bonnes bases, les sprints de développements seront beaucoup plus productifs que si l'équipe doit demander régulièrement des précisions.
Le logiciel agile Nutcache fourni tous les outils nécessaires à la gestion des « user stories ». N'hésitez pas à tester les différentes fonctionnalités gratuitement durant 14 jours.
[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]
City skyline
Photo By: John Doe
Birthday Sparks
Photo By: John Doe
Fashion Magazine
Photo By: John Doe
Blurred Lines
Photo by: John Doe
