it-swarm-eu.dev

Wie verfolgen Sie ein Anforderungsdokument in einem agilen Team?

Ich verstehe, dass User Stories die agile Welt dominieren, aber wie werden diese Artefakte gespeichert, damit neue Entwickler, die dem Team beitreten, die Anforderungen erfüllen können?

Was passiert, wenn sich die User Story später ändert, wie wird sie aktualisiert und als Artefakt aufbewahrt? Ich habe gesehen, dass viele Teams einfach ein neues Ticket/eine neue Feature-Anfrage/einen neuen Fehlerbericht geöffnet haben, anstatt die ursprüngliche Geschichte zu verfolgen.

22
Sheehan Alam

Zunächst einmal entspricht fast nichts in der Antwort von @ DXM meiner Erfahrung mit Agile und insbesondere nicht mit Scrum.

Das Agile Manifesto besagt, dass umfassende Dokumentation zwar wertvoll ist, funktionierende Software jedoch wertvoller ist. Dokumentation ist also sicherlich keine schlechte Sache, aber sie sollte wirklich dazu dienen, funktionierende Software zu erstellen.

Individuen und Interaktionen über Prozesse und Werkzeuge

Arbeitssoftware über umfassende Dokumentation

Kundenzusammenarbeit bei Vertragsverhandlungen

Reagieren auf Änderungen nach einem Plan

Das heißt, während die Elemente auf der rechten Seite einen Wert haben, schätzen wir die Elemente auf der linken Seite mehr.

Es hat sich immer wieder als verschwenderisch erwiesen, jedes Detail festzunageln, bevor mit dem Codieren begonnen wird. Daher wird die Dokumentation in der Regel JIT (just in time) behandelt. Das heißt, Sie dokumentieren, was Sie tatsächlich codieren werden.

Eine der beliebtesten Methoden für Scrum ist die Verwendung von User Stories, die vom Product Owner verwaltet und im Product Backlog gespeichert werden. Das Product Backlog ist eine ziemlich allgemeine Liste aller Dinge, die eine Lösung tun muss, und eine User Story ist im Allgemeinen eine gut dimensionierte Methode, um jedes Element auf der Liste zu beschreiben. User Stories sind nicht obligatorisch, aber sie scheinen eine gute Möglichkeit zu sein, die Details nicht zu übertreiben und stattdessen zur Zusammenarbeit anzuregen.

Wenn also eine Story fertig ist - das Team hat etwas erstellt, getestet und bereitgestellt, das die Akzeptanzkriterien erfüllt, wird die Story nicht GEKAUFT, sondern einfach im Backlog als erledigt markiert -, sodass der Backlog einige Hinweise enthält von dem, was in jedem Sprint gemacht wurde - Geschichten und die damit verbundenen Punkte. Auf diese Weise können Sie die Geschwindigkeit berechnen und sind an und für sich eine wertvolle Dokumentation.

Alles in allem kann eine User Story die gesamte Dokumentation sein, die zum Verständnis einer Anforderung erforderlich ist. Wahrscheinlicher ist jedoch, dass eine Konversation zwischen dem Kunden und dem Entwicklungsteam generiert wird. Daher gibt es eine Reihe von Möglichkeiten, um dieses Gespräch zu führen. Wenn es sich um eine persönliche Ad-hoc-Angelegenheit handelt, wie dies häufig der Fall ist, können die Analysten/Entwickler (und sollten dies möglicherweise, abhängig von Ihrer Organisation) alle getroffenen Entscheidungen aufschreiben und irgendwo speichern, z. B. in einem Wiki oder einem Dokumentations-Repository. Wenn es sich um eine E-Mail-Konversation handelt, können Sie die E-Mails speichern. Wenn es sich um eine Whiteboard-Sitzung handelt, machen Sie mit Ihrem Handy ein Foto von der Tafel und speichern Sie es. Der Punkt ist, dass diese Dinge Ihnen helfen, den Code zu erledigen, und möglicherweise später helfen können, wenn Sie herausfinden müssen, wie oder warum Sie es so gemacht haben, wie Sie es getan haben.

Eine andere Methode zur Erfassung von Anforderungen besteht darin, sie sofort in Testfälle einzubetten (was meiner Meinung nach bei DXM der Fall war). Dies kann sehr effizient sein, da Sie ohnehin für jede Anforderung testen müssen. In diesem Fall können Sie Ihre Anforderungen effektiv in Ihrem Testtool speichern.

