Requirements Engineering und Scrum beschäftigt auch das von mir aktuell betreute Team.
Die folgenden Fragen hat mir das Team in den Posteingang gesteckt:
- Wo wird der Systemkontext abgebildet, in der Vision?
- Wo werden Constraints dokumentiert?
- Macht es Sinn zusätzlich zu den Stories Use-cases bzw. Diagramme zu erstellen? Falls ja wo werden diese abgelegt?
- Falls beim Umsetzen der User Stories nochmals Requirements-Analyse betrieben wird, wo werden die Details dieser Anforderungen dokumentiert?
- Kann man ein zusätzliches Anforderungsdokument erstellen, in dem, wo nötig zu den einzelnen Backlog-Einträgen eine detaillierte Spezifikation festgehalten wird?
Diese Fragen werden mir immer wieder gestellt. Ich stelle ganz allgemein fest, dass nach wie vor die Meinung herrscht, dass ein Dokumentieren in agilen Projekten "verboten" ist. Ich hoffe diese Meinung setzt sich nicht durch. Gute "klassische" Best Practices müssen in agilen Projekten nicht verworfen werden, sondern unter der agile Praktik "Avoid Waste" betrachtet werden.
Hier ein paar meiner persönlichen generellen Überlegungen:
- Wenn das Team eine Use Case Spezifikation (wobei ich eher sagen würde User Story Spezifikation) für sinnvoll und nützlich erachtet - zusätzlich zu den user story Karten auf dem Scrumboard, dann go4it.
- Wenn ein System Context Diagramm als sinnvoll erachtet wird, weil die Einbettung des Systems in die Umgebung kompliziert ist und eine Visualsierung hilft, dann go4it, usw. usw.
Meines Erachtens und meiner Erfahrung heraus benötigt auch ein agiles Projekt über ein gewisses Set an Dokumentation auch in Bezug auf das Requirements Engineering. Welche RE Dokumente nun Sinn machen, hängt von dem zu erstellenden System ab:
- Ist es hoch interaktiv und treibt den Benutzer durch Prozesse (Beispiel eine EPR oder CRM System), so sind Storyboards zusätzlich zu den User Story Cards auf dem Scrumboard sinnvoll.
- Sind die einzelnen User Stories komplex (Beispiel: Vertragsverwaltung von Versicherungsverträgen), dann ist eine Beschreibung nach Use Case Art mit Szenarios eventuell geeignet.
- Ist es ein Batch System mit einer über Interfaces und Messages getriebenen Batchverarbeitung, dann ist wohl ein Kontextdiagramm für die Einbettung und eine UML-Beschreibung mit einer State Machine zur Beschreibung der Batchprozesse sinnvoll (da ja Batchprozesse den Zustand von Geschäftsobjekten voran treiben).
Wesentlich in einem agilen Projekt ist, dass das Team am Anfang überlegt, was für ein System es erstellt und welche Dokumentation zusätzlich zum Scrumboard hilfreich wäre. Ein Grund kann auch sein, dass die Software (viel) später zu einer Version 2 weiter entwickelt werden soll, dann eventuell mit einem anderen Team.
Die Dokumente entstehen Sprint für Sprint. Am Anfang wird wohl eher mehr geschrieben (Festigung der Architektur und Beschreibung der grundsätzlichen Abläufe im System). Später wird eher weniger dokumentiert werden. Ein Ablauf muss wohl nur dann spezifiziert werden, wenn er vom Standard abweicht oder so komplex ist, dass er alleine anhand der Vision, des Code und der Abnahmetest nicht verstanden werden kann.
Ich hoffe, diese allgemeine Beschreibung hilft ein bisschen den groben Rahmen zu sehen.
Hier nun meine persönliche Antworten auf die konkreten Fragen (auch mit meiner Brille als Board Member des International Requirements Engineering Boards IREB).
Ad 1) Wo wird der Systemkontext abgebildet, in der Vision?
Das ist ein möglicher Weg, das macht Sinn. Ich verfolge das Ziel, dass ein Visionsdokument nicht länger als 10 Seiten wird, das funktioniert nicht immer, wäre aber ein Ziel. Zudem ist der typische Leserkreis zu des Vision Dokument zu beachten. Leser sind neben dem Product Owner und Team, vor allem externe Stakeholder, wichtig vor allem das Management. Für diese sollte die Vision auch - leicht - lesbar sein. Wenn die Vision mit dem Systemkontext zu technisch wird, dann würde ich die technischen Teile lieber in ein anderes Dokument, zum Beispiel auch in das SAD verschieben.
Ad 2) Wo werden Constraints dokumentiert
Kommt darauf an, welche Constraints. Es gibt solche an den Prozess, an das Produkt, an einzelne Funktionalitäten. Meine Vorschläge für diese unterschiedlichen Typen von Constraints:
- Prozess (wie FDA, oder Einhaltung von Normen und Standards wie SOX): In die Vision schreiben, dass solche zu beachten sind. Zusätzlich auf dem Scrumboard einen Quadranten Constraints eröffnen und die Constraints auf das Scrumboard hängen. Es kann auch sein, dass Prozess Constraints sich in den Done Kriterien wiederfinden (Am Ende eines Sprints muss dieser oder jener Nachweis mit geliefert werden).
- Produkt: Unterscheidet sich nicht wesentlich von nicht funktionalen Anforderungen. Beispiel: Fachliche Nutzdaten müssen außerhalb des geschützten Systembereiches, d.h. in der DMZ des Unternehmens und extern, verschlüsselt übermittelt werden. Dann muss markiert werden, welche User Stories davon betroffen sind. Anderes Beispiel: Forderung auf einer tieferen Detailstufe aufgrund einer SOX Compliance (wie z.B. Unabhängigkeit von Wirtschaftsprüfern, also eine Funktionalität). Auch hier müssen die betroffenen User Stories markiert werden.
- Funktionalität: Bei der User Story auf der Karte (oder in einer RE-Spezifikation, die neben dem Scrumboard existiert) beschreiben. Zu den Constraints sind Abnahmetests dazu definieren, um den Nachweis der Einhaltung der Constraints zu liefern. Eventuell ergiben sich neue User Stories aufgrund von Constraints.
Letztendlich gilt es zu unterscheiden, welcher Typ von Constraint vorliegt und wie dieser heruntergebrochen wird.
Ad 3) Macht es Sinn zusätzlich zu den Stories Use-cases bzw. Diagramme zu erstellen? Falls ja wo werden diese abgelegt?
Die Frage kann nicht allgemein beantwortet werden (siehe allgemeine Bemerkungen). Wenn Diagramme helfen, weil das Team davon profitiert den Aspekt X des Systems grafisch darzustellen, dann macht es Sinn Diagramme zu erzeugen. In meinen Augen sind zumindest im SAD Diagramme. Ein nicht triviales System mit persistenten Daten hat typisch ein UML Geschäftsobjekt-Modell, eventuell auch ein physikalisches Datenmodell. Im Design sind eventuell ein Klassendiagramme sinnvoll für bestimmte Ausschnitte des Systems.
Wo diese abgelegtwerden?
Meiner Meinung nach gehören ALLE Artefakte in das Versions-/Konfigurationsmanagement System, d.h. Vision, Fotos des Scrumboards, Foto von Workshops, SAD, Design und RE Dokumente, der Source Code, der Testcode, Marketing Dokumente, einfach alles. Das bedeutet eine Ablagestruktur zu entwerfen, in die alles hinein geworfen und gefunden werden kann. Prozesse wie RUP von IBM oder Prince2 oder Hermes bieten Vorlagen dazu. Diese sind genauso geeignet wie eine selber entworfene. Ich persönlich lege Dokumente gerne in Folder ab gemäß den SWE-Disziplinen (Mgmt, RE, Design, Architektur, MeetingMinutes, ReviewResults...), ich bin das eben so gewöhnt aus meinen bisherigen Best Practices...
Ad 4) Falls beim Umsetzen der User Stories nochmals Requirements-Analyse betrieben wird, wo werden die Details dieser Anforderungen dokumentiert?
In einem zusätzlichen Dokument, dass im Versionsmanagementsystem abgelegt wird. Welches Dokument das ist, wie es heisst, wie die Struktur aussieht, um das Dokument abzulegen und wann es von wem geschrieben wird, entscheidet das Team ("Avoid Waste" ;-).
Ad 5) Kann man ein zusätzliches Anforderungsdokument erstellen, in dem, wo nötig zu den einzelnen Backlog-Einträgen eine detaillierte Spezifikation festgehalten wird?
Ja, klar. Interessanter ist die Referenz der Karte in ein Dokument. Zwei Ideen:
- Leichtgewichtig: Fotografiert die Karte und fügt das Foto der Karte in dem Dokument an die Stelle der RE-Spec ab.
- Etwas schwerer: Vergebt auf den Karten ID's für die User Story und referenziert in dem Dokument die ID der Karte.
Hinweis: Jedes nicht triviale Projekt hat typisch die Karten am Scrumboard zusätzlich irgendwo in einem elektronischen Tool abgelegt (TFS, Excel, Word, ...). Dann kann in dem Tool die Referenz gepflegt werden (und auch dort das Foto der Karte abgelegt werden).
