Über unsMediaKontaktImpressum
Chris Rupp, Alexander Rauh & Christian Bock 02. November 2022

Continuous Documentation im agilen Systems Engineering

Die Kunst, die Menge der überflüssigen Dokumentation zu minimieren

"Funktionierende Software ist wichtiger als umfassende Dokumentation" ist einer der vier Werte des Manifests für agile Softwareentwicklung [1]. Viele Menschen fehlinterpretieren diese Aussage und proklamieren, dass in der Agilen Softwareentwicklung Dokumentation unnötig ist. Doch das ist grundlegend falsch. In vielen Kontexten bestehen Nachweispflichten oder Bedürfnisse/Probleme in der Entwicklung selbst, für die Dokumentation einen geeigneten Lösungsansatz darstellt. Wichtig ist, dass Sie sich bewusst machen, welche Dokumentation in welchem Maß für Sie in Ihrem Kontext notwendig und hilfreich zur Lösung eines Problems ist. Denn genauso häufig, wie die Dokumentation vernachlässigt wird, tritt der Fall ein, dass jede Menge Dokumentation generiert wird, die überflüssig ist. Sie ist weder aufgrund von Randbedingungen (z. B. rechtlichen Nachweispflichten) erforderlich, noch trägt sie zur Lösung eines Problems in der Entwicklung bei (z. B. Code-Kommentierung zum besseren Verständnis des Quellcodes).

Welchem Zweck dient Ihre Dokumentation?

Dokumentation ist kein Selbstzweck. Das bedeutet, dass Sie auf jegliche Dokumentation verzichten sollten, die für Sie bzw. Ihre Entwicklung keinen Mehrwert bietet. Ziel ist es, die Menge der überflüssigen Dokumentation auf das für Ihren Kontext sinnvolle Minimum zu beschränken oder sie ganz zu eliminieren. Doch hierfür müssen Sie zunächst herausfinden, welche Dokumentation in Ihrem Kontext und für Ihre Entwicklung überflüssig ist und welche nicht. Nach unseren Erfahrungen lassen sich folgende Zwecke unterscheiden:

  1. Dokumentation zur Steuerung der Tätigkeiten in der Entwicklung.
  2. Dokumentation zur Erfüllung von Nachweispflichten gegenüber Dritten.
  3. Dokumentation zur Konservierung von Wissen und Entwicklungserkenntnissen.

1. Dokumentation zur Steuerung der Tätigkeiten in der Entwicklung

Ein Zweck von Dokumentation kann die Planung, Priorisierung und Steuerung von Entwicklungstätigkeiten sein. Dabei werden alle für ein Release oder Inkrement notwendigen Tätigkeiten z. B. in Form von Backlog Items gesammelt. Anschließend erfolgt eine Priorisierung dieser Tätigkeiten untereinander, sodass die für das jeweilige Inkrement zwingend notwendigen Aufgaben definitiv Beachtung finden. Anhand dieser Aufgaben lassen sich zudem Mechanismen wie z. B. Story Points und Burn Down Charts etablieren, mit denen der Fortschritt in der Systementwicklung bestimmt werden kann. Eine Eigenschaft dieser Art von Dokumentation ist deren begrenzte Lebenszeit bzw. Gültigkeit. Die Aufgaben beziehen sich schließlich immer auf einen bestimmten Zeitraum während der Systementwicklung, z. B. auf ein Release oder Inkrement. Ist eine solche Aufgabe und das entsprechende Backlog Item abgeschlossen, muss diese im Rahmen der weiteren Entwicklung nicht weiter beachtet werden. Diese Dokumentation darf veralten. Sobald sie nicht mehr zweckdienlich ist und keine Notwendigkeit für deren Aufbewahrung besteht, kann diese auch vernichtet werden.

2. Dokumentation zur Erfüllung von Nachweispflichten gegenüber Dritten

