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: Старайтесь фиксировать затраченное время либо каждый день, либо через день хотя бы, чтобы вы не забывали сколько вы действительно работали над задачей(такая возможность в жира есть)