Ein Arbeitstag, von morgens bis zum Feierabend.

INSIGHTS · Ein Tag mit angajuu

Ein Tag im Entwicklungsteam

Was sich ändert, wenn eine Anforderung ankommt, aus der man wirklich bauen kann — und wie der Weg zurück zur Abdeckung aussieht.

Derselbe Dienstag, zwei Schreibtische weiter. Hier wird nicht mehr entschieden, was gebaut wird; hier wird gebaut. Der teure Teil dieses Tages ist trotzdem nicht das Tippen. Es sind die zehn Minuten, in denen jemand nicht weiß, was gemeint war — und die anderthalb Tage, die daraus werden, wenn er falsch rät und niemand es merkt.

Was folgt, ist ein Arbeitstag ohne Abstimmungstermin. Nicht, weil Termine schlecht wären, sondern weil die Fragen, aus denen sie entstehen, dort beantwortet sind, wo die Antwort stehen bleibt.

Ein Tag, drei Momente, an denen sich zeigt, ob die Ablage trägt.

09:00

Auf dem Board liegt ein Vorgang, den angajuu angelegt hat. Er trägt genau fünf Felder: Projekt, Titel, Beschreibung, Vorgangstyp und Priorität. Sonst nichts — keine Labels, keine Komponenten, kein Bearbeiter. Den Typ hat angajuu selbst gewählt, und zwar nach der Art der Anforderung: Aus einer Produktanforderung wird ein Epic, aus einer Kundenanforderung eine Story. Das ist keine Einstellung, die jemand vergessen haben könnte.

Wichtiger als das, was im Vorgang steht, ist das, was seitdem nicht passiert ist: Er wurde einmal angelegt und danach nie wieder angefasst. Lautet der Satz in angajuu heute anders als vor drei Wochen, steht in Jira weiter der alte. Der Tag beginnt deshalb mit einem Sprung zurück zur Quelle.

Für das Team ist das der eigentliche Unterschied. Kein „hast du kurz?“, kein Vorgang, der drei Tage nach dem Anlegen noch einmal umgeschrieben wurde, weil jemand nachgedacht hat. Der Satz stand fest, bevor er hier ankam — und deshalb kann man um neun Uhr einfach anfangen.

09:30

Die Frage kommt beim Lesen, wie immer. „Archiviert“ — heißt das aus der Liste verschwunden oder aus der Auswertung herausgerechnet? Für die Umsetzung ist das der Unterschied zwischen einem Kennzeichen und einer zweiten Abfrage. Vor einem Jahr wäre daraus eine Nachricht im Teamchat geworden und im schlechten Fall ein Termin am Donnerstag.

Heute sind es dreißig Sekunden. In der Seitenspalte der Produktanforderung stehen die Kundenanforderungen, die an ihr hängen. Er öffnet die erste und liest den Satz, den der Kunde selbst formuliert hat, mitsamt Quelle — also der Angabe, wer das verlangt hat — und dem Projekt, aus dem er stammt. Titel und Beschreibung stehen in beiden Sprachen; die deutsche Fassung ist hier die Originalfassung. Dort steht: „archiviert und aus der Monatsauswertung ausgenommen“. Frage beantwortet, ohne dass jemand gestört wurde.

Zwei Grenzen gehören dazu. Die Seitenspalte zeigt die verknüpften Anforderungen mit ihrem Titel; ob eine Verknüpfung bestätigt ist und wie viel sie abdeckt, steht dort nicht, sondern im Abdeckungsbereich der Verfeinerung. Und die Anforderung sagt dir nicht, wer ihren Text zuletzt geändert hat — das Feld dafür gibt es nicht. Der Verlauf hält Zustandswechsel und Übergaben fest, „Status geändert von … nach …“ oder den angelegten Jira-Vorgang; eine reine Textänderung hinterlässt dort keinen Eintrag. Das verschiebt die Frage: nicht „wer hat das geändert?“, sondern „in welchem Zustand ist dieser Satz?“. Der Zustand ist geführt, sein Wechsel eingetragen, und die Anforderungsseite bietet nur die Übergänge an, die von hier aus erlaubt sind.

