Оценка проектов в Agile по методу MoSCoW

10 Авг 2015

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

В традиционных методологиях процесс планирования подразумевает составление чёткого расписания и содержания проекта. Благодаря этому, заказчики и пользователи привыкли включать в требования всё, что только можно. И после принятия плана и потери контроля над разработкой – ведь он теперь у команды проекта – не желают добавлять туда что-то ещё. К тому-же, чаще всего добавить туда уже нечего. В таком случае, при приёмке клиент будет ожидать наличия всех оговорённых в начале проекта функций. Следовательно, нет необходимости в оценке ценности каждого отдельного элемента и порядок выполнения требований абсолютно не важен.

Но на самом деле, с точки зрения удобства и актуальности, порядок разработки крайне важен. Это происходит потому, что вполне вероятно, не все функции и элементы, обсуждаемые в начале проекта будут востребованы в момент их разработки. И в таком случае, ненужная функция или элемент не принесут никакой ценности владельцам продукта, при этом на них будет потрачено время, средства, а также проект понесёт все риски, связанные с из разработкой. Чтобы этого избежать, необходимо провести оценку ценности для каждого элемента. Для этого существует метод MoSCoW.

MoSCoW – это аббревиатура для четырёх основных этапов приоритизации элементов в процессе разработки:

• «MUST». Первая буква означает те элементы, которые непременно должны быть включены в продукт, иначе он не будет выполнять наиболее важные функции и приносить пользователю ценность. Также к данной категории относятся требования законодательства, необходимые для реализации проекта. Эта категория имеет наивысший приоритет.
• «SHOULD». В данной группе находятся те элементы, которые следует включить в финальную версию продукта. Это те элементы, которые важны для заказчика, и продукт не будет полноценным, но при этом будет работать. Вторая группа по уровню приоритета.
• «COULD». Те элементы и опции, которые клиент хотел бы видеть в своём продукте. Наличие опций из этой группы приносит наибольшее удовлетворение клиенту или заказчику. Эти опции можно сказать, «вишенка на торте», имеют низкий приоритет, но для удовлетворения заказчика, необходимы.
• «WON’T». В эту группу включаются те опции, которые решено было не включать в нынешнюю версию продукта.

По аналогии с пирамидой Маслоу, эти группы также можно расположить в виде пирамиды, где на верхнем уровне будут находиться необходимые опции, а внизу — самые необязательные (см. Рисунок 1). Соответственно, чем ближе к верху пирамиды, тем меньше количество элементов в группе.

 

Рисунок 1. Пирамида MoSCoW

Когда элементы продукта сгруппированы, команда проекта проводит сравнительную оценку каждого из них при помощи story point – абстрактной единицы измерения, имеющей смысл только для данного конкретного проекта. На первом этапе выбирается элемент, для выполнения которого требуется наименьшее количество времени или сил. Сложность его выполнения принимается за 1 story point. То, что именно брать за базу, полностью зависит от команды и её особенностей. Главное, чтобы эта оценка отражала трудность и/или длительность работы над элементом. На следующем этапе проводится оценка оставшихся элементов путём сравнения их с базой.

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

1. Из элементов продукта выбираются 3-4 элемента с наименьшей степенью неопределённости.
2. Команда проводит декомпозицию работ по каждому элементу, чтобы затем провести оценку времени, стоимости и ресурсов для реализации данного элемента в продукте. В данном случае требуется «идеальная» оценка времени и затрат, при самых благоприятных условиях.
3. По результатам данной оценки определяется стоимость 1 story point’a в часах. Время работы над элементом делится на количество story point’ов. Если у взятых 3-4 элементов эти значения немного расходятся, чаще всего берут среднее значение. То же самое повторяется для оценки затрат.
4. Сумма story point’ов по продукту умножается на стоимость в часах – таким образом получается предварительная оценка проекта. Аналогично проводится оценка затрат.

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

Мультипликаторы:

• Х*1.25 – Типовой проект. Такое значение авторы предлагают для случая, когда команда реализует привычный для них продукт, который они производили уже не раз, с минимальными отличиями. В таком случае степень неопределённости невысока, а команда уже знает о возможных трудностях, а потому их оценка требует лишь небольшой корректировки.
• Х*1.5 — Чётко определённый проект. Чтобы получить такой мультипликатор, проект должен иметь невысокую неопределённость, но не быть типовым для команды. Например, если у команды не так много опыта с конкретным типом продукта или клиент просить серьёзно модифицированный продукт, что вносит некоторую степень риска.
• Х*2.0 – Новые разработки. Данный мультипликатор используется в случае, если команда вынуждена столкнуться с чем-то абсолютно новым для себя в рамках работы над продуктом.
• Х*2.0 и выше – Быстрый старт. Используется тогда, когда нет времени на тщательную декомпозицию работ и проработку проекта. В таком случае проводится грубая оценка проекта с подобным мультипликатором.

В заключении приведём пример, как примерно выглядит этот процесс:

1. Пусть суммарная оценка всего проекта составляет 150 story point’ов.
2. Если проект чётко определён, то с учётом мультипликатора, оценка станет 225 story point’ов.
3. Пусть 1 story point будет равен 10 часам. Тогда по плану, вся работа над нашим проектом должна уложиться в 2250 часов, или 282 рабочим дням.

Таким же образом можно произвести оценку затрат проекта или потребности в ресурсах.

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

Смотрите также:

• Статья: Можно ли разработать стандарт, охватывающий и Agile и традиционный проектный подход?
• Статья: Программное обеспечение для управления проектами по Agile
• Статья: Офис управления проектами и методология Scrum

Если вы хотите изучить гибкие подходы к управлению проектами, тогда регистрируйтесь на открытый базовый тренинг “Agile Certified Professional”!

Вы также можете оставить заявку на тренинг в корпоративном формате.

Оригинал: http://www.pmhut.com/an-agile-primer-agile-estimating-and-the-moscow-process