Der Begriff Transformation geistert schon lange durch die Welt der IT. Digitale Transformation ist ein Schlagwort für die ganze Branche. Ich möchte mich aber mit einer Form der Transformation beschäftigen, die ganz sicher nicht neu ist: Die Transformation von Wissen in Software. Dabei geht es mir diesmal nicht um die Frage, wie solches Wissen strukturiert erfasst wird oder wie der Prozess der Transformation – die agile Software-Entwicklung – abläuft. Ich beschäftige mich mit dem Problem, dass diese Transformation von Wissen in Software ganz offensichtlich Redundanzen schafft.

01b-wissen-wird-transformiert

Aus einer Anforderung wird Produktwissen

Anforderungen der Nutzer eines Produktes sind Treiber für Veränderungen. Jede Projektorganisation wird durch den Einsatz der Methode CARDS+ in die Lage versetzt, neue Produktideen, Anforderungen und Verbesserungsvorschläge strukturiert und in guter Qualität zu erfassen, in einem Prozess, in dem wir Produktwissen inkrementell sammeln und laufend verbessern. Es liegt mit den Bausteinen Epic und Case in einer Form vor, die gut im Prozess des Backlog-Managements einer agilen Software-Entwicklung verwendet werden kann. Die ganze Anforderung bzw. jene Teile der Anforderung, die nach Einschätzung des Product-Owners sinnvoll und wirtschaftlich vom Team umgesetzt werden können, sind nun Bestandteil der Produktdokumentation. Die Anforderung wurde einem Topic zugeordnet. Der Überblick über die Anforderung bleibt in einem oder manchmal sogar mehreren Epics erhalten. Die genauen Details werden durch ausreichend viele Cases erfasst, vorerst ohne Lösung. Die ursprüngliche Anforderung bleibt Teil der Projektdokumentation oder kann archiviert werden.

Ein Problem wird gelöst

Ein Team braucht am Beginn eines Sprints sehr viel detailliertes Wissen, um ein Problem korrekt und vollständig zu verstehen. Nur so kann das Team eine angemessene Lösung finden. Das Wissen muss darum in zwei Kategorien geteilt werden: Nachhaltig und kurzfristig. In die Kategorie nachhaltiges Wissen fallen die Bausteine Topic, Epic und Decision. Sie dokumentieren wichtige fachliche und technische Entscheidungen. Der Abschnitt Ausgangslage im Baustein Case ist ebenfalls nachhaltiges Wissen, beschreibt es doch das Warum, Wer und Wann einer Funktion der Anwendung: Warum benötigt wer diese Funktion, wann und wie häufig wird sie verwendet. Die Frage nach der Lösung, das Wie, kann nachhaltig nur durch Code und Test beantwortet werden. Das bedeutet, dass die Bausteine Domain, Service, Entity und Event nur Platzhalter für Code sind. Mit diesen Bausteinen wollen wir einheitliche Bezeichnungen für die Struktur der Software vorgeben. Sie sorgen für ein gemeinsames Verständnis der Lösungen, bilden Muster, definieren Stereotypen, z.B.:

  • Ein “Publisher” ist immer eine Komponente, die nachrichten-orientiert Daten abgibt.
  • Ein “Manager” kapselt immer einen Zugriff auf einen Datenspeicher.
  • Ein “Adapter” realisiert immer einen Zugriff auf eine Datenquelle.
  • u.s.w.

Diese Stereotypen werden sich sehr schnell in der Sprache der Entwickler festsetzen. Mit der Nennung des Stereotypen sind ohne große Erklärung viele Fragen der Entwickler beantwortet. Immer unter der Voraussetzung, dass die Begriffe auch konsequent und korrekt verwendet werden.

Ein Case wird realisiert

Agile Software-Entwicklung versucht, das komplexe Problem in komplizierte oder offensichtliche Lösungen zu zerlegen. Der Baustein Case ist ein Mittel der Wahl. Der Product-Owner oder ein Business-Analyst konzentriert sich in der Anforderungsanalyse auf die Beschreibung des Problems, die Ausgangslage, und reichert sie um konkrete Beispiele an. Die Lösung kann vorerst offen bleiben. Der Product-Owner und ein Teil des Teams besprechen später im Refinement-Meeting den Case. Sie klären alle Fragen und finden eine Lösung. Ein offensichtliches Problem hat eine wiederkehrende Lösung, die weniger Dokumentation erfordert. Für eine komplizierte Aufgabe muss das Team wenigstens eine schätzbare Lösungsidee entwerfen. Die Lösung im Case wird nur als Folge von Essenzschritten aus den Bausteinen Service, Entity und Event gebildet. Nicht zu detailliert, um robust bei Korrekturen in der Lösung zu sein. Sehr detaillierte Annahmen und Klärungen werden als Kommentare im Wiki erfasst. Diese Kommentare werden am Ende des Sprints nach der Umsetzung gelöscht. Diese Moderation der Kommentare ist wichtig und sollte spätestens im Review-Meeting stattfinden. Das Ziel dieser Maßnahmen ist klar: Am Ende des Sprints sollen die von der Realisierung betroffenen Bausteine der Produktdokumentation im Wiki nur das erklären, was nicht im Code steht.

