Wir sind jetzt agil – wir dokumentieren keine Anforderungen mehr!

„Wir sind jetzt agil – wir dokumentieren nicht mehr!“ Oder: „Die User Stories reichen uns als Dokumentation.“ Solche oder ähnliche Aussagen habe ich schon öfter von Softwareentwicklungsteams gehört.

Für die Entwicklung von überschaubaren Systemen mit kürzerer Lebensdauer kann das gut funktionieren. Genauso, wenn das Team, das das System gebaut hat, auch nach der Inbetriebnahme des Systems verfügbar ist, um eventuell aufkommende Fragen von Nutzern oder Systembetreuern zu beantworten.

Schwieriger wird es bei der Entwicklung von komplexen Systemen mit langer Lebensdauer, wie zum Beispiel in der Raumfahrt. Softwaresysteme sind hier gut und gerne über zehn Jahre im Betrieb und müssen über den gesamten Zeitraum gewartet und betreut werden. Viele der an der ursprünglichen Realisierung beteiligten Person haben das Unternehmen dann vielleicht schon wieder verlassen oder arbeiten in anderen Projekten, so dass ihre Unterstützung nicht kurzfristig eingeholt werden kann. Wenn die Dokumentation dann nur im Sourcecode vorliegt, müssen sich projektfremde Personen erst mühsam in den Code einarbeiten. Bei Fehlern im Live-System kann genau das wertvolle Zeit kosten.

Gar nicht zu dokumentieren ist also keine gute Idee. Also wäre es doch theoretisch im eigenen Interesse des Entwicklungsteams, Dokumentation außerhalb des Quellcodes zu schreiben, oder? Leider nur theoretisch. Dokumentationserstellung zählt in der Softwareentwicklung (mit einigen wenigen Ausnahmen!) eher zu den unliebsamen Tätigkeiten. Ein „notwendiges Übel“ quasi, um das man sich nur kümmert, wenn kein Weg daran vorbeiführt. Falls niemand nach einer Dokumentation fragt, kann das eine Weile gut gehen. Zumindest solange, bis dann besagte Fehler im Live-System auftauchen und alle angestrengt überlegen, welcher Service denn noch mal für was zuständig war…

Falls aber am Ende doch eine Dokumentation mit ausgeliefert werden muss, weil der Kunden oder der Gesetzgeber dies verlangen, kommen „dokumentationsfaule“ Teams früher oder später ins Schwitzen. Manche machen dann „Dokumentationssprints“, in denen alle Teammitglieder zum Projektende – oft über mehrere Wochen – nur noch dokumentieren. Aus eigener Erfahrung weiß ich, dass dies meist ein äußerst mühsames Unterfangen ist. Denn bei sehr komplexen Systemprozessen reichen schon ein paar Wochen oder sogar Tage, um beispielsweise Details beispielsweise über Prozessabläufe zu vergessen. Diese dann aus dem Quellcode zu rekonstruieren, ist oft langwierig und fehleranfällig.

Wahrscheinlich ist es mit der Dokumentation also ein bisschen, wie mit dem guten Vorsatz, mehr Sport zu treiben: Wir wissen alle, dass Sport gesund ist. Trotzdem hindert uns oft unser innerer Schweinehund daran, uns mehr zu bewegen. Wenn dann schließlich das schlechte Gewissen groß genug ist, wird versucht, dies durch lange und intensive Trainingseinheiten zu kompensieren. Prompt stellt sich ein heftiger Muskelkater ein, der dann auf dem Sofa auskuriert werden muss. Stattdessen wäre es vermutlich besser, regelmäßiger und moderater zu trainieren…

Der Vortrag will aufzeigen, wie es ein agiles Team schafft, den inneren „Dokumentations-Schweinehund“ zu überlisten und Dokumentation zur guten Gewohnheit zu machen.

Verschiedene Techniken werden hierzu vorgestellt, wie z. B. die Integration der Dokumentationserstellung in den Entwicklungsprozess über eine Definition of Done oder Unteraufgaben, die Nutzung von angepassten Standardtemplates zur Dokumentation und dem Ansatz "Docs as Code". Außerdem lernen die Zuhörer das Konzept der "Lean Documentation" kennen, bei dem Soll- und Ist-Zustand im selben Dokument beschrieben werden und auf eine eigene Anforderungsdokumentation verzichtet werden kann.

Was lernen die Zuhörer in dem Vortrag?

  • Verknüpfung klassischer und agiler Methoden
  • Strukturiertes Vorgehen zur Anforderungserhebung
  • Zusammenspiel Ereignisgesteuerter-Prozessketten und User-Story-Mapping
  • Zusammenspiel Ereignisgesteuerter-Prozessketten und UX-Design
  • Wertvolle Learnings, wo process driven requirements management in der Kommunikation mit dem Team helfen kann
Kathrin Herrmann
Kathrin Herrmann

Seit 2004 bin ich im Softwarebereich tätig und kenne sehr gut die Herausforderungen, die die Einführung einer neuen Softwarelösung und die Weiterentwicklung...


Michael Herrmann
Michael Herrmann

Michael Herrmann...

45 Minuten Vortrag

Fortgeschritten
Zeit

14:55-15:40
08. Oktober


Zielgruppe

Product Owner, Entwickler, Scrum Master


Themengebiet

Techniken


Raum

tba


ID

Di2.4

Zurück

Copyright © 2019 HLMC Events GmbH