Eine Sache bleibt offen — ob der Ausschluss auch für laufende Abonnements gilt. Also schreibt er die Frage als Kommentar an die Anforderung. Ein gewöhnlicher Kommentar löst nichts aus: Kein Modell antwortet, niemand bekommt eine Benachrichtigung, erst eine Erwähnung mit @ai oder @juujuu startet einen Auftrag. Die Frage bleibt dort stehen, wo sie hingehört — neben dem Satz, um den es geht.

11:00

Der Agent bekommt den Satz und die Grenze: was gebaut werden soll und was er nicht anfassen darf. Wie eine solche Vorlage aussehen muss, ist ein eigenes Thema und steht am Ende verlinkt. Interessanter ist hier die Stunde danach.

Was übergeben wird, entscheidet, was zurückkommt.

Um 11:40 liegen achthundert Zeilen vor ihm, und die Frage lautet nicht, ob der Code baut, sondern ob er tut, was der Kunde verlangt hat. Dafür nimmt er eine Liste, die er nicht selbst geschrieben hat; sie stammt aus dem Produktanforderungsdokument des Projekts: Einleitung, Umfang, Ziele, die Kundenanforderungen nach Priorität geordnet, und je Anforderung ein Abschnitt „Akzeptanztests“, für den das Modell zwei bis fünf Zeilen liefern soll: woran man erkennt, dass die Anforderung erfüllt ist.

Der Wert dieser Zeilen liegt in ihrem Zeitpunkt; sie entstehen aus der Kundenanforderung, in einem zweiten Modelldurchlauf, acht Anforderungen auf einmal — und zwar bevor die erste Zeile Code geschrieben ist. Eine Prüfliste, die im selben Atemzug entsteht wie die Umsetzung, prüft die Umsetzung gegen sich selbst. Diese hier kann sich der Umsetzung nicht mehr anpassen.

Auch hier die ehrliche Fassung. Die Kästchen vor den Zeilen sind Schriftzeichen, keine Kontrollfelder: nichts zum Anklicken, nichts, was gespeichert wird, wenn man sie liest. Die Liste hängt auch nicht an der Anforderung, sie liegt in genau einem Dokument. Erzeugt wird zweisprachig, ausgegeben wird in PDF wie Markdown nur die englische Hälfte; die deutsche siehst du ausschließlich in der Ansicht im Werkzeug. Und ohne hinterlegten Claude-Schlüssel entsteht dieses Dokument als einziges KI-Ergebnis überhaupt nicht — es bricht ab, statt leer zu bleiben.

Er liest die Zeilen also selbst, eine nach der anderen, gegen das, was zurückkam. Drei Punkte sind erfüllt, einer nicht: Der Agent hat das Archivieren gebaut, den Ausschluss aus der Auswertung nicht. Zwanzig Minuten Nacharbeit — und die zwanzig Minuten fallen heute an und nicht in der Demo.

Das ist die Stelle, an der sich Entwicklungsarbeit gerade verändert. Nicht weniger anspruchsvoll, nur anders anstrengend: Lesen statt Tippen, Urteilen statt Ausprobieren. Wer das ohne belastbare Vorlage tun muss, geht abends leer nach Hause — und weiß nicht genau, warum.

14:30

Zusammengeführt. Jetzt kommt der Teil, den Werkzeuge gern überspringen: Was stimmt jetzt an anderer Stelle, ohne dass es jemand von Hand nachträgt?

