Pull to refresh

Comments 16

Очень интересная техника. Возьму на вооружение

Изначально в planning poker карточках не дни, а story points. Почему выбраны именно дни и как аргументировать отказ от story points?
Поделюсь своим опытом: пытались применить покер планирование в наших командах, но так и не прижилось. Все участники были скованны в общении и не понимали, зачем нужны карточки. Правила игры не принимались командой и было сложно их мотивировать им следовать. В результате отказались от этой практики в пользу обсуждения каждой задачи на совещании по планированию с конкретным исполнителем в присутствии команды.

Еще важный момент, вы пишите в конце, что задача обсуждается с заказчиком с конкретным исполнителем в присутствии команды. А как вы привязываете задачу к конкретному исполнителю? И когда это происходит?

При изначальном планировании спринта заказчик (product owner) набрасывает задачи, которые хочет увидеть по завершению спринта. Техлид распределяет их по ответственным в команде разработчикам (по компонентам, технологиям, компетенциям и пр.). Далее те люди на которых назначено проводят сами оценку задачи по исходным данным что есть и только когда такие оценки готовы собирается команда на обсуждение по сценарию похожему на покер, только без карточек. В процессе обсуждения задачи могут переназначаться, а трудоемкость корректироваться.
Для нас так оказалось наиболее эффективно по времени и комфорту в коллективе.
UFO just landed and posted this here
Вот сейчас мне даже сложно сказать, почему это должны быть абстрактные попугаи? Почему команда не может решить, сколько они хотят взять времени для качественного решения задачи? У нас часто беседа в таком ключе проходит: «Давай возьмем на это день, чтобы покрутить задачу с разных сторон, и убедится, что рассмотрели несколько вариантов ее решения», т.е. не задача сложная, а берется специально чуть больше времени, чтобы не спеша о ней подумать.
Задача назначается конкретному члену команды. Производительность у всех разная. Поэтому оценивают сложность в SP, а не время. Джун может делать неделю то, на что у сеньора уйдет день, но на сложность задачи это не влияет. Именно поэтому планнинг покер — про сложность. И оценивают не дни/часы, а сложность задачи.

У SP еще часто в плане времени есть эталон — какая-то типовая задачка, которая принимается за 1.

Время может каждый прикинуть на себя, а в задачу писать время — это лишний раз подставляться. За спринт команда в целом отрабатывает определенное количество SP, усреднив цифру за несколько спринтов можно получить скорость (велосити) как всей команды, так и сделать прикидку на каждого индивидуально.

Так менеджер может исходя из оцененного перечня задач (бэклога) оценить требуемое время.

А можно подробней про последний абзац? Как всё-таки менеджер может оценить требуемое время, если сторипоинты это не оценка времени?

PP обычно (по крайней мере, в классическом скраме так) используется в связке с важной фичей: нет привязки задачи к конкретному исполнителю, любая задача — забота всей команды. То есть, да, естественным образом кто-то берет задачу из свободных, но этот исполнитель может отвлечься, заболеть или тупо не справиться, и задача всех остальных членов команды — помочь. Из этого следует, что «задача на пять дней» может в реальности, даже при абсолютно точной оценке, занять от одного дня (если задача отлично параллелится, ничем не блокируется и вся команда работает над ней одновременно) до двух недель (если исполнителя постоянно отвлекать или отправить в отпуск, и никто не подключится). Соответственно, и выходные метрики (в т.ч. велосити) оценивают продуктивность команды как целого.

Отрицательный момент: такая схема работы не очень стабильна, и требуется кто-то, кто бы следил за процессом и не давал разработчикам закукливаться на своих задачах и забивать на окружающих.
UFO just landed and posted this here

Если можно, то немного вопросов.
Какая у вас команда, сколько аналитиков и разрабочиков?
Дело в том, что при маленькой команде обычно присутствует 1 аналитик, 1 разработчик. И время на решение задачи каждый выдаст свое, аналитик плохо знает или не знает разработку, аналогично и разработчик.
В большой команде другая проблема. Несколько аналитиков и разработчиков, но зачастую они эксперты в отдельной области, и мало знают другую область. В то же время у большой комманды обычно и задач много, например у нас до сотен задач в день может поступать. А держать всю комманду — не эффективно.
В то же время, если у нас аналитик и разработчик в одном лице, и таких сотрудников много, то тут вообще странно, как такая команда живёт.

У нас 3 команды участвуют по отдельность друг от друга: аналитики, разработчики, админы.

Мы всячески стараемся, чтобы в команде всегда было два и более человека, которые могут выполнить конкретную задачу, иначе риски слишком высоки(bus number) и задачу оценивают только те люди, которые будут ее выполнять, иначе смысла нет.
У PP есть большой недостаток — крайне сложно с ходу сказать, является ли конкретная задача «3», «8» или «42», даже когда есть эталонная «1». Поэтому есть альтернативный вариант, когда задачи сортируются от простой к сложной, причем, несколько задач могут занимать одно место, а шкала логарифмическая, т.е. место n+1 это примерно вдвое сложнее, чем n. Сортировка работает по принципу пресловутого bubble sort, когда задача сравнивается с окружающими и перемещается при необходимости. Нечего перемещать — отлично, проставляем оценки из ряда Фибоначчи, и готово.

Правда, у такого подхода есть свой важный недостаток. В PP есть элемент внезапности, когда все «игроки» показывают свои карты, в результате, в РР джуниор-новичок выдает свою независимую оценку, а не полагается слепо на оценки высказавшихся ранее синиоров. Здесь же «сортировка» пошаговая, и надо кому-то следить, чтобы все члены команды могли свободно высказаться и обосновать свою оценку.
Нужно стремиться, чтобы сложность задачи не превышала 1 день.

Почему и каким образом?

Если один участник оценивает задачу в ½ дня

Это минимальный срок выполнения задачи? Или на обсуждение не будут выносится более мелкие задачи?

Планирование лучше всего проводить так, чтобы у команды всегда был запас задач на 1-2 дня, но не больше.

Не слишком ли часто будут проводится такие встречи?
//Почему и каким образом?

Чем мельче задача, тем ниже вероятность ошибки, и тем лучше команда может договорится о ее выполнении. Что очень важно для меня, merge request на ревью такой задачи бодет содержать небольшое кол-во файлов.

Если задача занимает 7 и более дней, она произведет огромное кол-во изменений в проекте. Если все эти изменения будут сделаны одним человеком без согласования с командой, проревьювить такие изменения будет крайне сложно. После ревью может оказаться, что значимую часть работы необходимо переделать, и тогда все затянется еще дольше, и придется снова проверять всю эту массу кода и т.д. воощем это сложно долго и плохо контролируемо.

Я не исключаю психологический фактор: задача на 1-2 недели это путь, на котором разработчик идет один и несет всю ответственность за этот код, на этом пути у него возникает много сомнений, о том как лучше сделать, что может плохо сказаться на сроках выполнения задачи да и на качестве — одна голова хорошо а две(и более) лучше.

//Это минимальный срок выполнения задачи? Или на обсуждение не будут выносится более мелкие задачи?

Все задачи выносятся на обсуждение(за редким исключением критичных задач). В нашей практике сложился минимальный срок 1/2 дня, но меньше чем 2 часа я бы не рекомендовал выдавать даже на, казалось бы, самые мелкие 15 минутные задачи.

//Не слишком ли часто будут проводится такие встречи?

Мы иногда делаем планирование на один рабочий день вперед, если он приходится перед выходными или праздничными днями, чтобы то, что обсудили на планировании, не забылось за выходные.
Sign up to leave a comment.