Тема: 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.
-
Доведение действий после разбора инцидента до закрытия: задачи, единый ответственный и проверка давности
The Site Reliability Workbook предупреждает, что без формального процесса отслеживания действия после разбора инцидентов часто забываются. Дайте каждому пункту задачу в трекере, одного ответственного, тип и приоритет, регулярно проверяйте открытые пункты по давности и считайте просроченный пункт поводом для решения, а не строкой, которую можно пропустить.
-
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.
-
Документация для освоения проекта: от чистой машины до принятого изменения
Документация для новичка — единый пронумерованный путь, который ведёт человека или агента от машины без установленных инструментов до принятого изменения только по письменным указаниям. Каждый новичок исправляет то, на чём споткнулся, а у пути есть ответственный и дата актуальности.
-
Календарь изменений и окна обслуживания для небольшой эксплуатационной команды
Заносите каждое плановое изменение, способное повлиять на пользователей, в общий календарь: ответственный, временное окно, строка об откате и правила запрета изменений. Книга Google SRE сообщает, что, по наблюдению SRE, примерно 70% сбоев вызваны изменениями в работающей системе, поэтому первый вопрос при любом инциденте — «что изменилось?», а ответ находится в календаре.
-
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.
-
Разбор задач небольшого проекта: фиксированные метки и регулярный обход
Разбор означает определить для каждой новой задачи, что это, можно ли по ней действовать и кто делает следующий шаг. Небольшой словарь меток трёх семейств (тип, статус, область) и короткий регулярный обход поддерживают достоверность трекера. Стандартные метки GitHub, среди которых bug, enhancement, documentation, duplicate, question, wontfix, good first issue и help wanted, подходят как начальный набор.
-
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.
-
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 и ICE: что означают числа и где заканчивается их применимость
RICE перемножает охват, влияние и уверенность и делит результат на трудозатраты; ICE убирает охват и оставляет влияние, уверенность и лёгкость выполнения. Оба метода помогают сделать доводы при расстановке приоритетов явными и сопоставимыми, и оба перестают работать, когда исходные данные — догадки в виде чисел или когда игнорируются зависимости и стратегия.
-
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.
-
Ритм выпусков небольшого проекта: по расписанию или по готовности
Номер версии говорит, что обещает выпуск; политика периодичности — когда он выходит. Rust выпускает стабильную версию каждые шесть недель через цепочку nightly, beta, stable; Python перешёл на ежегодные функциональные выпуски по PEP 602; Django выпускает функциональные версии по расписанию, а исправления — по необходимости. Небольшой проект может перенять эту схему: функциональные выпуски по календарю или по накоплении заметных изменений, исправления — после принятия каждого исправления.
-
Проведение проектного ревью: срок обсуждения, ответственный за решение и записанный итог
Рассмотрению предложения нужны ограниченный срок комментариев, назначенный человек или группа с правом решения, письменный итог — принять, отклонить, отложить — с причинами и правило повторного рассмотрения. Процессы Rust RFC и Python PEP показывают общий подход, а эта методика адаптирует его для одной команды.
-
Как отклонить запрос функции и сохранить участника проекта
Отказ, который ссылается на письменные границы проекта, приходит быстро, называет альтернативу и закрывает обсуждение, добрее молчания и сохраняет запросившего как участника. Open Source Guides отмечают, что письменная фиксация облегчает отказ, а ответу редко требуется больше одного-двух предложений.
-
Критерии приёмки задачи, которые можно превратить в тесты
Записывайте критерии приёмки каждой задачи как конкретные примеры с исходным состоянием, действием и наблюдаемым результатом, используя Given/When/Then из Gherkin или аналогичную структуру и называя граничные случаи. То, что никто, кроме автора, не может выполнить или проверить, не является критерием.
Машиночитаемо: JSON