Software Factory
Was eine Software Factory ist und welche Automatisierungen sie betreiben: das Backlog planen, Features bauen, Bugs beheben, Pull Requests begleiten, Incidents behandeln und über die Arbeit berichten.
- 13 Artikel, die neuesten zuerst
- Das Issue-Label ist das Protokoll der Agenten Auf software-factory.dev beschreibt der Skill development-workflow die Factory aus ihrer eigenen Sicht. Er zeigt, dass keine Automation eine andere aufruft: Sie stimmen sich über Labels auf Issues ab.
- Automatische Statusberichte sind nur so ehrlich wie ihr Prompt Auf software-factory.dev bleibt der automatische Wochenrückblick ehrlich, weil die Ehrlichkeit im Prompt steht: Der Challenges-Abschnitt macht ihn authentisch, und eine Zahl, die keiner erfasst hat, muss auch so benannt werden.
- Wer die Factory prüft, darf das eigene Protokoll nicht umschreiben Auf software-factory.dev nimmt der Automation Auditor jede andere Automation am Band unter die Lupe. Seine nützlichste Regel: Das Audit der letzten Woche darf er nie überschreiben.
- Eskalierte Arbeit braucht einen Weg zurück aufs Band Auf software-factory.dev bringt die kleinste Automation der Factory eskalierte Issues zurück aufs Band, sobald ein Mensch geantwortet hat. Auch der Weg vom Menschen zurück zur Maschine braucht einen eigenen Owner.
- Die Stale-Uhr nach der Zykluszeit eurer Agenten stellen Beim Stale-Issue Reviewer auf software-factory.dev gilt Arbeit nach drei Stunden als liegengeblieben, nicht nach drei Tagen. Denn wer eine Linie überwacht, braucht eine Uhr, die in ihrem Takt läuft.
- Der PR Shepherd rührt nur Konflikte an, die er versteht Der PR Shepherd der Factory auf software-factory.dev rebased Pull Requests mit Konflikten, semantische Konflikte überlässt er aber einem Menschen. Schwer wird Automatisierung dort, wo ihr festlegen müsst, wo ihre Kompetenz endet.
- Was ist eine Software Factory? Eine Software Factory koordiniert Agenten, Kontext, deterministische Gates und menschliche Entscheidungen auf dem Weg von der Absicht bis in die Produktion.
- Eine Bugfix-Automation darf nie stillschweigend aufhören Die Bugfix-Automation der Factory auf software-factory.dev beendet jeden Lauf auf einem von zwei Wegen: mit einem Fix oder mit einer Eskalation an einen Menschen. Ehrliches Scheitern muss man entwerfen.
- Bevor der Feature Builder baut, sucht er nach offenen Bugs Die Build-Automation von software-factory.dev beginnt mit einem Pre-Flight-Check. Liegt ein Bug der Priorität 1 oder 2 ohne Bearbeiter herum, ruht jede neue Feature-Arbeit.
- Wer Verbesserungen automatisiert, muss den Ehrgeiz deckeln Der Product Improver der Factory auf software-factory.dev legt höchstens drei Issues pro Lauf an. Findet er nichts, das sich lohnt, legt er gar keines an.
- Incident und Regel im selben Commit beheben Der Incident Responder der Factory auf software-factory.dev schreibt die fehlende Regel ins Konventionsdokument, im selben Commit wie den Fix. So steht die Regel, die den Bug verhindert hätte, schon vor der nächsten Änderung bereit.
- Erst Feedback und Nutzungsdaten abgleichen, dann Arbeit daraus machen Der Feedback Digest der Factory auf software-factory.dev legt neues Feedback neben sieben Tage Nutzungsdaten. Ein Issue entsteht nur, wenn die Daten den Wunsch belegen.
- Der Feature Planner füllt sein Backlog selbst, mit einem Menschen am Gate Läuft die Linie leer, schreibt die Triage-Automation der Factory auf software-factory.dev ihr Backlog selbst. Was riskant ist, geht vorher über eine Person.