Dans Scrum ou d'autres processus Agile - comment gérez-vous les versions d'exigences

Question

Dans Scrum et/ou d'autres méthodes Agile, comment gérez-vous les versions des exigences simplement? Je suppose qu'il y a beaucoup d'organisations qui sont agiles mais qui doivent aussi garder une trace des changements d'exigences à des fins réglementaires et ainsi de suite.

Vous pouvez avoir une exigence dans la version 1 qui est substantiellement modifiée dans la version 8. Comment voulez-vous suivre ce genre de changement entre les versions?

Answer 1

La réponse est simple: nous ne sommes pas , car le suivi des changements n'a généralement pas beaucoup de sens ou n'apporte aucun bénéfice. Toutefois, si, pour une raison quelconque, vous devez suivre les changements (comme des frais inutiles imposés par des «règlements» - ce qui n'est pas rare, n'est-ce pas?), La meilleure chose à faire est de garder votre carnet de commandes vous seriez capable de dire comment et quand cela a changé. C'est là que les outils logiciels Scrum peuvent aider, car le faire avec un tableau et des fiches constituerait une grande souffrance. Parfois, un simple historique de tous les changements à tout élément de backlog (comme ce que nous avons dans our Scrum tool) suffira, parfois vous aurez besoin de rapports plus complexes (disponibles dans certains outils plus complexes), et parfois vous devrez produire des documents supplémentaires.

BTW - Je comprends « une exigence » pour désigner un seul élément de retard, généralement une histoire d'utilisateur (ou épique). En tant que tels, ceux-ci ne changent généralement pas beaucoup, leur position sur l'arriéré, mais habituellement pas les histoires elles-mêmes. L'enregistrement des modifications de la position des histoires sur l'arriéré n'a pas beaucoup de sens dans un projet agile, cependant l'enregistrement lorsque des histoires ont été faites (garder des données sur les sprints passés) est une bonne pratique. L'enregistrement des modifications apportées à l'histoire elle-même (modifications, changements de pièces jointes, etc.) serait là où l'outil Scrum devrait vous aider si c'est ce que vous voulez/devez suivre.

Answer 2

Vous pourriez versionner votre document (s) d'exigences avec le code source ... de cette façon, vous auriez les documents qui ont détaillé les exigences à tout moment, avec le code qui implémente (ou tentatives à) ces exigences.

Cela étant dit, je ne pense pas que ce soit différent dans « agile » ou « scrum » que dans tout processus de développement.

Answer 3

Il n'y a rien construit sur SCRUM qui ressemble à la gestion de la version de l'exigence. Le fait que vous en ayez besoin peut être un signe que vous n'êtes pas vraiment en train de mettre en œuvre SCRUM ou que SCRUM n'est pas le bon processus pour vous. Si je devais implémenter quelque chose de similaire, je regarderais d'abord le backlog de votre produit (à partir duquel les tâches de sprint détaillées sont dérivées) et maquetterais les histoires/cas d'utilisation/versions des exigences, puis je vérifierais les mises à jour sur les éléments déjà publiés. voir si une nouvelle tâche de "mise à jour du code pour correspondre à l'exigence" est requise pour le sprint.

(je parle en évitant agile comme il y a des centaines de processus agiles là-bas, peut-être quelqu'un d'autre peut donner leur point de vue sur AUP ou Crystal Clear)

Answer 4

Un wiki lié à votre user stories/outil d'exigences est probablement votre meilleur pari.

Nous utilisons Assembla comme notre principal outil de collaboration pour nos projets agiles. Il a un wiki où vous pouvez documenter vos besoins et un outil de billetterie qui peut être facilement lié au wiki (et aux vérifications de code) grâce à des balises simples pour la traçabilité des exigences.

Tant le wiki et l'outil de billetterie garder l'histoire, il serait facile de visualiser et documenter les changements au fil du temps.

Comme d'autres l'ont mentionné, dans une perspective de processus, il est probablement préférable de briser vos besoins/histoires de épopées en plus petites histoires et ajouter de nouvelles histoires pour saisir de nouvelles exigences que les choses progressent. L'outil que j'ai mentionné (et je suis sûr que plusieurs autres outils) vous permettent de le faire facilement et de lier les éléments ensemble si vous voulez voir comment une fonctionnalité a progressé ou a été ajouté au fil du temps.

Answer 5

Pourquoi avez-vous besoin pour suivre les changements d'exigence (j'ai beaucoup de raisons, mais quel problème essayez-vous de résoudre?). Avez-vous l'option de construire votre produit de façon itérative ou avez-vous besoin de comprendre la plupart du temps?

Si vous êtes en mesure de construire itérativement, je passerais la gestion des versions des exigences. Les livraisons de sprints individuels définiront le produit à différents moments. Le backlog de sprint suivant définira le travail engagé.

Le carnet de commandes principal ou la liste de souhaits peut être modifié au besoin. Il peut ne pas être nécessaire de suivre les modifications car le travail n'a pas été engagé.

Si vous avez besoin d'un plus grand contrôle, j'aime la recommandation Paddyslacker d'un Wiki. La plupart des autres mécanismes ne gèrent pas les concepts relationnels des épopées et la décomposition des exigences. J'ai toujours trouvé un seul fichier insuffisant pour les fonctionnalités complexes.

Answer 6

Vous n'avez pas mentionné sur quelle plate-forme vous développez mais si vous utilisez TFS; il garde la trace de toutes les modifications apportées aux éléments de Backlog, quand ils ont été modifiés, et par qui.