Stellen sie sich ein erfolgreiches System vor. Alle an das Software-Produkt gestellten Anforderungen werden erfüllt. Die Nutzer sind zufrieden. Der Auftraggeber ist erfolgreich. So erfolgreich, dass die Anzahl der Nutzer steigt und das Einsatzgebiet erweitert wird. In der Vision erreicht die Software-Architektur ihre Grenzen. Eine weitere Steigerung der Nutzerzahlen ist nicht mehr möglich. Die Herausforderung ist die Skalierung des Systems. Der Einsatz einer neuen Technologie ist die Lösung. Ich möchte zeigen, dass eine Produktdokumentation, die mit der Methode CARDS+ erstellt und gepflegt wird, bei einer so umfangreichen Veränderung eines Software-Produktes großen Wert hat.

02 Vision Produktinnovation

Ausgangssituation

Die Entwickler des Systems haben in der Vergangenheit gute Arbeit geleistet. Das System hat ein gutes technisches Design. Es ist aber so erfolgreich, dass die ursprünglich angesetzten Nutzerzahlen um ein Vielfaches überschritten wurden. Das System wird mittlerweile in Bereichen eingesetzt, die beim Entwurf des Systems undenkbar waren. Den Entwicklern kann man keinen Vorwurf machen. Sie haben mit agiler Entwicklung nach den Wünschen des Auftraggebers eine angemessene Lösung realisiert und über Jahre mit guter Qualität gepflegt.

ktip Jeder kennt Twitter. Entwickler kennen Twitter als Sponsor von Apache Storm. Nicht zuletzt durch den Ausbau des Dienstes steigen die Anforderungen an Twitter stetig weiter, sodass eine Erweiterung von Storm, der Umstieg auf ein neues Produkt oder eine Neuentwicklung nötig geworden war. Twitter hat sich für eine Entwicklung von Heron entschieden. Neben der API-Kompatibilität zu Storm hat Heron die Leistungsfähigkeit, mehrere Milliarden Events pro Minute verarbeiten zu können, Latenzen unter einer Sekunde, vorhersagbares Verhalten beim Skalieren, hohe Datengenauigkeit und einfaches Deployment in der verteilten Infrastruktur auf.

Es ist der Fluch des Erfolges. Es ist nicht möglich, beim Start eines Projektes eine so leistungsfähige Lösung zu nehmen, um für den Fall eines so großen Erfolges gerüstet zu sein. Kein Auftraggeber akzeptiert Kosten aufgrund einer Aussicht auf Erfolg, den er selbst nicht sieht. Das Beispiel von Twitter zeigt außerdem, dass die Innovation von technischen Plattformen mittlerweile so schnell vonstatten geht, dass kein Software-Experte mehr sicher sein kann, dass seine gut begründete Entscheidung heute in einem Jahr noch gültig ist.

Projektinitialisierung

Der Auftraggeber startet ein Projekt mit dem Ziel, sein System zu modernisieren. Die fachlichen Anforderungen an das neue System sind unverändert. Mit anderen Worten: Die Systembeschreibung und das Glossar gelten auch für das neue System. Der Auftraggeber hat jedoch wesentliche Änderungen an den nicht-funktionalen Anforderungen.

Die Entwickler wählen eine neue technische Plattform aus. Entsprechend den Möglichkeiten der neuen Technologien passen die Entwickler im cross-funktionale Team die Lösungen in den Cases der neuen Version der Systembeschreibung an. Für jeden Case, der vom Wechsel der technischen Plattform betroffen ist, muss es eine neue Lösung geben. Manchmal gibt es jedoch keine Lösung für einen Case. Und genau das werden wir als “Lösung” im Case beschreiben. Der Auftraggeber muss im Anschluss aktiv werden und eine Entscheidung treffen. Er hat mehrere Möglichkeiten:

  • Der Case wird komplett gestrichen und damit der Umfang des Systems reduziert. Dabei kann eine Kosten-Nutzen-Rechnung helfen.
  • Der Case wird durch einen neuen Case ersetzt, für den es eine Lösung mit der neuen technischen Plattform gibt. Der ursprüngliche Case wird ohne Lösung dokumentiert.

