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

Вам потребуется неделя, чтобы окончательно согласовать свой график и финансы. Но как только вы это сделаете, вы обнаружите, что требования к проекту изменились, и большая часть вашей работы теперь не имеет значения. Какая пустая трата времени, энергии и ресурсов! Наверняка же есть лучший способ?

В этой статье мы рассмотрим, как игра в "покер планирование" может помочь вам весело, быстро и эффективно оценить, что требуется для вашего проекта. Будучи частью Agile подхода, она вовлекает в процесс всех членов вашей команды.

Что такое Agile?

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

Agile дает командам свободу в адаптации в процессе работы, а это значит, что конечный продукт часто отличается от первоначальной идеи. Но поскольку клиент погружен в проект, а члены команды извлекают уроки из каждой итерации, они могут предоставить продукт, который действительно нужен конечному пользователю.

Agile команды стремятся регулярно выдавать промежуточные результаты на протяжении всего проекта, а не выдавать единый конечный результат в его конце. Для этого они работают короткими очередями, называемыми "спринтами". Каждый спринт начинается с совещания по планированию, на котором члены команды обсуждают, что они могут сделать, согласовывают цели и распределяют задачи между собой.

Во время спринта команда каждый день собирается на короткую "летучку” (эти встречи называются scrum). Участники рассказывают о том, над чем они работают, предупреждают друг друга о любых проблемах и обсуждают возможные решения. Затем, в конце спринта, команда сверяется с заказчиком, чтобы убедиться, что он или она удовлетворены продуктом и проделанной на данный момент работой.

Эффективный способ распределения проектной работы между членами команды — разбить ее на более мелкие элементы, известные как "истории пользователей". Они состоят из:

1. Письменного описания желаемого результата с точки зрения пользователя.

2. Группового обсуждения для уточнения более мелких деталей.

3. Теста в конце спринта, чтобы проверить, удовлетворен ли клиент тем, что было произведено.

"Покер планирование" в Agile

Ответственность за оценку времени и затрат на продукт традиционно ложится на отдельного человека и может занять много времени и усилий. Но, как отмечает эксперт по Agile Майк Кон в своей книге "Agile: оценка и планирование проектов", использование большего количества времени и энергии не обязательно повышает точность. На приведенной ниже диаграмме показана взаимосвязь между этими двумя элементами:

Рисунок 1. Схема отдачи усилий, связанных с планированием в подходе Agile

Эта диаграмма демонстрирует, что вам нужно приложить лишь немного усилий, чтобы значительно повысить точность ваших оценок. Она также подчеркивает, что можно потратить слишком много времени и при этом добиться менее точного результата.

Кон предлагает Agile командам играть в "покер планирование" на своих scrum-встречах, чтобы оценить затраты и сроки реализации пользовательских историй. (На самом деле это не покер, но в нем используются карты с баллами или простые сводные таблицы результатов.)

Идея возникла в 1950-х годах из подхода к прогнозированию, получившего название метода Дельфи. "Покер планирование" было разработано консультантом по Agile Джеймсом Греннингом в 2002 году и популяризировано Коном три года спустя. Греннинг усовершенствовал свою версию в 2009 году с помощью своей "Покерной вечеринки-планерки".

По словам Кона, игра в "покер планирование" — это быстрый и эффективный способ привлечь вашу команду к планированию и оценке аспектов вашего Agile проекта. Он говорит, что вы повышаете точность своего планирования, потому что используете:

1. Экспертное мнение (вашей команды).

2. Аналогии (сравнение одной части работы с другой).

3. Дезагрегирование (разделение проекта на более мелкие части для упрощения оценки).

И вы не полагаетесь на суждение только одного человека. Кон говорит, что полезно вовлекать всех с самого начала, поскольку не всегда ясно, кто что будет делать во время спринта.

Покер планирование: пошаговое руководство

Шаг 1: подготовка

Прежде чем вы начнете, следует продумать несколько вещей:

- Когда играть: играйте в покер планирование, когда в начале проекта необходимо оценить ряд задач или когда члены команды определяют новые истории пользователей в начале спринта.

