Lassen Sie für einen Moment mal alle eingefahrenen Vorstellungen von Objektorientierung und Agilität und Schichtenmodellen hinter sich. Folgen Sie mir einfach auf einer Traumreise in ein anderes Land der Softwareentwicklung…
Alles beginnt mit einem Unternehen. Das möchte eine Software in Auftrag geben. Es stellt sich den weltbesten online Shop vor, der es im Nu auf Augenhöhe mit Amazon, eBay und Expedia bringt. Das Budget hat der Vorstand schon fixiert. Die Wünsche wurden in den Fachabteilungen gesammelt. Und die IT hat auch schon ihren Senf dazu gegeben, denn irgendwer muss die Software hinterher ja auch betreiben. Es kann also losgehen…
Als Unternehmen, will es natürlich soviel wie möglich für sein Geld. Und als Teilnehmer an den komplexen Märkten des 21. Jahrhunderts will es gleichzeitig maximale Flexibilität auf dem Weg zum Maximum für sein Geld. Das scheint ein Widerspruch. Doch das Unternehmen hat einen Weg gefunden, beide Wünsche unter einen Hut zu bringen: Es vergleicht jeden Tag den Stand der Softwareentwicklung mit den Bedürfnissen der Anwender.
Jeden Tag ziehen sich die Anwender (bzw. ihre Vertreter für die Softwareabnahme während der Entwicklungsdauer) den aktuellen Stand der Software und probieren die hinzugekommene oder veränderte oder korrigierte Funktionalität aus. Das Entwicklungsteam stellt also jeden Tag ein neues Release bereit, das wieder etwas besser ist, als das vom Vortag. Und diese Verbesserungen sind immer anwenderrelevant; die Anwender können einen Unterschied erkennen, der ihnen wichtig ist – und sei der auch nur klein. So können sie jeden Tag feststellen, ob die Software noch auf Kurs zu ihrem Ziel ist. Sehen sie Abweichungen, steuern die Anwender nach, indem sie ihre Anforderungen verändern. Und das jeden Tag aufs Neue, wenn sie wollen.
Das Softwareentwicklungsteam unterstützt den Wunsch der Anwender, jeden Tag eine verbesserte Version testen zu wollen. Dafür hat es zunächst einen automatischen Build- und Deliveryprozess aufgesetzt, der dafür sorgt, dass alle Softwareartefakte jeden Tag gebaut, überprüft, verpackt und für den Download durch die Anwender bereitgestellt werden.
Die Überprüfung besteht aus automatisierten Tests und stellt vor allem sicher, dass die Software frei von Regressionsfehlern ist. Soweit möglich, sollen die Tests aber natürlich auch “beweisen”, dass hinzugekommene Funktionalität von vornherein keine Fehler enthält und den formalisierten Anforderungen (Akzeptanztests) entspricht.
Damit der automatische Build- und Deliveryprozess auch jeden Tag etwas zu tun hat, muss die Codebasis natürlich jeden Tag anwenderrelevante Änderungen aufweisen. Das Entwicklungsteam muss also jeden Tag etwas Auslieferbares fertigstellen. Ganze User Stories, wie sie das Unternehmen an das Entwicklungsteam heranträgt, sind natürlich viel zu groß, um sie in einem Tag umsetzen zu können. Auch Features herausgelesen aus User Stories passen noch nicht in einen Tag. Aber Features Slices, d.h. hauchdünne Längsschnitte durch Features, die lassen sich in einem Tag realisieren. Manchmal braucht es dafür ein wenig Phantasie, um sie in den Features zu erkennen, doch allermeistens klappt das.
So teilt das Team die Anforderungen in mehreren Schritten in Happen von Tagesumfang. Ob das 3, 4 oder 6 Arbeitszeitstunden sind, hängt vom Team und seiner Möglichkeit und Fähigkeit zur Fokussierung ab.
In wenigen Stunden muss und will das Team also Anwendernutzen auf die Straße bringen. Dafür ist maximale Geschwindigkeit in der Umsetzung nötig. Die erreicht das Team dadurch, dass es alle Entwickler auf das Feature Slice des Tages ansetzt. Alle arbeiten daran parallel, so wie beim Formel 1 Boxenstopp die Mechaniker an einem Rennboliden.
Dass sich dabei die Teammitglieder nicht ins Gehege kommen, also durch Konflikte Zeit verlieren, stellt die Komponentenorientierung sicher. Jedes Teammitglied bekommt für die Dauer einer Feature Slice Realisierung eine Anzahl von Komponenten zugeteilt, für die es allein verantwortlich ist. Alle Arbeit findet dann pro Entwickler konzentriert an einer Komponente zur Zeit statt. Die Kontrakte der Komponenten stellen dabei sicher, dass Änderungen keine unerwartete Reichweite haben. Die Komplexität hält sich durch kontraktuelle Entkopplung in Grenzen und automatisierte Tests in Isolation helfen, die Fehlerzahl gering zu halten.
Komponenten und Entwicklerzuordnung (Feature Team) sind das Ergebnis der Arbeitsorganisation des Teams. Vor Beginn der Feature Slice Realisierung identifiziert es die betroffenen Komponenten und weist sie Teammitgliedern nach Kompetenz, Erfahrung, Wunsch, Verfügbarkeit usw. zu.
Welche Komponenten aber überhaupt zur Auswahl stehen, ergibt sich aus den Bauteilen eines Event-BasedComponents (EBC) Modells, die innerhalb eines Architekturrahmens und im Sinne maximal paralleler Realisierbarkeit zu Komponenten zusammengefasst werden. Das Modell definiert die Funktionseinheiten auf verschiedenen Abstraktionsebenen, die die Anforderungen erfüllen. Das tut es unabhängig von der Implementierung, um die Lösungsplanung schneller und flexibler zu halten.
Das Team modelliert die Lösung also, um ganz präzise zu wissen, welche Funktionseinheiten zu implementieren sind. Die werden bestimmt durch die Funktionalität, die User Stories/Features beschreiben. Andererseits sind aber auch nicht-funktionale Anforderungen zu erfüllen. Dafür direkt Funktionseinheiten während der Modellierung zu finden, hieße jedoch, die Modellierung zu überfrachten. Deshalb entwirft das Entwicklungsteam vor dem Modell eine Softwarearchitektur. Sie definiert einen Rahmen von architekturellen Funktionseinheiten, in den sich das Modell mit seinen Funktionseinheiten einpassen muss.
Präzise Kenntnis der zu implementierenden Funktionseinheiten, die die funktionalen wie nicht-funktionalen Anforderungen dienen, ist Voraussetzung für die tägliche Feature Slice Realisierung in Höchstgeschwindigkeit.
So wichtig ein guter Entwurf jedoch auch sein mag, um den Anwender ihre Flexibilität zur Kursänderung zu geben, er reicht nicht aus. Mit Höchstgeschwindigkeit können nur Entwickler arbeiten, die genau wissen, was sie tun. Wie genau kann nun aber Wissen sein, wenn sich nicht nur die Domäne bewegt, sondern vor allem der Markt der technischen Realisierungsmöglichkeiten?
Das Entwicklerteam trennt deshalb ganz klar zwischen “Performance”, d.h. Zeit, in der es in Höchstgeschwindigkeit entwickelt, und “Übung”. Feature Slices realisiert das Team selbstverständlich in seiner Performance-Zeit. Da sitzt jeder Handgriff. Alle arbeiten wie geschmiert miteinander. Was zu tun ist, liegt klar auf der Hand bzw. ist aus Architektur, Modell und Arbeitsorganisation für jeden abzulesen.
Damit Performance-Zeit möglich ist, reflektiert das Entwicklerteam jedoch ständig darüber, was es noch nicht genau weiß. Es hinterfragt ständig sein Wissen in Bezug auf Domäne und Technik. Und wo es Wissenslücken auftut, da setzt es ausdrückliche Übungszeit an, um sie zu schließen. Ist die Wissenslücke projektspezifisch technisch, dann wird sie im Rahmen einer Spike Solution angegangen. Ist die Wissenslücke allgemein, dann wird sie durch Fortbildung geschlossen.
Domänenwissenslücken schließlich trägt das Entwicklerteam an die Anwender heran. So schließt sich der Kreis. Der Anwender repräsentiert durch die Rolle ProductOwner ist die entscheidende Klammer um die Softwareentwicklung.
Der Anwender “zieht täglich am Team”, weil er den Fortschritt der Entwicklung kontinuierlich gegen seine Anforderungen halten will. Nur so kann er schnell reagieren. Nur so bekommt er auch das Maximum für sein Geld.
Und das Team “zieht täglich am Anwender”, um dessen Anforderungen von vornherein möglichst genau zu treffen. Das heißt, der Anwender steht immer für Rückfragen zur Verfügung, um das Team in seiner täglichen Feature Slice Produktion nicht zu behindern.
Damit der gegenseitige Zug wirklich funktioniert, braucht es abschließend natürlich eines: Verlässlichkeit. Das Entwicklerteam muss verlässlich Anforderungen in Software mit Anwendernutzen transformieren. Der Anwender muss die Software verlässlich sofort abnehmen. Und der Anwender muss verlässlich für Rückfragen zu den Anforderungen bereitstehen.
Ohne Verlässlichkeit ist die ganze Softwareentwicklung nichts. Oder wenn sie etwas ist, dann zumindest nichts, das wie geschmiert und mit Höchstgeschwindigkeit abläuft.
Und ohne Verlässlichkeit kein Vertrauen. Denn Vertrauen kann man nicht befehlen; es entwickelt sich nur, wo Verlässlichkeit erfahren wird.
Das hat das Unternehmen begriffen und verzichtet daher auf den üblichen Festpreismodus für die Entwicklung des online Shops. Es hat sein Budget fixiert, es hat Wünsche gesammelt – und dann überträgt es die Realisierung einem Entwicklungsteam, zu dem es Vertrauen hat, dass es die Realisierung in Höchstgeschwindigkeit beherrscht.
Da Vertrauen immer gegenseitig sein muss, stellt das Unternehmen natürlich sicher, dass es selbst dem Entwicklungsteam ein verlässlicher Partner ist, der die erwartete Höchstgeschwindigkeit mittragen will und kann.
Und so wird am Ende der Traum wahr: Das Unternehmen bekommt ohne Budgetüberschreitung das immer wieder flexibel neu bestimmte Maximum.
Jetzt können Sie die Augen wieder öffnen. Lassen Sie den Traum aber noch etwas nachwirken. Vielleicht bewirkt er ja etwas bei Ihnen. Vielleicht machen Sie sich ja auf den Weg, aus dem Traum Realität werden zu lassen… Ich glaube, das ist möglich.
Die Abstraktionsebenen der Softwarearchitektur sind für mich diese:
Architektur macht zunächst auf den Abstraktionsebenen Bounded Context und App Längsschnitte durch das Anwendungssystem. Architektur schneidet es in dünne Scheiben. Die sind vollständig insofern, als dass sie vom Frontend bis zum Backend reichen.
App, Maschine und Prozess zerlegt die Architektur dann transversal weiter. Die funktionalen Scheiben werden “gewürfelt”, um insbesondere Skalierbarkeit, Performance und Verfügbarkeit zu erreichen. Jedes Teil stellt dann nicht mehr für sich einen Anwendernutzen her, sondern trägt nur dazu bei. (Hier ist die klassische Schichtenarchitektur anzusiedeln.)
Grad gibt es ja mal wieder Diskussion um eine Code Kata, die 
Gerade hat die 
Heute höre ich Klagen über Arbeitsbedingungen. Immer wieder werden da Mauern beschrieben, gegen die Entwickler laufen, weil sie nicht so dürfen, wie sie wollen. ReSharper darf nicht angeschafft werden: zu teuer. Automatisiertes Testen darf nicht in Anschlag gebracht werden: dafür hat der Kunde nicht bezahlt. Eine Fortbildung darf nicht besucht werden: vier Monate Urlaubssperre, weil die Projekte weit jenseits des Plans liegen.
Oder wie wäre es, das Buch sofort in “Module” zu zerlegen. Und nicht nur dieses Buch, sondern auch die bisherigen von Förster und Kreuz? Dann die Module mit Tags versehen oder in eine