Comments 16
Очень интересная техника. Возьму на вооружение
Поделюсь своим опытом: пытались применить покер планирование в наших командах, но так и не прижилось. Все участники были скованны в общении и не понимали, зачем нужны карточки. Правила игры не принимались командой и было сложно их мотивировать им следовать. В результате отказались от этой практики в пользу обсуждения каждой задачи на совещании по планированию с конкретным исполнителем в присутствии команды.
Еще важный момент, вы пишите в конце, что задача обсуждается с заказчиком с конкретным исполнителем в присутствии команды. А как вы привязываете задачу к конкретному исполнителю? И когда это происходит?
Для нас так оказалось наиболее эффективно по времени и комфорту в коллективе.
У SP еще часто в плане времени есть эталон — какая-то типовая задачка, которая принимается за 1.
Время может каждый прикинуть на себя, а в задачу писать время — это лишний раз подставляться. За спринт команда в целом отрабатывает определенное количество SP, усреднив цифру за несколько спринтов можно получить скорость (велосити) как всей команды, так и сделать прикидку на каждого индивидуально.
Так менеджер может исходя из оцененного перечня задач (бэклога) оценить требуемое время.
А можно подробней про последний абзац? Как всё-таки менеджер может оценить требуемое время, если сторипоинты это не оценка времени?
Отрицательный момент: такая схема работы не очень стабильна, и требуется кто-то, кто бы следил за процессом и не давал разработчикам закукливаться на своих задачах и забивать на окружающих.
Если можно, то немного вопросов.
Какая у вас команда, сколько аналитиков и разрабочиков?
Дело в том, что при маленькой команде обычно присутствует 1 аналитик, 1 разработчик. И время на решение задачи каждый выдаст свое, аналитик плохо знает или не знает разработку, аналогично и разработчик.
В большой команде другая проблема. Несколько аналитиков и разработчиков, но зачастую они эксперты в отдельной области, и мало знают другую область. В то же время у большой комманды обычно и задач много, например у нас до сотен задач в день может поступать. А держать всю комманду — не эффективно.
В то же время, если у нас аналитик и разработчик в одном лице, и таких сотрудников много, то тут вообще странно, как такая команда живёт.
Мы всячески стараемся, чтобы в команде всегда было два и более человека, которые могут выполнить конкретную задачу, иначе риски слишком высоки(bus number) и задачу оценивают только те люди, которые будут ее выполнять, иначе смысла нет.
Правда, у такого подхода есть свой важный недостаток. В PP есть элемент внезапности, когда все «игроки» показывают свои карты, в результате, в РР джуниор-новичок выдает свою независимую оценку, а не полагается слепо на оценки высказавшихся ранее синиоров. Здесь же «сортировка» пошаговая, и надо кому-то следить, чтобы все члены команды могли свободно высказаться и обосновать свою оценку.
Нужно стремиться, чтобы сложность задачи не превышала 1 день.
Почему и каким образом?
Если один участник оценивает задачу в ½ дня
Это минимальный срок выполнения задачи? Или на обсуждение не будут выносится более мелкие задачи?
Планирование лучше всего проводить так, чтобы у команды всегда был запас задач на 1-2 дня, но не больше.
Не слишком ли часто будут проводится такие встречи?
Чем мельче задача, тем ниже вероятность ошибки, и тем лучше команда может договорится о ее выполнении. Что очень важно для меня, merge request на ревью такой задачи бодет содержать небольшое кол-во файлов.
Если задача занимает 7 и более дней, она произведет огромное кол-во изменений в проекте. Если все эти изменения будут сделаны одним человеком без согласования с командой, проревьювить такие изменения будет крайне сложно. После ревью может оказаться, что значимую часть работы необходимо переделать, и тогда все затянется еще дольше, и придется снова проверять всю эту массу кода и т.д. воощем это сложно долго и плохо контролируемо.
Я не исключаю психологический фактор: задача на 1-2 недели это путь, на котором разработчик идет один и несет всю ответственность за этот код, на этом пути у него возникает много сомнений, о том как лучше сделать, что может плохо сказаться на сроках выполнения задачи да и на качестве — одна голова хорошо а две(и более) лучше.
//Это минимальный срок выполнения задачи? Или на обсуждение не будут выносится более мелкие задачи?
Все задачи выносятся на обсуждение(за редким исключением критичных задач). В нашей практике сложился минимальный срок 1/2 дня, но меньше чем 2 часа я бы не рекомендовал выдавать даже на, казалось бы, самые мелкие 15 минутные задачи.
//Не слишком ли часто будут проводится такие встречи?
Мы иногда делаем планирование на один рабочий день вперед, если он приходится перед выходными или праздничными днями, чтобы то, что обсудили на планировании, не забылось за выходные.
Planning Poker: как сделать процесс постановки задач максимально прозрачным и четким