Totgesagte leben länger

Untoter SDLC?

Der Software Development Lifecycle, kurz SDLC, ist gerade ein Thema bei uns in der Firma. Ein Kollege schickte mir diese Woche einen Link, The Software Development Lifecycle Is Dead, mit der Frage, was ich davon halte.

Die These: Requirements, Design, Implementierung, Test, Review, Deployment – dieser Zug aus getrennten Phasen kollabiere mit Agenten zu einem engen Loop. Ein Mensch beschreibt seine Absicht, der Agent baut, testet und deployt, der Mensch schaut auf das Ergebnis und gibt die nächste Richtung vor. Keine Tickets, keine Sprints, keine Pull Requests, die auf ein menschliches Review warten.

Mein erster Impuls: Mann. Da setze ich mir zu Hause ein KI-unterstütztes Ein-Mann-Projekt auf, ohne dass mir jemand dazwischenquatscht – und dann mache ich es trotzdem zu kompliziert. Der zweite: Was der Artikel beschreibt, ist keine professionelle Softwareentwicklung. Das ist Vibe Coding.

Mache ich es zu kompliziert? Wie sieht der Lebenszyklus eines neuen Features bei Televism eigentlich aus?

Was bei mir bereits kollabiert ist

Über die Implementierung habe ich in der Dark Factory schon geschrieben: Ticket rein, Agent setzt um, ein zweites Modell reviewt den Merge Request, ich entscheide an den Threads, was nachgebessert wird. Währenddessen bin ich längst bei der nächsten Idee.

Da hat der Artikel einen Punkt: Was früher eigene Phasen mit Wartezeiten dazwischen waren, ist heute so eng gekoppelt, dass die Grenzen kaum noch interessieren. Ich plane nicht mehr, wann jemand Code schreibt, testet oder einen Review-Fund fixt. Das passiert in einem Zug.

Das Deployment ist klassisch, im Sinne von: ohne KI. Die main-Pipeline kann den Stand manuell auf QA ausliefern. Dort spielen Bots eine Saison, und es wird geprüft, ob sie sauber zu Ende gegangen ist. Bei Bedarf logge ich mich ein und teste von Hand, meist auf den Daten, die die Bots erzeugt haben. Ein weiterer Job bringt die getestete Version auf Prod – sobald es Prod gibt.

Wie steht es um Anforderungen und Architektur?

Kommunikation mit der Dark Factory

In meinen früheren Versuchen, Televism zu bauen, war ich wirklich ein Ein-Mann-Team: Die Idee ging direkt durch meine Finger in die Tastatur. Jetzt sind wir ein Team, und ich muss meinem Agenten mitteilen, was er umsetzen soll.

Diese Schnittstelle ist bei mir ein Ticket. Tickets in so einem kleinen Projekt? Das wirkt überdimensioniert, entstand aber aus Pragmatismus: Irgendwo muss stehen, was gemacht werden soll, bevor die Dark Factory loslegt. Das Repository wollte ich dafür nicht nutzen:

• Alte Planungsdokumente können vom Agenten als aktuelle Dokumentation gelesen werden und ihn auf die falsche Fährte locken. Dasselbe gilt für Menschen mit einer Volltextsuche.
• Sie müssten selbst durch den MR-Prozess – oder es bräuchte einen zweiten, schlankeren Prozess nur für sie.

Also nicht das Repo, aber wo dann? Auch mit Agenten sollten Änderungen nicht zu groß werden. Der Agent kann ein großes Feature durchaus am Stück umsetzen. Aber je größer und gemischter der Merge Request, desto schwerer lässt er sich verstehen, prüfen und korrigieren. Fünf Entscheidungen und dreitausend Zeilen auf einmal will ich auch von einem Agenten nicht. Ein größeres Feature zerlege ich deshalb in Schritte, von denen jeder noch eine verständliche Geschichte erzählt: Das ist das Ziel. Das machen wir jetzt. Das sind die Rahmenbedingungen.

Ich brauche also einen Ort außerhalb des Repositories für ein Vorhaben mit seiner Absicht – und darunter die Schritte, die es dorthin bringen. In GitLab sind das ein Issue und untergeordnete Tasks.

Leitplanken oder Vollständigkeit?

Architektur und Design entstehen damit auf Ebene der Subtasks. Die Frage ist: wie viel davon? Man kann dem Agenten auch nur das Was geben und dazuschreiben: „Keine Rückfragen, setz das um.“ Dann kommt zuverlässig irgendetwas heraus. Für einen kleinen Change oder ein eingeschwungenes Projekt reicht das sogar.

