Planning Poker: как сделать процесс постановки задач максимально прозрачным и четким
Комментарии (7)
27 июля 2017 в 14:21
0↑
↓
Очень интересная техника. Возьму на вооружение
DigitalSmile
27 июля 2017 в 14:40
0↑
↓
Изначально в planning poker карточках не дни, а story points. Почему выбраны именно дни и как аргументировать отказ от story points?
Поделюсь своим опытом: пытались применить покер планирование в наших командах, но так и не прижилось. Все участники были скованны в общении и не понимали, зачем нужны карточки. Правила игры не принимались командой и было сложно их мотивировать им следовать. В результате отказались от этой практики в пользу обсуждения каждой задачи на совещании по планированию с конкретным исполнителем в присутствии команды.
rzykov
27 июля 2017 в 15:55
0↑
↓
Еще важный момент, вы пишите в конце, что задача обсуждается с заказчиком с конкретным исполнителем в присутствии команды. А как вы привязываете задачу к конкретному исполнителю? И когда это происходит?
-
DigitalSmile
27 июля 2017 в 16:01 (комментарий был изменён)
0↑
↓
При изначальном планировании спринта заказчик (product owner) набрасывает задачи, которые хочет увидеть по завершению спринта. Техлид распределяет их по ответственным в команде разработчикам (по компонентам, технологиям, компетенциям и пр.). Далее те люди на которых назначено проводят сами оценку задачи по исходным данным что есть и только когда такие оценки готовы собирается команда на обсуждение по сценарию похожему на покер, только без карточек. В процессе обсуждения задачи могут переназначаться, а трудоемкость корректироваться.
Для нас так оказалось наиболее эффективно по времени и комфорту в коллективе.
chizh_andrey
27 июля 2017 в 15:30
+1↑
↓
Вот сейчас мне даже сложно сказать, почему это должны быть абстрактные попугаи? Почему команда не может решить, сколько они хотят взять времени для качественного решения задачи? У нас часто беседа в таком ключе проходит: «Давай возьмем на это день, чтобы покрутить задачу с разных сторон, и убедится, что рассмотрели несколько вариантов ее решения», т.е. не задача сложная, а берется специально чуть больше времени, чтобы не спеша о ней подумать.27 июля 2017 в 17:10 (комментарий был изменён)
0↑
↓
Задача назначается конкретному члену команды. Производительность у всех разная. Поэтому оценивают сложность в SP, а не время. Джун может делать неделю то, на что у сеньора уйдет день, но на сложность задачи это не влияет. Именно поэтому планнинг покер — про сложность. И оценивают не дни/часы, а сложность задачи.У SP еще часто в плане времени есть эталон — какая-то типовая задачка, которая принимается за 1.
Время может каждый прикинуть на себя, а в задачу писать время — это лишний раз подставляться. За спринт команда в целом отрабатывает определенное количество SP, усреднив цифру за несколько спринтов можно получить скорость (велосити) как всей команды, так и сделать прикидку на каждого индивидуально.
Так менеджер может исходя из оцененного перечня задач (бэклога) оценить требуемое время.
27 июля 2017 в 15:38
0↑
↓
'команда принимает решение о том, какая оценка является более подходящей для задачи' — именно это и хотел прочитать в статье