Ein weiterer Zweck von Dokumentation kann das Führen von Nachweisen der Güte des Produkts gegenüber Dritten darstellen. Besonders im regulierten Umfeld wie z. B. in der Medizintechnik oder auch in der Funktionalen Sicherheit von technischen Systemen wie Kraftfahrzeugen oder Flugzeugen stellen Gesetze, Normen und Standards spezielle Anforderungen an das Produkt und an während der Entwicklung des Produkts durchzuführende Tätigkeiten. Bevor ein solches Produkt offiziell verkauft werden darf, muss der Anbieter nachweisen, dass das Produkt konform zu den im jeweiligen Kontext geltenden Gesetzen, Normen (z.B. ISO 26262, ISO 13485 und IEC 61508) und Standards entwickelt wurde. Diese Nachweise werden i. d. R. anhand erzeugter Dokumentationen geführt, die speziell die von der Norm geforderten Aspekte umfasst. Dabei ist zu beachten, dass die Dokumentation über den gesamten Lebenszyklus des Produkts Gültigkeit haben muss und trotz einer Weiterentwicklung nicht veralten darf. In einer inkrementellen Entwicklung ist zu beachten, dass sofern frühe Inkremente und/oder Releases an Kunden ausgeliefert werden sollen, die regulatorischen Vorgaben bereits für diese Inkremente und/oder Releases einzuhalten sind.

3. Dokumentation zur Konservierung von Wissen und Entwicklungserkenntnissen

Mit der Konservierung des im System abgebildeten Wissens sowie Erkenntnissen aus der Entwicklung kann Dokumentation einen weiteren Zweck erfüllen. Im erweiterten Sinne zählt hier ebenfalls die Unterstützung der Kommunikation innerhalb der Entwicklung dazu, bei der unterschiedliche Beteiligte mit unterschiedlichem Wissen über dasselbe System diskutieren. Speziell bei der Entwicklung komplizierter technischer Systeme, in der unterschiedliche Gewerke aufeinander treffen und gemeinsam ein funktionierendes System abliefern sollen, ist ein gemeinsames Verständnis für das Gesamtsystem von essenzieller Bedeutung. Hierbei lässt sich allerdings nicht pauschal sagen, ob die Dokumentation über den gesamten Lebenszyklus aktuell sein muss oder ob deren Gültigkeit stärker begrenzt ist. Anhand zweier Extreme wollen wir dies verdeutlichen:

Folgende Situation: In einem Austausch zwischen Entwicklern für Elektronik und Entwicklern für Software erstellen die Beteiligten eine Skizze, um deren Sichtweisen zu erläutern. Diese Skizze dient ausschließlich dem gemeinsamen Verständnis in dem Moment der Diskussion. Ein Aufbewahren über die Diskussion hinaus ist abhängig von dem skizzierten Inhalt, aber häufig kurz nach der Diskussion aufgrund weiterer Erkenntnisse bereits veraltet. Sie dient lediglich dem Moment.

Dies bedeutet nicht gleichzeitig, dass die einzige Dokumentation, die es sich aufzubewahren lohnt, die Codekommentierung ist. Neben der Codekommentierung gibt es viele weitere Artefakte, die aufbewahrt werden sollten und in einigen Kontexten sogar müssen – hierzu liefern wir Ihnen im Folgenden noch weitere Beispiele.

Je nachdem, welchen dieser Zwecke Sie mit Ihrer Dokumentation verfolgen, ergeben sich unterschiedliche Anforderungen an die zu erzeugenden Artefakte. Ein maßgebliches Unterscheidungsmerkmal stellt die Gültigkeitsdauer in kurzlebige und langlebige Dokumentation dar.

Was ergibt sich aus der Unterscheidung zwischen kurzlebiger und langlebiger Dokumentation?

