Und weiter geht die wilde Fahrt! Herzlich willkommen zurück auf der Reise durch unser Buch „Requirements-Engineering und –Management – Aus der Praxis von klassisch bis agil“. Unsere heutige Haltestelle ist Kapitel 11 oder auch „Dokumentation im agilen Umfeld“.
Welche Möglichkeiten es gibt, dass in agilen Entwicklungsprojekten die Dokumentation nicht zu kurz kommt und wie Sie dabei am besten Vorgehen, werden dabei unser Reiseleiter – also die zentralen Fragen für diesen Beitrag – sein und Ihnen einen groben Überblick verschaffen.
„Dokumetation? Wir arbeiten doch agil!“ – Eine häufige Misinterpretation des agilen Manifests führt zu dem Irrglauben, dass man in agilen Projekten keine Dokumentation braucht. Dabei bedeutet das Statement „Funktionierende Software mehr als umfassende Dokumentation“ lediglich, dass die Entwicklung lauffähiger Software eine höhere Priorität haben sollte als eine umfassende Spezifikation dieser, nicht jedoch, dass gänzlich auf Dokumentation verzichtet werden sollte.
Die Artefakte, die zur Dokumentation von Anforderungen verwendet werden unterscheiden sich natürlich von Projekt zu Projekt, je nachdem, welche Vorgehensweise gewählt wurde. Artefakte, welche man häufig in agilen Projekten findet, sind Backlog-Items, z.B. User-Storys, welche als Teil des Product-Backlogs die Grundlage für die Planung von Sprints dienen.
Da in User-Storys der Fokus auf der Funktionalität liegt, werden nicht-funktionale Aspekte häufig vernachlässigt. Um dem entgegen zu wirken, stellen Akzeptanzkriterien sowie Technical Storys zwei mögliche Mittel der Wahl dar. Darüber hinaus können globale Qualitätsanforderungen oder Randbedingungen auch in die Definition of Ready oder Definition of Done mit einfließen – was es mit diesen beiden Begriffen auf sich hat, dazu später mehr. Prinzipiell gibt es keine Vorgabe wie User-Storys zu dokumentieren sind, es gibt allerdings Best-Practices, die sich für uns in der Praxis bewährt haben. Demnach werden User-Storys in der Regel nach dem folgenden Schema verfasst:
Akzeptanzkriterien definieren, wann bzw. unter welchen Bedingungen ein Backlog-Item, z.B. eine User-Story als umgesetzt und damit auch gleichzeitig als abgenommen gilt. Hilfreich für die Formulierung von Akzeptanzkriterien kann dabei das Given-When-Then-Schema sein sowie die SMART-Formel sein.
Da verschiedene Mitglieder des Teams oftmals unterschiedliche Auffassungen davon haben, wann eine Artefakt, sei es eine User-Story oder ein entwickeltes Inkrement, „fertig“ ist, ist es wichtig, dass man die verschiedenen Auffassungen konsolidiert und ein gemeinsames Verständnis darüber schafft. Die beiden Methoden, die sich dabei für uns bis Dato bewährt haben sind die Definition of Ready sowie die Definition of Done.
In der Definition of Ready (kurz: „DoR“) legt das Team gemeinsam Kriterien fest, anhand welcher festgemacht werden kann, ob eine User-Story detailliert genug ist bzw. ausreichend konkret und klarbeschrieben ist, um in den Sprint-Backlog gepullt und abgearbeitet zu werden.
Die Definition of Done (kurz: „DoD“) legt fest, welche Kriterien erfüllt sein müssen, damit die Arbeit am Inkrement als abgeschlossen gilt.
Wichtig ist dabei, dass es keine allgemein gültigen DoRs/DoDs gibt. Diese muss jedes Projekt/Unternehmen für sich selbst definieren und im Laufe der Projektlaufzeit ggf. auch weiterentwickeln und an ihre Bedürfnisse anpassen.
Alles Weitere rund um das Thema „Dokumentation im agilen Umfeld“ und noch viele mehr finden Sie in unserem Buch „Requirements-Engineering und –Management – Aus der Praxis von klassisch bis agil“.
Wir verabschieden uns an der Stelle und freuen uns schon mit Ihnen auf das nächste Kapitel.
Ihre SOPHISTen