Wie Modellierung agile Systementwicklung ermöglicht

Schon vor zwei Jahren schrieb ich hier, dass agile Systementwicklung schon seit fast 50 Jahren praktiziert wird. Trotzdem tun sich viele in der Praxis damit schwer. Gründe gibt es dafür viele: Zum Beispiel sind viele der relevanten Standards nicht unbedingt agil-freundlich geschrieben. Weiterhin ist der Umgang mit Änderungen immer noch eine Herausforderung; Änderungen sind jedoch ein zentraler Aspekt von agilem Vorgehen („Reagieren auf Veränderung“). Aber ohne Modellierung kann das Reagieren auf Veränderung sehr aufwändig sein.

Modellierung hilft auch in anderen Bereichen des agilen Manifests, wie zum Beispiel bei der Zusammenarbeit, sowohl im Team als auch mit dem Kunden.

Vorweg noch ein kurzes Wort zur Modellierung: Damit meine ich nicht unbedingt UML- oder SysML-Modellierung, sondern auch einfache Informationsmodelle, wie ich es unter anderem auch im Artikel zu MBSE beschrieben hatte.

Was ist Modellierung?

Sprachen wie UML und SysML sind extrem leistungsfähig; aber ich glaube nicht, dass sie mittelfristig in der Breite eingesetzt werden, sondern eher in Fachabteilungen von wenigen Leuten in der Tiefe. Wenn ich also Modellierung als Befähiger für Agilität bezeiche, denke ich nicht an diese Sprachen. Statt dessen denke ich an einfache Informationsmodelle, die die Artifakte in der Systementwicklung miteinander verknüpfen:

Modelle dieser Art gibt es auch schon lange: Schon DOORS ermöglichte dies vor 20 Jahren, und Technologien wie das Eclipse Modeling Framework ermöglichen es, sich eigene, leistungsfähige Modelle zu entwickeln und zu verknüpfen. Fast jedes für die Teamarbeit gedachte Werkzeug arbeitet mit Modellen, egal ob JIRA oder Trello. Oft ist man sich als Nutzer gar nicht bewusst, dass man modelliert: Man setzt einfach die einzelnen Elemente in einen Kontext, der intuitiv richtig ist und falsches Zusammensetzen oft gar nicht ermöglicht.

Gute Werkzeuge, wie Jama, ermöglichen die Anpassung des Informationsmodells und das intuitive Arbeiten damit: Sowohl zum Erstellen, Bearbeiten und Analysieren.

Was ist agil?

Auch über Agilität habe ich hier schon einiges geschrieben. Um nun zu verstehen, wie Modellierung bei der agilen Systementwicklung helfen kann, schauen wir uns die vier Aussagen des Agilen Manifests an:

Diese Aussage hat auf den ersten Blick nichts mit Modellierung zu tun, auf den zweiten aber schon: Denn ein Modell kann den Kontext der Interaktion definieren, was zu Skalierung, Übersicht und Nachvollziehbarkeit beiträgt.

Ein gutes Beispiel ist gitHub, eine für Open Source-Projekte kostenlose Plattform für Softwareentwicklung. Zu den dort verwendeten Modellelementen gehören Programmdateien, Issues oder Patches. Bevor ein Patch in den Quellcode eingepflegt wird, kann dieser aber diskutiert werden. Und die Diskussion findet direkt im Kontext dieses Patches statt. Wenn nun ein Jahr später fragt, warum eine bestimmte Zeile Code in den Quellcode aufgenommen wurde, so ist diese Zeile (Modellelement) mit dem Patch verknüpft, und dieser wiederum mit der Diskussion, in der sich die Antwort finden lässt.

Das Gegenteil davon wäre, wenn die Diskussion per E-Mail stattfindet, vielleicht in einem viel zu großen Verteiler. Nach einem Jahr diese Diskussion wiederzufinden ist extrem Aufwändig bis unmöglich.

Persönliche Interaktion ist immer vorzuziehen; aber was klassischerweise per E-Mail diskutiert würde, sollte besser im Kontext eines Modellelements mit den richtigen Leuten diskutiert werden. Twittern

Diese Aussage muss für unsere Zwecke natürlich etwas angepasst werden.