Die Unterscheidung zwischen kurzlebiger und langlebiger Dokumentation ergibt sich aus deren unterschiedlicher Zweckmäßigkeit. Sie hilft Ihnen dabei, zu entscheiden und zu identifizieren, welche Artefakte Sie für Ihren Entwicklungsprozess benötigen und welche Probleme Sie idealerweise mit welchem Artefakttyp adressieren können. Die kurzlebige Dokumentation dient der Steuerung und Priorisierung von Entwicklungstätigkeiten sowie der Planung von Releases oder der akuten Lösung von Problemen in der Kommunikation. Wohingegen die langfristige Dokumentation beispielsweise der Erfüllung von Nachweispflichten, dem Konservieren von Wissen bzgl. des Produktes oder der Ergebnisse der Entwicklungsaktivitäten dient. Die Unterscheidung nach der Zweckmäßgikeit der Dokumentation hilft Ihnen dabei, die Aufwände Ihrer Dokumentationstätigkeiten bewusst zu steuern und zu fokussieren. Denn wenn für Sie beispielsweise keine Erfordernis für kurzlebige Dokumentation besteht, dann handelt es sich um in diesem Kontext überflüssige Dokumentation, auf die Sie dementsprechend auch – buchstäblich – keine Zeit verschwenden sollten, insofern sie keine Lösung für ein Problem in Ihrer Entwicklung darstellt. Ein kurzes Beispiel: Arbeiten Sie in einem Kontext, in dem es viele Wettbewerber und viele zu erwartende Anforderungsänderungen gibt, und die Time to Market ist für Sie ein entscheidender Faktor, so könnte die kurzlebige Dokumentation zur Abbildung der hohen Dynamik in den Anforderungen ein für Sie probates Mittel sein. Besteht für Sie gleichzeitig eine regulatorisch notwendige Nachweispflicht, so kann für Sie auch ein gewisses Maß an langlebiger Dokumentation hilfreich sein, um die geforderten Nachweise zu erbringen. Sie sehen also, dass es sich um keine Entweder-Oder-Beziehung (XOR) sondern vielmehr eine ODER-Beziehung (OR), in den meisten Fällen sogar eher eine UND-Beziehung (AND) handelt. Darüber hinaus liefert Ihnen die Gültigkeitsdauer ein Indiz, welchen Aufwand Sie jeweils in die Erzeugung und Pflege der unterschiedlichen Arbeitsergebnisse investieren sollten. Da kurzfristige Dokumentation sowieso nur eine begrenzte Gültigkeit aufweist, können Sie Pflegeaufwände nahezu ganz vernachlässigen. Langfristige Dokumentation sollte den Anspruch verfolgen, dass sie auch nach mehreren Jahren mit überschaubarem Aufwand noch nachvollziehbar, verständlich und vor allem aktuell ist. Daher sollten Sie nicht nur für die initiale Erzeugung gewisse Aufwände im Rahmen Ihrer Systementwicklung vorsehen, sondern auch die Pflege der erzeugten Arbeitsergebnisse ausreichend würdigen und als Teil Ihres Produkts verstehen. Je nachdem, in welchem Kontext Sie arbeiten und welche konkreten Herausforderungen in diesem bestehen, wird sich das Maß bzw. das Verhältnis der kurz- und langlebigen Dokumentation unterscheiden.

Was versteht man unter kurzlebiger, was versteht man unter langlebiger Dokumentation?

Was genau verbirgt sich nun hinter kurz- und langlebiger Dokumentation? Wir verdeutlichen es anhand einiger weiterer Beispiele und den Eigenschaften der jeweiligen Art der Dokumentation.

Bei der kurzlebigen Dokumentation handelt es sich um Artefakte, die der Steuerung und Priorisierung von Entwicklungsaktivitäten sowie der Planung von Releases dienen. Darunter fallen zum Beispiel Backlog Items wie Epics, Capabilities, Features und User Stories sowie Akzeptanzkriterien [2], das Product und Sprint Backlog, User Story Maps, Customer Journeys, die Definition of Done, Wireframes, Mockups oder andere explorative Prototypen. Wichtig ist, dass Sie sich hier bewusst machen, dass kurzlebige Artefakte, wie die im vorherigen Satz als Beispiele genannten, nicht (!) zur Erfüllung von rechtlich bzw. regulatorisch geforderten Nachweispflichten geeignet sind. Der Grund dafür liegt in einer der grundlegenden Eigenschaften kurzlebiger Artefakte verankert – nämlich, dass es sich bei diesen Artefakten um "Wegwerfartefakte" handelt, die nicht up to date gehalten werden und daher irgendwann veralten. So ergibt es beispielsweise keinen Sinn, ein Backlog Item, nachdem es umgesetzt wurde, nachträglich upzudaten, da es sich im konkreten Fall einer User Story lediglich um ein Kommunikationsversprechen handelt, das die Kommunikation in der Entwicklung fördern soll [3]. Dementsprechend sollten kurzlebige Artefakte auch nicht zwingend die gleichen Qualitätskriterien (z. B. die Qualitätskriterien für Anforderungen Vollständigkeit, Eindeutigkeit, und Konsistenz [4]) wie langlebige Artefakte erfüllen. Machen Sie also nicht den Fehler, Backlog Items mit einer langlebigen Produktdokumentation gleichzusetzen oder diese als solche verwenden zu wollen. 

