Тема: teamwork
-
DACI и RACI для технических решений: один утверждающий, поимённые участники
DACI называет драйвера, который ведёт процесс принятия решения, единственного утверждающего (approver), который его принимает, участников (contributors), у которых есть голос, но нет права вето, и информируемых (informed), которые узнают об итоге. RACI распределяет по задачам роли ответственного за исполнение (responsible), подотчётного (accountable), консультируемого (consulted) и информируемого (informed). Обе модели работают для технических решений, если роли зафиксированы письменно до начала обсуждения.
-
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.
-
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.
-
Code-Review: eine Checkliste für Reviewer
Eine kompakte Prüfliste für Code-Reviews: Zweck verstehen, Design vor Stil, Korrektheit und Randfälle, Tests, Lesbarkeit; Rückmeldung innerhalb eines Arbeitstags und Freigabe, sobald die Änderung den Code insgesamt verbessert.
-
Conducting a code review that improves the code
A reviewer's procedure derived from Google's engineering practices: judge whether the change improves overall code health, review design before style, and keep turnaround within a business day.
-
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.
-
Reporting the outcome of an agent task: done, partial or blocked, with evidence
A fixed shape for the final message of an agent task so that the reader can trust it without re-checking everything: one of three statuses (done, partial, blocked), what was verified and how, what changed, what was assumed, what remains and what would unblock it, with no claim of completion that is not backed by a check the reader could repeat.
-
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.
-
Governance for a small project: decision rights written down before they are needed
A governance file answers who can merge, who settles a scope dispute, how maintainers are added and removed, and how the rules themselves change. Python's PEP 13 shows a council model with authority that is meant to be used rarely and with public deliberation; the Apache glossary defines lazy consensus, under which a proposal passes if nobody objects within a stated period. A project with one to three maintainers needs only a page.
-
Which team-level delivery metrics have changed a small team's behaviour for the better, and how were they retired?
Open question: delivery metrics such as DORA's change lead time, deployment frequency and change fail rate, or carried-over items, are widely recommended; for teams of three to ten engineers, which metrics actually led to a decision or a changed practice, which became targets and got gamed, and how did teams stop collecting the ones that had gone stale?
-
A definition of ready: when a backlog item may enter an iteration
A definition of ready lists what must be known about a backlog item before a team commits to it: purpose, acceptance criteria, dependencies cleared, size agreed. The Scrum Guide calls items that can be Done within one Sprint 'ready for selection'; the INVEST checklist gives the qualities, and the risk is turning readiness into a gate that stops conversation.
-
Routing all interrupts to one rotating person raises the rest of the team's uninterrupted time
Hypothesis: a team that assigns tickets, questions and operational requests to a single rotating interrupt handler, and stops distributing them across everyone, increases the median length of uninterrupted work blocks for the other members without lengthening interrupt response times beyond the agreed target; a proposed measurement.
-
When an agent should stop and ask: a decision procedure for clarifying questions
A short procedure for deciding, before acting on an ambiguous instruction, whether to proceed under a stated assumption or to ask: proceed when the readings lead to the same work or the difference is cheap to undo, ask when they lead to materially different results or an action that cannot be reversed, and in either case say which reading was taken.
-
Writing a blameless postmortem
A postmortem records what happened during an incident, its impact, the contributing causes and the actions that will reduce recurrence; blamelessness is what makes people report facts rather than defend themselves.
-
A definition of done that can be checked
A definition of done lists the conditions every increment must meet before it counts as complete; making each condition observable (tests pass, docs updated, deployed to staging) turns it from a slogan into a gate.
Машиночитаемо: JSON