Skip to content

Типы задач и оценка

Типы рабочих элементов

ТипОписаниеПример
FeatureНовая функциональность для пользователяЭкран онбординга, интеграция с платёжной системой
BugДефект в существующей функциональностиОшибка при оформлении заказа
PostmortemЗадачи из action items постмортемаДобавить circuit breaker, улучшить алерты
Tech TaskТехнические улучшения, не видимые пользователю напрямуюРефакторинг, миграция БД, настройка CI
Stability IssueПроблемы со стабильностью сервисовУтечка памяти, деградация latency

Оценка сложности

Discovery — оценка в майках (T-shirt sizing)

На этапе Discovery фичи оцениваются в майках для быстрого сравнения объёма работ:

РазмерОриентир
SДо 2-3 дней работы одного разработчика
M1 неделя, возможно потребуется 2 человека
L2+ недели, кросс-функциональная работа
XLТребует декомпозиции на более мелкие фичи

Delivery — декомпозиция и оценка тех задач

При переходе в Delivery фича декомпозируется на конкретные технические задачи, каждая из которых оценивается точнее для планирования delivery-слотов.

Распределение мощности

Ёмкость стрима распределяется между несколькими категориями работ:

КатегорияОписание
Фичи и доработки процессовПродуктовая разработка, основной поток ценности
Поддержка (баги с прода)Исправление дефектов, обнаруженных пользователями
Инциденты и postmortemРеагирование на инциденты и выполнение action items
Технологический роадмеп, enablers, техдолгПлатформенные улучшения, погашение техдолга
Стабилизация сервисовУлучшение надёжности и производительности
Уязвимости и безопасностьУстранение уязвимостей, security-задачи

Баланс

Соотношение между категориями зависит от текущего состояния продукта и сервисов. Приоритеты обсуждаются на продуктовом комитете и деливери-ревью.

Классы обслуживания

Классы обслуживания определяют, как задача движется по потоку:

КлассОписаниеПример
Фикс дейтЖёсткий дедлайн, привязана к внешнему событиюЗапуск маркетинговой кампании, требования регулятора
СтандартОбычный поток, приоритет через продуктовый комитетБольшинство фич и техзадач
ИнтанджиблРабота без явного краткосрочного эффекта, но критична в долгосрочной перспективеТехдолг, обновление библиотек, документация

Шаблон постановки задачи

Каждая задача при постановке должна содержать:

  1. Проблема — понятно описано, что именно не работает или чего не хватает
  2. Сценарии — описаны пользовательские сценарии (Story / JTBD)
  3. Метрика — указано, на какую продуктовую или техническую метрику влияет задача