Wenn eine Story fertiggestellt (und akzeptiert) ist und der Benutzer dann seine Anforderungen ändert, müssen Sie wahrscheinlich eine neue Story erstellen. Wenn Sie ein Wiki für Ihre Dokumentation verwenden, können Sie die neue Geschichte wieder mit dem Original verknüpfen und diese ursprüngliche Geschichte ebenfalls mit dem neuen Material verknüpfen, damit jemand, der sie sich ansieht, weiß, dass sich die Dinge geändert haben. Das ist das Schöne an Wikis - es ist einfach und ziemlich schmerzlos, Dinge zu verknüpfen. Wenn Sie den testgetriebenen Ansatz verwenden, aktualisieren Sie entweder den Testfall, um die Änderung zu bewältigen, oder erstellen neue Testfälle für die neue Story, wenn sich Neu und Alt nicht gegenseitig ausschließen.

Am Ende kommt es darauf an, was Sie brauchen. Wenn die Hauptsache darin besteht, die Leute schnell auf den neuesten Stand zu bringen, ist es wahrscheinlich eine gute Idee, dass jemand ein Onboarding-Dokument schreibt, um ihnen zu helfen. Lassen Sie das also jemanden machen. Wie ich bereits erwähnt habe, sind Wikis ein großartiges Werkzeug, um diese Art von Dingen beizubehalten. Sie können also Atlassians Lösungen in Betracht ziehen, das das Confluence-Wiki mit Jira und Greenhopper integrieren kann, um Ihre Geschichten/Aufgaben/Fehler zu verfolgen und Ihre zu verwalten Projekt im Allgemeinen. Es gibt auch viele andere Tools zur Auswahl.

11
Matthew Flynn

[Update # 1] Wie @MatthewFlynn hervorhob, unterscheidet sich seine Erfahrung mit agilen und vielen anderen (einschließlich meiner eigenen) sehr von der Antwort darauf Ich biete hier. Die Antwort hier basiert auf meinen Beobachtungen darüber, was in der Vergangenheit in meinem eigenen Team funktioniert hat und was nicht, kombiniert mit vielen Büchern und Blogs, die ich zu diesem Thema gelesen habe ...

der größte Teil des Strebens nach agiler Entwicklung zielt speziell auf die Beseitigung von Anforderungsdokumenten ab.

Agile versucht, die meisten Dokumentationen zu beseitigen, und ich stimme ihren Ideen zu, aber von allen Dokumenten haben die Anforderungen bei weitem das größte Ziel. Der Grund dafür (IMO) ist, dass Anforderungsdokumente am weitesten vom tatsächlichen Arbeitscode und allen Dokumenten entfernt sind, die sie erstellen

  • am wenigsten genau
  • am schwersten zu pflegen
  • am wenigsten nützlich

Um das Team zu leiten, was als nächstes entwickelt werden soll, ersetzt Agile Anforderungsdokumente durch einen Rückstand an Storys, in denen angegeben ist, woran Sie als Nächstes arbeiten sollten, und Elemente mit höchster Priorität, bei denen der größte Gewinn für das Geld (sowohl das gegenwärtige als auch das zukünftige Geld) an erster Stelle steht in dieser Liste.

Ein Rückstand sollte jedoch nicht mit einem Anforderungsdokument verwechselt werden:

  • In einem Backlog sollten nur N Geschichten mit Details ausgefüllt werden. Je weiter eine Geschichte entfernt ist, desto weniger Details sollten Sie einfügen (dh verschwenden Sie keine Zeit damit, etwas zu definieren, das ein halbes Jahr lang nicht passieren wird ).
  • Ab einem bestimmten Punkt sollten "Anforderungs" -Elemente nicht einmal in einen Rückstand aufgenommen werden, wenn sie länger als 2 Veröffentlichungszyklen sind (auch bekannt als potenzielle versandfähige Inkremente (PSI)). Auch wenn Sie wissen, dass die Anforderung wichtig ist und irgendwann erledigt werden muss, sollten Sie der Versuchung widerstehen, sie dem Backlog hinzuzufügen. Wenn es wirklich wichtig ist, wird sich jemand in der nächsten Version daran erinnern. Wenn sich niemand daran erinnert, liegt es höchstwahrscheinlich daran, dass es doch nicht so wichtig war.

Sobald eine Geschichte fertig ist, wird diese Geschichte aus dem Rückstand entfernt und GEKAUFT(1). Auch hier sind Geschichten keine Anforderungen. Sie sagen dem Team NUR, woran sie als nächstes arbeiten sollen. Sie sind nicht für historische Aufzeichnungen.

Bei einem ordnungsgemäßen agilen Prozess sollten jedoch bei jeder Lieferung von Arbeiten Teil-/Integrations-/Abnahmetests sein. Diese Tests sind sehr wertvoll, weil sie viele Zwecke haben. Ich werde nicht auf die vollständige Liste eingehen, aber einer dieser Zwecke ist die Dokumentation Ihrer aktuellen Produktionssoftware.

Ein Test dokumentiert, wie sich die Software unter bestimmten Eingaben und Voraussetzungen verhalten soll. Außerdem wird dokumentiert, wie öffentliche (und interne) APIs Ihres Codes verwendet werden. Es dient auch als Sicherheitsnetz. Wenn ein neuer Entwickler in ein Team eintritt und versehentlich etwas kaputt macht, wird dieser Fehler abgefangen, sobald er eingecheckt wird.

Ein agiler Prozess fördert natürlich die Nutzung automatisierter Komponententests so weit wie möglich, aber wir alle wissen, dass nicht jedes einzelne Element automatisiert werden kann. Ihre Software-Suite verfügt immer über eine Reihe von Tests, die manuell ausgeführt werden müssen. A) Ihre Entwickler sollten jedoch aktiv daran arbeiten, so viel wie möglich zu automatisieren, und b) manuelle Tests sollten regelmäßig von Ihrem QS-Team durchgeführt werden, damit Funktionsstörungen so schnell wie möglich erkannt werden.


