Zusammenarbeit im Entwicklungsteam

Zusammenarbeit im Entwicklungsteam

0:00 Das letzte Modul verlässt die Einzelperson und wendet sich dem Team zu. Denn alles, was Sie in den vergangenen drei Tagen gelernt haben, wirkt nur begrenzt, solange es privat bleibt. Und es gibt einen Befund, der dieses Modul trägt und den ich für den ehrlichsten des ganzen Seminars halte: KI verstärkt, was ein Team ohnehin ist.

0:19 Sie vergrößert die Stärken leistungsfähiger Organisationen und die Funktionsstörungen der übrigen. Werkzeuge lösen kein Teamproblem — sie machen es größer.

Zusammenarbeit im Entwicklungsteam

0:28 Wir schließen den dritten Tag und damit das Seminar ab. Dieses Modul bündelt, was aus den einzelnen Techniken eine Teampraxis macht: gemeinsame Regeln, eine Definition of Done, Nachvollziehbarkeit, Review-Kapazität, Referenzlösungen, Entscheidungsnotizen und Metriken. Und am Ende steht die Abschlussarbeit — eine vollständige Änderung am Fahrtenbuch, bei der bewertet wird, wie Sie vorgehen und nicht, wie viel Code entsteht.

Gemeinsame Regeln statt privater Prompt-Sammlungen

0:53 Fangen wir dort an, wo fast jedes Team anfängt: bei der individuellen Nutzung. Jeder probiert aus, jeder entwickelt Gewohnheiten, jeder sammelt private Textbausteine. Das ist als Anfang völlig richtig und sollte auch nicht übersprungen werden. Als Dauerzustand wird es teuer, und zwar auf drei Arten, die sich schleichend aufbauen.

1:14 Der Übergang zum Team bedeutet, das Wirksame aus den privaten Sammlungen ins Repository zu heben: Projektanweisungen, die für alle gelten, gemeinsame Auftragsvorlagen, verbindliche Checklisten. Und beachten Sie das Wort „das Wirksame" — nicht alles Gesammelte. Es gilt derselbe Grundsatz wie bei Anweisungsdateien in Modul sechs: wenig, überprüfbar, begründet.

1:35 Eine Sammlung von dreißig Regeln, die niemand kennt, ist schlechter als fünf, die alle anwenden — und das gilt für Teamregeln noch stärker als für Anweisungsdateien, weil hier auch die Zustimmung der Kollegen dazukommt. Drei Kosten, die sich langsam aufbauen und deshalb selten zugeordnet werden. Erstens werden die Ergebnisse unvorhersehbar, weil dieselbe Aufgabe je nach Bearbeiter anders behandelt wird — das merkt man erst im Review, und dann sieht es nach einem Personenproblem aus.

2:03 Zweitens bleiben Erfahrungen stecken, weil niemand mitbekommt, was funktioniert hat. Und drittens hängt das Wissen an Personen und geht mit ihnen. Der vierte Punkt ist die Konsequenz und zugleich die Warnung vor der Überkorrektur. Der erste Punkt ist mir wichtig, weil er in die Gegenrichtung warnt: Überspringen Sie die private Phase nicht.

2:23 Sie ist der richtige Anfang, und wer sofort zentralisiert, standardisiert Unwissen. Der zweite ist der eigentliche Fehler — sie zum Dauerzustand machen. Der dritte ist die Überkorrektur: alles Gesammelte ins Repository heben statt nur das Wirksame. Und der vierte betrifft die Akzeptanz: Regeln ohne Begründung werden umgangen, und zwar von den Fähigsten zuerst.

Definition of Done für KI-gestützte Änderungen

2:45 Kommen wir zu einer gemeinsamen Antwort auf die Frage, wann eine Änderung fertig ist. Der Nutzen liegt weniger in der Liste selbst als darin, dass sie Auseinandersetzungen im Review vorwegnimmt. Für KI-gestützte Arbeit kommen dabei Punkte hinzu, die früher nicht nötig waren — und einer davon ist besonders teuer. Eine gemeinsame Definition verhindert die meisten Diskussionen im Review, weil sie vorher geführt wurden.

3:10 Das ist der eigentliche Wert: nicht die Kontrolle, sondern die Entlastung des Einzelfalls. Für KI-gestützte Arbeit sind einige Punkte dazugekommen, die früher schlicht nicht nötig waren — weil niemand Code abgab, den er nicht selbst geschrieben hatte. Sehen wir uns die Liste an, und achten Sie dabei auf die zweite Spalte. Und genau diese neuen Punkte sind es, die im Alltag am ehesten übergangen werden.

