Anbieter zum Thema

MicroConsult Academy GmbH

emlix GmbH

Dokumentation

Die Dokumentation ist ein wesentliches Unterscheidungsmerkmal im Vergleich zwischen den klassischen und agilen Ansätzen. So wird in der agilen Entwicklung eine vollständige und konsistente Dokumentation als zu aufwändig und zu kostenintensiv angesehen und daher zugunsten der Flexibilität darauf verzichtet oder zumindest stark eingeschränkt. Methoden wie DSDM, Scrum oder Chrystal verwenden die Dokumentation in Form eines Anforderungsdokumentes. In XP wird auf die Dokumentation ganz verzichtet. Ziel ist es, mit besonders wenig Dokumentation, ausgenommen des Codes, auszukommen.

Die Entscheidung, ob eine Dokumentation erstellt wird und in welchem Umfang, ist den jeweiligen Entwicklern überlassen und nicht genauer beschrieben. Durch die Reduzierung der Dokumentation entstehen sowohl Vor-, als auch Nachteile:

Bildergalerie

Vorteile:

Zeitersparnis: Es muss keine oder nur ein geringer Teil an Dokumentation erstellt werden, daher hat das Entwicklungsteam mehr Zeit, sich auf die Fertigstellung des Produktes zu konzentrieren und ist somit effektiver.

Weniger Aktualisierungsaufwand: Durch weniger Dokumentation ist diese übersichtlicher und schlanker und kann einfacher aktualisiert werden. Dies erhöht die Chancen, dass die Dokumentation über den kompletten Produktlebenszyklus konsistent ist und folgt dem Prinzip „eliminate anything which does not add value".

Weniger unnötige Dokumente: Beim traditionellen Requirements Engineering werden sehr viele Unterlagen erzeugt, um alle später auftretenden Fragen beantworten zu können. Es werden somit auch Fragen dokumentiert, die nie gestellt werden, was Geld und Zeit verschlingt. Dies reduziert sich beim agilen Vorgehen deutlich.

Nachteile:

Integrationsaufwand: Neue Teammitglieder haben teils zahlreiche Fragen, hier kann die Dokumentation zum Austausch von Wissen dienen. Eine gute Dokumentation kann sehr dienlich sein, da zahlreiche Informationen durch die neuen Teammitglieder entnommen werden können. Für grundlegendes muss somit nicht immer der bereits im Projekt eingearbeitete Kollege belästigt wird.

Fluktuation: Wissen von Teammitglieder die nicht mehr im Projekt sind oder das Unternehmen verlassen haben, geht verloren. Dies führt langfristig zu Problemen.

Wartung: Fehlende Dokumentation kann sich unter Umständen auf die Wartungskosten auswirken, da hier erhöhter Aufwand zur Einarbeitung notwendig ist.

Grundsätzlich lässt sich festhalten, dass die notwendige Dokumentation auch abhängig von der Teamgröße sein kann. Eine umfangreiche Dokumentation kann für ein großes Team durchaus besser sein, da nicht zahlreiche Mitarbeiter eingearbeitet werden müssen. Bei einem kleinen Team kann der Aufwand dahingehend größer sein, eine sehr umfangreiche Dokumentation zu erstellen, als ein oder zwei neue Teammitglieder einzuarbeiten.

Auf alle Fälle gilt für Projektbeginn zu prüfen, ob eine Dokumentation nicht z.B. gesetzlich vorgeschrieben ist oder Institutionen diese fordern. Dies kann z.B. im militärischen oder medizinischen Bereich der Fall sein.

Zusammengefasst ist meist bei agilen Methoden etwas zu wenig Dokumentation vorhanden, bei konventionellen zu viel. Bei agilen Ansätzen muss versucht werden, Zukunftsfragen auf die wahrscheinlichsten Ereignisse einzuschränken, und diese prägnant und verständlich zu beantworten, was eine große Herausforderung darstellt.

Validierung

Agile Ansätze verwenden häufig Review-Sitzungen und Akzeptanztest, ob das System wie erwartet für die Validierung der Anforderungen reagiert. Eine Validierung dient nicht als Beweis, ob ein Modell korrekt ist oder nicht, sondern ob zweckmäßig oder unzweckmäßig. Hierbei zeigen Review-Sitzungen den aktuellen Projektstand auf und führen, für agile Ansätze typisch, zu Vertrauen beim Kunden.

Darüber hinaus können Probleme frühzeitig hervorgehoben werden. Unter agilen Gesichtspunkten gibt es verschiedene Arten von Sitzungen. Hierbei können die Kunden die Software verwenden, erleben wie sie funktioniert und bestimmen, welche Funktionen bereits komplett realisiert wurden. Fragen oder Änderungen können sofort durch den Entwickler beantwortet oder mit ihm diskutiert werden.

Der Kunde erfährt in den Sitzungen die Stärken und Schwächen sowie die Vor- und Nachteile des Designs. Abhängig von der Methode und den Projektumständen kann die Software nach jedem Review produktiv geschaltet werden, was sich positiv auf den Return on Investment (ROI) auswirkt.

Beobachtung, soziale Analyse und Brainstorming

Diese Methoden werden in Verbindung mit agilen Ansätzen in der Fachliteratur nicht explizit erwähnt, können aber durchaus Anwendung finden. Hochqualifizierte Nutzer setzen oft Wissen unterbewusst voraus bzw. vergessen Selbstverständlichkeiten zu vermitteln. Hier können vor allem Beobachtung dazu dienen, unterbewusste Tätigkeiten aufzunehmen.

Zusammenfassung: klassich versus agil

Neben der Dokumentation liegt einer der größten Unterschiede agiler Methoden in den ineinander verlaufenden Phasen. Jede Phase wird in jeder Iteration wiederholt, was die Unterscheidung der Phasen erschwert. Zudem sind Prozesse in der agilen Entwicklung meist nur sehr vage beschrieben. Agile Ansätze umfassen ein Minimum an Dokumentation. So ist es den Entwicklern überlassen, sicher zu stellen, dass für zukünftige Anforderungen z.B. auch eine ausreichende Dokumentation vorhanden ist.

Aus Sicht des Requirements Engineering sollte es möglich sein, Änderungen nachzuvollziehen, wodurch der Dokumentationsaufwand wächst. Ein ökonomischer Nutzen hieraus wurde aber bisher nicht bewiesen. Die Dokumentation wäre wiederrum für die Vertragsparteien von Bedeutung, weshalb in agilen Projekten zumeist auf Stundenbasis (Dienstleistungsvertrag) und nicht pauschal (Werkvertrag) gearbeitet wird. Pauschalverträge schaffen Vertrauen beim Kunden, da genau definiert ist, was er wann zu welchem Preis erhält. Dies kann wiederum bei agilen Ansätzen durch die enge Zusammenarbeit gewonnen werden.

Die Entscheidung, ein agiles Vorgehen anzuwenden, bedeutet nicht, konventionelle Methoden gänzlich auszuschließen. Auch bei einem agilen Ansatz werden konventionelle Methoden eingesetzt. Dies trifft insbesondere auch auf das Requirments Engineering zu.

Klassisch, agil, und dann? – Teil 1

Klassische Ansätze im Requirements Engineering

Klassisch, agil, und dann? - Teil 3

Beyond Agile - Die Zukunft des Requirements Engineering

(ID:42704398)