L’importance du suivi des mises à jour des exigences / Blogs / Perficient

La beauté d’Agile est sa capacité à s’adapter au changement. L’un des principes qui sous-tendent le Manifeste Agile est « Accepter l’évolution des exigences, même tardivement dans le développement. Les processus agiles exploitent le changement pour l’avantage concurrentiel du client.

Les clients changent d’avis. Peut-être qu’ils n’aiment pas l’apparence ou le fonctionnement de quelque chose une fois qu’il utilise du contenu réel et réel. Peut-être ont-ils pensé à un autre scénario important où les exigences initiales ne fonctionneront tout simplement pas. Il y a peut-être eu un bouleversement des parties prenantes et les nouveaux membres ont des opinions différentes de l’équipe initiale.

Il existe d’innombrables raisons pour lesquelles les exigences peuvent changer et, heureusement, les pratiques Agiles sont suffisamment agiles pour gérer les changements inévitables. Créez une nouvelle user story avec les nouvelles exigences, ajoutez des critères d’acceptation appropriés, affinez-la, puis organisez-la dans le backlog afin qu’elle puisse être intégrée à un futur sprint. Ce qui est souvent sous-estimé (ou même passé sous silence), c’est de bien documenter ces changements d’exigences.

Bien que la nouvelle user story capture les mises à jour elles-mêmes, elle ne traite pas nécessairement de la manière dont les modifications s’intègrent dans la vue d’ensemble ou quand/pourquoi/par qui les modifications des exigences ont été apportées.

Les exigences initiales en matière de fonctionnalités sont clairement énoncées. Après la mise en œuvre, une nouvelle user story a été ajoutée et complétée pour mettre à jour la fonctionnalité, mais les mises à jour n’ont pas été intégrées à la fonctionnalité. Des mois plus tard, alors que les utilisateurs testent les critères de fonctionnalité dans le cadre du processus UAT, ils remarquent que la fonctionnalité ne correspond pas aux exigences de la fonctionnalité et créent un ticket de bogue. Il ne vous reste plus qu’à concilier le ticket de bogue avec les exigences des fonctionnalités et des user stories et à déterminer et expliquer le comportement attendu. Vous savez quand la nouvelle user story a été ajoutée, mais vous ne savez pas qui l’a demandée ni pourquoi.

Il existe plusieurs façons différentes de suivre les mises à jour des exigences. Certaines de ces méthodes incluent :

• Ajout de notes dans la nouvelle user story indiquant quand la mise à jour a été demandée, qui l’a demandée et toute information pertinente sur la raison pour laquelle la mise à jour a été demandée.
• Ajouter ces mêmes notes dans la fonctionnalité initiale indiquant quand la mise à jour a été demandée, qui l’a demandée et toute information pertinente sur la raison pour laquelle la mise à jour a été demandée.
• Mettez à jour les exigences dans la description de la fonctionnalité elle-même. La suppression des exigences non pertinentes lors de l’insertion de la nouvelle peut fournir une image complète des modifications exactes, mais peut également sembler encombrée et écrasante lors de l’examen d’une fonctionnalité avec de nombreuses exigences mises à jour.
• Si possible, ajouter une balise à la fonctionnalité chaque fois que les exigences sont mises à jour peut également s’avérer utile lors de l’exécution de rapports. Si une fonctionnalité avait des exigences mises à jour 3 fois distinctes, voir les 3 balises « mises à jour » différentes peut renforcer où vont les efforts de l’équipe et pourquoi.
• La création d’un « journal des modifications » global peut également être utile. Semblable à la user story et aux notes de fonctionnalité, ce document peut indiquer la fonctionnalité mise à jour, quand la mise à jour a été demandée, qui l’a demandée et toute information pertinente sur la raison pour laquelle la mise à jour a été demandée. Bien que ce document puisse ne pas être visible ou pertinent pour toutes les parties prenantes, il fournit une vue d’ensemble facile à consulter des changements d’exigences sur le projet.

Quelle que soit la ou les méthodes de suivi utilisées, utilisez des mots-clés et ajoutez suffisamment de détails pour pouvoir retrouver la mise à jour plus tard. Ceci est particulièrement important si la référence est « vivante » et peut être mise à jour plusieurs fois.

Par exemple, les conceptions actuelles du client utilisent le rouge des camions de pompiers #ce2029 pour leurs H2. Après la première série de commentaires, le concepteur a mis à jour le fichier de conception existant pour utiliser à la place le rouge tomate #ff6347. Les conceptions ont continué à faire l’objet de commentaires et pour s’adapter à une modification apportée ailleurs, la couleur H2 a ensuite été mise à jour en rouge cerise # D2024D.

Mes notes, à la fois dans les nouvelles user stories, la fonctionnalité existante et le journal des modifications, ressembleraient à ceci :

Mise à jour du 26/01/2023 : selon les commentaires de la partie prenante A le 24/01/2023, la couleur H2 a été modifiée du rouge camion de pompier #ce2029 au rouge tomate #ff6347. Les conceptions ont été mises à jour à la demande, la user story LMN a été ajoutée pour s’adapter à ce travail.

Mise à jour 09/02/2023 : Selon les commentaires de l’intervenant B le 07/02/2023, la couleur H2 a été modifiée du rouge tomate #ff6347 au rouge cerise #D2024D, car le rouge cerise est cohérent avec les nouveaux éléments de conception utilisés ailleurs. Les conceptions ont été mises à jour à la demande, la user story XYZ a été ajoutée pour s’adapter à ce travail.

Lorsqu’un bogue indiquant que les H2 sont rouge cerise au lieu de rouge tomate ou rouge camion de pompier est signalé, je peux rechercher un certain nombre de mots-clés, notamment « couleur H2 », « rouge cerise », « rouge tomate », « rouge camion de pompier »,  » #ce2029″, « #ff6347 », ou « D2024D », et pourra voir la trace des mises à jour demandées. Mes notes incluent les mots-clés qui m’aident à trouver facilement les mises à jour, mais incluent également des informations sur qui a demandé la mise à jour, pourquoi et quand elle a été faite, que je peux ensuite utiliser pour confirmer que le bogue signalé n’est pas un problème qui doit être adressée.

Les changements d’exigences sont inévitables, mais la documentation autour des changements d’exigences devrait l’être aussi.