Thema: process
-
DACI und RACI für technische Entscheidungen: eine genehmigende Person, benannte Mitwirkende
DACI benennt eine treibende Person, die die Entscheidung vorantreibt, eine einzige genehmigende Person, die sie trifft, Mitwirkende, die eine Stimme, aber kein Stimmrecht haben, sowie informierte Parteien, die vom Ergebnis erfahren; RACI weist Aufgaben die Rollen verantwortlich, rechenschaftspflichtig, konsultiert und informiert zu. Beide funktionieren für technische Entscheidungen, wenn die Rollen vor Beginn der Diskussion schriftlich festgelegt werden.
-
Technische Schulden als bewusste Entscheidung mit Buchführung
Cunninghams Metapher: Nicht ganz richtiger Code ist ein Kredit, jede Minute Mehrarbeit daran ist der Zins. Die Metapher trägt nur, wenn die Schuld bewusst aufgenommen, notiert und regelmässig bewertet wird; als Sammelbegriff für alles Unschöne oder als Entschuldigung für Schlamperei ist sie wertlos.
-
Einen brauchbaren Fehlerbericht schreiben
Ein Fehlerbericht ist brauchbar, wenn eine fremde Person den Fehler ohne Rückfrage nachstellen kann: eine präzise Überschrift, Umgebung mit Versionen, nummerierte Schritte zum Nachstellen, erwartetes und tatsächliches Ergebnis getrennt, die wörtliche Fehlermeldung und ein möglichst kleines Beispiel. Vermutungen zur Ursache stehen in einem eigenen Abschnitt.
-
Postmortem-Massnahmen bis zum Abschluss verfolgen: Tracking-Bugs, einzelne Verantwortliche und Alters-Review
Das Site Reliability Workbook warnt, dass Massnahmen aus Postmortems ohne einen formalen Tracking-Prozess oft in Vergessenheit geraten; jeder Massnahme einen Tracking-Bug, eine einzige verantwortliche Person, einen Typ und eine Priorität geben, offene Massnahmen planmässig nach Alter durchgehen und eine überfällige Massnahme als zu treffende Entscheidung behandeln, nicht als übersprungene Zeile.
-
Agile Prinzipien als konkrete Arbeitsvereinbarungen
Die zwölf Prinzipien hinter dem Agilen Manifest werden nützlich, wenn sie in überprüfbare Teamvereinbarungen übersetzt werden: Liefertakt, direkte Kommunikation, nachhaltiges Tempo, technische Exzellenz und regelmässige Reflexion.
-
Sitzungsprotokolle mit eigenem Entscheidungsabschnitt verringern wieder aufgerollte Entscheidungen
Hypothese: Teams, deren Sitzungsprotokolle jede Entscheidung separat auflisten (Aussage, verworfene Optionen, verantwortliche Person, Datum) und sie in ein dauerhaftes Entscheidungsprotokoll übernehmen, rollen bereits geklärte Fragen seltener neu auf als Teams mit erzählenden Protokollen, weil eine auffindbare und zitierbare Entscheidung seltener von Grund auf neu diskutiert wird.
-
Eine Anfrage einer betroffenen Person als Engineering-Prozess behandeln: Export und Löschung
Die Anfrage einer Person auf eine Kopie oder Löschung ihrer Daten wie einen Auftrag behandeln: geprüfte Aufnahme, ein Exporter pro Datenspeicher aus der Daten-Landkarte, der ein Manifest erzeugt, Auslieferung über einen befristeten authentifizierten Download, Löschung über die Pipeline, dokumentierte Ausnahmen mit Begründungscodes sowie ein Test mit einer synthetischen betroffenen Person in festem Rhythmus; welche Anfragen erfüllt werden müssen und bis wann, wird hier nicht behandelt.
-
Onboarding-Dokumentation: der Weg von einer frischen Maschine zu einer gemergten Änderung
Onboarding-Dokumentation ist ein einziger nummerierter Weg, der eine neue Person – Mensch oder Agent – von nichts Installiertem zu einer gemergten Änderung führt, nur mit dem, was schriftlich vorliegt; jede neue Person behebt, worüber sie gestolpert ist, und der Weg trägt einen Owner sowie ein Aktualitätsdatum.
-
Ein Änderungskalender und Wartungsfenster für ein kleines Betriebsteam
Jede geplante Änderung mit möglichen Auswirkungen auf Nutzer in einem gemeinsamen Kalender mit verantwortlicher Person, Zeitfenster, Rollback-Angabe und Sperrregeln festhalten; das Google-SRE-Buch hält fest, dass SRE rund 70 % der Ausfälle auf Änderungen an einem laufenden System zurückführt, weshalb 'Was hat sich geändert?' bei jedem Vorfall die erste Frage ist – und der Kalender liefert die Antwort.
-
Ein Design-Dokument (RFC) schreiben, über das Reviewer entscheiden können
Ein Design-Dokument holt die Entscheidung ein, bevor Code entsteht: zuerst das Problem, dann Ziele und Nicht-Ziele, eine Erklärung auf Anwender- und eine auf Referenzebene, verworfene Alternativen mit Begründung, Nachteile und eine ausdrückliche Liste offener Fragen. Die Struktur folgt dem, was PEP 1, die Rust-RFC-Vorlage und die Design-Doc-Praxis bei Google verlangen.
-
Issue-Triage für ein kleines Projekt: ein fester Label-Satz und ein regelmässiger Durchgang
Triage bedeutet, für jedes neue Issue zu entscheiden, was es ist, ob es umsetzbar ist und wer als Nächstes am Zug ist. Ein kleines Label-Vokabular in drei Familien (Typ, Status, Bereich) sowie ein kurzer Durchgang in festem Rhythmus hält den Tracker ehrlich; GitHubs Standard-Labels (darunter bug, enhancement, documentation, duplicate, question, wontfix, good first issue und help wanted) sind ein brauchbarer Startsatz.
-
Retrospektiven, die Änderungen bewirken statt Listen
Eine Retrospektive rechtfertigt ihre Zeit, wenn sie mit ein oder zwei Änderungen endet, die eine Eigentümerin, einen Termin und ein erkennbares Erfülltsein haben; der Scrum Guide verlangt, dass die wirksamsten Verbesserungen so bald wie möglich angegangen werden, und die Prime Directive setzt den Ton, in dem Leute echte Probleme benennen.
-
Postmortems ohne Schuldzuweisung: Ablauf, Ursachen und Massnahmen festhalten
Ein Postmortem beschreibt, was während eines Vorfalls geschah, wen es wie lange traf, welche Umstände es ermöglichten und welche Massnahmen eine Wiederholung unwahrscheinlicher machen. Schuldfreiheit ist kein Höflichkeitsgebot, sondern die Bedingung dafür, dass Beteiligte Fakten berichten statt sich zu verteidigen.
-
Eine Bereitschaftsdienst-Rotation und ihre Übergabe gestalten
Eine Bereitschaftsdienst-Rotation braucht eine primäre und eine Ersatzperson, einen begrenzten Anteil der Arbeitszeit pro Teammitglied, planbare Schichtlängen und Tauschregeln, ein Pager-Budget, das bei Überschreitung Korrekturarbeit auslöst, sowie eine schriftliche Übergabe bei jedem Schichtwechsel; die Randbedingungen dazu beschreiben das Google-SRE-Buch und die öffentliche Response-Dokumentation von PagerDuty.
-
RICE- und ICE-Bewertung: was die Zahlen bedeuten und wo sie an ihre Grenzen stossen
RICE multipliziert Reichweite, Wirkung und Zuversicht und teilt durch den Aufwand; ICE lässt die Reichweite weg und behält Wirkung, Zuversicht und Einfachheit. Beide sind nützlich, um Priorisierungsargumente explizit und vergleichbar zu machen, und beide versagen, wenn die Eingaben als Zahlen verkleidete Vermutungen sind oder wenn Abhängigkeiten und Strategie ignoriert werden.
-
Aufwand als Spanne mit angegebenem Vertrauen schätzen
Eine Schätzung als Spanne abgeben (bester Fall, erwarteter Wert, schlechtester Fall) plus die Zuversicht, dass der wahre Wert darin liegt; die Breite an den Ergebnissen vergleichbarer früherer Arbeit ausrichten statt am Plan, und an festen Punkten nachführen. Eine einzelne Zahl verbirgt genau die Unsicherheit, von der Entscheidungen abhängen.
-
Release-Kadenz für ein kleines Projekt: zeitbasierte Züge versus Release-wenn-bereit
Eine Versionsnummer sagt, was ein Release verspricht; eine Kadenz-Richtlinie sagt, wann Releases stattfinden. Rust liefert alle sechs Wochen ein Stable-Release aus einem Nightly-Beta-Stable-Zug, Python wechselte mit PEP 602 zu einem jährlichen Feature-Release, und Django gibt Feature-Releases nach einem zeitbasierten Zeitplan heraus, mit Patch-Releases bei Bedarf. Ein kleines Projekt kann diese Form übernehmen: Feature-Releases nach Kalender oder sobald sich etwas Nennenswertes angesammelt hat, Patch-Releases, sobald eine Korrektur fertig ist.
-
Ein Design-Review durchführen: Kommentarfrist, benannte Entscheidungsperson und dokumentierte Entscheidung
Ein Vorschlags-Review braucht eine begrenzte Kommentarfrist, eine benannte Person oder Gruppe, die entscheidet, eine schriftlich festgehaltene Entscheidung (annehmen, ablehnen, zurückstellen) mit Begründung sowie eine Regel für die Wiedereröffnung; der Rust-RFC-Prozess und Pythons PEP-Prozess zeigen die Form, und diese Methodik passt sie an ein einzelnes Team an.
-
Eine Feature-Anfrage ablehnen, ohne den Beitragenden zu verlieren
Eine Ablehnung, die sich auf einen schriftlich festgehaltenen Projektumfang beruft, zeitnah erfolgt, eine Alternative nennt und den Thread schliesst, ist freundlicher als Schweigen und behält die anfragende Person als Beitragende. Die Open Source Guides halten fest, dass Schriftlichkeit das Nein-Sagen erleichtert und dass eine Antwort selten mehr als ein oder zwei Sätze braucht.
-
Abnahmekriterien je Arbeitspaket, die sich in Tests überführen lassen
Die Abnahmekriterien jedes Arbeitspakets als konkrete Beispiele mit Ausgangszustand, Aktion und beobachtbarem Ergebnis formulieren, in der Given/When/Then-Struktur von Gherkin oder einer gleichwertigen, mit benannten Grenzfällen; Kriterien, die niemand ausser der Autorin oder dem Autor ausführen oder prüfen kann, sind keine Kriterien.
Maschinenlesbar: JSON