Sprechen wir von langlebiger Dokumentation, handelt es sich um Artefakte, die oftmals zur Erfüllung einer regulatorisch geforderten Nachweispflicht oder zur Konservierung von Wissen bzw. den Ergebnissen unterschiedlicher Entwicklungsaktivitäten verwendet werden. Darunter fällt ein breites Spektrum von Artefakten, die wir daher in unterschiedliche Kategorien unterteilen:

  • Requirements-Spezifikationen,
  • Architektur-/Design-Spezifikationen,
  • safety-relevante Informationen,
  • security-relevante Informationen,
  • implementierungs-bezogene Informationen,
  • Tests,
  • release-bezogene Dokumentation, sowie
  • Planungsdokumente (z. B. Qualitätsmanagement- oder Projektpläne).

Für diese Artefakte gelten nicht selten auch Aufbewahrungsfristen, die seitens des Gesetzgebers gefordert werden. Wichtig ist hier, dass diese Artefakte über den gesamten Produktlebenszyklus aktuell gehalten werden müssen und die Qualitätskriterien (z. B. aus normativen Vorgaben, z. B. der ISO 26262 im Automobilbereich oder der ISO 14971 aus dem Bereich der Medizintechnik) an langlebige Artefakte deutlich strenger sind, als die, die wir an kurzlebige Artefakte stellen. Im Folgenden beschreiben wir genauer, wie Sie mit kurz- und langlebigen Artefakten umgehen können.

Wie zerlege ich meine Backlog Items im Systems-Engineering-Umfeld?

Bei der Zerlegung Ihrer Backlog Items sollten Sie sich – wie zum Beispiel in SAFe empfohlen – unterschiedlicher Abstraktionsebenen bedienen, um zum einen die Arbeit der einzelnen Teams voneinander zu entkoppeln und die Menge der Abhängigkeiten so weit wie möglich zu minimieren. Zum anderen sollten Sie sich die Abstraktionsebenen zu Nutze machen, um die Arbeit auf unterschiedlichen Integrationsstufen oder Abstraktionsebenen zu koordinieren sowie übergreifende Rollen wie beispielsweise Systemarchitekt:innen, Safety-/Security-Expert:innen oder Produktmanager:innen möglich frühzeitig zu involvieren.

So können Sie beispielsweise für jede Integrationsstufe Ihres Systems (z. B. System, Subsystem, Komponente) eine jeweilige Abstraktionsebene in Ihren Backlog Items (z. B. Epic, Feature, User Story) definieren und diese aufeinander mappen. Somit steuern und planen Sie die Tätigkeiten in den entsprechenden Integrationsstufen über die Backlog Items der entsprechenden Abstraktionsebene. Sie können z. B. Epics verwenden, um Systemfunktionen zu beschreiben, Features, um Subsystemfunktionen zu beschreiben und User Stories, um die Komponentenfunktionen zu beschreiben.

Dabei können Sie ähnlich vorgehen wie beim Wechselspiel zwischen Analyse und Architektur. Das heißt, dass Sie beispielsweise ein Epic fachlich als System-Black-Box-Funktionalität definieren, dieses dann mit den relevanten Rollen auf Systemebene (z. B. Architekt:innen, Risikoingenieur:innen, Produktmanager:innen) analysieren, um zu identifizieren, welche Subsysteme an der Funktionalität beteiligt sind. Im nächsten Schritt zerlegen Sie das Epic, also die Gesamtfunktion, in entsprechende Features, also Teilfunktionen, die Sie den Subsystemen zuordnen können und wiederholen dieses Vorgehen, bis Sie feingranulare Backlog Items (i. d. R. User Stories) erhalten, die Sie dann einem Team konkret zuordnen können (s. Abb. 1).