3:34 Sechs Punkte, und die zweite Spalte sortiert sie nach Automatisierbarkeit. Drei lassen sich ganz oder teilweise automatisieren — die automatischen Prüfungen, neue Abhängigkeiten, teilweise auch die Testfrage. Zwei nicht: Der Diff wurde vollständig gelesen, und die Annahmen sind festgehalten. Und jetzt der Punkt, auf den es ankommt: Genau diese beiden kosten Zeit und Nachdenken.

3:56 Deshalb fallen sie unter Druck als erste weg — nicht aus Nachlässigkeit, sondern weil sie die einzigen sind, bei denen das Weglassen überhaupt Zeit spart. Der erste Punkt ist der häufigste Selbstbetrug: die Zusammenfassung lesen und es als Diff-Review verbuchen. Der zweite ist ein Organisationsproblem — die Punkte aufschreiben, ohne sie im Review tatsächlich abzufragen. Dann steht die Liste im Wiki und niemand handelt danach.

4:22 Der dritte ist die bequeme Auswahl: nur die automatisierbaren Punkte ernst nehmen. Und der vierte ist der aus Modul fünf bekannte: die Annahmen nicht festhalten, weil sie beim Schreiben selbstverständlich wirkten. In drei Monaten sind sie es nicht mehr.

Nachvollziehbarkeit von Agentenbeiträgen

4:37 Jetzt zu einer Frage, die schnell heikel wird, wenn man sie falsch rahmt: Soll erkennbar bleiben, ob eine Änderung mit Agentenunterstützung entstanden ist? Meine Antwort ist ja — aber ausdrücklich nicht zur Bewertung. Sondern weil es die Fehlersuche verändert. Die richtige Rahmung entscheidet hier darüber, ob die Maßnahme im Team überlebt.

4:57 Stellen Sie sich vor, Sie finden Monate später einen ungewöhnlichen Codeabschnitt. Sie gehen völlig anders vor, wenn Sie wissen, dass hier ein Auftrag samt Annahmen dahintersteckte, den man nachlesen kann. Dann suchen Sie nicht nach der Absicht — Sie schlagen sie nach. Ohne diese Information bleibt Ihnen nur die Rekonstruktion aus dem Code selbst, und die führt bei ungewöhnlichen Stellen regelmäßig in die Irre.

5:21 Es geht also um Arbeitsersparnis, nicht um Zuschreibung. Und die Mittel dafür sind erfreulich schlicht: eine Kennzeichnung in der Commit-Nachricht, ein Hinweis in der Änderungsbeschreibung, der ursprüngliche Auftrag im Ticket. Nichts davon verlangt ein neues Werkzeug. Wichtiger als die Form ist ohnehin, dass die Absicht erhalten bleibt und nicht nur das Ergebnis.

5:41 Und genau darin liegt die eigentliche Gefahr agentischer Arbeit für die Wartbarkeit: Code entsteht in Minuten, seine Begründung existiert nur in einem Chatverlauf — und der ist morgen geschlossen. Der erste Punkt ist der, vor dem ich gewarnt habe: die Kennzeichnung als Bewertung verstehen und sie deshalb weglassen. Wenn sie im Team als Qualitätsurteil gelesen wird, verschwindet sie innerhalb weniger Wochen.

6:04 Der zweite ist der inhaltliche — nur das Ergebnis sichern und die Absicht im Chatverlauf lassen. Der dritte ist der Überkorrektur-Fehler: aufwendige Formate einführen, die nach zwei Wochen niemand mehr pflegt. Und der vierte ist schlicht Selbstüberschätzung: annehmen, man werde sich in drei Monaten schon erinnern.

Review-Kapazität als Engpass

6:23 Jetzt zu dem Thema, das sich durch das ganze Seminar zieht, hier aber als Teamfrage auftritt. Wenn die Erzeugung schneller wird und die Prüfung nicht, staut sich die Arbeit vor dem Review. Und das ist kein Ärgernis, das man aushalten muss — es ist eine Steuerungsfrage mit drei Hebeln. Drei Hebel wirken, und alle drei fühlen sich zunächst falsch an. Das ist der Grund, warum sie so selten gezogen werden. Die Menge begrenzen fühlt sich nach Bremsen an.

