Майк Кон - Agile - оценка и планирование проектов

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

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

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

Лично я предпочитаю пункты. У оценки историй в пунктах больше преимуществ. Когда команда не может понять, насколько полезно разделение оценки размера и срока, я настаиваю, чтобы она начала с оценки в идеальных днях, а потом склоняю к переходу на пункты. Чтобы добиться этого, я чаще спрашиваю членов команды о том, «насколько велик этот объект по сравнению с тем, что мы уже оценивали», а не о том, «сколько идеальных дней потребуется для реализации этого объекта». Большинство команд даже не замечают перехода, а когда все же обращают на него внимание, оценка в пунктах уже входит в привычку.

1. Какой подход вы предпочитаете — использование пунктов или идеальных дней? Почему?

2. Как внедрить такую практику во всей организации? Какие препятствия вы предвидите и как вы предполагаете справиться с ними?

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

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

Редко когда, если такое вообще случается, мы располагаем достаточным временем, чтобы сделать все. Поэтому нам приходится распределять приоритеты. Ответственность за приоритизацию лежит на всей команде, однако процессом руководит владелец продукта. К сожалению, обычно трудно оценить стоимость небольших единиц функциональности, таких как отдельно взятая пользовательская история. Чтобы справиться с этой задачей, индивидуальные пользовательские истории или функции объединяются в темы . Истории и темы затем приоритизируются по отношению друг к другу с целью формирования плана релиза. Темы должны подбираться так, чтобы каждая из них определяла отдельный набор ценных для пользователей или клиента функций. Например, при разработке веб-сайта SwimStats у нас могут быть следующие темы:

• Фиксация всех персональных записей и предоставление пловцам возможности их просмотра.

• Предоставление тренерам возможности оптимально распределять пловцов по заплывам и предсказывать результат команды в соревнованиях.

• Предоставление тренерам возможности вводить план тренировок и отслеживать дистанции, пройденные на тренировках.

• Интеграция с распространенными карманными компьютерами, используемыми в бассейне.

• Импорт и экспорт данных.

• Предоставление официальным представителям возможности следить за результатами заплывов и счетом в соревнованиях.