(1) - Da habe ich mehrere Antworten für den "Chucked" Teil bekommen. In 5 Jahren, seit ich zu Agile gewechselt bin, hat mein Team nie eine einzige Geschichte weggeworfen, selbst 30% derjenigen, die geplant, dann verschoben und dann vergessen wurden. Mein Chef wollte sie "als Referenz" behalten, und dennoch hat sich noch niemand eine dieser Geschichten angesehen.

Die Leute sind im Allgemeinen an ihre Daten gebunden, und ich weiß, dass es schwer zu ergründen ist, etwas wegzuwerfen, wenn Sie es bereits haben, aber das Inventar (ob physisch oder elektornisch) zur Hand zu haben, ist nicht kostenlos und je mehr ich darüber nachdenke, desto mehr stimme ich zu mit dem "chucking". Dies ist von "Agile Softwareanforderungen: Lean-Anforderungspraktiken für Teams, Programme und Unternehmen" (S.190) - "User Stories können nach der Implementierung sicher weggeworfen werden. Dadurch bleiben sie leicht , hält sie teamfreundlich und fördert die Verhandlung, aber Akzeptanztests bleiben für die gesamte Lebensdauer der Anwendung bestehen ... "

8
DXM

Was passiert, wenn sich die User Story später ändert, wie wird sie aktualisiert und als Artefakt aufbewahrt? Ich habe gesehen, dass viele Teams nur ein neues Ticket/eine neue Feature-Anfrage/einen neuen Fehlerbericht geöffnet haben, anstatt die ursprüngliche Geschichte zu verfolgen.

Das Verwalten von any Dokumentation kann schwierig sein, unabhängig davon, ob Sie agile Storys oder ein großes Dokument im Voraus verwenden Um die Belastung zu verringern, sollte die Dokumentation minimal sein und schrittweise aktualisiert werden, um den Anstrengungen zu entsprechen, die bei den Tests und der Implementierung unternommen werden. Wie das OP jedoch angedeutet hat, besteht die Gefahr, dass durch einfaches Aktualisieren der Dokumentation die Historie der Entwicklung der Software im Laufe der Zeit verloren geht.