6:50 Die Größe begrenzen fühlt sich nach Mehrarbeit an. Und automatisieren fühlt sich nach Vorabinvestition an, für die gerade keine Zeit ist. Alle drei zahlen sich trotzdem aus — und einer davon hat sogar Zahlen hinter sich, was in diesem Feld nicht selbstverständlich ist. Sehen Sie sich die rechte Spalte an, sie erklärt den Widerstand. Menge begrenzen — weniger gleichzeitig offene Änderungen bedeuten kürzere Wartezeiten und gründlichere Reviews.

7:16 Es fühlt sich nach Bremsen an und ist keins. Größe begrenzen — fünf kleine Änderungen werden zusammen schneller und gründlicher geprüft als eine große mit demselben Inhalt. Das ist der Hebel mit den Zahlen: Die Trefferquote fällt jenseits von vierhundert Zeilen und nach sechzig bis neunzig Minuten ab. Und automatisieren — damit die menschliche Aufmerksamkeit für das übrig bleibt, was nur ein Mensch beurteilen kann.

7:41 Die Konsequenz ist unangenehm klar: Reviews, die formal stattfinden und nichts mehr finden. Das ist der schlechteste aller Zustände, weil er Sicherheit vortäuscht — schlimmer als gar kein Review, bei dem wenigstens jeder weiß, dass nicht geprüft wurde. Sie erinnern sich an dieselbe Logik bei der unzuverlässigen Pipeline aus Modul acht. Und der Grund dafür ist messbar: Die Aufmerksamkeit fällt mit dem Umfang überproportional ab.

8:06 Automatisierbares von Hand zu prüfen verbraucht genau die knappe Ressource, die für Fachlichkeit, Angemessenheit und Risiko gebraucht wird.

Golden Paths und Referenzlösungen

8:14 Kommen wir zu einem Mittel, das Sie aus Modul sechs schon kennen — dort als Kontextfrage, hier als Teampraxis. Für jedes wiederkehrende Muster lohnt sich eine bewusst gepflegte Referenzstelle. Der Nutzen ist doppelt, und die zweite Hälfte davon ist neu. Der Aufwand dafür ist überschaubar, der Nutzen fällt bei jedem Auftrag erneut an.

8:35 So wird bei uns eine Prüfregel gebaut, so ein Datenzugriff, so ein Test für einen Anwendungsfall. Der erste Nutzen ist alt: Menschen haben einen Anhaltspunkt, statt jedes Mal neu zu entscheiden. Der zweite ist neu und in der Praxis inzwischen der gewichtigere: Agenten bekommen ein Vorbild, auf das sich im Auftrag zeigen lässt.

8:54 Und Zeigen ist, wie wir in Modul sechs gesehen haben, wirksamer als jede Beschreibung — weil ein Beispiel vollständig und widerspruchsfrei ist. Fünf Punkte, und der Aufwand steckt in den letzten dreien. Je Muster genau eine Stelle, nicht mehrere — sonst weiß niemand, welche gilt. Ausdrücklich als Referenz kennzeichnen. Ändert sich das Muster, zieht die Referenz mit. Und die Zahl klein halten, denn jede zusätzliche will gepflegt werden.

9:21 Der fünfte Punkt ist die Warnung: Eine ungepflegte Referenz wird zur Quelle veralteter Kopien — und zwar in Serie, weil jetzt auch ein Agent darauf zeigt. Der erste Punkt ist der gefährlichste, weil er das Mittel ins Gegenteil verkehrt: auf eine Stelle zeigen, die niemand gepflegt hat. Der zweite ist die gut gemeinte Dopplung — das Muster zusätzlich beschreiben, und dann laufen Beschreibung und Code auseinander.

9:47 Der dritte betrifft das Maß: zu viele Referenzen, keine gepflegt. Und der vierte ist der Irrtum, den ich am häufigsten sehe: darauf vertrauen, dass gute Beispiele sich von selbst durchsetzen. Ohne Kennzeichnung tun sie das nicht.

Entscheidungen sichern statt Chatverläufe

10:01 Jetzt zu einer Frage, die durch agentische Arbeit deutlich an Gewicht gewonnen hat: Wo bleibt eigentlich das Warum? Denn der Chatverlauf, in dem eine Entscheidung fiel, ist kein Wissensspeicher — auch wenn er sich in dem Moment so anfühlt. Und dieser Verlust fällt erst auf, wenn er nicht mehr zu beheben ist. Warum taugt ein Chatverlauf nicht? Er ist lang und unstrukturiert.

