Dokumentieren in agilen Methoden (Teil 3) – Lean Software Development

Im zweiten Teil unserer Blogserie zum Thema „Dokumentieren in agilen Methoden“ haben wir Ihnen Adaptive Software Development (ASD) vorgestellt. Sie haben den Artikel verpasst und möchten nicht auf die Inhalte verzichten? Hier geht’s zum vorherigen Artikel.

In dem dritten Artikel der Serie möchten wir Ihnen Lean Software Development (LSD) als agiles Framework vorstellen. Dazu erklären wir Ihnen die definierten Rollen und Artefakte, die das Framework bietet. Die Inhalte des Blogs stammen aus dem Buch Lean Software Development – An Agile Toolkit [1].

LSD ist eine Sammlung an Hilfsmitteln und Werkzeugen zur Verbesserung von Softwareentwicklungsprozessen. Eine feste Prozessstruktur wird nicht vorgeschrieben. Grundsätzlich wird der gesamte Prozess wie bei Scrum und ASD auch in kleine und gut überschaubare Teile zerlegt. Die Dauer dieser Iterationen kann je nach Projekt zwischen zwei und zehn Wochen variieren. Viele Ansätze, die in Lean Software Development enthalten sind, stammen ursprünglich aus großen Produktionsbetrieben und wurden auf die Softwareentwicklung übertragen.

LSD ist in sieben Prinzipien unterteilt, die bei der Entwicklung von Produkten eine wichtige Rolle spielen. Innerhalb dieser Prinzipien sind verschiedene Hilfsmittel zur jeweiligen Optimierung zugeordnet. In der nachfolgenden Tabelle 1 sind die Lean-Prinzipien und dazu eine kurze Erläuterung aufgelistet.

Blog_DokuLSD_Bild 1

Tabelle 1 – Die sieben Lean-Prinzipien und deren Bedeutung

Insgesamt definiert LSD 22 Hilfsmittel zur Optimierung von Softwareentwicklungsprozessen, die genau einem dieser Prinzipien zugeordnet sind. Eine Erläuterung der Hilfsmittel würde den Umfang dieses Beitrages überschreiten. Für Informationen zu den einzelnen Ansätzen sei auf das Buch „Lean Software Development – An Agile Toolkit“ verwiesen.

Die folgenden Abschnitte beschreiben Rollen und Artefakte, die in Lean Software Development eine zentrale Rolle spielen.

Die Customer oder auch Customer Representatives sind die Anwender des Produktes. Sie liefern Wünsche für Funktionen in Form von User Stories, die im System integriert werden sollen. Außerdem liefern sie wichtiges Feedback zu Produktinkrementen, das im weiteren Entwicklungsprozess beachtet werden kann.

Analysts helfen den Kunden ihre Wünsche in User Stories und Requirements zu formulieren, sodass diese später von den Developern verstanden werden können. Zur Dokumentation dieser Stories empfiehlt LSD die Verwendung von Use Case Modellen. Um bei den Developern ein gewisses Grundverständnis zu schaffen, können wichtige Fachbegriffe in einem Glossary zusammengefasst und definiert werden. Wie in Scrum auch können die verfassten User Stories als Backlog Items für die einzelnen Iterationen verwendet werden.

Für die Bearbeitung der Backlog Items und damit für die Erstellung des Produktinkrements ist das Development Team zuständig. Die Aufgabenverteilung in der aktuellen Iteration erfolgt selbstständig durch die Teammitglieder. Das Development Team besteht aus verschiedenen Personen mit unterschiedlich spezialisierten Kenntnissen. Als Beispiel kann durch Standards für Namenskonventionen, Coding Styleguides sowie Vorgaben für den Buildprozess deren Arbeitsweise vereinheitlicht werden. Während ihrer Arbeit verfassen die Developer Sketches und Drafts für einzelne Systemteile. Diese Wissenssammlung kann beispielsweise Entwürfe für das Benutzerinterfaces oder auch Modellen und Diagrammen für die konkrete Umsetzung im Produkt beinhalten. Vollständig ist diese Sammlung nicht aber sie bietet durchaus eine gute Grundlage für die Wissenskonservierung.

„Wohin soll die Entwicklung gehen?“ – In guten Teams existiert ein Master Developer, der das Development Team in eine bestimmte Richtung leitet. Er ist ein erfahrener Entwickler, der schon ausgeprägte Kenntnisse im Design von Systemen besitzt. Für die Developer dient er als eine Art Mentor, der ihnen sein Wissen zur Verfügung stellt. Seine Führungsposition innerhalb des Development Teams entbindet den Master Developer allerdings nicht von Entwicklungsaufgaben für das Produkt. Sein Wissen wird dringend benötigt.

Das Development Team stellt die zentrale Position im Entwicklungsprozess dar und erhält aus diesem Grund besondere Unterstützung. Diese unterstützende Funktion übernimmt in erster Linie der Project Manager. Er organisiert das gesamte Projektumfeld. Mit seinem Wissen zum Entwicklungsprozess kann er dem Development Team bei der Identifizierung und Lösung von Problemen helfen. Festgehalten werden diese Probleme bzw. Verbesserungen auf der List of Problems/Improvements. Zudem ist der Project Manager für die Planung des Projektablaufes verantwortlich. Dazu erstellt er in Zusammenarbeit mit dem Development Team den Release Plan, in dem wichtige Meilensteine für die Produktauslieferung eingetragen sind. Im Iteration Plan werden die großen Meilensteine in kleinere Abschnitte unterteilt.

Wie in Scrum auch muss jedes implementierte Feature in LSD getestet sein, bevor es zu den Kunden aufgeliefert werden kann. Die Verantwortlichkeit dafür liegt bei den Testern im Team. Sie beschreiben Testfälle, die anschließend möglichst automatisiert ablaufen sollten. Im Fehlerfall erhalten die Developer Feedback zu Problemen im System. Aufgabe der Tester ist es, sogenannte Qualifier bei der Testdurchführung zu beachten. Dabei handelt es sich um Einschränkungen, die meist erst nach der Inbetriebnahme des Systems in Kraft treten. Qualifier sind beispielsweise Nutzerzahlen oder auch definierte Antwortzeiten, die das System bewältigen muss.

Da der Ursprung von LSD in Produktionsbetrieben liegt, wird auch die Rolle des Suppliers in die Prozessbetrachtung einbezogen. In der Softwareentwicklung bedeutet das zum Beispiel den Zukauf von Funktionen aus anderen Produkten oder die Auslagerung der Entwicklung einzelner Module zu fremden Unternehmen. Contracts regeln dabei die Rechte und Pflichten der Beteiligten. Zu erbringende Leistungen sowie damit verbundene Kosten zählen zu den Inhalten dieser Contracts.

LSD bezieht neben der eigentlichen Entwicklung eines Produktes auch die Support- und Wartungsphase in die Prozessbetrachtung und -verbesserung ein. Für diese Phasen sind Supporter bzw. Maintainer zuständig. Tabelle 2 fasst die in LSD definierten Rollen für einen schnellen Überblick zusammen. In Tabelle 3 sind die Artefakte von LSD zusammengefasst.

LSD schlägt vier unterschiedliche Strategien für den Übergang von Entwicklungs- zu Maintenancephase vor:

  1. Teile des Development Teams sind für den Support verantwortlich. Der Vorteil dabei ist, dass die Einarbeitungszeit in das Produkt entfällt.
  2. Developer und Supporter arbeiten für eine gewisse Zeit zum Ende der Produktentwicklung zusammen, wodurch das Wissen von Team zu Team übertragen wird.
  3. Die Developer konservieren das Wissen zum System durch eine ausführliche Nachdokumentation.
  4. Die Auslieferung einer automatisierten Testsuite wird von LSD empfohlen. Zur Unterstützung dazu soll ein Modell für den Überblick über das gesamte System angefertigt werden.

Blog_DokuLSD_Bild 2

Tabelle 2 – Die Rollen in LSD im Überblick

Blog_DokuLSD_Bild 3

Tabelle 3 – Die Artefakte in LSD im Überblick

Fazit

LSD definiert deutlich mehr Rollen und Artefakte als Scrum oder auch ASD für den Entwicklungsprozess. Auf den ersten Blick scheint deutlich mehr Aufwand in der Produktentwicklung zu stecken, allerdings macht LSD keine Vorgaben, welche Rollen besetzt sein sollen oder welche Dokumente während der Produktentwicklung entstehen müssen. Der Grund dafür ist, dass es sich um Best Practices handelt, die individuell auf die eigenen Bedürfnisse angepasst werden sollen. Hinsichtlich der Dokumentation gibt LSD die Empfehlung für eine automatisierte Testsuite, die von einer Gesamtübersicht über das System als Modell unterstützt wird. Die Art und der Umfang des Modells werden nicht näher spezifiziert.

Bisher haben wir drei unterschiedliche agile Frameworks unter die Lupe genommen. Alle drei unterscheiden sich in ihren definierten Rollen und Artefakten. Grundsätzlich sind Scrum, ASD und LSD gleich ausgerichtet, denn sie müssen an die jeweiligen Projektgegebenheiten angepasst werden. Im vierten und letzten Teil der Blogserie „Dokumentieren in agilen Methoden“ möchten wir Ihnen noch Crystal als agiles Framework vorstellen. Bleiben Sie dran!

Falls Sie Fragen haben, können Sie sich damit gerne per E-Mail (heureka@sophist.de) oder per Telefon (0911 40 900 0) an uns wenden. Kommentare, Anmerkungen oder praktische Erfahrungen mit LSD können Sie direkt hier im Blog hinterlassen.

Literaturverzeichnis

[1]      M. Poppendieck und T. Poppendieck, Lean Software Development – An Agile Toolkit, Addison-Wesley, 2003.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


× fünf = 15

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>