Comment suivez-vous un document d'exigences dans une équipe agile?
Je comprends que les User Stories dominent le monde agile, mais comment ces artefacts sont-ils stockés, afin que les nouveaux développeurs qui se joignent à l'équipe puissent répondre aux exigences?
Que se passe-t-il si la User Story change plus tard, comment est-elle mise à jour et conservée en tant qu'artefact? J'ai vu de nombreuses équipes ouvrir un nouveau ticket/demande de fonctionnalité/rapport de bug au lieu de garder une trace de l'histoire originale.
Tout d'abord, presque rien dans la réponse de @ DXM ne correspond à mon expérience avec Agile, et surtout pas avec Scrum.
Manifeste Agile indique que si une documentation complète est précieuse, un logiciel fonctionnel 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 fonctionnel sur une documentation complète
Collaboration client sur la négociation du 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, de sorte que 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 est d'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 éléments sont ce qui vous aide à 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 des 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 devrez probablement créer une nouvelle histoire. Si vous utilisez un wiki pour votre documentation, vous pouvez lier la nouvelle histoire à l'original, et également lier 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 les nouveaux et les anciens 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.
[mise à jour # 1] Comme l'a souligné @MatthewFlynn, son expérience avec Agile ainsi que beaucoup d'autres (y compris la mienne) est très différente de la réponse que Je fournis ici. La réponse ici est basée sur mes observations de ce qui a fonctionné et n'a pas fonctionné dans ma propre équipe dans le passé, combiné avec de nombreux livres et blogs que j'ai lus sur le sujet ...
l'essentiel du mouvement vers le développement agile vise spécifiquement à éliminer les documents d'exigences.
Agile essaie de supprimer la plupart des documents et je suis d'accord avec leurs idées, mais de tous les documents, les exigences ont de loin le plus gros oeil de boeuf peint sur eux. La raison pour cela (IMO) est que les documents sur les exigences sont les plus éloignés du code de travail réel et de tous les documents, ce qui les rend
- moins précis
- le plus difficile à entretenir
- moins utile
Pour guider l'équipe sur ce qui devrait être développé ensuite, Agile remplace les documents d'exigences par un arriéré d'histoires qui identifient ce que vous devez travailler sur les éléments suivants et les plus prioritaires avec le plus grand rapport qualité-prix (à la fois présent et futur) sont généralement placés en premier dans cette liste.
Cependant, un backlog ne doit pas être confondu avec un document d'exigences:
- Dans un carnet de commandes, seul N nombre d'histoires doivent contenir des détails. Plus une histoire est avancée, moins vous devez y mettre de détails (c.-à-d. Ne perdez pas votre temps à essayer de définir quelque chose qui ne se produira pas pendant six mois) ).
- Au-delà d'un certain point, les éléments "requis" ne devraient même pas être placés dans un carnet de commandes s'ils sont sortis pendant plus de 2 cycles de publication (également appelés incréments potentiels livrables (PSI)). Même si vous savez que l'exigence est importante et doit être accomplie à un moment donné, résistez à la tentation de l'ajouter à l'arriéré. Si c'est vraiment important, quelqu'un s'en souviendra dans la prochaine version. Si personne ne s'en souvient, c'est probablement parce que ce n'était pas si important après tout.
Une fois qu'une histoire est terminée, cette histoire est supprimée de l'arriéré et est CHUCKED(1). Encore une fois, les histoires ne sont pas des exigences. Ils indiquent UNIQUEMENT à l'équipe sur quoi travailler ensuite; ils ne sont pas destinés à un historique.
Cependant, dans un processus agile approprié, chaque fois que vous livrez du travail, une partie de cette livraison devrait être des tests unitaires/d'intégration/d'acceptation. Ces tests sont très précieux car ils ont de nombreux objectifs. Je n'entrerai pas dans la liste complète, mais l'un de ces objectifs est la documentation de votre logiciel de production actuel.
Un test documente comment le logiciel doit se comporter compte tenu d'un certain ensemble d'entrées et de conditions préalables. Il explique également comment utiliser les API publiques (et internes) de votre code. Il sert également de filet de sécurité afin que lorsqu'un nouveau développeur entre dans une équipe et casse quelque chose par inadvertance, cette erreur soit détectée dès son enregistrement.
Le processus agile encourage évidemment à tirer le meilleur parti des tests unitaires automatisés, mais nous savons tous que toutes les choses ne peuvent pas être automatisées. Votre suite logicielle comportera toujours un ensemble de tests qui doivent être exécutés manuellement. Cependant, a) vos développeurs doivent travailler activement à l'automatisation autant que possible et b) un ensemble manuel de tests doit être régulièrement exécuté par votre équipe AQ afin que toute interruption de fonctionnalité soit découverte le plus tôt possible.
(1) - Depuis que j'ai eu plusieurs réponses pour la partie "chucked". En 5 ans depuis le passage à l'agile, mon équipe n'a jamais jeté une seule histoire, même 30% de celles qui ont été programmées, puis différées puis oubliées. Mon patron voulait les garder "pour référence" et pourtant personne n'a jamais regardé aucune de ces histoires.
Les gens sont généralement attachés à leurs données et je sais qu'il est difficile d'imaginer jeter quelque chose une fois que vous l'avez déjà, mais garder l'inventaire (physique ou électoral) à portée de main n'est pas gratuit et plus j'y pense, plus je suis d'accord avec le "chucking". Cela vient de "Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise" (p.190) - "Les user stories peuvent être jetées en toute sécurité après l'implémentation. Cela les maintient légères , les maintient en équipe et favorise la négociation, mais les tests d'acceptation persistent pendant toute la durée de vie de l'application ... "
Que se passe-t-il si la User Story change plus tard, comment est-elle mise à jour et conservée en tant qu'artefact? J'ai vu de nombreuses équipes ouvrir un nouveau ticket/demande de fonctionnalité/rapport de bug au lieu de garder une trace de l'histoire originale.
La gestion any la documentation peut être difficile, que vous utilisiez des histoires agiles ou un gros document, et dans afin de réduire la charge, la documentation doit être minimale et mise à jour progressivement pour correspondre aux efforts déployés sur les tests et la mise en œuvre. Cependant, comme l'OP l'a fait allusion, la simple mise à jour de la documentation risque de perdre l'historique de l'évolution du logiciel au fil du temps.
Est-ce vraiment important? Cela peut parfois arriver. Pour la plupart, vous souhaitez simplement afficher les histoires/UML/quoi que ce soit ainsi que les tests et le code lui-même à l'heure actuelle, mais lorsque des questions sont soulevées quant à la raison pour laquelle une fonctionnalité a été implémentée d'une manière particulière, elle peut souvent être utile pour consulter l'historique afin de voir comment la fonctionnalité a changé au fil du temps, pour brosser un tableau plus clair des raisons pour lesquelles l'option de mise en œuvre [~ # ~] x [~ # ~] a été choisie au lieu de l'option [~ # ~] y [~ # ~].
Il existe plusieurs façons de suivre ces artefacts. L'une des meilleures options peut être de conserver vos histoires dans un outil qui vous permet de faire versionner le texte de votre histoire d'une manière similaire à la version de votre code source. Les Wiki ont tendance à être très bons dans ce domaine, tout comme certains des outils de gestion de projets/problèmes, tels que Trac ou Redmine qui conservent l'historique des modifications des problèmes eux-mêmes. , ainsi que les pages wiki de ces systèmes. Cependant, cela peut être poussé un peu plus loin, pour améliorer la capacité de retracer les changements d'un problème à une fonctionnalité, en veillant à ce que les nouvelles histoires ou les problèmes soient liés d'une manière ou d'une autre aux anciens problèmes et histoires connexes. Cela peut être aussi simple que l'ajout d'un ancien identifiant de problème/histoire au texte d'un problème/histoire plus récent, mais peut être considérablement amélioré en incluant tout problème ou identifiant d'histoire dans le commentaire d'archivage chaque fois que vous validez une modification de votre système de contrôle de version. . Cette méthode est cependant de la plus grande valeur si vos commits sont fréquents et limités à une seule histoire ou problème.
La plus grande difficulté est bien sûr que ce type d'approche nécessite une attention particulière et un engagement de la part de chaque membre de l'équipe pour être cohérent, et pour garder leurs engagements petits et fréquents, et pour ceux qui gèrent les histoires et/ou les systèmes de suivi des problèmes/projets à garder en plus des artefacts qui fournissent des liens entre l'état actuel de votre implémentation et toutes les modifications qui se sont produites précédemment.
Cela a déjà été dit, mais je pense que l'essentiel est le suivant:
les exigences peuvent couvrir de nombreuses facettes et se traduire généralement par plusieurs histoires.
une histoire organise le travail d'une équipe en morceaux suffisamment petits pour tenir dans les limites de temps d'un sprint.
il y a souvent de nombreux détails qui doivent être définis pour qu'une fonction particulière fonctionne correctement. C'est à ce moment qu'il devient utile de conserver ces définitions dans un document d'exigences distinct - pour plus de clarté, une compréhension commune et une référence ultérieure.
Prenons l'exemple de la légendaire animalerie en ligne:
- L'histoire peut dire "En tant qu'utilisateur, je veux voir la TVA imprimée sur mon reçu,…". Maintenant, le calcul de la TVA (taxe sur la valeur ajoutée) peut être une question compliquée et nécessite probablement plus de travail que cette histoire ne le suggère.
- Il peut y avoir une histoire supplémentaire qui demande que le calcul de la TVA soit effectué (disons multipliez le montant total des ventes par le taux de TVA), mais il est probable qu'il n'inclut pas toutes les variations de ce calcul.
- Dans un premier temps, l'équipe se concentrerait sur la fourniture du module de base, par exemple en prenant une liste de produits et leur prix de vente, et en retournant le montant de la TVA. C'est quelque chose qu'une équipe peut accomplir dans le délai d'un sprint.
- Il est probable qu'il y aura beaucoup plus d'histoires pour couvrir tous les cas possibles de calcul de la TVA.
- Pour conserver les nombreuses règles de calcul de la TVA différentes à travers et au-delà des sprints simples, il est logique de conserver un document d'exigences distinct qui répertorie toutes les différentes façons de calculer la TVA. Ce document peut évoluer avec le temps. En fait, l'ajout d'une nouvelle section pourrait faire partie de la tâche d'une histoire à compléter.
Vous pouvez utiliser freemind pour rassembler la liste des fonctionnalités. Comment cela se fait, jetez un œil à ce tutoriel (quelque part au milieu).
Lorsque vous avez une liste de fonctionnalités, vous allez écrire des user stories. Cela peut être fait en utilisant un simple fichier texte, ou un document Word, ou quelque chose d'aussi complexe que n outil de gestion agile .
Lorsque vous avez terminé avec les user stories, elles sont hiérarchisées. Plus tard, à partir des user stories, les gens produisent des tâches, les gens prennent des tâches et l'implémentent dans du code.
Tout cela peut être vu comment un projet c # est géré depuis le début dans le automne de la série de cast vidéo agile .