Der Subtask soll dem Agenten nicht bis ins letzte Detail vorgeben, wie etwas umgesetzt wird. Er hält fest, was mir als technisch Verantwortlichem wichtig ist – umso mehr, je neuer und riskanter die Änderung ist. Beim siebten CRUD-Screen reichen drei Stichpunkte. Wenn die Spielzeit voranschreitet und dabei Events auslöst, die ordentlich Last erzeugen, fasse ich die Leitplanken für die Umsetzung enger.

Ein vom Agenten erzeugter Vierhundert-Zeilen-Plan hilft mir dabei nicht; ich würde ihn nicht vollständig reviewen. Und was der Agent lokal erzeugen kann, kann er auch in der Cloud erzeugen, bevor er anfängt. In den Subtask gehören lieber zwanzig Zeilen mit dem, was wirklich zählt: die gewünschte Schnittstelle, Library-Vorgaben, Design-Vorgaben (synchron / asynchron), relevante Tests und die Grenze, an der der Agent anhalten soll.

Die Story dagegen beschreibt, in guter alter Product-Owner-Rolle, vollständig, was am Spiel anders werden soll: Intent, gewünschtes Ergebnis, fachliche Regeln, Entscheidungen und das, was ausdrücklich nicht dazugehört. Kein Bauplan, aber ein lückenloses Was.

So sieht der Ablauf aus, mit dem Hut, den ich gerade trage:

Skaliert das?

Zurück zur Diskussion in der Firma. Wenn ich bei Televism ansehe, wie viel Zeit in Spielregeln, Klickdummys und Balancing fließt und wie wenig in Architektur und Umsetzung, dann wird ein PO es schwer haben, sechs Entwickler mit Stories in diesem Detailgrad zu versorgen. In einem größeren Team müsste ich einen Teil dieser Entscheidungen delegieren.

Was heißt das für Teams? Nur noch ein PO und ein bis zwei Entwickler, oder gleich ein technisch affiner PO allein? Aus Sicht von Wissensverteilung und Risikomanagement kann das nicht das Ziel sein, jedenfalls nicht für Kernsoftware.

Dann brauchen Entwickler mehr Produktkontext und mehr Entscheidungsspielraum. Nicht so, dass sechs Entwickler je eine eigene Produktvision entwickeln und jeder die Kunden interviewt; das Was bleibt in der Hoheit des PO. Aber Stories können nicht mehr so ausdetailliert sein, wie Entwickler es gewohnt sind. Angefangen bei Dialogen wie diesem:

Refinement.
Dev: „Soll X auch konfigurierbar sein?“
PO: „Ja, gute Idee, mach das.“
Dev: „In welcher Zeitzone soll das laufen?“
PO: „Was ist denn der Standard?“
Dev: „UTC.“
PO: „Ja, mach das so.“

Für solche wiederkehrenden Entscheidungen lässt sich der Entscheidungsspielraum vorab klären. Dann braucht es nicht jedes Mal eine Rückfrage beim PO. Die größere Verschiebung liegt aber darin, dass Stories Leitplanken setzen und innerhalb dieser Leitplanken Verantwortung übergeben: Die Spannweite reicht von „Welche Einstellungen konfigurierbar sein sollen, entscheidet ihr; die Standardwerte müssen ohne Konfiguration einen sinnvollen Betrieb ermöglichen“ bis „Dieses Feature unterliegt der DSGVO; der Umgang mit personenbezogenen Daten muss noch erarbeitet, offene Fragen vor der Umsetzung mit dem Datenschutzverantwortlichen geklärt werden.“

Das heißt nicht, dass überall weniger Details stehen sollen. Vollständig müssen die Entscheidungen sein, die der jeweilige Verantwortliche nicht delegieren will oder kann. Alles andere wird als Leitplanke übergeben.

Zu Ende gedacht landet man tatsächlich beim Artikel. Fachliche Leitplanke: Ich habe eine Absicht. Technische Leitplanken: keine. Ein Agent baut, der Mensch schaut hin und iteriert.

Für einen Prototyp oder eine bewusst offene Suche kann das genau richtig sein. Für ein langlebiges Produkt reicht es nicht. Dort braucht es nicht weniger Lifecycle, sondern einen anderen: weniger Übergaben vollständig ausformulierter Details, aber klarere Übergaben von Leitplanken und Verantwortung.