Gläserne Decke für die Agilität – Abhängigkeiten

Agile Softwareentwicklung weist den richtigen Weg zu besserer Software. Die Softwareentwicklung muss alles tun, um so dicht wie möglich an den diffusen und wechselnden Bedürfnissen der Kunden zu sein. Also mehr Dialog als fixierte Kontrakte. Mehr den Menschen im Blick als starre Tools. Mehr Offenheit für Veränderungen als Plantreue.

Dazu muss natürlich das Vorgehen einer Entwicklergruppe passen. Scrum oder XP machen angesehene Vorschläge dazu.

Trotzdem kommt es mir so vor, dass die versprochenen Vorteile sich nicht so schnell manifestieren, wie erhofft. Liegt das immer wieder daran, dass Scrum oder XP nicht gut genug implementiert werden? Ja, sicher kommt das immer wieder vor. Das scheint mir jedoch keine vollständige Erklärung. Ich glaue, selbst wenn ein Team Scrum perfekt einführte, würde es deshalb allein noch nicht wirklich agil werden.

Der Weg zu besserer Software scheint klar. Man muss nur die Vorgehensmodellleiter hochsteigen. Doch dann stößt man – ob man es merkt oder nicht – an gläserne Decken. Die Verbesserungen geraten vorzeitig ins Stocken – der Grund ist allerdings nicht recht auszumachen. Alle Vorgehensmodell-Rituale werden doch eingehalten… Was läuft denn noch falsch?

Ich glaube, eine solche gläserne Decke besteht in einem fundamentalen Widerspruch zwischen zwei Gedankenmodellen von Software.

Das heutige technische Gedankenmodell

Die Softwareentwicklung hat in weiten Teilen ein technisches Gedankenmodell. Im Kern dieses Modells stehen abhängige Funktionseinheiten. Verständlich ist das durchaus, wenn man die Softwareentwicklung als Enkel des Maschinenbaus und Kind der Elektrotechnik sieht. Denn Maschinen und Geräte jeder Art funktionieren nur, wenn ihre Teile komplett sind. Das heißt, die müssen in geeigneter Weise bottom-up hergestellt und integriert werden.

Ein Computer ist ohne Netzteil, Bildschirm, Hauptplatine, Prozessor, Speicher, Tastatur nichts. Man kann keinen aus einem halben Netzteil, einem Viertel Prozessor, einem Drittel Speicher usw. zusammensetzen. Alles steht in einer Abhängigkeitsbeziehung, die zumindest eine Integrationsreihenfolge diktiert. Und alles, was da integriert wird, das muss vollständig sein.

Ohne Display kein vollständiges Gehäuse, ohne Prozessor keine vollständie Hauptplatine usw. Was weiter oben steht, also höher integriert ist, das ist abhängig von dem, was weiter unten steht.

Hört sich das plausibel an? Dann finde ich plausibel, dass das reflexartig genannte Pattern für die Struktur von Software genauso aussieht:

Wenn man Entwickler nach der einer Soll-Architektur fragt, dann kommt in 9 von 10 Fällen “Schichtenarchitektur” als Antwort. Wenn man in Projekten nach der Architektur fragt, dann kommt auch in 9 von 10 Fällen der Begriff “Schichtenarchitektur” – wenn auch meist mit Einschränkungen wie “Wir haben es nicht geschafft, eine saubere Schichtenarchitektur hinzukriegen. Aber das war unser Ziel.” Gefolgt von einem Augenaufschlag, der eigentlich nur eine Reaktion verträgt: Kopfstreicheln. Denn ist eine Strukturierung nach Schichtenmodell - das gern differenzierter als obigens aussehen darf - nicht das Ziel schlechthin, für eine Softwarearchitektur?

Nein, das sehe ich nicht so. Das pauschale Schichtenmodell hat eher mehr kaputt gemacht als Gutes bewirkt. Sein größter Schaden mag dabei gar nicht mal technischer Natur sein, sondern mentaler. Das Schichtenmodell hat offenes, flexibles Denken in Richtung besserer Architekturen gelähmt. Bei vielen Entwicklern.

Aber das ist hier gar nicht mein Punkt. Heute geht es mir um das fundamentale Denken in Abhängigkeiten und deshalb in Schichten. Die “Abhängigkeitsdenke” ist überall. Hier die Diagrammtypen, die der Beitrag zur UML bei Wikipedia zuerst nennt:

Insgesamt werden 12 Diagrammtypen beschrieben, wovon mindestens 7 (58%) Abhängigkeitsdiagramme sind. (Und eigentlich würde ich sogar noch das Sequenzdiagramm mit in diese Gruppe rechnen. Dann wären es 66%.) [1]

Solch technische Sicht ist für sich genommen natürlich kein Problem. Maschinenbau und Elektrotechnik leben damit ja wunderbar – und können eigentlich auch nicht anders. Auch Softwareentwicklung kann man natürlich ausgerichtet an diesem Gedankenmodell betreiben. Das tun ja auch Millionen von Entwicklern täglich.

So weit, so gut also erstmal.

Das agile Gedankenmodell