Ist das wirklich wichtig? Manchmal kann es sein. Zum größten Teil möchten Sie einfach nur die Storys/UML/was auch immer zusammen mit den Tests und dem Code selbst anzeigen. Wenn jedoch Fragen aufgeworfen werden, warum eine Funktion auf eine bestimmte Weise implementiert wurde, kann dies häufig der Fall sein Es ist nützlich, den Verlauf zu betrachten, um zu sehen, wie sich die Funktion im Laufe der Zeit geändert hat, um ein klareres Bild darüber zu zeichnen, warum die Implementierungsoption [~ # ~] x [~ # ~] ausgewählt wurde anstelle der Option [~ # ~] y [~ # ~].

Es gibt verschiedene Möglichkeiten, solche Artefakte im Auge zu behalten. Eine der besseren Möglichkeiten kann darin bestehen, Ihre Storys in einem Tool zu speichern, mit dem Sie Ihren Story-Text auf ähnliche Weise wie die Versionierung Ihres Quellcodes versionieren können. Wikis sind in der Regel sehr gut darin, ebenso wie einige der Projekt-/Issue-Management-Tools wie Trac oder Redmine , die den Verlauf von Änderungen an den Issues selbst speichern sowie die Wiki-Seiten in diesen Systemen. Dies kann jedoch noch etwas weiter vorangetrieben werden, um die Möglichkeit zu verbessern, Änderungen von Problem zu Feature zu verfolgen, indem sichergestellt wird, dass neue Storys oder Probleme in irgendeiner Weise mit älteren verwandten Themen und Storys verknüpft sind. Dies kann so einfach sein wie das Hinzufügen einer älteren Problem-/Story-ID zum Text einer neueren Ausgabe/Story, kann jedoch erheblich verbessert werden, indem Probleme oder Story-IDs in den Check-in-Kommentar aufgenommen werden, wenn Sie eine Änderung an Ihrem Versionskontrollsystem vornehmen . Diese Methode ist jedoch von größtem Wert, wenn Ihre Commits häufig und auf eine einzelne Story oder ein Problem beschränkt sind.

Die größte Schwierigkeit besteht natürlich darin, dass diese Art von Ansatz sorgfältige Aufmerksamkeit und die Verpflichtung jedes Teammitglieds erfordert, konsistent zu sein und ihre Commits klein und häufig zu halten, und dass diejenigen, die die Storys und/oder Issue-/Projekt-Tracking-Systeme verwalten, diese einhalten müssen Zusätzlich zu den Artefakten, die Verknüpfungen zwischen dem aktuellen Status Ihrer Implementierung und allen zuvor vorgenommenen Änderungen herstellen.

1
S.Robins

Es wurde schon einmal gesagt, aber ich denke, das Wesentliche ist:

  • anforderungen können viele Facetten abdecken und in der Regel zu mehr als einer Geschichte führen.

  • eine Geschichte organisiert die Arbeit eines Teams in Stücken, die klein genug sind, um in die Zeitgrenzen eines Sprints zu passen.

  • oft müssen viele Details definiert werden, damit eine bestimmte Funktion ordnungsgemäß funktioniert. Dies ist der Zeitpunkt, an dem es nützlich wird, diese Definitionen in einem separaten Anforderungsdokument zu speichern - für Klarheit, gemeinsames Verständnis und spätere Bezugnahme.

Betrachten Sie das legendäre Beispiel einer Online-Zoohandlung:

  • In der Geschichte heißt es möglicherweise: "Als Benutzer möchte ich die auf meiner Quittung aufgedruckte Mehrwertsteuer sehen, ...". Die Berechnung der Mehrwertsteuer kann nun eine komplizierte Angelegenheit sein und erfordert wahrscheinlich mehr Arbeit, als diese Geschichte nahelegt.
  • Möglicherweise gibt es eine zusätzliche Geschichte, in der die Berechnung der Mehrwertsteuer verlangt wird (z. B. multiplizieren Sie den Gesamtumsatz mit dem Mehrwertsteuersatz), die jedoch wahrscheinlich nicht alle Variationen dieser Berechnung enthält.
  • Zunächst konzentrierte sich das Team darauf, das Basismodul bereitzustellen, beispielsweise eine Liste der Waren und deren Verkaufspreis zu erstellen und den Mehrwertsteuerbetrag zurückzugeben. Das kann ein Team innerhalb eines Sprints erreichen.
  • Es wird wahrscheinlich noch viel mehr Geschichten geben, um alle möglichen Fälle für die Mehrwertsteuerberechnung abzudecken.
  • Um die vielen verschiedenen Regeln für die Berechnung der Mehrwertsteuer über einzelne Sprints hinaus sichtbar zu halten, ist es sinnvoll, ein separates Anforderungsdokument zu führen, in dem alle verschiedenen Methoden zur Berechnung der Mehrwertsteuer aufgeführt sind. Dieses Dokument kann sich im Laufe der Zeit weiterentwickeln. Tatsächlich könnte das Hinzufügen eines neuen Abschnitts Teil der zu erledigenden Aufgabe einer Geschichte sein.
1
miraculixx

Sie können freemind verwenden, um die Liste der Funktionen zu sammeln. Wie es gemacht wird, werfen Sie einen Blick auf dieses Tutorial (irgendwo in der Mitte).

Wenn Sie eine Liste mit Funktionen haben, schreiben Sie User Stories. Dies kann mithilfe einer einfachen Textdatei oder eines Word-Dokuments oder eines so komplexen Dokuments wie ein agiles Verwaltungstool erfolgen.

Wenn Sie mit User Stories fertig sind, werden diese priorisiert. Später erstellen die Benutzer anhand der User Stories Aufgaben, übernehmen Aufgaben und implementieren sie in Code.

All dies kann gesehen werden, wie ein c # -Projekt von Anfang an in der Herbst der agilen Video-Cast-Serie verwaltet wird.

0
BЈовић