Никита Ульшин про IT
Telegram ·
Понятную задачу легко оценить
Если после декомпозиции команда долго спорит об оценке, то нужно не добиваться числа любой ценой, а вернуться к подготовке задачи и проверить проблемные места.
Я в работе практически постоянно сталкиваюсь с ситуациями, когда команды затрудняются оценить сроки выполнения той или иной задачи. Попытки собрать груминг и всё решить неизменно заканчиваются спорами: обсуждаются нюансы, корнер-кейсы и детали реализации.
Когда подобное случается, я первым делом проверяю: понятно ли команде, как сделать задачу? Если задача достаточно понятна, то сама оценка происходит быстро. Открытые вопросы обычно имеются, но не влияют на оценку кардинально. Но иногда буквально одна деталь может сделать оценку затруднительной.
В такие моменты лучшее, что я могу сделать, — это остановить спор и попытаться понять, что же осталось непрояснённым в задаче. Вот буквально сесть, собрать открытые вопросы, назначить ответственных и отправиться их решать вместо оценки.
Пробел далеко не всегда оказывается в требованиях. Например, некоторое время назад два разработчика час спорили над одним контрактом API. Помимо бизнес-требований, до оценки приходится прояснять и технические решения, потому что они влияют на архитектуру (поэтому я люблю подумать о них отдельно, в RFC).
Конечно, это всё не панацея. Разброс в оценках может сохраняться по разным причинам (например, из-за разного опыта участников), и сам по себе долгий спор ещё не доказывает, что нарушен DoR или задача плохо декомпозирована. Но для меня главный критерий — чёткое понимание того, как новая функциональность будет интегрирована в существующую систему и как она будет обрабатывать пограничные случаи.
Если спор упирается в то, как встроить функциональность в систему или обработать пограничный случай, я возвращаю задачу на проработку. Договариваться о числе имеет смысл после того, как разобрались с этим вопросом.
// По каким признакам вы понимаете, что пора остановить оценку и вернуть задачу на проработку?