Das Problem mit umfassender Dokumentation ist, dass diese bei großen Systemen aufwändig zu pflegen ist. Das ist bei Modellen aus zwei Gründen einfacher: (1) Erstens bedeutet Pflegen in der Regel ändern, und wie wir gleich sehen werden, ist das Ändern von Modellen wesentlich einfacher, schneller und weniger Fehleranfällig als das Ändern von Dokumenten. Zweitens ist die Dokumentation in der Regel ein Abfallprodukt der Modellierung, da diese lediglich eine Sicht auf das Modell darstellen.

Modellierung allein reicht nicht aus, um funktionierende Systeme zu bekommen; sie machen es aber wesentlich leichter, sich auf das Wesentliche zu konzentrieren.

Auch bei der Zusammenarbeit mit Kunden kann die Modellierung den Kontext setzen – wie schon weiter oben bezüglich der Individuen und Interaktionen beschrieben. Leider beschränkt sich die Zusammenarbeit lediglich auf Reviews, die alle paar Jahre stattfinden, und wo dann plötzlich der Kunde aus allen Wolken fällt, wenn er die Spezifikation sieht. Oder umgekehrt, wo der Lieferant entsetzt ist, dass der Kunde alles ganz anders sieht.

Ein gutes Beispiel, wie hier Modellierung helfen kann, ist Jama: Deren Review Center erlaubt es auch wieder, einen für den Review angepassten Blick auf das Modell zu erstellen, der dann nur die benötigten Elemente, Attribute und Relationen enthält. Dort kann dann auch wieder im Kontext einzelner Elemente eine Diskussion geführt und Entscheidungen getroffen und dokumentiert werden. Im Gegensatz zu dem oben beschriebenen Ansatz von gitHub ist das Jama Reviewcenter formaler und spricht auch Menschen außerhalb der Organisation an – wie zum Beispiel, oder insbesondere, Kunden.

Wie schon am Anfang gesagt, sind Änderungen heutzutage eine der größten Herausforderungen. Obwohl Änderungen prinzipiell einfach sind, ergibt sich hier schnell bei großen Entwicklungen eine schwer überschaubare Komplexität. Beim dokumentenbasierten Arbeiten ist schwer nachzuvollziehen, welche Änderung im Dokument nun wirklich welche anderen Teile der Spezifikation beeinflusst. Durch die feinere Granularität bei der Modellierung ist dies wesentlich einfacher nachzuvollziehen.

Wenn wir uns das oben gezeigte Datenmodell anschauen und sich ein Stakeholder Requirement ändert, dann ist grundsätzlich alles abwärts davon „suspekt“ und müssen überprüft werden. Zum Beispiel alle „Functional Requirements“. Basierend auf diesem Prinzip können dann Impakt-Analysen durchgeführt werden. Auch dies ist an sich nichts neues, Werkzeuge wie DOORS konnten das schon vor 20 Jahren, was sicherlich zu dessen Erfolg beigetragen hat.

Die Rolle von Werkzeugen

An der einen oder anderen Stelle klang es sicher schon durch: Modellierung allein reicht nicht, wenn das Werkzeug dem Nutzer nicht hilft, die hier gezeigten Aspekte auch wahrzunehmen. Was man alles mit Modellen machen kann, habe ich bereits an anderer Stelle beschrieben. Leider sind nicht alle Werkzeuge in der Lage, die dort beschriebenen Dinge zu machen. Und selbst, wenn sie es können: Manche Werkzeuge sind schwerfällig und schwer zu bedienen. Ein gutes Werkzeug hingegen sollte so leicht sein, dass man es gar nicht bemerkt. Ein gutes allgemeines Beispiel dafür ist das bereits erwähnte Trello, ein Beispiel aus dem Systems Engineering ist Jama.

Es gibt noch einen zweiten Vorbehalt: Bei realistischen Projekten aus der Praxis gibt es garantiert immer mehr als nur ein Modell, oder ein Modell und viele Dokumente: Schließlich sind auch Tests, Quellcode, CAD-Zeichnungen und vieles mehr Modelle, die in der Regel ihre eigenen Werkzeuge haben und nicht im Anforderungswerkzeug verwaltet werden. Über Modellgrenzen hinweg zu arbeiten schafft noch mal ganz andere Herausforderungen, über die ich ein andermal schreiben werde.

Bild: Jama Software
Publizitätspflicht: Jama ist Kunde von Formal Mind