Antwort.

Historie der Frage:

In IT-Projekten mit langen Entwicklungszyklen können sich die Anforderungen häufig ändern und die Dokumentation schnell veralten. Das führt zu Inkonsistenzen zwischen Entwicklern und Auftraggeber, erhöht die Unterstützungskosten und erschwert die Einführung von Änderungen.

Problem:

Es genügt oft, dass die Beschreibung der Anforderungen ungenau, unvollständig oder veraltet ist, um Fehler, Missverständnisse im Team, ein Anstieg der technischen Schulden und eine geringe Effizienz der QA-Arbeit zu verursachen.

Lösung:

Der Systemanalytiker führt Prozesse für lebendige Dokumentation und regelmäßige Überprüfung der Artefakte ein. Der Einsatz von Ansätzen wie Documentation as Code (Dokumentation in Git-Repositories), enge Integration mit Aufgabeninstrumenten (Jira, Confluence), Automatisierung der Verknüpfung von Anforderungen mit Aufgaben und Testfällen sowie die Organisation von Treffen zur Überprüfung der Dokumentation und der Anforderungen. Es ist wichtig, eine Kultur der „einzigen Wahrheit“ für alle Stakeholder zu entwickeln.

Wesentliche Merkmale:

Aufbau von selbstaktualisierender Dokumentation.
Öffentlicher und transparenter Prozess zur Änderung von Anforderungen.
Systematische Überprüfung von Änderungen und Benachrichtigung der Stakeholder.

Fangfragen.

Was unterscheidet Living Documentation von einer guten Spezifikation?

Lebendige Dokumentation bedeutet nicht nur Aktualität, sondern auch die Integration mit Entwicklungstools (zum Beispiel können Tests nach BDD selbst das aktuelle Dokument erstellen), automatische Überprüfung von Änderungen und eine einfache Überprüfung der Historie.

Kann man vollständig auf formale Dokumentation verzichten, indem man nur User Stories und Backlog-Tickets verwendet?

Nein, User Stories decken nicht die Integrationsschnittstellen, die Details zu Geschäftsregeln und die Szenarien von Edge Cases ausreichend ab: Es ist eine Harmonie zwischen Prägnanz und Vollständigkeit der Spezifikationen erforderlich.

Wenn sich die Anforderungen geändert haben, reicht es dann aus, einfach den Text in Confluence zu aktualisieren?

Nein, es ist wichtig, dieses Update mit allen verknüpften Artefakten zu synchronisieren: Testfällen, Aufgaben, Datenmodellen. Eine gute Praxis ist die Automatisierung solcher Verknüpfungen, sonst kommt es zu einer Desynchronisation und Fehlern.

Typische Fehler und Anti-Patterns

Aktualisierung der Dokumentation „nach dem Restprinzip“ – wenn sie nur bei wesentlichen Änderungen bearbeitet wird.
Nutzung von vielen getrennten Tools, in denen die einzige Version der Anforderungen verloren geht.
Erstellung von Dokumentation nur zur Rechenschaftslegung, ohne auf den Nutzen für das Team zu fokussieren.

Beispiel aus dem Leben

Negativer Fall:

In einem großen Fintech-Projekt wurden die Anforderungen in Word-Dokumenten gehalten, per E-Mail versendet und führten keine einheitliche Historie. Nach dem Release entsprach ein Teil der Funktionalität nicht den Erwartungen des Auftraggebers, und einige Bugs spiegelten sich nicht in den Spezifikationen wider.

Vorteile:

Schnelle anfängliche Erstellung der Dokumentation

Nachteile:

Schneller Verlust der Aktualität
Fehler bei Nachbesserungen
Fehlende einheitliche Basis für alle

Positiver Fall:

In einem anderen Projekt wurde die Dokumentation im selben Repository wie der Code (Asciidoc + Gitlab) gepflegt, jede Änderung durchlief ein Code-Review. Es wurden verknüpfte Beziehungen zwischen Anforderungen, Testfällen und Aufgaben eingerichtet.