Anforderungen an ein agiles Projekt dokumentieren

Einer der Werte des Agilen Manifests lautet „funktionierende Software vor umfassender Dokumentation“ . Und doch müssen Anforderungen dokumentiert werden. Wenn ein vor 6 Monaten entwickeltes Feature geändert wird, brauche ich (als Entwickler) einen Ort, an dem ich auf die bestehenden Anforderungen verweisen kann. Dokumentierte Anforderungen sind natürlich auch für QA-Ressourcen wichtig. Wenn eine Frage zu einer bestimmten Anforderung auftritt, sollte es außerdem einen einzigen Ort geben, auf den man sich zur Klärung beziehen kann, anstatt von mir zu verlangen, meinen Code oder eine Reihe von E-Mails zu analysieren, um zu sehen, wie die Dinge erstellt wurden.

Die agilen Teams, in denen ich war, haben alle ein Online-Management (z. B. Rally, Jira) verwendet, in dem Anforderungen unter jeder User Story als Akzeptanzkriterien definiert werden können. Obwohl ich dies als eine äußerst funktionale Lösung/Ort für die Anforderungsdokumentation empfinde, da Sie das Tool ständig verwenden, um die Geschichte voranzutreiben, scheint es ein wenig informell zu sein. Bei dem letzten Projekt, an dem ich gearbeitet habe, pflegte das Projektmanagementteam ein BRD (Business Requirements Document), das alle Systemanforderungen in einem einzigen Dokument enthielt. Bei diesem speziellen Projekt wurde die BRD für die Freigabe des zu entwickelnden Kunden durch den Kunden verwendet und wurde auch vom Managementteam meines (Beratungs-)Unternehmens überprüft, um sicherzustellen, dass alles abgeschlossen wurde. Das Problem mit BRDs ist meiner Erfahrung nach, dass sie so ausführlich sind, dass sie nicht mehr lesbar sind.

Das Agile-Framework befasst sich nicht mit der Definition eines bestimmten Dokumentationsmittels, aber gibt es eine einzige Best Practice für die Dokumentation von Anforderungen an ein agiles Entwicklungsprojekt?

Warum ist es Ihrer Meinung nach erforderlich, Anforderungen außerhalb der abgeschlossenen User Stories (und der damit verbundenen Akzeptanzkriterien) zu dokumentieren?
Mit anderen Worten - welchen Mehrwert bringt es, Ihre Anforderungen in zwei verschiedenen Tools oder Formaten zu pflegen? Berücksichtigen Sie zunächst den Wert für externe Parteien (Kunden, Benutzer). Berücksichtigen Sie zweitens den inneren Wert. Berücksichtigen Sie dann den Aufwand, der erforderlich ist, um Ihre Anforderungen an zwei Stellen zu erstellen und zu pflegen. Denken Sie daran, dass Sie eine einzige Informationsquelle haben möchten .
@ThomasOwens Ich stimme voll und ganz zu, dass es eine einzige Informationsquelle geben sollte, daher dieses Thema :). Wie bereits erwähnt, verwendeten die höheren Stellen in meinem Unternehmen die BRD, die de facto das „Anforderungsdokument“ für das Projekt war, im Grunde als einen Vertrag, dem der Kunde und wir zustimmten. Ich glaube nicht, dass die Geschichten einzelner Benutzer zu ihrer Zufriedenheit formal genug wären, noch glaube ich, dass sie bereit wären, ein Tool wie Rally zu verwenden (nicht, dass das akzeptabel wäre).
Wenn also User Stories + Akzeptanzkriterien nicht ausreichen, warum verwenden Sie sie dann? Es spricht nichts dagegen, dass Sie eine formale Anforderungsspezifikation in keiner der agilen Methoden verwenden können.
@ThomasOwens Es ist nicht der Inhalt der User Stories + AC. Es ist ihr Standort; in einem Online-Tool, mit dem ein Manager möglicherweise nicht vertraut ist, getrennt nach individueller Geschichte. Ich vergleiche dies mit einer BRD, die ein einzelnes, allgegenwärtiges Word-Dokument ist.
Sie haben also die Wahl. Sie benötigen eine einzige Informationsquelle. Was werden Sie tun? Passen Sie Ihren Prozess an, um Anforderungen in einer BRD zu erfassen, einem Word-Dokument, das an einen bestimmten Ort hochgeladen wird und von den richtigen Personen bearbeitet werden kann (möglicherweise mit Überarbeitungsverlauf)? Oder schulen Sie Ihre Manager darin, den Prozess zu verstehen und die gleichen Tools wie das Team zu verwenden?
Oder das einzige Dokument für die Manager aus den Jira-Storys erstellen? Ich bin mir nicht sicher, ob Jira es nativ unterstützt - obwohl es etwas gibt, um Versionshinweise aus Problemfeldern zu kompilieren -, aber ich würde wetten, dass es eine Erweiterung (Plug-in) gibt, die dies tut, da Sie wahrscheinlich nicht der einzige mit dieser Herausforderung sind .