Ein weiterer Vorteil dieses Vorgehens ist, dass Sie die Priorisierung der Systemfunktionen, also in unserem Beispiel der Epics, durchführen können und so gezielt den Zeitpunkt für die Entwicklungstätigkeiten steuern können. So sollten Sie z. B. wenig bis keine Zeit in das Refinement der niedriger priorisierten Systemfunktionen stecken und diese erst dann betrachten, wenn sich eine entsprechende Wichtigkeit und/oder Dringlichkeit für diese einstellt. Durch die Zerlegung Ihrer Backlog Items können Sie dies für den jeweiligen Betrachtungsgegenstand der entsprechenden Abstraktionsebene planen. Zusätzlich hilft Ihnen und v. a. den Teams, die im Detail arbeiten, dieser Top-Down-Ansatz dabei, den Blick für das Produkt als Ganzes, also das "Big Picture", zu behalten und die richtige Lösung im Detail für das Problem im systemischen Kontext zu finden. Hier folgt das agile Vorgehen also einem grundlegenden Prinzip des Systems Engineering: die ganzheitliche und systemische Betrachtung des zu entwickelnden Systems.

Ein weiterer Vorteil dessen, dass die Abstraktionsebenen der Backlog Items den Integrationsstufen Ihres Systems entsprechen, ist, dass Sie so die Integrationsaufwände bewusst mit einplanen können, indem Sie beispielsweise als Teil der Definition of Done auf den höheren Abstraktionsebenen (z. B. Epic und Feature Ebene) festlegen, dass die Integration der einzelnen Architekturelemente erfolgt sein muss, damit das entsprechende Backlog Item als "done" – also abgeschlossen – angesehen werden kann. So stellen Sie sicher, dass Integrationsaufwände bewusst mit eingeplant werden und die Notwendigkeit zur Abstimmung unter den Teams ins Bewusstsein rückt. Beachten Sie dabei, dass sich die Releases der Subsysteme aufgrund der angepassten Definition of Done nach den Releases des Systems richten müssen, um die Integrationsfähigkeit zu gewährleisten.

Wichtig bei der Definition Ihrer Backlog Items ist vor allem, dass Sie Ihre Backlog Items möglichst lösungsneutral beschreiben, Sie sich also im Problemraum bewegen, und sich dabei der für Sie geltenden Constraints bewusst sind. Wozu die Trennung zwischen Problem- und Lösungsraum? Wenn Sie Ihre Backlog Items möglichst lösungsneutral formulieren, bieten Sie den Teams, also den Experten in ihren entsprechenden Disziplinen, einen möglichst großen Lösungsraum, in dem diese dann die Möglichkeit haben, die ideale Lösung für das bestehende Problem, also die eigentliche Anforderung, in Anbetracht der geltenden Constraints zu finden. 

Wie gehe ich mit meiner langfristigen Dokumentation um?

Genauso wie bei der Definition der Struktur und Inhalte Ihrer kurzlebigen Dokumentation müssen Sie sich überlegen, wie Sie Ihre langlebige Dokumentation gestalten bzw. aufbauen. Ein Irrglaube, dem wir in vielen unserer Kundenprojekte begegnen, ist, dass eine umfangreiche Dokumentation regulatorisch gefordert sei. Dies ist allerdings nicht der Fall. Von regulatorischer Seite wird typischerweise lediglich ein Nachweis über einen Aspekt in der Entwicklung gefordert. Um diesen Nachweis zu erbringen, ist Dokumentation lediglich ein mögliches Hilfsmittel. Setzen Sie sich daher intensiv mit den für Sie geltenden Nachweispflichten auseinander und überlegen Sie sich, wie Sie diesen Nachweis erbringen können und wollen. Legen Sie zusätzlich genau fest, was das für Sie mindestens erforderliche Maß an Dokumentation ist, das erstellt werden muss, um den Nachweis zu erbringen und beschränken Sie sich auf dieses, um die Menge der überflüssigen Dokumentation zu reduzieren. Letztlich handelt es sich hierbei auch zu einem gewissen Grad um Risikomanagement. Daher empfehlen wir Ihnen, hier bewusst zu trennen zwischen regulatorisch relevanter Dokumentation und Dokumentation, die Sie in Ihrer Entwicklung unterstützt und Wissen konserviert – diese bezeichnen wir im Folgenden als "Engineering-Dokumentation".

