⌨️ Planning poker

#Agile #PersonalExperience

Всех с предпоследней пятницей года! Сегодня расскажу о покере планирования — инструменте невероятной простоты и эффективности. Традиционно эту методику относят к Agile, что логично: человек, описавший эту методику, был одним из соавторов Agile-манифеста . Текущий пост скорее описывает опыт автора, а не саму концепцию. Поэтому я не буду углубляться в разъяснение терминологии, касающейся современных (или уже не очень) методов разработки. О них расскажу вам позже.

Название метода указывает на проблему, которую он пытается решить: как с большей точностью оценить и запланировать задачу.
Сначала вводные. Бизнес или смежные отделы просят отдел DevOps решить большую задачу — скажем, развернуть в инфраструктуре новый k8s-кластер или расширить существующий. Эта большая задача оценивается приблизительно и с запасом, в формате: «Сделаем до такого-то числа, если не возникнет форс-мажоров». Так как задача большая, её необходимо разделить на несколько задач поменьше, которые уже можно оценить с той или иной точностью.
Итак, собираем новый кластер. Что надо сделать?

Декомпозируем задачу:
Заказать новые серверы у хостинговой компании.
Протестировать их (чтобы предупредить проблемы при эксплуатации).
Выполнить преинстал (новые серверы должны на базовом уровне соответствовать другим серверам парка в части ОС, установленного базового ПО, сетевых настроек, прав пользователей и так далее).
Развернуть на них кластер.
Настроить мониторинг кластера и серверов.
Подключить кластер к уже существующей реализации Argo CD (инструмент для удобства деплоя, выполняющий роль прослойки между вашим репозиторием и кластером).

Каждую задачу необходимо оценить отдельно.

Приступаем к оценке. Сразу обозначу некоторое противоречие: несмотря на то что мы будем оценивать задачу в часах, оцениваем мы скорее не время, а усилия и ресурсы, необходимые для завершения задачи с учётом неопределённости.

В оригинальной версии покера планирования это могут быть стори-пойнты (Story Points) — по сути, абстрактные единицы оценки сложности задачи. Классические статьи на эту тему предлагают пользоваться размером одежды (XS, S, M, L, XL … XXL), размером собак (от чихуахуа до волкодава) или просто числами из адаптированного ряда Фибоначчи (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 или 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100). Зачем такие сложности?

Это попытка абстрагироваться от времени как единицы измерения. Однако я предпочитаю всё-таки оценивать задачи в часах. Будем использовать следующий ряд: 2h, 4h, 8h или 1d, 2d, где h — часы, d — дни. Даже из этого не слишком длинного ряда я бы убрал 6h как оценку, нагнетающую неопределённость: рабочий день длится 8 часов, а оценить задачу в ⅔ рабочего дня не совсем понятно. Цифра 6, полагаю, предназначена для задач, которые кажутся слишком большими для 4 часов и слишком маленькими для 8. Но почему бы тогда не округлить в большую сторону?

Каждую задачу оценивает каждый член команды. Он оценивает, сколько усилий, по его мнению, требуется потратить на задачу. В случае онлайн-голосования оценки отправляются боту для голосования. В офлайне участники кладут перед собой карту рубашкой вверх, показывая, что сделали выбор. После голосования бот показывает результаты, либо карты переворачиваются. Участники, чья оценка оказалась самой высокой или низкой, обосновывают её. Обсуждение продолжается до достижения консенсуса, то есть до тех пор, пока все не согласятся с оценкой, или не будет выработана доминирующая позиция группы.
Правила могут модифицироваться: можно использовать таймер для ограничения времени обсуждения или несколько кругов голосования. Достигли консенсуса, присвоили оценку, закрепили её в вашем таск-трекере, переходим к следующей задаче.

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