10:22 Er enthält Verworfenes gleichberechtigt neben Übernommenem — man sieht dem Text nicht an, welcher Vorschlag am Ende gewonnen hat. Und er lässt sich nicht durchsuchen, wenn man die richtige Frage nicht schon kennt. Was erhalten bleiben muss, ist etwas anderes und viel kleineres: die Entscheidung und ihre Begründung. Warum ist die Abrechnung so geschnitten?

10:43 Warum diese Bibliothek und nicht jene? Das bewährte Format ist erfreulich schlank: Kontext, Entscheidung, Status, Konsequenzen — eine Seite. Es stammt von Michael Nygard aus dem Jahr 2011 und hat sich seither kaum verändert, was für ein Format spricht. Zwei Zeilen möchte ich hervorheben. Der Status erlaubt es, eine Entscheidung später als abgelöst zu markieren, statt sie zu löschen — die Historie bleibt lesbar.

11:09 Und bei den Konsequenzen ist Nygard ausdrücklich: Dort gehören alle Folgen hinein, nicht nur die positiven. Eine Notiz, die nur Vorteile aufzählt, ist eine Werbebroschüre. Vier Punkte, und sie bauen aufeinander auf. Es werden mehr Entscheidungen getroffen, und zwar schneller. Wer sie getroffen hat, weiß in drei Monaten nicht mehr, wie gründlich er den Vorschlag geprüft hat — das ist keine Schwäche, das ist normal.

11:35 Code entsteht in Minuten, seine Begründung existiert nur in einem Chatverlauf. Und der ist morgen geschlossen. Das ist die eigentliche Wartbarkeitsgefahr agentischer Arbeit — nicht die Codequalität, sondern der Verlust der Begründung.

Metriken mit Augenmaß

11:49 Jetzt zu einem Wunsch, der berechtigt ist und dessen Weg schmal: den Nutzen messen. Die naheliegenden Zahlen sind dabei die schädlichsten — und wir haben dasselbe Muster in diesem Seminar bereits zweimal gesehen. Es lohnt sich, das ausdrücklich als Muster zu benennen. Wer es einmal erkannt hat, erkennt es künftig sofort wieder.

12:09 Erzeugte Zeilen, Annahmequote von Vorschlägen, Anteil generierten Codes — diese Zahlen sind leicht zu erheben, und genau das macht sie gefährlich. Sie messen Aktivität, nicht Wert. Und sobald sie Ziel werden, werden sie erreicht: mit mehr Code, nicht mit besserer Software. Ein Team, das am Anteil generierten Codes gemessen wird, wird diesen Anteil steigern.

12:31 Es wird dafür nicht mehr KI einsetzen, wo es hilft, sondern auch dort, wo es schadet. Die Tabelle sortiert nach dem, was gemessen wird. Oben Aktivität — erzeugte Zeilen, Annahmequote. Als Ziel schädlich. Darunter drei Zahlen, die am Ergebnis hängen: Dauer von der Idee bis zur Produktion, Nacharbeit nach der Abnahme, Reviewzeit und Fundrate.

12:52 Diese sind brauchbar, und sie entsprechen weitgehend den bekannten DORA-Kennzahlen. Aber lesen Sie die Fußzeile: Auch die brauchbaren taugen als Gesprächsanlass im Team, nicht als Steuerungsgröße von außen. Sobald sie von außen vorgegeben werden, werden auch sie erreicht statt erarbeitet. Und hier möchte ich das Muster ausdrücklich benennen, weil es dreimal aufgetreten ist. Wird ein Maß zum Ziel, hört es auf, ein gutes Maß zu sein.

13:20 Bei der Abdeckungsquote in Modul acht war es so. Bei der Testmenge in Modul sieben ebenfalls. Und jetzt bei den KI-Metriken. Es ist immer dieselbe Mechanik, und wer sie einmal erkannt hat, sieht sie überall. Der Schlusssatz gilt für alle drei: Keine dieser Zahlen ersetzt die schlichte Frage, ob die Arbeit besser geworden ist.

Regeln pflegen und vereinfachen

13:40 Zum letzten fachlichen Kapitel, und es schließt einen Kreis zurück zu Modul sechs. Jede Sammlung von Regeln wächst, wenn niemand sie beschneidet — und wachsende Regelwerke werden zuverlässig ignoriert. Das gilt für Menschen und, wie wir gemessen haben, auch für Maschinen. Beide Argumente zeigen dabei in dieselbe Richtung, und das macht die Empfehlung belastbar.

