Das Ziel agiler Entwicklung ist es, den Entwicklungs­prozess flexibler und schlanker zu gestalten, als das bei den klassischen Vorgehensmodellen der Fall ist. Gilt das auch für das Dokumentieren?

Nehmen Sie an, Sie werden beauftragt, ein völlig neues Software-Produkt zu entwickeln. Sie bekommen die Chance, eine individuelle Lösung mit einer agilen Projekt­organisation auf der „grünen Wiese” zu entwerfen.

Stellen Sie sich ein Szenario vor, in dem ein Auftraggeber ein individuell entwickeltes IT-System durch eine Lösung mit einem Standardprodukt ersetzen will. Sie bekommen den Auftrag, die Migration zu planen und umzusetzen.

Aufgrund der noch immer fehlenden Rechtssicherheit bei Gewerken mit agiler Software-Entwicklung besteht regelmäßig der Bedarf an einem Lastenheft. Arbeiten Auftraggeber und Produktverantwortlicher konsequent mit cards+, dann besteht die Möglichkeit, die Leistungsbeschreibung für das Lastenheft zu großen Teilen aus dem Wiki zu exportieren.

Schnittstellenbeschreibungen sind alternativlos in einer komplexen IT-Systemlandschaft mit vielen unabhängigen Partnersystemen aus verschiedenen Organisationen eines Unternehmens. Ein Produktverantwortlicher darf sich trotzdem die Frage stellen, wie umfangreich so ein Dokument sein muss. Mit cards+ kann er das Wiki zu seinem Vorteil nutzen.

Ein Gerichtssachverständiger für Softwarequalität erklärt, warum Software selten dem Stand der Technik entspricht.

Mit Continuous Documentation ändern wir die Art und Weise, wie wir Spezifikationen erstellen und integriert in einer Produkt­dokumentation konsumieren. Wir folgen den Prinzipien der kontinuierlichen Verbesserung in den Dimensionen Code, Test und Spezifikation.

Ist der Hype um Domain-Driven Design berechtigt oder verbirgt sich dahinter nur alter Wein in neuen Schläuchen?