Architekturarbeit mit Kanban organisieren

…ohne dabei den Kopf zu verlieren!

Die bisherigen Artikel dieser Serie zeigten, wie man sich Architekturarbeit sinnvoll aufteilt, insbesondere die Arbeit an der Form und die an der Struktur. Wie funktioniert das nun im Großen, mit vielen Leuten, in vielen Teams?

Amazon neu bauen

Stellen Sie sich vor, Sie wollten mit 75 Leuten amazon.com neu entwerfen und programmieren. Wie würden Sie sich organisieren, um zum Ziel zu kommen, ohne dabei verrückt zu werden? Ich habe schon Softwarearchitekten gesehen, die in einem solchen Projekt so aussehen würden:

Als Projektleiter wollen Sie das nicht wirklich. Ein überlasteter Architekt tendiert dazu, weniger Sorgfalt in den Entwurf zu stecken als er müsste. Das System wird vielleicht funktionieren, doch im Betrieb so seine Schwächen zeigen. Also müssen Sie schon beim Team-Aufbau darauf achten, dass sich nicht nur Programmierarbeit, sondern auch die Architekturarbeit gleich mit verteilt und nicht an einer Person hängen bleibt.

Subdomänen schneiden

Ein erster Schritt zu einer sinnvollen Teamaufteilung führt über die Identifikation von Subdomänen der Anwendungsdomäne. Conways Gesetz hilft uns dabei, das verträglich aufzustellen. Amazon möchte Bücher und anderes verkaufen. Kunden sollen die Sachen bestellen und bezahlen und eine Email zur Bestätigung bekommen. Aus einem Lager bekommen die Kunden die bestellten Sachen geliefert. Das Lager muss rechtzeitig, aber nicht zu üppig, aufgefüllt werden. Sie identifizierten mit diesen wenigen Sätzen also gerade die folgenden Subdomänen: Bestellung, Zahlung, Lagerhaltung, Auslieferung, Kundenverwaltung, Schnittstellen.

Dabei habe ich bereits eine Faustregel für die Komponentenfindung in den Subdomänen benutzt: Solange man noch nicht viel weiß, gründet man am besten vier generische Arten von Komponenten, mit folgenden vier Zwecken:

• Stamminformationen verwalten
• das Geschäft machen
• das Geschäft messen, berichten und verfolgen
• externe Systeme anbinden

Wenn Sie das z.B. für die Subdomäne Lagerhaltung machen, könnten Sie auf folgende Komponenten kommen (der Zweck der Komponente jeweils in Klammern):

• Bestand (Stamminformationen)
• Wareneingang, Nachbestellung (Geschäft machen)
• Auswertungen (Geschäft messen)
• Lieferanten (externe Systeme anbinden)

Fünf große Komponenten mit entsprechend vielen Use Cases, deshalb ordnen Sie drei Teams à 5 Leute zu:

Die Teams rot, grün und blau sind Feature-Teams (wie von Bas Vodde und Craig Larman vorgeschlagen). Sie sind dafür verantwortlich, abgeschlossene Features zu entwickeln, eins nach dem anderen. Sie dürfen dabei alle fünf Komponenten modifizieren – es gibt also keine Zuordnung von Komponente zu Team.

Die drei Teams sprechen sich untereinander ab, der kleine Kreis neben den Teams deutet ein regelmäßiges Meeting an, das intern in der Subdomäne stattfindet. Dort können alle Fragen geklärt werden, die nur die eine Subdomäne Lagerhaltung betreffen. Entsprechend können Sie das für weitere Subdomänen machen, z.B. für Bestellung:

Oder für die Subdomäne Auslieferung:

Insgesamt bekommen Sie dadurch eine Struktur in Ihre Teams, die möglichst geringen Kommunikationsaufwand verursacht, doch innerhalb der Subdomäne maximale Freiheit erlaubt.

Die Architekturrunde

Alle gemeinsam machen den Entwurf des Systems. Dazu gründen Sie am besten eine Top-Level Architekturrunde, rekrutiert aus Vertretern der Feature-Teams in den Subdomänen:

Die Mitglieder dieser Runde stammen aus den Feature-Teams aller Subdomänen. Zusätzlich sind Vertreter der Kunden, der Benutzer und Domänenexperten dabei, die nicht Bestandteil der Feature-Teams sind.

Die Runde trifft sich mehrmals pro Woche, die Leute sprechen über Features des Systems und stellen fest, welchen Beitrag jede Subdomäne leisten muss. Sie definieren, welche Absprachen für die jeweilige Änderung der Form des Systems notwendig sind, die von einem Use Case ausgelöst wird. Sie nehmen den Abstimmungsbedarf in die Subdomänen mit und berichten beim nächsten Mal, was dort besprochen wurde.

Mehr zum genauen Ablauf dieser Kommunikation lesen Sie weiter unten. Zunächst ein Beispiel.

Beispiel für kollaborativen Entwurf eines Features

Nehmen Sie an, die Teams wollen die folgende User Story entwerfen und realisieren:

Als ein Kunde möchte ich in den Produkten stöbern, um etwas bestellen zu koennen. Dabei möchte ich zu einem Buch seinen Bestand und seine Lieferzeit angezeigt bekommen.

Zum Zeitpunkt der Ausführung der Autors befindet sich der Benutzer im Shop, der zur Subdomäne Bestellung gehört. Das Konzept „Bestand“ gehört zur Subdomäne Lagerhaltung. Das Konzept „Lieferzeit“ gehört in die Subdomäne Auslieferung, also ist zur Realisierung dieser Story eine Kommunikation zwischen drei Teams erforderlich, sagen wir, es sind die Teams rot, saphir und gelb.

Dieser Gesprächsbedarf wird in der Top Level Architekturrunde erkannt, die Leute nehmen das Thema dort lediglich mit und verabreden, wann sie sich dazu treffen wollen. Sie gehen während der Runde erst einmal zum nächsten Thema über.

Später treffen sie sich und vereinbaren zwei neue Schnittstellen. Die Komponente Lagerhaltung::Bestand bekommt eine neue Schnittstelle zur Abfrage der vorhandenen Stückzahl. Die Komponente Auslieferung::Warenausgang erhält eine neue Schnittstelle zur Abfrage der Lieferzeit. Die Komponente Bestellung::Shop wird innerhalb der Stöbern-Story beide Schnittstellen aufrufen und die Werte anzeigen, wie hier abgebildet:

Die Teams rot, saphir und gelb berichten über das beabsichtigte Form-Inkrement in der nächsten Architekturrunde. Andere Mitglieder der Runde geben Feedback. Die Form wird gutgeheißen. Die Teams realisieren und testen die Struktur und dokumentieren die Änderungen.

Kanban zur Koordination im Großen

Wie schaffen Sie es nun, Formänderungen für 75 Leute zu koordinieren, ohne dabei verrückt zu werden? Machen Sie sich eine Kanban-Tafel zu Nutze. Kanban skaliert auch für größere Gruppen, vorausgesetzt, man macht sich klar, wie die Zusammenarbeit gestaltet werden soll, welche Ergebnisse fließen und woran man denn erkennt, wie weit man ist.

Im Amazon-Beispiel würde man mit einer Idee beginnen, diese dann in einzelne Features zerlegen, für jedes Features die Änderung der Form finden und entwerfen, dann entwickeln, testen und in Produktion nehmen. Alles in schneller Folge, für kleine Features, mit zeitnahem Feedback. Achtung: Nicht Wasserfall-artig zuerst alles entwerfen, dann alles entwickeln, dann alles testen, sondern immer sofort das Feature, das entworfen ist, schon einmal entwickeln, testen und freigeben, während die nächsten Features bereits entworfen werden. (Nicht der sequenzielle Prozess ist beim Wasserfall das Problem, sondern die große Batchgröße und das dadurch fehlende schnelle Feedback.)

Jedes Feature würde man durch eine Haftnotiz (das kanban) repräsentieren, auf der der Feature-Titel steht und eine Liste von Subdomänen, die betroffen sein werden:

Diese kanban (Plural, ohne -s) hängen an einer Kanban-Tafel. Das kann ein Whiteboard sein, das in Spalten eingeteilt ist, die den Schritten im Arbeitsprozess entsprechen. Hängen Sie zwei Whiteboards nebeneinander, dann könnte das linke von beiden so aussehen:

Die kanban für Ideen sind orange, die für Features sind gelb. Die Annahme ist, dass die Mitglieder der Top Level Architekturrunde im wesentlichen in der Spalte „Form / Architektur“ arbeiten. Der Rest des Prozesses spielt sich auf der rechten Hälfte der Kanban-Tafel, also auf dem zweiten Whiteboard ab, das daneben hängt:

Sie sehen, dass die Spalte „Entwickeln“ in Zeilen eingeteilt ist – eine Zeile für jede Subdomäne. Die Features, die gerade in Entwicklung sind, hängen in der Unterspalte „unterwegs“. Anhand der Zeile kann man erkennen, in welcher Subdomäne gerade daran gearbeitet wird. Sind die Teams mit einem Feature fertig, hängen sie das gelbe kanban in die Spalte „fertig zum Systemtest“. Von dort aus ziehen es sich die Tester und die Vertreter der Benutzer weiter durch den Rest des Prozesses, bis das Feature produktiv geht.

Annahmen / Auswirkungen auf den Alltag

Ich nehmen für dieses Beispiel an, jedes der 15 Teams habe 5 Leute. Dann können vier davon jeweils zu zweit programmieren (pair programming) und eine Person übernimmt die Rolle des Domänenexperten für Entwurf und Architektur. Das muss nicht immer dieselbe sein, doch in vielen Fällen wird sich das so herausbilden.

Nehmen wir an, so ein Paar braucht zwei Wochen, um ein Feature fertig zu entwickeln. Wir haben zwei Paare pro Team, also gilt:

• work in progress (WIP) = 2 Features
• Zykluszeit = 2 Wochen pro Feature
• also ist der Durchsatz = 1 Feature pro Woche

Dabei habe ich das Gesetz von Little benutzt:

Bei 15 Teams nehme ich jetzt an, dass jedes 1 Feature pro Woche macht und sich damit auf der gesamten Kanban-Tafel 15 kanban pro Woche nach rechts bewegen müssen, damit kein Stau entsteht. Die Tester müssen in der Lage sein, diese 15 pro Woche auch zu testen und produktiv zu nehmen. Die Domänenexperten für Entwurf und Architektur müssen in der Lage sein, diese 15 pro Woche zu verstehen, zu entwerfen, die Formänderungen in der Top Level Architekturrunde abzustimmen und sie an die Entwicklungsteams zu geben.

Zum Glück habe ich angenommen, dass jedes der 15 Teams einen Kümmerer für die Architektur schickt und sich jeder Kümmerer deshalb nur mit einem Feature pro Woche beschäftigen muss. Wahrscheinlich braucht er/sie etwa…

• 1 Std. um das Requirement zu verstehen
• 1 Std. um das Requirement aufzuschreiben
• 8 Std. zum Entwerfen der Form
• 10 Std. zur Abstimmung mit der Top Level Architekturrunde (nicht nur für 1 Feature, sondern für alle, die in der Woche besprochen werden!)
• 4 Std. zur Dokumentation der Architektur

Das sind 24 Stunden pro Woche, verbleiben noch 16 Stunden Reservezeit, um konzentriert arbeiten zu können und dabei nicht verrückt zu werden. Der Wochenplan für einen Architektur-Kümmerer könnte also folgendermaßen aussehen:

Die Top Level Architekturrunde trifft sich z.B. jeden Tag von 13 bis 15 Uhr – der Vormittag verbleibt für konzentrierte Entwurfsarbeit oder für Code Reviews mit den Teamkollegen. Damit jedes der 15 Features pro Woche, deren Formänderung abzustimmen ist, auch mal drankommt, müssen in jedem Treffen der Architekturrunde nur 3 Features behandelt werden. In einem Zwei-Stunden-Meeting würde man also 30 Minuten pro Feature diskutieren und hätte noch 30 Minuten Puffer. Jeder Kümmerer bringt pro Woche ein Feature zur Abstimmung und gibt Feedback für die 14 anderen.

Die Häkchen für die Subdomänen, die sich auf jedem kanban befinden, sind während des Meetings sehr nützlich. Zettel mit vielen Häkchen müssen intensiv vorgestellt und besprochen werden. Zettel mit nur einem Häkchen können schneller durchlaufen.

Konzentriert und schnell

Die Kanban-Methode bringt uns bei, nur so viel Arbeit zu leisten, wie „rechts von uns“ auch wirklich benötigt wird. Fokussierung ist Trumpf!

Die Top Level Architekturrunde sollte nur so viele kanban produzieren, wie in die Spalte „fertig zum Entwickeln“ passen. Bei einem WIP-Limit von 6 und einem Durchsatz von 15 pro Woche ist das Stoff für zwei Tage. Das reicht, weil man sich ja täglich trifft und neue kanban produziert. Die Kümmerer (also die Domänenexperten für Entwurf und Architektur) können 15 Features parallel entwerfen, dürfen aber nur 3 am nächsten Tag zur Abstimmung stellen, deshalb ist das WIP-Limit der Spalte „zur Abstimmung“ gleich 3.

Rechnen Sie einmal durch: Wie lange braucht ein Feature, wenn es die Spalte der Top-10 Features wichtigsten verlassen hat, bis es in Produktion genommen werden kann? Rechts von dieser Spalte können sich maximal 96 Features gleichzeitig in Arbeit befinden. Bei einem Durchsatz von 15 pro Woche sind das im Durchschnitt 6,4 Wochen, bis ein Feature (zusammen mit den anderen 95) durch den Prozess „hindurchgeschwommen“ ist.

Fazit

Entwickler und Architektur-Kümmerer können sich bei dieser Art, sich zu organisieren, voll konzentrieren. Jeder arbeitet nur an einem Feature gleichzeitig und stimmt sich ab und zu mit den anderen ab – zu definierten Zeitpunkten, so dass diese Taskwechsel leicht fallen.

Mehrfache Anwendung von Teile-und-Herrsche hat das ermöglicht:

• Domäne in Subdomänen teilen
• Teams auf Subdomänen verteilen
• Form und Struktur separat bearbeiten
• WIP-Limits beachten (nur so viel arbeiten wie nötig)
• Die Wachphase vormittags für konzentrierte Arbeit nutzen
• Das „Suppenkoma“ nach dem Mittagessen für die Abstimmung in großer Runde

Falls Sie (wie ich) auch schon einmal verrückt geworden sein sollten beim Entwurf großer Systeme – fragen Sie mich, ich kenne das und weiß Ihnen zu helfen!