14:02 Bemerkenswert finde ich, dass hier beide Seiten in dieselbe Richtung zeigen. Für Menschen ist es Erfahrung: Niemand liest dreißig Regeln, und wer es doch tut, behält sie nicht. Für Maschinen ist es gemessen: Mehr Kontext senkt die Trefferquote, über achtzehn Modelle hinweg. Wenn zwei so verschiedene Argumente zum selben Schluss führen, ist der Schluss meist tragfähig. Also: in regelmäßigen Abständen streichen statt ergänzen.

14:28 Und zwar nicht einmalig, sondern in festen Abständen — sonst wächst die Sammlung wieder zu. Drei Fragen zum Streichen, und dann eine vierte Sache, die in die andere Richtung geht. Welche Regel hat im letzten Vierteljahr tatsächlich etwas verhindert? Welche wird ohnehin von einer Maschine erzwungen und muss nicht mehr dastehen? Welche beschreibt einen Zustand, den es nicht mehr gibt?

14:51 Und dann die Lernschleife: die kurze Rückschau auf misslungene Agentenläufe. Fast immer zeigt sich dabei, dass nicht das Werkzeug versagt hat, sondern etwas im Auftrag oder im Kontext gefehlt hat. Genau diese Lücke ist die nächste Regel wert — und sie ersetzt oft zwei alte. Der erste Punkt ist die Wachstumsdynamik: nur ergänzen und nie streichen. Eine Datei, die nur wächst, ist ein Warnzeichen — unabhängig davon, wie gut die einzelnen Regeln sind.

15:18 Der zweite ist die Dopplung mit den Maschinen. Der dritte ist der aus meiner Sicht folgenreichste: Nach einem misslungenen Lauf das Werkzeug tauschen statt den Auftrag zu prüfen. Damit verlieren Sie die Lernschleife. Und der vierte: die Rückschau ausfallen lassen, weil der Lauf ja verworfen wurde — gerade dann lohnt sie sich.

Abschlussarbeit: Eine vollständige Änderung

15:37 Damit zur Abschlussarbeit. Sie bearbeiten eine realistische Änderung am Fahrtenbuch, und zwar mit allem, was Sie in drei Tagen gelernt haben. Die Aufgabe kommt bewusst unvollständig, der Bestand ist nicht durchweg sauber, und mindestens ein Risiko ist versteckt. Also so, wie es im Alltag ist. Damit schließt sich der Kreis zu Modul eins, wo wir dieselbe Aufgabe nur verteilt haben.

16:01 Der Maßstab ist ausdrücklich nicht die Menge des erzeugten Codes. Bewertet werden die Qualität des Vorgehens und die Belastbarkeit der Nachweise. Also: Sind die Nicht-Ziele benannt? Liegt ein Plan vor der ersten Codezeile? Sind die Annahmen festgehalten? Wurde der Diff gelesen und nicht die Zusammenfassung? Und finden Sie das versteckte Qualitäts- oder Sicherheitsrisiko? Wer es findet, hat die drei Tage verstanden — denn es liegt genau dort, wo wir gelernt haben hinzusehen.

16:31 Der Weg ist der neunstufige Zyklus aus Modul fünf, hier auf fünf Zeilen zusammengefasst. Klären und analysieren, Kriterien und Plan, Tests und Umsetzung, automatische Prüfungen und Review, dann beheben oder verwerfen und dokumentieren. Beachten Sie die Formulierung im letzten Schritt: beheben oder verwerfen. Das Verwerfen ist eine zulässige und manchmal die richtige Antwort — und wer sie begründet wählt, hat aus Modul neun das Wichtigste mitgenommen.

16:58 Dokumentieren Sie am Ende Ergebnis, Annahmen und offene Risiken — das ist der Nachweis, der zählt.

Was bleibt

17:04 Vier Sätze zum Schluss. Eine KI-Ausgabe ist ein Vorschlag, kein Beleg — die Prüfung bleibt beim Menschen. Clean Code dient vier Zielen, und Regeln ohne Ziel sind Ritual. Was maschinell prüfbar ist, gehört nicht in Prosa und nicht in den Review. Und kleine Änderungen sind nicht Stil, sondern die Bedingung für prüfbare Arbeit.

17:25 Wenn Sie diese vier mitnehmen, haben Sie das Gerüst. Alles andere lässt sich daraus ableiten — und das Übrige lernt man ohnehin nur am eigenen Projekt. Vielen Dank.