Ziel aller Ansätze ist es, für jeden Case eine korrekte Lösung zu finden. Wichtig ist, dass kein Case aus der ursprünglichen Systembeschreibung gelöscht wird.

ktip Während der Projektlaufzeit kann es sehr hilfreich sein, die alte Lösung im Case stehen zu lassen und die neue Lösung zusätzlich zu ergänzen. Dadurch kann der Fortschritt des Umbaus sichtbar gemacht werden. Es gibt dann Produktinkremente, wo neue Lösungen noch fehlen oder nicht mehr eingeplant sind. Ein weiterer Vorteil ist der Vergleich der alten und neuen Lösung für jeden einzelnen Case.

Die Systembeschreibung mit den neuen Lösungen zeigt auch, ob die neue technische Plattform geeignet ist, die bisher verwendete technische Plattform zu ersetzen. Viele Cases ohne Lösung sind ein guter Hinweis, dass die gewählte neue Plattform nicht alle Funktionen hat, um alle Anforderungen an das System zu erfüllen.

Projektdurchführung

Die neue Systembeschreibung ist gleichzeitig eine gute Grundlage für die Umsetzung. In einem agilen Projekt sind diese Cases gut geeignet für den schnellen Aufbau eines Product-Backlog. Der Vorteil durch die Verwendung einer gut gepflegten Produktdokumentation ist offensichtlich: Viele fachliche Fragen können sofort beantwortet werden. Der Product-Owner kümmert sich von Anfang an um die Erstellung und Priorisierung der User-Stories. Mit dem Einsatz einer neuen technischen Plattform muss sich das cross-funktionale Team völlig neuen Herausforderungen stellen. Eventuell benötigt das Team einen oder zwei Sprints, um sich mit den neuen Gegebenheiten zu arrangieren. Die Leistungsfähigkeit (englisch: velocity) des Teams wird anfangs sinken. Häufig wird das Projekt vergrößert, um in kürzerer Zeit die Umstellung der Plattform abzuschließen – so zumindest der Plan. Aber mit der Systembeschreibung ist der Product-Owner in der Lage, schnell und mit guter Qualität User-Stories auch für ein vergrößertes Team zu liefern.

Durch agile Methoden kann ein Product-Owner während der Umstellung der Plattform fachliche Änderungen vornehmen. Durch die neue Plattform ergeben sich Möglichkeiten zur Verbesserung, die wertvoll für die Nutzer sind. Und in vielen Fällen wird die Programmierung vereinfacht. Ein echter Mehrwert! Das neue System wird sich vom alten System unterscheiden. Jede andere Annahme würde bedeuten, dass wir die Chancen der neuen Plattform nicht richtig nutzen. Ganz im Sinne der Agilität wollen wir Veränderung.

Fazit

Ein Auftraggeber hat immer die Möglichkeit, seine individuelle Lösung auf neue Beine zu stellen, wenn der Erfolg seines Systems es erforderlich macht. Die Methode CARDS+ hilft dabei. Durch eine gut gepflegten Produktdokumentation hat der Auftraggeber ein hohes Maß an Sicherheit, dass mit der Umstellung keine fachliche Funktion verloren geht. Die Systembeschreibung und das Glossar des bestehenden Systems sind die Grundlage. Der Product-Owner und das cross-funktionale Team haben sehr schnell ein gut gepflegtes Product-Backlog. CARDS+ hilft bei der Projektdurchführung, die neue Produktdokumentation schnell und in guter Qualität verfügbar zu machen. Die Architekturdefinition muss dort korrigiert werden, wo es Unterschiede zwischen alter und neuer technischen Plattform gibt. In manchen Fällen wird sie besser neu geschrieben.