Mit KI wird vieles einfacher und schneller, und in der Entwicklung ist die Automatisierung am weitesten fortgeschritten. Das Problem liegt davor und danach.

Davor, weil die Anforderungen klarer sein müssen als jemals zuvor. Sind sie unklar, spiegelt die KI diese Unklarheit und füllt die Lücken mit Mutmassungen. Schwammige Anforderungen, die bisher die Entwicklung ausgeglichen hat, funktionieren nicht mehr im gleichen Mass wie früher.

Danach, weil der Test mit diesem Tempo Schritt halten muss.

KI gehört deshalb nicht nur in die Entwicklung, sondern auch zum Product Owner. Sonst driftet entweder die Qualität, oder der PO entwickelt sich zum Bottleneck.

Der PO mit KI

Setzt der PO selbst KI ein, führt der beste Weg zu einer soliden Spezifikation über das Frage-Antwort-Spiel mit der KI, und zwar so lange, bis die KI meldet, dass sie ein solides Verständnis davon hat, was entstehen soll.

Genau diese Rückfragen würde sonst der Entwickler stellen und damit die Lücken und Uneindeutigkeiten der Spezifikation aufdecken. Zwischen Entwickler und PO kostet dieses Pingpong aber Zeit und Performance. Deshalb muss der PO die Spezifikation in einer richtig guten Qualität liefern.

Der PO ohne KI

Die Alternative ist, dass der PO keine KI einsetzt und wie immer arbeitet. Er erledigt seine Aufgaben gewissenhaft und langsam. Da die Entwicklung nun aber viel schneller ist, braucht sie auch mehr Anforderungen zum Umsetzen. Sonst verpufft der Leistungsvorsprung in Wartezeiten, und der PO wird zum Bottleneck.

Der Entwickler muss es trotzdem verstehen

Ist die KI mit der Spezifikation zufrieden, ist die Arbeit noch nicht getan. Der Entwickler muss verstehen, was die KI umsetzt, und dasselbe Verständnis entwickeln. Dazu kommen oft Non-Functional Requirements, deren sich die KI gar nicht bewusst ist und die der PO nicht sauber spezifizieren kann.

Die KI kann zum Beispiel nicht wissen, welcher Durchsatz erwartet wird, und damit auch nicht, ob eine Entkopplung über eine Queue sinnvoll ist oder nur Overhead erzeugt. Genau diesen Fall hatte ich bereits in einem Projekt.

Dafür braucht es die bilaterale Abstimmung zwischen PO und Entwickler. Die Lücken der Spezifikation hat der PO zu diesem Zeitpunkt schon mit der KI geschlossen. In der Abstimmung geht es darum, dass der Entwickler versteht, was gebaut wird, und um die Non-Functional Requirements.

Die Tests kommen zuerst

Die Entwicklung setzt die Funktionalität nun in Rekordzeit um und verschiebt das Bottleneck in den Test.

Ich lese immer wieder, wie viel Autonomie die KI in der Entwicklung haben sollte. Dabei ist die Antwort so einfach. Bevor etwas entwickelt wird, werden die Tests dafür geschrieben, und damit ist das gewünschte Verhalten festgelegt.

Dieses Verfahren gibt es schon lange, es heisst TDD, Test-Driven Development. Nur sind die automatisierten Tests bisher oft genug dem Zeitmangel zum Opfer gefallen.

Das ist mit KI Geschichte. Die KI kann auch die automatisierten Tests schon vor der Implementierung erstellen. Ohne dieses Instrument wandert das Bottleneck einfach von der Entwicklung in die Qualitätssicherung, und der Effizienzgewinn verpufft erneut.

Wo der Human in the Loop noch sinnvoll ist

Hat die KI die Tests vorab geschrieben, muss ein Mensch kontrollieren, ob sie genau das abtesten, was wichtig ist. Je nach Setup erstellt der Entwickler die Tests mit der KI, und die QA reviewt sie, oder die QA erstellt sie direkt. Ist das erledigt, ist die erste Hürde genommen.

Die KI kann die Implementierung dann ohne menschliches Zutun fertigstellen, und sie stellt selbst fest, wann sie fertig ist, denn dann müssen alle Tests grün sein.

Die KI dreht damit plötzlich mit sich selbst die Runden und nicht mehr mit dem Menschen. Das kann über Nacht geschehen, also ausserhalb der Geschäftszeiten. Der Entwickler arbeitet also virtuell rund um die Uhr.

Einchecken kann die KI dabei nicht selbst. Das macht am Morgen der Mensch nach dem Review. Hat die KI die Tests verändert, fällt das dort sofort auf, verschleiern kann sie es nicht.

Wo dein Durchsatz hängen bleibt

Es reicht nicht, KI in der Entwicklung einzuführen. KI braucht es bereits im Anforderungsprozess und in der Qualitätssicherung. Es braucht radikales Umdenken, damit der Effizienzgewinn beim Unternehmen ankommt, als mehr Durchsatz und kürzere Time to Market.

Genau von diesen Prozessanpassungen handelt mein Buch «Schnelle Leute, langsame Firma». Wenn du KI zwar eingeführt hast, der Durchsatz aber immer noch nicht zufriedenstellend ist, lass uns darüber reden. Buch unten einen Termin, und ich zeige dir, wo die Bottlenecks in deinem Unternehmen liegen.