Agilität interessiert sich erstmal nicht für Technik. Technik ist nur ein Mittel, um für den Kunden eine Lösung herzustellen. Aus Sich der Agilität zählt also nicht, wie Software intern strukturiert ist. Sie hat deshalb ein ganz anderes Gedankenmodell von ihr.

Für die Agilisten besteht Software nicht aus Schichten von abhängigen Funktionseinheiten. Stattdessen denken sie in Scheiben, in Durchstichen, in Längsschnitten durch Software.

Agile Softwareentwicklung orientiert sich konsequent am Nutzen für den Anwender. Der mag klein sein, eine dünne Scheibe vom großen Ganzen, aber nur er zählt.

Solche Nutzenscheiben (Features) können zwar auch abhängig von einander sein insofern, dass z.B. Monatsberichte bei einer Faktura-Anwendung keinen rechten Sinn machen, wenn nicht zumindest Rechnungen vorhanden sind. Doch das ist keine technische Abhängigkeit, sondern nur eine inhaltliche. Das Monatsberichte-Feature könnte mithin technisch hergestellt werden und sogar zum Einsatz kommen, selbst wenn es noch keine Rechnungserfassung gibt, sondern die Rechnungsdaten aus einem Altsystem importiert werden. Abhängigkeiten zwischen Features sind vergleichsweise lose.

Widerstreit

Das scheint mir nun ein fundamentales, wenn auch subtiles Problem: der Widerstreit der Gedankenmodelle, von denen eines die Software in Schichten gegliedert sieht und das andere sie in Scheiben gegliedert denkt.

Diese um 90° gegeneinander gedrehten Vorstellungen von Software müssen von der Programmierung immer wieder überein gebracht werden. Das Vorgehensmodell “denkt” in Scheiben, die Programmierung “denkt” in Schichten.

Klar, irgendwie geht diese Transformation. Jeden Tag bekommen Entwicklergruppen das hin. Aber ist das einfach? Ist das so einfach, wie es sein sollte oder könnte?

Nein, ich glaube, dieser Widerstreit zehrt an der Kraft der Softwareentwicklung. Er führt zu Konflikten zwischen Entwicklern und zwischen Entwicklern und Kunde. Auf die eine oder andere Weise.

Wenn Denkmodelle ganz anders sind, dann braucht es immer wieder Übersetzungsaufwand. Das zeigen Jahrtausende Menschheitsgeschichte. Und jedes Softwareprojekt weiß das aus eigener Anschauung. Denn das Denkmodell des Kunden in Bezug auf seine Fachdomäne trifft ja dort ständig auf das Denkmodell der Entwickler in ihrer technischen Domäne. Bis Entwickler wirklich verstehen, was Kunden wollen, kann viel Zeit vergehen und können viele Tränen fließen.

Warum sollte das anders sein, wenn zwei so unterschiedliche Gedankenmodell in Bezug auf die Herstellung von Software aufeinander treffen? Ist da Verständnis, Harmonie, Einfachheit zu erwarten? Kaum.

Ziel: Kohärenz

Ich glaube, dass Softwareentwicklung mit Agilität solange an eine gläserne Decke stößt, bis sie aufhört, in Schichten und Abhängigkeiten zu denken. Erst wenn ihr primäres Gedankenmodell, d.h. ihre technische Sicht der entspricht, die ein agiler Prozess hat, in dem sie Code produziert, kann sie das nächste Level erreichen. [2]

Kohärenz zwischen agilem und technischem Gedankenmodell ist unabdingbar für eine flüssige Umsetzung von Anforderungen in Code.

Die Frage ist nun, wie kann ein technisches Gedankenmodell aussehen, das Software nicht mehr aus Schichten und Abhängigkeitsbeziehungen aufgebaut sieht, sondern sie ganz natürlich als bestehend aus Scheiben denkt?

Anmerkungen

[1] In der UML mögen “nur” 58% der Diagramme Abhängigkeitsdiagramme sein. Deren Anteil am Entwicklerleben ist aber sicherlich deutlich höher. Ich schätze, dass 80-90% aller Diagramme, die gezeichnet werden von Entwicklern, Abhängigkeitsdiagramme der einen oder anderen Form sind (egal, ob sie strikt der UML folgen oder nicht).

[2] Anders herum hat es übrigens nicht funktioniert. Jahrzehntelang hatte die Softwareentwicklung versucht, die Kunden mit rein technischer Vorgehensweise zu befriedigen. Das Ergebnis kennen wir alle. Software “von unten nach oben” zu bauen, macht niemanden glücklich. Erst das Framework, erst die Infrastruktur, dann die Logik, dann das GUI… Nein, so geht es nicht.

Agile Softwareentwicklung ist das Resultat dieses Irrweges. Sie hat der technischen Sicht eine Kundensicht entgegengestellt, die um 90° gedreht ist. Dadurch ist ein Spannungsfeld entstanden – dem sich früher oder später die Softwareentwicklung eigentlich nur ergeben kann, um effektiver und effizienter zu werden. Mit einem technischen Denkmodell, das immer nur dagegen hält, wird schlicht zuviel Kraft verschwendet.