Как оцениваются задачи в Agile
Что проверяют
Понимаете ли вы, зачем команда вообще оценивает задачи и чем относительная оценка отличается от часов. Следом часто спрашивают, как вы оценили бы задачу, в которой много неизвестного.
Как отвечать
Суть в том, что оценка нужна для планирования и разговора о сложности, а не для контроля людей. Scrum Guide не предписывает конкретный способ, поэтому в командах встречаются разные:
- сторипойнты: относительная оценка по шкале, похожей на Фибоначчи (1, 2, 3, 5, 8, 13). Учитывают объём, сложность и неопределённость, а не часы одного человека. Сравнивают с эталонной задачей, которую все хорошо помнят;
- planning poker: каждый выбирает карту втёмную, открывают одновременно, расхождения обсуждают. Одновременность защищает от якоря, когда все подстраиваются под оценку сеньора;
- T-shirt sizing: размеры S, M, L, XL для грубой оценки эпиков и дорожной карты;
- часы или идеальные дни: для коротких технических задач и когда заказчик платит за время;
- без оценок: в Kanban смотрят на пропускную способность и время цикла, а сроки прогнозируют по истории, например методом Монте-Карло.
Оценивают обычно на груминге бэклога, а на планировании спринта сверяют объём с velocity команды. Задачу крупнее 8 или 13 пойнтов дробят, а под неизвестность заводят spike с ограниченным временем.
Для Python-разработчика хорошо показать, что входит в оценку: код, тесты на pytest, миграции Alembic или Django, ревью, обновление зависимостей и выкладка.
Где спотыкаются
Переводят пойнты в часы по фиксированному курсу. Тогда относительная оценка теряет смысл, это те же часы с лишним шагом.
Делают velocity показателем эффективности или сравнивают её между командами. У каждой команды своя шкала, и под давлением пойнты просто раздуваются.
Оценивают только написание кода. Тесты, ревью, миграции и отладку на стенде забывают, и задача на «два дня» занимает неделю.