Produktives Denken (Productive Thinking)

Produktives Denken

Ermöglicht eine strukturierte Design-Sitzung mit Tim Hursons Produktivem Denken-Modell und optional die Erstellung eines RFCs daraus.

Eingabe

$ARGUMENTS

• Wenn die Eingabe mit rfc beginnt, wird der RFC-Modus ausgeführt. Alles danach ist ein optionaler Titel oder Ausgabepfad.
• Andernfalls wird der interaktive Modus ausgeführt, wobei die Eingabe als Problemstellung behandelt wird. Ist sie leer, bitten Sie den Benutzer, das Problem in ein oder zwei Sätzen zu beschreiben, bevor Sie etwas anderes tun.

So wird die Sitzung durchgeführt

• Alles im Code verankern. Vor jedem Schritt relevante Dateien, Schemata, Konfigurationen und Dokumentationen durchsuchen und lesen, und Pfade zitieren, wenn Sie darauf zurückgreifen. Der Wert dieser Sitzung gegenüber einem Whiteboard-Chat liegt darin, dass die Schlussfolgerungen auf dem tatsächlichen Systemverhalten beruhen – also überprüfen statt anzunehmen. Für breite Abfragen über viele Dateien hinweg delegieren Sie an einen Explore-Subagenten, damit der Kontext der Sitzung auf die Diskussion fokussiert bleibt.
• Die Last für den Benutzer gering halten. Pro Durchgang höchstens 5 Fragen stellen und diese mit eigenen Antwortvorschlägen auf Basis Ihrer Recherchen kombinieren, damit der Benutzer mit „ja, weitgehend, aber …“ antworten kann, statt von Null anfangen zu müssen.
• Ein Schritt pro Durchgang. Jeden Schritt mit einer Überschrift wie Schritt 2 von 6 — Was ist Erfolg? beginnen, den Schritt durchführen, dann anhalten und warten. Erst fortfahren, wenn der Benutzer bereit ist; Schritte können übersprungen, wiederholt oder zwischen ihnen gewechselt werden.
• Eine laufende Notizdatei führen. Nach jedem Schritt das vereinbarte Ergebnis an <rfc-dir>/<slug>.notes.md anhängen (<rfc-dir> wie im RFC-Modus, Schritt 3, wählen). Lange Sitzungen werden später komprimiert oder fortgesetzt; die Notizdatei ermöglicht es dem RFC-Modus oder einer neuen Sitzung, ohne Verlust von Entscheidungen anzuknüpfen. Teilen Sie dem Benutzer beim ersten Erstellen mit, wo sie sich befindet.

Die sechs Schritte

1. Was ist los?

Ziel: gemeinsames Verständnis der aktuellen Realität und der angestrebten Zukunft. Vorhandene Implementierungen, Aufrufstellen, Datenmodelle und die aktuelle Git-Historie der betroffenen Bereiche untersuchen. Abdecken: den Schmerzpunkt oder Engpass (mit Belegen wie Fehlern, Metriken oder Code), die betroffenen Module und Dienste, wer betroffen ist und wie „gelöst“ aussieht.

2. Was ist Erfolg? (DRIVE)

Ziel: Kriterien, an denen jede Option gemessen wird. Einen Entwurf aus Schritt 1 vorschlagen und vom Benutzer korrigieren lassen.

• Do (Tun): Was die Lösung tun muss
• Restrictions (Einschränkungen): harte Randbedingungen (Abwärtskompatibilität, Leistungsbudgets, Stack, Compliance)
• Investment (Aufwand): Zeit, Personen und Komplexität, die das Team zu investieren bereit ist
• Values (Werte): Ingenieurprinzipien, die bei Gleichstand entscheiden (Einfachheit, Testbarkeit, …)
• Essential outcomes (Wesentliche Ergebnisse): nicht verhandelbare Resultate, möglichst messbar

Auch explizite Nicht-Ziele festhalten.

3. Was ist die Frage?

2–3 „Wie könnten wir …“-Fragen vorschlagen, die die Herausforderung unterschiedlich einrahmen, z. B. eine enge und eine, die eine Annahme aus Schritt 1 hinterfragt. Der Benutzer wählt eine aus oder formuliert sie um; sie wird zur Problemstellung für den Rest der Sitzung.

4. Antworten generieren

2–3 wirklich unterschiedliche, im Codebestand verankerte Ansätze vorschlagen – keine Variationen einer Idee. Für jeden: eine kurze Skizze, die davon berührten Dateien oder Module und das Hauptrisiko. In diesem Schritt keine Bewertung vornehmen und den Benutzer zu eigenen Ideen einladen.

5. Die Lösung schmieden

Jeden Ansatz anhand von DRIVE bewerten (eine kleine Tabelle eignet sich gut), einen empfehlen und den dabei in Kauf genommenen Kompromiss benennen. Dann absichern: Fehlermodi, Randfälle, Migrationsbedenken, offene Fragen. Festhalten, warum die anderen Optionen verloren haben – das wird „Alternativen, die in Betracht gezogen wurden“.

6. Ressourcen abstimmen

Sich auf die Lieferform verständigen – nicht einzelne Tickets: Phasen oder Meilensteine und was jede demonstrierbar macht, das riskanteste zuerst beweisen, Feature-Flag- und Migrationsstrategie, Teststrategie, Rollout und Rollback sowie Überwachungsumfang. Die detaillierte Aufteilung in Tickets erfolgt später mit /task-breakdown, das auf dem RFC aufbaut. Abschließend anbieten, den RFC zu generieren.

RFC-Modus

1. Finden der Sitzung: das bisherige Gespräch plus die Notizdatei verwenden, falls vorhanden. Gibt es überhaupt keine Sitzung, dies mitteilen und anbieten, eine zu starten: nach der Problemstellung fragen und mit Schritt 1 beginnen.
2. Fehlen Schritte, auflisten, welche, und fragen, ob sie jetzt nachgeholt oder der RFC mit diesen Abschnitten als TBD (noch offen) markiert werden soll. Keine Entscheidungen erfinden, die der Benutzer nicht getroffen hat.
3. Ausgabeort wählen. RFCs, Notizen und Aufgaben-Dateien sind lokale Arbeitsdokumente des Entwicklers: standardmäßig ungetrackt, nicht mit dem Code committet. Nach einem vorhandenen lokalen, git-ignorierten Ordner dafür suchen (.gitignore und .git/info/exclude prüfen) und dessen Namenskonvention übernehmen. Gibt es keinen, .rfcs/YYYY-MM-DD-<slug>.md vorschlagen und .rfcs/ zu .git/info/exclude hinzufügen, was lokal ignoriert wird, ohne die .gitignore des Repos zu ändern. Einen getrackten Ordner wie docs/rfcs/ nur verwenden, wenn der Benutzer angibt, dass das Team RFCs committed.
4. Den RFC mit templates/rfc.md schreiben, jeden Abschnitt aus der Sitzung füllen und Codebestandsbezüge mit Dateipfaden versehen.
5. Dem Benutzer den Pfad mitteilen und alle TBD-Abschnitte und offenen Fragen auflisten.
6. Den nächsten Schritt anbieten: /task-breakdown <rfc-path>, um den RFC in Tickets mit 1 Story Point umzuwandeln, die das Team aufnehmen kann.