Тема: process
-
DACI и RACI для технических решений: один утверждающий, поимённые участники
DACI называет драйвера, который ведёт процесс принятия решения, единственного утверждающего (approver), который его принимает, участников (contributors), у которых есть голос, но нет права вето, и информируемых (informed), которые узнают об итоге. RACI распределяет по задачам роли ответственного за исполнение (responsible), подотчётного (accountable), консультируемого (consulted) и информируемого (informed). Обе модели работают для технических решений, если роли зафиксированы письменно до начала обсуждения.
-
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.
-
Tracking postmortem action items to closure: tracking bugs, single owners and ageing review
The Site Reliability Workbook warns that without a formal tracking process, action items from postmortems are often forgotten; give every item a tracking bug, one owner, a type and a priority, review open items by age on a schedule, and treat an item past its date as a decision to make rather than a line to skip.
-
Agile principles as concrete working agreements
The twelve principles behind the Agile Manifesto become useful when translated into checkable team agreements: delivery cadence, direct communication, sustainable pace, technical excellence and regular reflection.
-
Meeting notes with a separate decisions section reduce re-opened decisions
Hypothesis: teams whose meeting notes list each decision separately (statement, rejected options, owner, date) and copy it into a durable decision log re-open settled questions less often than teams with narrative notes, because a decision that can be found and quoted is less likely to be argued again from scratch.
-
Handling a data subject request as an engineering process: export and delete
Treat a person's request for a copy or deletion of their data as a job: verified intake, one exporter per store in the data map producing a manifest, delivery through an expiring authenticated download, deletion through the pipeline, exemptions listed with reason codes, and a synthetic-subject test on a fixed cadence; which requests must be honoured and when is not addressed.
-
Onboarding documentation: the path from a fresh machine to a merged change
Onboarding documentation is one numbered path that takes a newcomer, human or agent, from nothing installed to a merged change using only what is written down; each newcomer fixes what tripped them, and the path carries an owner and a freshness date.
-
A change calendar and maintenance windows for a small operations team
Put every planned change that can affect users on one shared calendar with an owner, a window, a rollback line and blackout rules; the Google SRE book states that SRE has found roughly 70% of outages to be due to changes in a live system, so 'what changed?' is the first question in any incident and the calendar is where it is answered.
-
Issue triage for a small project: a fixed label set and a regular pass
Triage means deciding for every new issue what it is, whether it is actionable and who moves next. A small label vocabulary in three families (type, status, area) plus a short pass at a fixed cadence keeps the tracker honest; GitHub's default labels (among them bug, enhancement, documentation, duplicate, question, wontfix, good first issue and help wanted) are a workable starting set.
-
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.
-
Designing an on-call rotation and its handover
An on-call rotation needs a primary and a backup, a bounded share of each engineer's time, shift lengths and swap rules that people can plan around, a pager budget that triggers corrective work when exceeded, and a written handover at every shift change; the Google SRE book and PagerDuty's public response documentation describe the constraints.
-
RICE and ICE scoring: what the numbers mean and where they stop
RICE multiplies reach, impact and confidence and divides by effort; ICE drops reach and keeps impact, confidence and ease. Both are useful to make prioritisation arguments explicit and comparable, and both break when the inputs are guesses dressed as numbers or when dependencies and strategy are ignored.
-
Release cadence for a small project: time-based trains versus release-when-ready
A version number says what a release promises; a cadence policy says when releases happen. Rust ships a stable release every six weeks from a nightly, beta, stable train, Python moved to an annual feature release with PEP 602, and Django issues feature releases on a time-based schedule with patch releases as needed. A small project can copy the shape: feature releases on a calendar or when something notable accumulates, patch releases whenever a fix lands.
-
Running a design review: comment period, named decider and a recorded disposition
A proposal review needs a bounded comment period, a named person or group who decides, a written disposition (accept, reject, postpone) with reasons, and a rule for reopening; the Rust RFC process and Python's PEP process show the shape and this methodology adapts it to a single team.
-
Declining a feature request without losing the contributor
A refusal that points to written scope, arrives promptly, names an alternative and closes the thread is kinder than silence, and it keeps the requester as a contributor. The Open Source Guides note that writing things down makes it easier to say no and that a reply rarely needs more than one or two sentences.
-
Acceptance criteria per work item that can be turned into tests
Write each work item's acceptance criteria as concrete examples with a starting state, an action and an observable outcome, using Gherkin's Given/When/Then structure or an equivalent, with the boundary cases named; criteria that cannot be executed or checked by someone other than the author are not criteria.
-
Work-in-progress limits in Kanban
Limiting the number of items in each workflow stage exposes bottlenecks and shortens lead time; the Kanban Guide defines the practices of visualising work, limiting WIP, managing flow and improving the system.
-
Running a retrospective that produces changes, not lists
A retrospective earns its time when it ends with one or two changes that have an owner, a deadline and a way to tell whether they happened; the Scrum Guide asks for the most impactful improvements to be addressed as soon as possible, and the Prime Directive sets the tone that makes people name real problems.
-
User interviews for engineers: a minimal protocol
An engineer can run a useful user interview with a written goal, a short guide of open questions about specific past events, a pilot run, a note-taker and a debrief within a day; the method collects reported behaviour, so it complements rather than replaces observation and metrics.
Машиночитаемо: JSON