Tout d'abord, presque rien dans la réponse de @ DXM ne correspond à mon expérience avec Agile, et surtout pas avec Scrum.
Le Manifeste Agile déclare que si une documentation complète est précieuse, un logiciel de travail est PLUS précieux. Ainsi, la documentation n'est certainement pas une mauvaise chose, mais elle devrait vraiment être au service de la création de logiciels fonctionnels.
Individus et interactions sur les processus et les outils
Logiciel de travail sur une documentation complète
Collaboration client sur négociation de contrat
Répondre au changement suite à un plan
Autrement dit, bien qu'il y ait de la valeur dans les éléments de droite, nous valorisons davantage les éléments de gauche.
Clouer chaque détail avant de commencer à coder s'est avéré être un gaspillage à maintes reprises, donc la documentation est généralement traitée de manière JIT (juste à temps). Autrement dit, vous documentez ce que vous allez réellement coder.
L'une des façons les plus courantes de faire Scrum consiste à utiliser les User Stories, qui sont gérées par le Product Owner et conservées dans le Product Backlog. Le Product Backlog est une liste de haut niveau de tout ce qu'une solution doit faire, et une User Story est généralement une manière bien dimensionnée de décrire chaque chose de la liste. Les histoires d'utilisateurs ne sont pas obligatoires, mais elles semblent être un bon moyen de ne pas exagérer les détails et d'inspirer la collaboration à la place.
Donc, de toute façon, quand une histoire est terminée - l'équipe a créé, testé et déployé quelque chose qui répond aux critères d'acceptation, l'histoire n'est pas CHUCKED, elle est simplement marquée comme terminée dans le backlog - donc le backlog a une indication de ce qui a été fait dans chaque sprint - histoires et les points qui leur sont associés. C'est ce qui vous permet de calculer la vitesse et constitue une documentation précieuse en soi.
Cela dit, une User Story peut être toute la documentation nécessaire pour comprendre une exigence, mais plus probablement, c'est quelque chose pour générer une conversation entre le client et l'équipe de développement. En tant que tel, il existe un certain nombre de choses que vous pouvez faire autour de cette conversation. S'il s'agit d'un événement ponctuel en face-à-face, comme c'est souvent le cas, l'analyste / développeur peut (et éventuellement, selon votre organisation, devrait) noter toutes les décisions qui ont été prises et les enregistrer quelque part, comme un Wiki ou un référentiel de documentation. S'il s'agit d'une conversation par e-mail, vous pouvez enregistrer les e-mails. S'il s'agit d'une session de tableau blanc, prenez une photo du tableau avec votre téléphone portable et enregistrez-la. Le fait est que ces choses vous aident à faire le code et pourraient vous aider plus tard si vous avez besoin de comprendre comment ou pourquoi vous l'avez fait comme vous l'avez fait.
Une autre méthode de capture des exigences consiste à les intégrer immédiatement dans les cas de test (ce qui, je crois, est ce à quoi DXM voulait en venir). Cela peut être très efficace, car vous devez quand même tester chaque exigence. Dans ce cas, vous pouvez stocker efficacement vos besoins dans votre outil de test.
Si une histoire est terminée (et acceptée) et que l'utilisateur modifie son besoin, eh bien, vous devez probablement créer une nouvelle histoire. Si vous utilisez un wiki pour votre documentation, vous pouvez lier la nouvelle histoire à l'original et lier également cette histoire originale aux nouvelles choses afin que quelqu'un qui la regarde sache que les choses ont changé. C'est la bonne chose à propos des wikis - il est facile et assez indolore de lier des choses. Si vous utilisez l'approche pilotée par les tests, vous devez soit mettre à jour le scénario de test pour faire face au changement, soit créer de nouveaux scénarios de test pour la nouvelle histoire si le nouveau et l'ancien ne s'excluent pas mutuellement.
En fin de compte, cela dépend de vos besoins. Si l'essentiel est de mettre les gens au courant rapidement, c'est probablement une bonne idée pour quelqu'un d'écrire un document d'intégration pour les aider. Demandez à quelqu'un de faire ça. Comme je l'ai mentionné, les Wiki sont un excellent outil pour garder ce genre de chose, vous pouvez donc envisager les solutions d'Atlassian qui peuvent intégrer le Wiki Confluence avec Jira et Greenhopper pour suivre vos histoires / tâches / défauts et gérer votre projet en général. Il existe également de nombreux autres outils.