Как и зачем мы проводим планирования
Планирование — это регулярный процесс командного обсуждения каждой задачи. Мы проводим его раз в 2 дня, и в нем участвуют только члены инженерной команды и те, кто ставит им задачу.
Для проведения планирования мы собираем всех участников в конференцию лично или удаленно.
Заказчик (постановщик задачи – менеджер продукта, маркетолог или даже генеральный директор) обязательно должен присутствовать на планировании, чтобы объяснить суть задачи, рассказать, как он ее понимает, донести до команды почему задача важна и мотивировать исполнителей на ее выполнение. Цель инженерной команды — за счет дополнительных вопросов выяснить максимальное количество подробностей, вытянуть из заказчика скрытые требования, предложить свои идеи по реализации и выработать наилучший способ решения. Либо объяснить, почему выполнение задачи стоит отложить на некоторое время или не брать в работу вообще.
Постановка задачи
Заказчик зачитывает свою задачу (это всегда делает строго заказчик, чтобы избежать “сломанного телефона” при передаче данных и ускорения процесса выработки решения), объясняет, что именно нужно сделать и почему это важно.
Цель каждого участника команды исполнителей, задавая различные вопросы заказчику и членам команды, выяснить что именно нужно сделать и понять, как лучше всего решить задачу. Затем исполнитель объясняет, что конкретно он планирует сделать, и уточняет, устроит ли такой вариант заказчика и команду. Все участники высказываются по очереди, и после того, как все определились с наилучшим решением, наступает этап оценки сложности задачи.
Оценка сложности
Оценка сложности производится с помощью цифровых карт — это и есть так называемый Planning Poker: все участники команды исполнителей должны в закрытую оценить сложность задачи в днях трудозатрат, т.е. сколько рабочих дней (из расчета стандартных 8 часов) нужно конкретно ему (участнику) на выполнение задачи. После того как все исполнители положили карты рубашками вверх, все должны перевернуть свои карты так, чтобы числа были видны всем участникам процесса.
Исполнители с пограничными оценками (т.е. участники, которые дали самую низкую и самую высокую оценку по времени) должны объяснить свой выбор. С одной стороны, давление команды не позволит участникам дать неадекватно завышенную оценку сроков, с другой — команда получает возможность обсудить возможные проблемы по задаче. Тот, кто поставил наименьшую оценку по времени, делится с командой, как именно он планирует выполнить задачу так быстро. Участник, который дал самую большую оценку, должен рассказать о том, какие риски и сложности он предвидит при выполнении этой задачи. После повторного обсуждения с учетом всех подводных камней, команда принимает решение о том, какая оценка является более подходящей для задачи. Этот срок заносится в карточку с описанием задачи в таск-менеджере.
Главная цель оценки сложности не предсказать, когда задача будет готова, а убедиться, что все участники одинаково понимают задачу.
Если один участник оценивает задачу в ? дня, а другой в 3 дня, они явно задумали выполнять задачу по-разному, и поэтому должны согласовать свои действия и объяснить, почему надо делать именно так, как они думают. Иногда расхождение в оценке может быть обусловлено разным опытом в решении схожих задач, в этом случае берется максимальная оценка, но если срок отличается более чем на 1 день, то задача выполняется в парном программировании, когда тот, кто оценил в меньшую сторону, руководит тем, кто оценил в большую.
Советы:
Нужно стремиться, чтобы сложность задачи не превышала 1 день.
Планирование лучше всего проводить так, чтобы у команды всегда был запас задач на 1-2 дня, но не больше. Так все участники будут хорошо помнить все детали обсуждения каждой конкретной задачи. Если задача провисела в очереди на исполнение более 4-х дней, ее нужно снова вынести на обсуждение, чтобы команда вспомнила, что и как нужно сделать по задаче.
Если задача выполняется на 2 дня дольше, чем планировалось, ее нужно вынести заново на планирование и обсудить с командой и заказчиком все сложности и проблемы с которыми столкнулись в ходе выполнения, чтобы в следующий раз при оценке учесть их.
Формат «Planning Poker» хорошо прижился в работу наших команд: разработчиков, аналитиков, админов, и позволяет лучше понимать задачи и пути их решения на этапе постановки.
А как вы обсуждаете задачи и оцениваете сложность и время их выполнения? Делитесь своим опытом в комментариях!
Комментарии (15)
DigitalSmile
27.07.2017 14:40Изначально в planning poker карточках не дни, а story points. Почему выбраны именно дни и как аргументировать отказ от story points?
Поделюсь своим опытом: пытались применить покер планирование в наших командах, но так и не прижилось. Все участники были скованны в общении и не понимали, зачем нужны карточки. Правила игры не принимались командой и было сложно их мотивировать им следовать. В результате отказались от этой практики в пользу обсуждения каждой задачи на совещании по планированию с конкретным исполнителем в присутствии команды.
rzykov
27.07.2017 15:55Еще важный момент, вы пишите в конце, что задача обсуждается с заказчиком с конкретным исполнителем в присутствии команды. А как вы привязываете задачу к конкретному исполнителю? И когда это происходит?
DigitalSmile
27.07.2017 16:01При изначальном планировании спринта заказчик (product owner) набрасывает задачи, которые хочет увидеть по завершению спринта. Техлид распределяет их по ответственным в команде разработчикам (по компонентам, технологиям, компетенциям и пр.). Далее те люди на которых назначено проводят сами оценку задачи по исходным данным что есть и только когда такие оценки готовы собирается команда на обсуждение по сценарию похожему на покер, только без карточек. В процессе обсуждения задачи могут переназначаться, а трудоемкость корректироваться.
Для нас так оказалось наиболее эффективно по времени и комфорту в коллективе.
Dmitry_5
27.07.2017 19:53Стори поинт это сложность, а не время. Тимлид сделает задачу на пять с.п. за день, а Джуниор три дня на один с.п. потратит
chizh_andrey
27.07.2017 15:30+1Вот сейчас мне даже сложно сказать, почему это должны быть абстрактные попугаи? Почему команда не может решить, сколько они хотят взять времени для качественного решения задачи? У нас часто беседа в таком ключе проходит: «Давай возьмем на это день, чтобы покрутить задачу с разных сторон, и убедится, что рассмотрели несколько вариантов ее решения», т.е. не задача сложная, а берется специально чуть больше времени, чтобы не спеша о ней подумать.
JSmitty
27.07.2017 17:10Задача назначается конкретному члену команды. Производительность у всех разная. Поэтому оценивают сложность в SP, а не время. Джун может делать неделю то, на что у сеньора уйдет день, но на сложность задачи это не влияет. Именно поэтому планнинг покер — про сложность. И оценивают не дни/часы, а сложность задачи.
У SP еще часто в плане времени есть эталон — какая-то типовая задачка, которая принимается за 1.
Время может каждый прикинуть на себя, а в задачу писать время — это лишний раз подставляться. За спринт команда в целом отрабатывает определенное количество SP, усреднив цифру за несколько спринтов можно получить скорость (велосити) как всей команды, так и сделать прикидку на каждого индивидуально.
Так менеджер может исходя из оцененного перечня задач (бэклога) оценить требуемое время.
solo12zw74
27.07.2017 20:08+1А можно подробней про последний абзац? Как всё-таки менеджер может оценить требуемое время, если сторипоинты это не оценка времени?
ilvar
27.07.2017 22:46PP обычно (по крайней мере, в классическом скраме так) используется в связке с важной фичей: нет привязки задачи к конкретному исполнителю, любая задача — забота всей команды. То есть, да, естественным образом кто-то берет задачу из свободных, но этот исполнитель может отвлечься, заболеть или тупо не справиться, и задача всех остальных членов команды — помочь. Из этого следует, что «задача на пять дней» может в реальности, даже при абсолютно точной оценке, занять от одного дня (если задача отлично параллелится, ничем не блокируется и вся команда работает над ней одновременно) до двух недель (если исполнителя постоянно отвлекать или отправить в отпуск, и никто не подключится). Соответственно, и выходные метрики (в т.ч. велосити) оценивают продуктивность команды как целого.
Отрицательный момент: такая схема работы не очень стабильна, и требуется кто-то, кто бы следил за процессом и не давал разработчикам закукливаться на своих задачах и забивать на окружающих.
Dmitry_5
27.07.2017 15:38'команда принимает решение о том, какая оценка является более подходящей для задачи' — именно это и хотел прочитать в статье
V_Maksim
27.07.2017 19:46Если можно, то немного вопросов.
Какая у вас команда, сколько аналитиков и разрабочиков?
Дело в том, что при маленькой команде обычно присутствует 1 аналитик, 1 разработчик. И время на решение задачи каждый выдаст свое, аналитик плохо знает или не знает разработку, аналогично и разработчик.
В большой команде другая проблема. Несколько аналитиков и разработчиков, но зачастую они эксперты в отдельной области, и мало знают другую область. В то же время у большой комманды обычно и задач много, например у нас до сотен задач в день может поступать. А держать всю комманду — не эффективно.
В то же время, если у нас аналитик и разработчик в одном лице, и таких сотрудников много, то тут вообще странно, как такая команда живёт.
RetailRocket
28.07.2017 12:41У нас 3 команды участвуют по отдельность друг от друга: аналитики, разработчики, админы.
Мы всячески стараемся, чтобы в команде всегда было два и более человека, которые могут выполнить конкретную задачу, иначе риски слишком высоки(bus number) и задачу оценивают только те люди, которые будут ее выполнять, иначе смысла нет.
ilvar
27.07.2017 22:56У PP есть большой недостаток — крайне сложно с ходу сказать, является ли конкретная задача «3», «8» или «42», даже когда есть эталонная «1». Поэтому есть альтернативный вариант, когда задачи сортируются от простой к сложной, причем, несколько задач могут занимать одно место, а шкала логарифмическая, т.е. место n+1 это примерно вдвое сложнее, чем n. Сортировка работает по принципу пресловутого bubble sort, когда задача сравнивается с окружающими и перемещается при необходимости. Нечего перемещать — отлично, проставляем оценки из ряда Фибоначчи, и готово.
Правда, у такого подхода есть свой важный недостаток. В PP есть элемент внезапности, когда все «игроки» показывают свои карты, в результате, в РР джуниор-новичок выдает свою независимую оценку, а не полагается слепо на оценки высказавшихся ранее синиоров. Здесь же «сортировка» пошаговая, и надо кому-то следить, чтобы все члены команды могли свободно высказаться и обосновать свою оценку.
BOM
28.07.2017 12:55Нужно стремиться, чтобы сложность задачи не превышала 1 день.
Почему и каким образом?
Если один участник оценивает задачу в ? дня
Это минимальный срок выполнения задачи? Или на обсуждение не будут выносится более мелкие задачи?
Планирование лучше всего проводить так, чтобы у команды всегда был запас задач на 1-2 дня, но не больше.
Не слишком ли часто будут проводится такие встречи?chizh_andrey
28.07.2017 13:49//Почему и каким образом?
Чем мельче задача, тем ниже вероятность ошибки, и тем лучше команда может договорится о ее выполнении. Что очень важно для меня, merge request на ревью такой задачи бодет содержать небольшое кол-во файлов.
Если задача занимает 7 и более дней, она произведет огромное кол-во изменений в проекте. Если все эти изменения будут сделаны одним человеком без согласования с командой, проревьювить такие изменения будет крайне сложно. После ревью может оказаться, что значимую часть работы необходимо переделать, и тогда все затянется еще дольше, и придется снова проверять всю эту массу кода и т.д. воощем это сложно долго и плохо контролируемо.
Я не исключаю психологический фактор: задача на 1-2 недели это путь, на котором разработчик идет один и несет всю ответственность за этот код, на этом пути у него возникает много сомнений, о том как лучше сделать, что может плохо сказаться на сроках выполнения задачи да и на качестве — одна голова хорошо а две(и более) лучше.
//Это минимальный срок выполнения задачи? Или на обсуждение не будут выносится более мелкие задачи?
Все задачи выносятся на обсуждение(за редким исключением критичных задач). В нашей практике сложился минимальный срок 1/2 дня, но меньше чем 2 часа я бы не рекомендовал выдавать даже на, казалось бы, самые мелкие 15 минутные задачи.
//Не слишком ли часто будут проводится такие встречи?
Мы иногда делаем планирование на один рабочий день вперед, если он приходится перед выходными или праздничными днями, чтобы то, что обсудили на планировании, не забылось за выходные.
shurupkirov
Очень интересная техника. Возьму на вооружение