Im Manifest für agile Softwareentwicklung ist zu lesen:

Funktionierende Software über umfassende Dokumentation

Das bedeutet nicht, dass Dokumentation eine schlechte Sache ist. Stattdessen ist funktionierender Code besser, damit Sie dokumentieren können, was Sie codieren werden.

Abgesehen davon sind möglicherweise nur Benutzergeschichten und Akzeptanzkriterien erforderlich, um die Anforderungen zu verstehen, wenn man bedenkt, dass Sie nicht für das Dokument „Vision and Scope“ verantwortlich sind.

Ich ermutige die Leute, User Stories (oder Backlog-Elemente jeglicher Art) nicht als eine weitere Form von Anforderungen zu betrachten. Es gibt einen entscheidenden Denkunterschied zwischen der Verwendung von Anforderungsdokumenten und Backlogs, die Teams und Organisationen verstehen müssen, um letztere effektiv zu nutzen. Rückstände entstehen. Dies bedeutet, dass sie sich nicht nur im Laufe der Zeit ändern (ein BRS kann durch nichts daran gehindert werden), dass spätere Backlog-Elemente auf früheren Elementen aufbauen und diese ändern, sodass es möglich ist, dass die früheren Elemente das Verhalten der Anwendung nicht mehr beschreiben.

Dies bedeutet, dass die Dokumentation, die Sie benötigen, weitgehend von Ihren Anforderungen getrennt ist (stellen Sie sich vor, was Sie in der Entwicklung wissen und was Sie in der Entwicklung getan haben). Beachten Sie, dass es bei Dingen wie ISO 9001 hauptsächlich darum geht, zu validieren, dass Sie Ihren Prozessen folgen (was auch immer diese sein mögen) und dass Sie Informationen aufzeichnen, die Sie später zum Auditieren oder Warten der Software benötigen. Die Zeiten, in denen es bei Dokumentations- und Prüfungsstandards darum ging, sicherzustellen, dass das Ergebnis perfekt zur ursprünglichen Idee passt, sind weitgehend vorbei. Ich sehe das nur noch dort, wo sie es in ihre Prozesse geschrieben haben und die dokumentierten Prozesse nicht ändern wollen, in diesem Fall ist es eine bewusste Entscheidung, kein Zwang.

Hinzufügen dieses Abschnitts, um auf den Kommentar zu antworten:

Es kann verwirrend sein, Agile und Scrum zu übernehmen, da viele gute Praktiken, die sich Leute ausgedacht haben, in Agile und Scrum zusammengefasst wurden, während gleichzeitig viele der Kernpraktiken und -prinzipien ausgelassen werden.

Agil: Agil sind nur Werteaussagen und Prinzipien. Sie finden sie unter https://agilemanifesto.org/ . Sie können Agilität nicht wirklich praktizieren – vielmehr können Ihre Praktiken mehr oder weniger agil (als Adjektiv) sein, je nachdem, wie gut sie mit diesen Werten und Prinzipien übereinstimmen.

Scrum: Sie können Scrum-Praktiken folgen. Scrum ist ein leichtgewichtiges Framework, was bedeutet, dass es eine Reihe von Ereignissen, Artefakten, Rollen und Praktiken bietet, aber es gibt viel Platz, um auszufüllen, wie Sie die Arbeit erledigen und wie diese Arbeit aussieht. Die neueste Version der Scrum Guides finden Sie unter https://www.scrumguides.org/scrum-guide.html . Es ist wahrscheinlich erwähnenswert, dass viele Teams auswählen, was aus Scrum folgen soll. Obwohl das nicht grundsätzlich falsch ist, ist es so konzipiert, dass es als Ganzes funktioniert, und viele Vorteile gehen verloren, wenn Sie anfangen, Praktiken fallen zu lassen.

XP: Sie haben das nicht erwähnt, aber viele in Scrum übliche Praktiken, die nicht ausdrücklich im Scrum-Leitfaden aufgeführt sind (wie User Stories), stammen tatsächlich von XP. XP ist viel präskriptiver, wie die Arbeit zu erledigen ist. Es gibt eine ziemlich große Veränderungskurve bei der Einführung von XP, und ich sehe nicht, dass viele Teams dies tun, aber als Scrum begann, gingen sie oft davon aus, dass XP einen Teil des Anleitungsraums in ihrem Framework ausfüllen würde, also lohnt es sich immer anschauen. http://www.extremeprogramming.org/ ist ein guter Ausgangspunkt, wenn auch ein bisschen klobig.

