Wer Verbesserungen automatisiert, muss den Ehrgeiz deckeln

Wer eine Automation nach Verbesserungen für ein Produkt suchen lässt, bekommt immer welche. Darin liegt das Problem, nicht der Nutzen.

In der Factory, die öffentlich auf software-factory.dev entsteht, gibt es dafür eine Automation namens Product Improver. Mich interessiert an ihr vor allem eine Designentscheidung: Sie deckelt ihren eigenen Ehrgeiz.

Ein echtes Review, zweimal pro Woche

Die Cron-Zeile 0 9 * * 1,4 startet sie jeden Montag und Donnerstag um 9 Uhr. Wer will, stößt sie zusätzlich manuell an.

Sie schaut dabei gründlich hin. Im Browser bedient sie die Live-App und klickt sich durch die wichtigsten Abläufe. Sie hält fest, wo die Darstellung hakt, wo die Bedienung Reibung erzeugt und wo die Barrierefreiheit Lücken hat. Ein Beispiel dafür sind Buttons, die nur ein Icon und kein Label haben.

Danach nimmt sie sich den Code vor. Sie hält die Implementierung gegen die Spec und die Komponenten gegen das Design-Dokument. Fehlende Ladezustände und Lücken in den Tests sucht sie ebenfalls. Zuletzt wertet sie zwei Wochen Nutzerfeedback auf wiederkehrende Muster aus.

Daraus ließe sich leicht eine lange Liste machen. Genau die macht sie nicht.

Höchstens drei Issues, und null ist in Ordnung

Diese Stelle solltet ihr übernehmen. Die Instruktionen ziehen eine harte Grenze und sagen das ohne Umschweife. Pro Lauf sind höchstens drei Issues erlaubt. Gibt es weniger als drei Verbesserungen, die einen Vorschlag wert sind, werden es entsprechend weniger. Findet sie nichts Sinnvolles, legt sie null Issues an und beendet den Lauf. In einer Zeile steht es wörtlich: „do not invent issues to fill a quota“. Gemeint ist: keine Issues erfinden, nur damit die Zahl stimmt.

Eine zweite Vorgabe kommt dazu. Jeder Vorschlag muss in einen einzigen Pull Request passen. Ein vages „improve onboarding“ (Onboarding verbessern) fällt damit raus. Gefragt ist eine konkrete, eng gefasste Änderung, die ein Builder in einem Anlauf abschließt. Die Vorschläge werden außerdem nach Risiko getrennt. Kleiner Feinschliff mit geringem Risiko kommt direkt ins Backlog. Alles mit hohem Risiko bekommt das Label needs-human und wartet auf eine Person.

Ehrgeiz, dosiert

Gerade diese Zurückhaltung ist das eigentliche Engineering. Ohne Deckel erzeugt eine Verbesserungsmaschine ein Backlog, mit dem keiner mehr etwas anfangen kann. Weil höchstens drei Issues erlaubt sind, muss die Automation eine Rangfolge bilden. Sie nimmt, was in diesem Lauf am meisten zählt, und verwirft den Rest. Ehrgeiz braucht eine Factory durchaus. Er braucht aber ein Maß, sonst flutet er die Linie.

Die komplette Automation steht in der Definition des Product Improver auf GitHub (öffnet in einem neuen Tab).

Was sorgt bei euch dafür, dass Verbesserungsideen, menschliche wie automatisierte, nicht schneller wachsen, als euer Team diese Woche ausliefern kann?

Weiterlesen

Die Artikel der Wissensbasis sind auf Englisch.

• The software-factory pattern →
• Agentic Software Factory: Advanced Team Training →