Aus Akzeptanzkriterien werden Tests

Akzeptanzkriterien sind wichtig für den Prozess der agilen Software-Entwicklung. Sie sind aber nur kurze Zeit gültig, nämlich bis zu dem Zeitpunkt, an dem der Product-Owner die Veränderung akzeptiert, im Regelfall am Ende des Sprints im Review-Meeting. Darum macht es keinen Sinn, Akzeptanzkriterien als Teil der Produktdokumentation zu betrachten. In Scrum nutzen wir das Konzept der User-Story, um Veränderungen am Produkt im Sprint zu planen, zu schätzen und schrittweise umzusetzen. Die Akzeptanzkriterien sind notwendig, um den Zustand “fertig” für eine Aufgabe des Teams im Sprint zu definieren.

Agile Software-Entwicklung lebt auch vom hohen Grad der Testabdeckung und einer umfassenden Testautomatisierung. Die Tests bilden immer eine Testpyramide, mit sehr vielen Unit-Tests und ausreichend vielen anderen Testarten. Akzeptanztests bilden die Spitze der Pyramide. Es ist für alle Beteiligten hilfreich, wenn Akzeptanzkriterien in Akzeptanztests übersetzt werden. Die Entwickler haben eine hohe Sicherheit, dass sie die richtige Lösung gefunden haben. Der Product-Owner sieht im Review-Meeting, dass seine Akzeptanzkriterien erfüllt werden.

Es ist natürlich nicht immer ganz leicht, Akzeptanzkriterien in Akzeptanztests zu übersetzen. Eine Hilfestellung geben Beispiele aus dem Baustein Case. Darum ist es wichtig, dass der Product-Owner und jeder Business-Analyst in der Anforderungsanalyse darauf achtet, die Beispiele im Wiki zu erfassen, die er gedanklich mit dem Case verknüpft. Eine weitere Möglichkeit ist das in der Entwicklung längst etablierte “Pairing”. Der Autor des Case und ein Tester des Teams entwickeln gemeinsam Akzeptanztests.

Die Systemidee wird zur Konfiguration

Schrittweises erweitern macht aus einer Systemidee eine komplexe Systemkonfiguration. Bei jeder komponenten-basierten Architektur (z.B. Microservices, EJBs) steckt sehr viel Wissen im Zusammenspiel der Komponenten. Nicht-funktionale Aspekte und Qualitätsanforderungen sind Treiber für Veränderungen der Systemkonfiguration. Skalierbare Systeme werden ausgebaut, wenn die Mengengerüste in der Datenverarbeitung steigen. Sicherheit, Logging oder Monitoring beeinflussen ganz wesentlich den Aufbau des Systems. Mit der Idee der DevOps wollen wir diese Themen im Team bereits bei der Umsetzung angehen. Agile Software-Entwicklung lässt uns auch diese Themen inkrementell realisieren.

Eine komponenten-basierte Architektur hat definierte Schnittstellen zwischen den Komponenten. Mit einem Schema (z.B. Avro) beschreiben wir Datenstrukturen unabhängig von der Implementierung in der Komponente. Ein REST-API beschreiben wir mit Swagger oder RAML, ein Web-Service mit WSDL. Eine Systemkonfiguration besteht aus einer Sammlung von Property-Dateien und Skripten (z.B. Ansible). Ganz wichtig ist eine Strategie für die Vergabe der Namen der Rechnerknoten. Natürlich steckt sehr viel Wissen und Arbeit in der Systemkonfiguration. Es ist aber ganz essentiell, dass die Ergebnisse aus der Entwicklung Teil der Produktdokumentation sind, hier im speziellen Teil des Betriebshandbuches. Jede weitere Dokumentation, die am Weg zum fertigen System gebraucht wird, ist ausschließlich Teil der Projektdokumentation oder wird nach Abschluss der Realisierung “entsorgt”. Das ist kein Problem, wenn die verbleibende Produktdokumentation das Wissen zur Systemkonfiguration angemessen und in der richtigen Form sichert.

Fazit

Die Transformation von Wissen in Software stellt uns vor besonderen Herausforderungen bei der Gestaltung einer redundanzfreien Produktdokumentation. Anforderungen müssen wir so zerlegen, dass sie zum Produkt passen. Damit entfernen wir uns von der ursprünglichen Anforderung, sie ist nur mehr Teil der Projektdokumentation. Neue Lösungsideen wollen wir anfangs nur skizzieren. Erst nach der Umsetzung im Sprint verbessern wir die Beschreibung der Lösung aufgrund des Feedbacks der Entwickler. Wiederkehrende Lösungen dürfen wir nur einmal beschreiben. Sie sind Teil eines gemeinsamen Verständnisses im ganzen Team. Der Wissensdurst, aber auch der Wunsch nach “maßgeschneiderter” Dokumentation der Entwickler am Beginn eines Sprints darf nicht zu umfassender Dokumentation führen. Wir müssen zwischen nachhaltiger und kurzfristig benötigter Dokumentation unterscheiden. Code, Test und Systemkonfiguration müssen wir als Teil der Produktdokumentation akzeptieren, und auch so verwenden.