Antworten (2)

Es gibt drei agile Prinzipien, die im Spiel sind:

  1. „Arbeitende Software statt umfassender Dokumentation“ aus dem Agilen Manifest .
  2. „Einfachheit – die Kunst, die Menge an nicht erledigter Arbeit zu maximieren – ist wesentlich.“ Dies ist eines der Prinzipien hinter dem Agilen Manifest .
  3. The Single Source of Information from Agile Modeling , das verschiedene Techniken und Prinzipien zum Entwerfen und Dokumentieren von Software in einer agilen Umgebung zusammenführt.

Anforderungen in einem Tool wie Rally oder JIRA in Form von User Stories + Akzeptanzkriterien und gleichzeitig in einem Anforderungsdokument zu pflegen, ist von Natur aus nicht agil. Sie erstellen übermäßige Dokumentation, können die nicht erledigte Arbeit nicht maximieren, und Sie haben mehrere Informationsquellen, die gepflegt werden müssen (und möglicherweise nicht mehr synchron sind).

Die einzige Lösung besteht darin, Ihre Anforderungen an einem Ort zu verwalten. Wenn Ihr Team derzeit ein Tool verwendet und einige Stakeholder mit diesem Tool nicht vertraut sind, haben Sie zwei Möglichkeiten. Die erste Option ist, dass Ihr Team seinen Prozess so anpassen kann, dass sich alle Beteiligten wohl fühlen. Die zweite Option ist, dass Ihr ScrumMaster oder Agile Coach die Stakeholder über den Wert aufklären kann

Es gibt nichts, was besagt, dass ein agiles Projekt nicht ein Anforderungsdokument in Form einer Tabelle oder eines Word-Dokuments erstellen und pflegen und damit arbeiten kann. Schließlich spezifizieren gute Anforderungen (unter anderem) die Wichtigkeit, um eine Priorisierung zu ermöglichen, sind überprüfbar und können mit den Informationen verknüpft werden, die zum Testen erforderlich sind (auch wenn nicht alle in einem Tool oder Dokument verfügbar sind), und sind auf andere Arbeiten rückführbar ( wahrscheinlich ID). Wenn Sie eine Anforderungsspezifikation haben, kann Ihr Team beispielsweise über die eindeutigen Anforderungskennungen weiterhin Arbeitsaufgaben, Testfälle oder Akzeptanzkriterien zu Elementen in der BRD zurückverfolgen.

Das ist ein bisschen zu stark vereinfacht. Es geht darum, den Wald von den Bäumen aus zu sehen. Normalerweise würde ein Projekt von einer Art hochrangiger Dokumentation profitieren, die eher eine Strategie als eine Taktik ist. Jira-Kommentare sind rein taktischer Natur. Eine der Schwächen, die mir aufgrund eines zu kurzen Sprint-Zyklus aufgefallen ist, ist, dass Projekte im Laufe der Zeit tatsächlich mäandern. Grundlegende Probleme werden ungelöst gelassen, um kurzfristige Ziele zu verfolgen.

Das agile Denken schlägt vor, dass die beste Vorgehensweise darin besteht, gerade genug zu dokumentieren. Wenn Sie etwas aus gutem Grund dokumentieren müssen, dokumentieren Sie es!

In der Softwareentwicklung hat jedes Projekt seine eigenen Bedürfnisse, es gibt nicht die eine, eindeutige Quelle der Wahrheit. Für einige Teams oder Projekte sind automatisierte Testfälle eine ausreichende Dokumentation. Manche brauchen einen formelleren Weg wie User-Storys in einem Workflow-System, statt nur auf Karteikarten.

BRDs klingen nach Überdokumentation und einer Möglichkeit, das Entwicklungsteam durch den Kunden zu steuern und zu kontrollieren, aber wenn es für das Projekt und das Team funktioniert, ist es nicht per se antiagil.

Das Agile-Framework beschäftigt sich nicht mit der Definition eines bestimmten Dokumentationsmittels

Die meisten agilen Frameworks geben nichts vor, außer dass sie wertorientiert sind und in Iterationen arbeiten und natürlich die anderen Prinzipien . Insgesamt ist es eine Denkweise. Frameworks, die alles spezifizieren, konzentrieren sich auf Prozesse und Tools und nicht auf Einzelpersonen und Interaktionen . Stellen Sie sich die Frage, wie agil dieses Framework wirklich ist.

Finden Sie eine Arbeitsweise, die zu Ihrer Branche, Ihrem Unternehmen, Ihrem Projekt oder Ihrem Produkt passt. Inspizieren und adaptieren Sie laufend, so finden Sie am Ende die optimale Arbeitsweise.

Anforderungen an ein agiles Projekt dokumentieren
AntwortenHierDatenschutz-Bestimmungen1y, 0v