In Jira zieht er den Vorgang in die letzte Spalte — sein Board, seine Regeln. Was angajuu daraus macht, ist eng begrenzt und ab Werk sogar ausgeschaltet. Eingeschaltet fragt ein Dienst in festem Takt nach, standardmäßig alle 15 Minuten, und holt vier Dinge: Status, Auflösungsdatum, die am Vorgang eingetragene Version und ob diese Version freigegeben ist. Der Status läuft über eine Zuordnung je Produkt auf den Umsetzungsstand der Produktanforderung; einen Bildschirm für diese Zuordnung gibt es nicht, und was nicht zugeordnet ist, landet stillschweigend auf „In Bearbeitung“. Einen Zustand schreibt der Abgleich nie: „Verifiziert“ verweigert der Code ausdrücklich, weil Verifizieren ein menschliches Urteil ist. Und weicht Jira vom Plan ab, plant sich angajuu nicht selbst um — daraus wird eine Arbeitsliste für einen Menschen.

Sichtbar wird der Umsetzungsstand auf der Produktseite: vier Zähler — Geplant, In Bearbeitung, Umgesetzt, Verifiziert — und eine Spalte in der Tabelle darunter. Ob die Zusage an den Kunden erfüllt ist, sagt keiner davon. Das wird nicht vorab ausgerechnet, sondern gerechnet, wenn jemand fragt.

Genau deshalb passiert an diesem Nachmittag weniger, als „fertig“ vermuten lässt. Die bestätigte Verknüpfung trägt den Grad „teilweise“ und zählt 50; die Kundenanforderung bleibt offen, obwohl der Code läuft. Das ist richtig so: Gefragt war nach Archivieren und Auswertung, gebaut ist das Archivieren.

Abgedeckt ist nichts, woran man sich erinnert. Es ist eine Zahl, die jedes Mal neu entsteht.

AnforderungStatusDeckung
Sammelrechnung je QuartalTEILWEISE
Mahnstufen eskalierenLÜCKE
DATEV-ExportERFÜLLT
Kundenportal-LoginUNBEWERTET
Deckungsgrad, wie ihn ein Projekt zeigt: erfüllt, teilweise, offen — und ehrlich unbewertet.

16:45

Um 16:45 sieht die Product Ownerin, was sich seit dem Vormittag geändert hat — ohne zu fragen und ohne dass ihr jemand etwas geschickt hätte. Auf der Berichtsseite, einer einzigen scrollenden Seite mit vier Karten, steht die Abdeckung in Prozent in der Lückenmatrix; der Lückenbericht daneben geht als PDF oder Excel hinaus und listet die Kundenanforderungen, hinter denen keine einzige bestätigte Verknüpfung steht. Die Anforderungsliste hat zusätzlich einen Filter für abgedeckt und nicht abgedeckt — der fragt allerdings nur, ob überhaupt eine bestätigte Verknüpfung existiert, nicht wie viel sie deckt.

Die Anforderung von heute steht dort weiter offen, bei 50 Prozent. Das ist kein Streitpunkt mehr, sondern eine Zeile: eine kleine, klare Frage für morgen früh statt eines Missverständnisses für den Monat.

Niemand fragt „ist das fertig?“, wenn alle dieselbe Antwort sehen.

Eines hat angajuu an diesem Tag nirgends gesagt: wer woran arbeitet. Ein Feld für den Bearbeiter gibt es an einer Anforderung nicht, an keiner Stelle des Modells, und die Startseite schreibt genau das in einer eigenen Zeile hin, statt eine Zuordnung zu erfinden. Das weiß dein Board. angajuu weiß, welcher Satz gilt, in welchem Zustand er ist und wie viel von ihm gedeckt ist.

Ein Tag ohne Abstimmungstermin ist kein Sparprogramm. Er ist das, was übrig bleibt, wenn niemand mehr Zeit darauf verwenden muss, den Stand herzustellen, über den gleich gesprochen wird.

Warum eine Vorlage, aus der ein Agent bauen kann, vor dem Prompt entsteht und nicht in ihm, steht in KI-getriebene Entwicklung beginnt vor dem Prompt. Und die Disziplin hinter der zweiten Frage dieses Tages — nicht nur „läuft es?“, sondern „ist es das, was verlangt war?“ — steht in VSDD — Verified Spec-Driven Development.

Schreib den ersten Satz.

Kostenlos für 5 Nutzer, 5 Projekte, 200 Anforderungen.

Kostenlos starten