Was AUTOSAR mich über Backlog-Management gelehrt hat

Die Beispiele in diesem Artikel sind illustrative Kompositionen und beschreiben kein bestimmtes Projekt, kein Produkt und keinen Arbeitgeber. Die geäußerten Ansichten sind meine eigenen.

Die meisten agilen Gespräche über Backlog-Management drehen sich um Priorisierung. Was zuerst gemacht wird. Was warten kann. Wie man die Nachfrage der Stakeholder mit der Kapazität des Teams in Einklang bringt.

Dort scheitern die meisten Systeme nicht.

Bevor ich je ein PI-Planning leitete, verbrachte ich Jahre mit sicherheitskritischer Software. Automotive- und Industriesysteme, bei denen ein Ausfall physische Folgen hatte und bei denen ein guter Teil der Arbeit in AUTOSAR-basierten Architekturen steckte.

AUTOSAR zwingt dich, jedes Signal, jede Schnittstelle, jede Timing-Vorgabe zu definieren, bevor du irgendetwas schreibst, das echte Arbeit leistet. Es ist kein beliebter Standard. Ich habe mich damals darüber beschwert. Dann wechselte ich in skalierte agile Umgebungen und fing an, ihn zu vermissen.

Ich erinnere mich, dass AUTOSAR mich frustrierte, weil es Gespräche erzwang, die sich schmerzhaft verfrüht anfühlten. Wir wollten bauen. Der Standard zog uns immer wieder zurück zu Schnittstellen, Timing, Signalbedeutung und Ausfallverhalten. Erst später, als ich Abhängigkeiten zwischen Teams statt zwischen Komponenten betrachtete, wurde mir klar, dass der Ärger nützlich gewesen war, weil er die Systemgrenze ans Licht gezwungen hatte.

Die Probleme verschwinden nicht, wenn du aufhörst, Code zu schreiben. Sie werden größer und schwerer zu sehen.

Ein Defekt innerhalb einer Komponente zeigt sich in einem Debugger. Eine Fehlausrichtung zwischen Teams zeigt sich Wochen später, nachdem andere Teams bereits darauf aufgebaut haben.

AUTOSAR nimmt an, dass der gefährlichste Teil eines Systems nicht die Komponenten sind. Es ist die Grenze zwischen ihnen.

Die meisten agilen Setups behandeln es nicht so. Sie nehmen an, dass sich die Grenze von selbst regelt.

Schnittstellen sind das eigentliche System

Stell dir zwei Komponenten vor, die sich um ein einziges Bit darin unterscheiden, wie sie dasselbe Signal interpretieren. Beide Implementierungen sind in sich korrekt. Die Schnittstelle ist falsch.

Probleme wie dieses können Tage zum Auffinden und Minuten zum Beheben brauchen, sobald sie gefunden sind. Das Muster ist häufig genug, dass jeder, der über Komponentengrenzen hinweg integriert hat, es wiedererkennt. Es geht selten um individuelle Fehler. Es geht darum, wie das System definiert ist.

Das verändert, wie man über Abhängigkeiten denkt.

Die Story in deinem Backlog ist die Implementierung. Die Abhängigkeit ist die Schnittstelle.

Die meisten Teams behandeln die Schnittstelle als Koordinationsproblem statt als Engineering-Problem. Dann sind sie überrascht, wenn die Integration zur Verhandlung wird.

Abhängigkeiten sind keine Koordination

Wenn Teams über Abhängigkeiten sprechen, klingt das Gespräch meist nach Planung. Wer braucht was, wann, von wem.

Es sieht strukturiert aus. Es fehlt etwas Grundlegendes.

Eine Schnittstelle ist keine Vereinbarung zwischen Menschen. Sie ist eine Spezifikation dessen, wie sich ein System unter Randbedingungen verhält. Sie hat Fehlermodi. Sie hat Randfälle. Sie hat Timing-Implikationen. Sie kann korrekt oder inkorrekt sein, unabhängig von den Menschen, die an ihr arbeiten.

Wenn Abhängigkeiten als Koordination behandelt werden, verschwinden diese Eigenschaften. Das Gespräch verlagert sich vom Engineering zur Terminplanung.

Das funktioniert, bis es das nicht mehr tut.

Timing lebt außerhalb des Backlogs

Timing ist der andere blinde Fleck.

Zu wissen, dass ein Team etwas von einem anderen braucht, reicht nicht. Du musst auch wissen, wann, und unter welchen Bedingungen.

Das lebt selten im Backlog. Es lebt in jemandes Kopf, meist in jemandem, der nicht im Team ist.

Solange diese Person verfügbar und aufmerksam ist, funktioniert das System. Wenn sie es nicht ist, rutschen Dinge auf eine Weise, die im Nachhinein schwer zu erklären ist.

Wenn es in den Kennzahlen auftaucht, ist es bereits teuer.

Grenzen ernst nehmen

Das ist kein Plädoyer für AUTOSAR-artige Zeremonie in Software, die sie nicht braucht. Es ist ein Plädoyer dafür, Grenzen ernst zu nehmen.

Die meisten agilen Systeme konzentrieren sich auf die Arbeit innerhalb von Teams. Das ist der sichtbare Teil. Die Boards, die Storys, die Commitments.

Die Fehler beginnen selten dort.

Wenn die Grenze der Ort ist, an dem Systeme scheitern, ist sie auch der Ort, an dem ein Delivery Board am leichtesten lügt. Ein Status-Board kann jedes Team grün zeigen, während die Lücken zwischen ihnen still wegrutschen. How to Read a Delivery Board arbeitet vier Wege heraus, dasselbe Board ehrlich zu lesen, einer davon die teamübergreifenden Schnittstellenlücken, um die es in diesem Text geht. Der interaktive E/E Solution Tracker lässt dich eine Grenzen-Linse einschalten und diese Lücken auf einem echten Programm sichtbar werden sehen.