Как сделать процесс постановки задач максимально прозрачным и четким
В прошлом посте мы рассказали о том, как работаем с бэклогом, а сегодня поделимся подробностями о процессе планирования, который в нашем случае не только полезный, но и увлекательный, поскольку оценку задач мы проводим с помощью «Planning Poker».
Содержание:
Как и зачем мы проводим планирования
Планирование – это регулярный процесс командного обсуждения каждой задачи. Мы проводим его раз в 2 дня, и в нем участвуют только члены инженерной команды и те, кто ставит им задачу.
Для проведения планирования мы собираем всех участников в конференцию лично или удаленно.
Заказчик (постановщик задачи – менеджер продукта, маркетолог или даже генеральный директор) обязательно должен присутствовать на планировании, чтобы объяснить суть задачи, рассказать, как он ее понимает, донести до команды почему задача важна и мотивировать исполнителей на ее выполнение. Цель инженерной команды – за счет дополнительных вопросов выяснить максимальное количество подробностей, вытянуть из заказчика скрытые требования, предложить свои идеи по реализации и выработать наилучший способ решения. Либо объяснить, почему выполнение задачи стоит отложить на некоторое время или не брать в работу вообще.
Постановка задачи
Заказчик зачитывает свою задачу (это всегда делает строго заказчик, чтобы избежать “сломанного телефона” при передаче данных и ускорения процесса выработки решения), объясняет, что именно нужно сделать и почему это важно.
Цель каждого участника команды исполнителей, задавая различные вопросы заказчику и членам команды, выяснить что именно нужно сделать и понять, как лучше всего решить задачу. Затем исполнитель объясняет, что конкретно он планирует сделать, и уточняет, устроит ли такой вариант заказчика и команду. Все участники высказываются по очереди, и после того, как все определились с наилучшим решением, наступает этап оценки сложности задачи.
Оценка сложности
Оценка сложности производится с помощью цифровых карт – это и есть так называемый Planning Poker: все участники команды исполнителей должны в закрытую оценить сложность задачи в днях трудозатрат, т.е. сколько рабочих дней (из расчета стандартных 8 часов) нужно конкретно ему (участнику) на выполнение задачи. После того как все исполнители положили карты рубашками вверх, все должны перевернуть свои карты так, чтобы числа были видны всем участникам процесса.
Исполнители с пограничными оценками (т.е. участники, которые дали самую низкую и самую высокую оценку по времени) должны объяснить свой выбор. С одной стороны, давление команды не позволит участникам дать неадекватно завышенную оценку сроков, с другой – команда получает возможность обсудить возможные проблемы по задаче. Тот, кто поставил наименьшую оценку по времени, делится с командой, как именно он планирует выполнить задачу так быстро. Участник, который дал самую большую оценку, должен рассказать о том, какие риски и сложности он предвидит при выполнении этой задачи. После повторного обсуждения с учетом всех подводных камней, команда принимает решение о том, какая оценка является более подходящей для задачи. Этот срок заносится в карточку с описанием задачи в таск-менеджере.
Главная цель оценки сложности не предсказать, когда задача будет готова, а убедиться, что все участники одинаково понимают задачу.
Если один участник оценивает задачу в ½ дня, а другой в 3 дня, они явно задумали выполнять задачу по-разному, и поэтому должны согласовать свои действия и объяснить, почему надо делать именно так, как они думают. Иногда расхождение в оценке может быть обусловлено разным опытом в решении схожих задач, в этом случае берется максимальная оценка, но если срок отличается более чем на 1 день, то задача выполняется в парном программировании, когда тот, кто оценил в меньшую сторону, руководит тем, кто оценил в большую.
Советы:
Нужно стремиться, чтобы сложность задачи не превышала 1 день.
Планирование лучше всего проводить так, чтобы у команды всегда был запас задач на 1-2 дня, но не больше. Так все участники будут хорошо помнить все детали обсуждения каждой конкретной задачи. Если задача провисела в очереди на исполнение более 4-х дней, ее нужно снова вынести на обсуждение, чтобы команда вспомнила, что и как нужно сделать по задаче.
Если задача выполняется на 2 дня дольше, чем планировалось, ее нужно вынести заново на планирование и обсудить с командой и заказчиком все сложности и проблемы с которыми столкнулись в ходе выполнения, чтобы в следующий раз при оценке учесть их.
Формат «Planning Poker» хорошо прижился в работу наших команд: разработчиков, аналитиков, админов, и позволяет лучше понимать задачи и пути их решения на этапе постановки.
А как вы обсуждаете задачи и оцениваете сложность и время их выполнения? Делитесь своим опытом в комментариях!