- Необходимое время: оно зависит от того, сколько пользовательских историй вам нужно оценить, и от размера вашей команды. В качестве приблизительного ориентира вам может потребоваться от одного до трех часов на сеанс.

- Кого включить: всех членов Agile команды, включая разработчиков, тестировщиков, аналитиков и инженеров. Если в вашей Agile команде 10 или более человек, разделите их на две группы. Модератором, как правило, становится владелец продукта.

Затем подготовьте колоду оценочных карт для каждого участника. Они должны быть достаточно большими, чтобы каждый член команды мог видеть их через стол.

Пометьте каждую колоду следующими номерами: 1, 2, 3, 5, 8, 13, 20, 40, и 100 (на основе чисел Фибоначчи). Это очки для оценки историй. Чем более дорогостоящей, сложной и трудоемкой, по мнению "игрока", является история, тем больше очков он ей присвоит. Этот диапазон также отражает большую неопределенность при попытке оценить более крупные позиции.

Вы можете использовать более простую систему подсчета очков, например, делая карточки с кодами размеров, такими как S, M, L, XL, XXL. Вы можете добавить экстра-карточку (символ бесконечности), чтобы указать, что история пользователя просто слишком велика, чтобы ее можно было оценить, и ее нужно разбить на более мелкие истории. И еще одну карточку (знак вопроса), чтобы показать, что для получения оценки требуется больше информации.

Не путайте эти очки с единицами времени, которое понадобится для выполнения задачи. Каждый член проектной команды скорее всего будет работать с разной скоростью, поэтому будет думать о разном количестве часов или дней для выполнения задачи. Однако, таким образом можно договориться о приблизительных масштабах работы.

Шаг 2: инструкции для модератора

  1. Усадите свою команду за стол и раздайте каждому участнику колоду карт для покер планирования.
  2. Напомните всем о кривой "усилие/точность" (см. диаграмму выше). Скажите им, что цель состоит в том, чтобы удержаться слева от пика усилий, где еще можно легко получить полезную оценку.
  3. Прочитайте описание каждой пользовательской истории и попросите свою команду обсудить ее. Убедитесь, что вы тщательно подготовились заранее, чтобы иметь возможность ответить на любые вопросы. Не позволяйте обсуждению занять слишком много времени, иначе вы рискуете потратить слишком много усилий. Подумайте об использовании таймера, чтобы побудить людей производить оценку быстро.
  4. Затем попросите каждого из участников выбрать карточку из своей колоды, чтобы представить свои оценки размера каждой пользовательской истории. Они должны учитывать время, сложность и риск и включать в себя все типы задач, такие как анализ, разработка, тестирование и документация. Как только они будут готовы, попросите их одновременно перевернуть свои карточки и показать их друг другу.
  5. Там, где оценки расходятся (а они, скорее всего, будут расходиться), поощряйте людей с самыми высокими и самыми низкими баллами объяснять и обсуждать свои решения. Делайте заметки, если вы считаете, что какой-либо из аргументов может быть полезен, когда вы находитесь на этапах программирования или тестирования.
  6. Попросите участников переоценить и снова раскрыть свои карты одновременно. Цель состоит в том, чтобы все сошлись на одном числе. Это часто происходит ко второму раунду. Если нет, повторите цикл еще раз — процесс редко занимает больше трех раундов. Это нормально, если у одного человека не будет точно такой же оценки, как у всех остальных, после пары раундов, или если несколько членов команды дали близкие оценки по шкале — выберите больший размер и двигайтесь дальше. Смысл упражнения в том, чтобы достичь разумности, а не совершенства!

Шаг 3: что дальше?

Поиграв в покер планирование, команда поймет масштаб и сложность своих пользовательских историй. Эти порции задач теперь могут быть расставлены по приоритетам и заложены (пока без деталей) в план следующего спринта. Члены команды теперь будут сами назначать себе задачи, и теперь у них больше шансов верно рассчитать, сколько времени что–то займет, хотя оценки и остаются приблизительными.