Зачем это нужно
В учебных заданиях дедлайн — это дата сдачи. В продуктовой разработке дедлайн — лишь одна точка на длинной дорожке: идея → планирование → разработка → релиз → эксплуатация. Если начать писать код до того, как задача «готова к работе», вы потратите время на уточнения. Если закрыть задачу до того, как она «действительно готова», в продакшене появится сырой функционал.
Definition of Ready (DoR) и Definition of Done (DoD) — два договора команды, которые защищают от хаоса. Этот урок объясняет полный путь задачи и то, что происходит, когда что-то идёт не так.
Основные идеи
Путь задачи от идеи до релиза:
Идея / гипотеза — «если мы добавим рекомендации, конверсия вырастет». Фиксируется PM, часто в виде Epic.
Уточнение и декомпозиция — Epic разбивается на Story и Task. Пишутся acceptance criteria.
DoR-check — команда проверяет: понятна ли цель, есть ли данные, согласованы ли метрики?
Разработка — код, модель, тесты. Задача движется по доске: To Do → In Progress → Code Review → QA.
DoD-check — перед закрытием: код в main, тесты зелёные, документация обновлена, мониторинг настроен.
Релиз — выкладка в продакшен по расписанию или по флагу (feature flag).
Поддержка — SRE/On-call следит за метриками; баги заводятся как новые Task.
Definition of Ready (DoR) — чеклист «можно брать в работу». Пример для ML-Story:
Описана бизнес-метрика успеха.
Есть доступ к данным (или явно указано, кто его предоставит).
Acceptance criteria сформулированы и согласованы.
Нет блокирующих зависимостей от других команд.
Definition of Done (DoD) — чеклист «задача завершена по-настоящему». Пример:
PR смержен, CI прошёл.
Unit-тесты и интеграционные тесты написаны.
Runbook или README обновлены.
Алерт на ключевую метрику настроен.
PM/QA подтвердили приёмку.
DoR и DoD — командные соглашения. Их нельзя скопировать из учебника: команда формулирует их вместе и пересматривает раз в квартал.
Инциденты и postmortem. Инцидент — событие, когда сервис работает хуже, чем ожидается: падение, деградация latency, некорректные предсказания модели. Процесс:
Detection — алерт или сообщение пользователя.
Response — on-call инженер оценивает масштаб, при необходимости откатывает релиз.
Resolution — устранение первопричины.
Postmortem — разбор без обвинений (blameless): что случилось, почему, что изменим в процессах.
Postmortem пишут в Confluence. Хороший postmortem содержит timeline, root cause, action items с владельцами и сроками.
Как это выглядит на практике
Story в Jira: ML-142 «Добавить fallback при недоступности модели».
DoR: Backend подтвердил, что API-gateway поддерживает routing; SRE согласовал SLA fallback (< 50 ms).
Разработка: MLE пишет PR, QA проверяет сценарий «model service down → возвращается rule-based score».
DoD: интеграционный тест в CI, runbook в Confluence обновлён, алерт «model_unavailable > 5 min» создан.
Через две недели алерт срабатывает: pod с моделью убит OOM-killer. On-call делает rollback, сервис восстанавливается за 8 минут. Postmortem фиксирует: не были заданы memory limits в Kubernetes manifest — action item для DevOps.
Что сделать после занятия
Составьте DoR и DoD для учебного ML-проекта (минимум по 5 пунктов в каждом).
Опишите на одной странице воображаемый postmortem: «модель стала предсказывать только один класс после релиза» — timeline + 3 action items.
Найдите в Jira (или нарисуйте на бумаге) workflow с колонками — сопоставьте их с этапами жизненного цикла из урока.