Kundenseitige BA hier, derzeit mitten in einer groß angelegten Enterprise Data Warehousing- und Infrastrukturmodernisierungsinitiative. Die Projektteams verwenden Jira anstelle von TFS, und obwohl die Konzepte dieselben sind, dient unsere Nutzung der Plattform hauptsächlich als Tracking- und Berichterstellungstool als Schnittstelle zum zentralen (Unternehmens-) Agile-Entwicklungsteam. Der Schwerpunkt unserer User Stories liegt hauptsächlich auf der Erörterung und Verfolgung von Tests, Verbesserungsanforderungen, Fehlerberichten – all die Art von Feedback, das sozusagen „nach der Tat“ zu jedem Arbeitsprodukt jedes Sprints kommt, und lange nach den anfänglichen Anforderungen wurden veröffentlicht.

Schlüsselkommentar zu den BRS/SRS-Spezifikationen – diese sollten von Endbenutzern in der Planungs-/Prototyping-Phase erbeten werden, um die Architekturentwicklung zu priorisieren und den Gesamtprojektplan zu entwickeln; Dies kann mit einer Umfrage oder einem anderen Anforderungsbewertungstool erfolgen, das von den technischen Leitern und dem E/PMO entworfen und in der Anfangsphase der Planung an die Verbraucher-Leads gesendet wird. Auf diese Weise kann das E/PMO den grundlegenden Umfang und die Machbarkeit der Entwurfsanforderungen einschätzen, die erforderlichen Ressourcenzuweisungen vornehmen und die Arbeit in Wellen, Sprints, entlang eines Kanban-Boards usw. für die verwendeten Methoden priorisieren.

User Stories hingegen konzentrieren sich eher darauf, auf Feedback zu bestimmten Kanälen, Diensten, Domänen oder Vorlagen zu reagieren, die entstehen, nachdem Verbraucher Machbarkeits- und Lückenanalysen für die Prototypversion durchgeführt haben.

Kurz gesagt – während der genaue Zweck jedes Dokuments je nach Organisation und Projekt unterschiedlich sein wird, sind die Anforderungsdokumentation und die Benutzerspeicher letztendlich eine Mischung aus Äpfeln und Orangen, aber alle drei könnten durchaus in demselben Obstkorb kombiniert werden. Die Betonung der jeweiligen Rolle sollte auf die Interessen der Gruppe(n) zugeschnitten sein, die die Initiative vorantreiben.

Endbenutzer legen ihre Anforderungen im Voraus und unabhängig von der in jedem Sprint geleisteten Arbeit fest; Sie werden ihren Plan auch kontinuierlich an BA/DevOps-Feedback anpassen – diese Mitteilung wird während der Entwicklung durch die User Stories als eine Art Tracking-Bulletin weitergegeben. Die drei sind komplementär, aber oft dienen sie dazu, die Interessen und Bedürfnisse oder deutlich unterschiedliche Aktionärsgruppen zu dokumentieren.

Dokumentation als Code

ist hier das Stichwort.
Moderne Testframeworks kombinieren englisch lesbaren Inhalt mit den Anweisungen zur Durchführung der eigentlichen Tests, Systemaufrufe, UI-Interaktionen usw.

Unter BDD (Behavior Driven Development) spezifizieren Sie wie bei TDD das Verhalten vorab als Test, z

Die Benutzer geben AB234 ein, drücken die Eingabetaste und sehen ihren Zugangscode

Der Test schlägt natürlich fehl, da noch kein tatsächlicher Code geschrieben wurde, um ihn zu implementieren.

Sie schreiben dann den Code und die Testdurchläufe und dann, entscheidend, haben Sie einen weiteren Test in Ihrer Suite für die Zukunft (oft als Regression bezeichnet, aber ich vermeide diesen Begriff, es ist nur die Testsuite, genau wie alle Tests). Sie können diesen Test jetzt ausführen, um sicherzustellen, dass die Funktionalität funktioniert, und häufig ein Flag oder eine Einstellung hinzufügen, um den für Menschen lesbaren Teil der Tests anzuzeigen, die bestanden oder fehlgeschlagen sind.

Agiles Vorgehen ≠ Fehlende Dokumentation

Wenn Sie wirklich wichtige Dinge dokumentieren müssen, wie Ressourcen, Arbeitszeiten, benötigte Ausrüstung, können Sie dies natürlich tun. Ich würde eher sagen, du solltest es tun.

Mit dem agilen Ansatz können Sie nur zusammenfassende Dokumente erstellen, die die aktuelle Situation darstellen.

Eine interessante Tatsache ist, dass es beim traditionellen Ansatz eine Menge umfassender Dokumentation gibt, die eigentlich nicht wesentlich und wertvoll ist.