Wozu diese Unterscheidung? Um das übergeordnete Ziel der Minimierung der überflüssigen Dokumentation zu erreichen. Überlegen Sie sich auch für die Engineering-Dokumentation, welche Dokumentation für Sie einen Mehrwert stiftet bzw. welche vielleicht sogar zwingend erforderlich ist. Die Trennung von regulatorisch relevanter und Engineering-Dokumentation erlaubt es Ihnen wiederum in hektischen Phasen vor einem Produktrelease, die Aufwände auf die für das Release notwendige, weil regulatorisch geforderte Dokumentation, zu konzentrieren. Die Engineering-Dokumentation, die Sie beispielsweise für die Wartung, den Support oder für die Wiederverwendung Ihres Systems oder Teil Ihres Systems in Zukunft verwenden, können Sie zu einem späteren Zeitpunkt erstellen, um das Release nicht zu verzögern.

Auch hier empfehlen wir Ihnen die bewusste Trennung von Problem- und Lösungsraum. Weshalb? Aus mehreren Gründen. Zunächst sparen Sie sich so Aufwand bei Änderungen, denn wenn Sie beispielsweise eine Änderung an der Lösung (z. B. im Rahmen eines Refactorings) durchführen, hat dies oft keine Auswirkung auf die Anforderung, also den Problemraum. So sparen Sie sich Aufwand bei der Pflege der Dokumentation und laufen weniger Gefahr, dass Sie durch Änderungen Inkonsistenzen oder andere Mängel in Ihrer Dokumentation erzeugen. Außerdem fördern Sie so Innovationen oder zumindest Produktverbesserungen. Denn wenn Sie eine Anforderung wiederverwenden, die lösungsneutral formuliert ist, erlauben Sie Ihrer Entwicklung eine neue – vielleicht bessere – Lösung zu finden, als in der Vorgängerversion des Produkts. Enthält Ihre Anforderung bereits eine Lösungsbeschreibung, so nageln Sie Ihre Entwicklung auf eben diese Lösung fest. Die Wahrscheinlichkeit bzw. Möglichkeit zur Innovation oder auch nur Verbesserung schrumpft auf praktisch null. Außerdem hilft Ihnen die bewusste Trennung von Problem- und Lösungsraum dabei, sich über das eigentliche Bedürfnis bzw. die eigentliche Anforderung Ihrer Stakeholder bewusst zu werden. Denn nur wenn Sie die eigentlich Anforderung Ihrer Stakeholder verstanden haben, können Sie eine passende Lösung dazu finden. Die bewusste Trennung von Problem und Lösung hilft Ihnen also dabei, das richtige Produkt für Ihre Stakeholder zu entwickeln, wodurch wiederum die Wahrscheinlichkeit dafür, dass Ihre Stakeholder mit Ihrem Produkt zufrieden sein werden, enorm steigt.

Wie funktioniert das Zusammenspiel zwischen kurz- und langlebiger Dokumentation?

