---
# System prepended metadata

title: Planning Poker

---

Planning Poker
===


:dart: Цель покер планирования
---
Главная цель оценки сложности задачи не предсказать, когда задача будет готова, а убедиться, что все участники одинаково понимают задачу, коллективно обсудили предполагаемые этапы реализации задачи, а потом уже дать адекватную оценку времени для ее реализации. 
Адекватная в том плане, что лимит времени на выполнение задачи не должен превышать **4** идеальных человеко-дней, где 1 ид./чел.дн. = **4ч**. 
Поэтому стараемся декомпозировать задачу так, чтобы ее можно было имплементировать в виде независимых апдейтов и релизить такими патчами в прод, тем самым не заламывая функциональность системы. 


:heavy_check_mark: Предусловия
---
* Определиться с составом участников встречи:
    * лид команды (фасилитатор встречи)
    * продакт (заказчик)
    * разработчики
    * QA
* В Slack-канале задачи (или команды) ЗАРАНЕЕ до планирования (хотя бы за день), лид команды просит всех участников (в большей степени это касается разработчиков): 
    * обязательно выделить время на ревью задачи чтобы тем самым понять, -
        * зачем мы делаем эту задачу;
        * чего мы хотим получить в конечном счете;
        * выяснить, что не хватает или мешает реализации задачи напр., - 
            * в задаче имеются комменты с меншенами людей, которые должны еще проработать требования в задаче (таск будет в новом жира-статусе - Analysis);
            * не утвержден дизайн для мокапа; 
            * есть депенденси задача которая препятствует выполнению текущей;
            * настроить что-то в ci-cd (напр-р, топик поднять);
            * и т.д.
    * предварительно формализовать требования в техн. решение т.е. определиться с тем, каким образом задача будет имплементирована. Подумать над другими возможными решениями;
    * выписать список вопросов по задаче, чтобы задать их на встрече и обсудить с командой;
    * выписать всевозможные риски из-за которых что-то может пойти не так;


:hammer: Постановка задачи
---
- *Заказчик* обязательно должен присутствовать на планировании, чтобы объяснить суть задачи, и как он ее понимает, донести до команды почему эта задача важна бизнесу, как это аффектит бизнес снаружи и какой профит компания получит в конечном счете.

- *Цель команды* — за счет наводящих вопросов выяснить максимальное количество подробностей по требованиям, предложить идеи и способы реализации, а также уточнить, устроит ли такой вариант заказчика. Желательно чтобы все участники высказались по очереди.


:game_die: Процесс оценки сложности
---

Оценка сложности задач осуществуляется с помощью покер карт, где каждый "вытягивает" карту с количеством _идеальных человеко-дней_. Тут подразумевается, что человек в теч. идеального дня занимается только задачей не отвлекаясь ни на что, т.е. **не** учитываем внеплановые хотфиксы по др. задаче, codereview, дежурство, встречи (стендапы, планирования, 1-1) и т.д.
    Значение фокус-фактора в среднем **~50%**. Под «фокус-фактором» понимается коэффициент, отражающий отношение КПД существующей команды к КПД «идеальной» команды. Также для того, чтобы правильно оценить свои силы, а именно, исключить кейс, что задача будет недооценена или переоценена, команда должна знать свою скорость работы. 

Возможные кейсы при оценке задачи:

- Тот, кто поставил _наименьшую_ оценку по времени при разнице в 1+ человеко-дней с медианой, рассказывает, почему он решил, что задачу можно  выполнить _так быстро_
- Участник с _наибольшей_ оценкой при разнице в 1+ человеко-дней с медианой, должен рассказать, какие риски и сложности он предвидит при выполнении задачи.
- Сюда же относятся кейсы: 
    --- _"эту задачу можно сделать быстро, изи ваще"_;
    --- _"оо, тут сложная реализация потребуется или долгий ресёрч, ну и там оч много, что нужно будет сделать "_. 
    В обоих этих случаях, ты должен конкретно аргументировать, почему так или иначе ты считаешь, и тут есть 2 причины этому:
    - возможно ты сам что-то неправильно понял в сути задачи, и пытаешься реализовать это "оверхард" способом или же выполнить лишнюю работу;
    - ты упускаешь какие-то важные моменты или нюансы, и в итоге это потребуется реализовать, но ты об этом даже и не подозреваешь.

:exclamation: После очередного обсуждения(если оценки были разрознены), команда повторно переигрывает оценку для задачи!
- Если кто-то вытаскивает карту ![harold](https://i.imgur.com/xqKUtvn.png) - это значит, что у человека все же остались еще вопросы или он вспомнил про еще какие-то детали и хотел бы обсудить их с командой прежде чем оценивать...



:white_check_mark: Что необходимо включать в оценку сложности задачи у разработчиков
---
- непосредственно сама разработка
- unit/integration тестирование
- время на прохождение code review
- различные риски, напр., 
    - сложность внедрения фичи в конкретное место (обсуждается индивидуально по каждой задаче)
    - новая предметная область или часть системы для разработчика

:warning: Если задача слишком большая и требуется больше **4** ид. человеко-дней на её реализацию, то данную задачу следует разбить на сабтаски, в этом случае оценка будет существенно реалистичней и точней...

:black_joker: Что нужно, чтобы участвовать в покер планировании
---
- Фасилитатор встречи призывает к старту оценки задачи, где нужно скинуть свою карту с оценкой задачи
- Играем картами *1, 2, 3, 4* идеальных человеко-дней, ну и конечно ![harold](https://i.imgur.com/xqKUtvn.png)
- В качестве значения конечной оценки используется значение **median**



:book: Мониторинг эффективности работы по оцененным задачам
---

:heavy_check_mark: Полученные оценки будут затем внесены в таску в соответствующие ETA-поля

:watch: Старайтесь фиксировать затраченное время либо каждый день, либо через день хотя бы, чтобы вы не забывали сколько вы действительно работали над задачей(такая возможность в жира есть)
