Перейти к основному содержимому

Scrum — бэклог, приоритеты и оценка

ОБЯЗАТЕЛЬНО
Аналитику Руководителю
Теория данных (раздел 3)

Миграции в инкременте — Пакетная работа; проверка — SQL для тестировщика.

Один бэклог — один порядок​

Product Backlog — единственный упорядоченный список того, что может понадобиться продукту. Product Owner отвечает за порядок с учётом:

  • ценности для пользователя и бизнеса;
  • рисков и зависимостей;
  • стоимости задержки (что дороже не сделать сейчас).

Продукт может быть "гениальным", но без монетизации и фокуса компания остаётся дилетантской — приоритет PO включает выживание продукта, не только "красивые фичи".

Разделение:

АртефактКто владеет порядком / содержанием
Product BacklogPO приоритизирует
Sprint BacklogDevelopers планируют выполнение

Refinement (уточнение бэклога)​

До Sprint Planning элементы должны быть достаточно ясны (Scrum Guide: ready — обычно через ongoing refinement):

  • понятны критерии приёмки;
  • нет скрытых блокеров;
  • команда может оценить относительный размер;
  • ясно, какую ценность несёт элемент.

Шаблон user story и свойства требований — 7-04/111, 7-04/116.

Не оценивайте в часах (на уровне бэклога)​

Команды систематически ошибаются в оценке абсолютного времени на незнакомой работе. Scrum использует относительный размер:

  • "малый / средний / большой";
  • лучше — story points по шкале Фибоначчи — 1, 2, 3, 5, 8, 13, 21…

Относительные единицы в раннем Scrum​

В ранних командах оценивали задачи условными единицами (например, "собаки" разного размера). Смысл тот же, что у points: сравнение с уже известными задачами, а не календарь.

Зачем Фибоначчи​

Последовательность отражает растущую неопределённость крупных задач: разница между 8 и 13 "сжимает" ложную точность. Шкала Fibonacci в Planning Poker — распространённый компромисс, а не строгая математика.

Часы уместны для учёта факта и capacity отдельных ролей; points — для прогноза спринта и velocity.

Planning Poker​

Play ITЗагрузка интерактивного демо…

Метод (адаптация дельфийского подхода RAND, но быстрее):

  1. Каждый получает карты Fibonacci.
  2. PO (или аналитик) кратко объясняет элемент.
  3. Все кладут карту одновременно (рубашкой вверх).
  4. Если разброс ≤ 2 ступеней — берут среднее или консенсус.
  5. Если разброс большой — объясняют крайние оценки (мин и макс) и повторяют раунд.

Плюсы:

  • снижается давление "старшего";
  • всплывают разные допущения (как в примере с кухней из гл. 6 книги Сазерленда: шкафы, кисть vs валик);
  • оценивает команда, которая будет делать, а не внешний эксперт.

Контрпример из той же главы — GSI Commerce: централизованные «лучшие оценщики» дали прогнозы, далёкие от реальности; проекты срывались, клиенты были недовольны. Когда оценку вернули самим командам (через покер планирования), прогнозы снова сошлись с фактом. Вывод Сазерленда: оценивает только та группа, которая будет выполнять работу — у каждой команды свой темп и контекст.

Подробнее в контексте аналитики — 7-04/116; оценка трудозатрат в управлении — 7-02/112.

Планирование спринта после оценки​

На Sprint Planning:

  1. PO предлагает Sprint Goal и кандидатов с верха бэклога.
  2. Developers выбирают объём, исходя из velocity и capacity (отпуска, праздники).
  3. Формируется Sprint Backlog и план работы.

Правило фокуса: не наращивать обязательства внутри спринта без отмены Sprint (редкое событие при резком изменении Product Goal).

Приоритеты vs multitasking​

См. Потери: PO защищает команду от "всё срочно" — один явный фокус спринта. MoSCoW и другие техники приоритизации в аналитике дополняют, но не заменяют единый упорядоченный бэклог.

Что читать дальше​

ТемаСсылка
Velocity и спринт./4
Внедрение с нуля./7
Формализация требований7-04/116
Содержание