Wie im zweiten Teil des Artikels bereits beschrieben, besteht keine Entweder-Oder-Beziehung zwischen der kurz- und langlebigen Dokumentation, sondern vielmehr eine ODER- bzw. sogar UND-Beziehung. Wie Sie die Stärken beider Dokumentationsarten unter einen Hut bekommen, ohne in zusätzlicher Arbeit zu versinken? Unser pragmatischer Ansatz: Continuous Documentation. Damit meinen wir das bewusste Verzahnen von kurzlebiger mit langlebiger Dokumentation mit dem Ziel, zu jedem Zeitpunkt der Systementwicklung über die zu diesem Zeitpunkt relevanten Teile der Dokumentation zu verfügen, z. B. die für eine Produktfreigabe notwendigen Artefakte im regulierten Umfeld. Das Vorgehen gestaltet sich wie folgt (s. Abb. 2):

  • Schritt 1: Der erste Schritt ist, dass Sie für Ihre Backlog Items identifizieren, welche Artefakte davon betroffen wären, also wo Sie bestehende Inhalte ändern oder neue Inhalte ergänzen müssten. Hierbei ist es ausreichend, die Artefakte zunächst zu identifizieren, Sie müssen nicht zwangsweise bereits die konkrete Änderung benennen.
  • Schritt 2: Sobald das Backlog Item bearbeitet wird, also in die Implementierung geht, führen Sie die notwendigen Änderungen durch, insofern die Verantwortung für das entsprechende Artefakt bei Ihnen liegt. Liegt die Verantwortung nicht bei Ihnen, so kommunizieren Sie die notwendigen Änderungen an die entsprechenden Autor:innen der betroffenen Artefakte.
  • Schritt 3: Im Anschluss, sobald die Änderungen durchgeführt wurden, führen Sie ein Review über die Gesamtheit der durchgeführten Änderungen durch (oft wird dies als "Feature-Review" bezeichnet). Dies dient dazu, sicherzustellen, dass die durchgeführten Änderungen durchgängig, konsistent und inhaltlich korrekt sind.
  • Schritt 4: In einem letzten Schritt führen Sie dann ein Review mit den Stakeholdern durch, die Sie für eine Freigabe des Dokuments benötigen. Der letzte Schritt ist dabei zunächst optional und kann abhängig von Ihrem Entwicklungsprozess auch losgelöst bzw. zeitunabhängig von den Schritten 1 bis 3 stattfinden oder weggelassen werden, insofern Sie beispielsweise keine Freigabe für Ihre Dokumentation benötigen. Wichtig ist jedoch, dass in den vorhergehenden Schritten die Dokumentation dem aktuellen Stand der Systementwicklung entspricht.

In der Praxis haben wir hierbei bereits einige Good Practices sammeln können, die wir im Folgenden mit Ihnen teilen. Zwei Good Practices haben wir bereits beschrieben, nämlich die bewusste Trennung von release-notwendiger und nicht-release-notwendiger (Engineering-)Dokumentation, um das Ausmaß und damit den Aufwand für die Dokumentation auf das wirklich Notwendige zu beschränken. Die zweite bereits beschriebene Good Practice ist die Durchführung der Reviews für die Gesamtheit der Änderungen ("Feature-Reviews"). Darüber hinaus empfehlen wir Ihnen die Pflege der Dokumentation in die Definition of Done für die Backlog Items der entsprechenden Abstraktionsebene zu definieren sowie die Identifikation und Dokumentation der betroffenen Dokumente eines Backlog Items in die dazugehörige Definition of Ready mit aufzunehmen. Auch hier gilt: überlegen Sie sich spezifisch für Ihren Kontext und Ihre Entwicklung, ob ein solches Vorgehen einen Mehrwert stiftet. Adaptieren Sie ggf. anhand Ihrer spezifischen Problemstellungen und versuchen Sie nichts zu reparieren, was nicht kaputt ist. Besinnen Sie sich also auch auf die Dinge, die in Ihrer Entwicklung bereits gut gelingen und behalten Sie diese bei oder intensivieren Sie diese vielleicht sogar.

Abschließend möchten wir die Kernaussagen und Takeaways wiederholen und zusammenfassen.

  1. Dokumentation ist kein Selbstzweck. Jede Dokumentation, die Sie erstellen, sollte ein konkretes Problem lösen, andernfalls ist sie überflüssig.
  2. Machen Sie sich bewusst, welche Probleme Sie mit Dokumentation zu lösen versuchen und wählen Sie die entsprechend zu Ihrem Problem passenden Artefakte in der passenden Repräsentation (z. B. Modell oder Text).

Wir hoffen, dass Sie aus unserem Artikel Impulse für Ihre konkrete Problemstellung ziehen können.

Autor:innen

Chris Rupp

Chris Rupp legte das Fundament des NLP-basierten Requirements-Engineering. Sie ist Autorin zahlreicher international verlegter Publikationen und als Trainerin und Beraterin für Kunden im Einsatz.
>> Weiterlesen

Alexander Rauh

Alexander Rauh unterstützt als Berater und Trainer bei der SOPHIST GmbH die Kund*innen im Systems Engineering bei der Einführung und Verbesserung von Entwicklungsprozessen und -methoden.
>> Weiterlesen
Christian Bock

Christian Bock

Christian Bock unterstützt als Berater und Trainer bei der SOPHIST GmbH die KundInnen im Requirements- und Systems Engineering bei der Definition, Einführung und Verbesserung von Entwicklungsprozessen
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben