Dokumentation in agilen Projekten

Lösungsmuster für ein bedarfsgerechtes Vorgehen

Andreas Rüping

• Verlag: dpunkt.verlag
• Jahr: 2013
• ISBN drucken: 9783864900402
• eBook-ISBN: 9783864913136
• Auflage: 1
• Thema: Informatik
• Thema: Qualitätssicherung & Prüfung

Prägnante und gut strukturierte Dokumente bieten eine hohe Lesbarkeit und einen schnellen Zugriff auf das darin enthaltene Wissen. Von den agilen Verfahren zur Softwareentwicklung können wir viel über eine bedarfsgerechte Dokumentation lernen, z.B. dass es sinnvoll ist, die Notwendigkeit einzelner Dokumente kritisch zu prüfen und nur solche Dokumente zu erstellen, die einen tatsächlichen, klar erkennbaren Nutzen haben. Der Leser erhält in diesem Buch konkrete Hinweise zu einer bedarfsgerechten Dokumentation - in Form von Lösungsmustern und zahlreichen Beispielen aus der Praxis.

1 Einleitung

1.1 Motivation

Agile Methoden legen in Softwareentwicklungsprojekten großen Wert auf direkte Kommunikation von Angesicht zu Angesicht und nehmen gegenüber umfangreicher schriftlicher Dokumentation eine eher kritische Haltung ein. Sie erkennen aber an, dass Dokumentation sinnvoll sein kann und manchmal auch benötigt wird.

Daraus resultiert die Frage, wie die Dokumentation in einem agilen Kontext sinnvoll gestaltet werden kann. Die Möglichkeiten dafür auszuloten ist Gegenstand dieses Buchs. Das Ziel dabei ist, bei der Planung, der Erstellung und der Nutzung von Dokumentation Strategien zu entwickeln, die sich am besten mit dem Wort bedarfsgerecht beschreiben lassen – die sich also an den tatsächlichen Bedürfnissen eines Projekts orientieren [Rüping 2011].

Ein bedarfsgerechtes Vorgehen bezieht sich zum einen darauf, was in einem Projekt schriftlich dokumentiert werden sollte (und was nicht). Es betrifft zum anderen die Frage, wie eine angemessene Dokumentation gestaltet werden kann. Beiden Fragen werden wir in diesem Buch nachgehen.

1.2 Historie der agilen Entwicklung

Um die Sichtweise der agilen Methoden verstehen zu können und speziell auch, was zu der betont kritischen Sicht auf umfangreiche Dokumentation geführt hat, lohnt sich ein Rückblick auf die 1990er-Jahre. In dieser Zeit haben die ersten agilen Verfahren ihren Ursprung. Blicken wir also einmal auf die damals gängigen oder zumindest doch empfohlenen Methoden in der Softwareentwicklung.

Prozesslastige Methoden in den 1990er-Jahren

Die 1990er-Jahre waren geprägt von einer Reihe von Methoden, die großen Wert auf definierte Prozesse und umfangreiche Dokumentation legten. Diese Methoden waren durch das Ziel gekennzeichnet, den Ablauf eines Projekts im vorhinein detailliert zu planen und sich bei der anschließenden Umsetzung streng am Plan zu orientieren.

Fast alle diese Methoden basieren auf dem klassischen Wasserfallmodell, das den Prozess der Softwareentwicklung in verschiedene Phasen unterteilt (Grobspezifikation, Feinspezifikation, Entwurf, Realisierung, Test, Auslieferung), die typischerweise streng sequenziell durchlaufen werden. Dokumentation spielt beim Wasserfallmodell insofern eine große Rolle, als die Ergebnisse einer Phase in der Regel gründlich dokumentiert werden und die Dokumentation als Input für die nächste Phase bereitgestellt wird.

Typische Vertreter dieser Methoden sind die folgenden:

Das V-Modell ist ein Vorgehensmodell zur Planung und Durchführung von Softwareentwicklungsprojekten, dessen Ursprünge ins Jahr 1979 zurückgehen. Es erweitert das traditionelle Wasserfallmodell, indem es jeder der ursprünglichen Phasen eine Test- oder Abnahmephase gegenüberstellt. Während das originale V-Modell durch relativ starre Prozesse gekennzeichnet war, lässt die 2005 in Deutschland eingeführte Variante XT bereits eine gewisse Anpassung der Prozesse an spezifische Gegebenheiten zu.

Das 1986 erstmals vorgestellte Spiralmodell ist ein Vorgehensmodell, das ebenfalls auf dem Wasserfallmodell beruht, es aber bereits um die Idee der iterativen Entwicklung erweitert. Es sieht vor, typische Phasen wie Analyse, Entwurf, Realisierung und Test immer wieder zu durchlaufen und sich so schrittweise dem Projektziel zu nähern.

Der 1998 erstmals veröffentlichte Rational Unified Process (RUP) [Kruchten 1998] umfasst ein Vorgehensmodell zur Softwareentwicklung, das zur Modellierung die bekannte Unified Modeling Language (UML) [Rumbaugh/Jacobsen/Booch 1998] einsetzt. Auch der Rational Unified Process weicht bereits deutlich vom klassischen Wasserfallmodell ab und empfiehlt stattdessen ein iteratives Vorgehen.

Ebenso prägend für die 1990er-Jahre waren Bemühungen, durch die Verbesserung der zugrunde liegenden Prozesse die Qualität von Software zu erhöhen. Resultat dieser Bemühungen waren verschiedene Prozessframeworks, die zwar kein spezielles Verfahren vorschreiben, aber doch dazu auffordern, innerhalb eines bestimmten Rahmens Prozesse und Vorgehen zu definieren. Zu den oben genannten Softwareentwicklungsmethoden sind diese Prozessframeworks in dem Sinne orthogonal, dass sie unterschiedliche Schwerpunkte setzen und sich mit diesen kombinieren lassen. Bekannte Prozessframeworks sind die folgenden:

Das Capability Maturity Model Integration (CMMI) ist ein Modell zur Beurteilung des Reifegrads sämtlicher Prozesse eines Unternehmens im Zusammenhang mit der Entwicklung und dem Betrieb von Software. Ziel ist die Definition, Planung, Implementierung und Qualitätssicherung dieser Prozesse. Das relativ starre ursprüngliche Modell (CMM) wurde 2003 durch den flexibleren Nachfolger (CMMI) abgelöst.

Die Normenreihe ISO 9000 ff. legt Mindestanforderungen für die Qualitätssicherung fest. Die Normen beziehen sich auf Produktherstellung und Dienstleistungen generell und werden gelegentlich auch auf die Softwareentwicklung angewendet. Seit Mitte der 1990er-Jahre sind manche Softwareunternehmen bestrebt, sich in Bezug auf ihre Qualitätsstandards nach ISO 9000 zertifizieren zu lassen.

Sowohl die genannten Softwareentwicklungsmethoden als auch die Prozessframeworks zur Qualitätssicherung sind im Laufe der Zeit weiterentwickelt worden. In einigen Fällen drückt sich dies in der Namensgebung aus. So trat zum Beispiel an die Stelle des ursprünglichen V-Modells die Variante XT, und CMM wurde durch CMMI abgelöst.

Die traditionellen Entwicklungsmethoden, die ursprünglich auf dem Wasserfallmodell basierten, haben sich dabei tendenziell auf ein stärker iteratives Vorgehen hin bewegt. Die Prozessframeworks haben im Laufe der Zeit an Flexibilität gewonnen und tragen mittlerweile der Tatsache Rechnung, dass Projekte individuell geprägt sind und dass Prozesse an die individuellen Gegebenheiten angepasst werden müssen. Dementsprechend befinden sich Prozessframeworks wie beispielsweise CMMI heutzutage nicht mehr unbedingt im Widerspruch zu agilen Methoden [Glazer/Dalton/Anderson/Konrad/Shrum 2008].

Ende der 1990er-Jahre stellte sich die Situation allerdings noch anders dar. Die genannten Entwicklungsmethoden waren damals noch bestrebt, allgemeingültige Modelle für die Softwareentwicklung aufzustellen, und begannen sich nur langsam vom Wasserfallmodell zu lösen. Sie wurden zunehmend als starr, schwergewichtig und wenig flexibel wahrgenommen. Mit dem Aufkommen der Prozessframeworks rückten Prozessdefinitionen noch mehr in den Mittelpunkt der Softwareentwicklung, was den Eindruck von Schwergewichtigkeit und mangelnder Flexibilität weiter verstärkte.

Die Kombination aus wasserfallbasierten Entwicklungsmethoden und vergleichsweise starren Prozessdefinitionen ...

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Vorwort
• Danke
• Inhaltsverzeichnis
• 1 Einleitung
• 2 Einstieg in ein agiles Vorgehen
• 3 Infrastruktur und Werkzeuge
• 4 Planung der Dokumentation
• 5 Auswahl der richtigen Inhalte
• 6 Gestaltung einzelner Dokumente
• 7 Umgang mit der Dokumentation
• 8 Zusammenfassung
• A.1 Kurzfassungen der einzelnen Muster
• A.2 Portfolio möglicher Dokumente
• A.3 Glossar
• Literatur
• Index