Оценка проектов в Agile по методу MoSCoW
Методологию Agile часто критикуют за то, что использование классического инструментария не позволяет достаточно точно оценить и спланировать, какие элементы будут присутствовать в конечном продукте. Впрочем, это сделано намеренно. Agile фокусируется на разработке самых важных функций, с возможностью добавить больше, если позволит время. В этом основное отличие гибких методологий от классических подходов к управлению проектами. Но за такую гибкость приходится платить неопределённостью.
В традиционных методологиях процесс планирования подразумевает составление чёткого расписания и содержания проекта. Благодаря этому, заказчики и пользователи привыкли включать в требования всё, что только можно. И после принятия плана и потери контроля над разработкой – ведь он теперь у команды проекта – не желают добавлять туда что-то ещё. К тому-же, чаще всего добавить туда уже нечего. В таком случае, при приёмке клиент будет ожидать наличия всех оговорённых в начале проекта функций. Следовательно, нет необходимости в оценке ценности каждого отдельного элемента и порядок выполнения требований абсолютно не важен.
Но на самом деле, с точки зрения удобства и актуальности, порядок разработки крайне важен. Это происходит потому, что вполне вероятно, не все функции и элементы, обсуждаемые в начале проекта будут востребованы в момент их разработки. И в таком случае, ненужная функция или элемент не принесут никакой ценности владельцам продукта, при этом на них будет потрачено время, средства, а также проект понесёт все риски, связанные с из разработкой. Чтобы этого избежать, необходимо провести оценку ценности для каждого элемента. Для этого существует метод MoSCoW.
MoSCoW – это аббревиатура для четырёх основных этапов приоритизации элементов в процессе разработки:
В традиционных методологиях процесс планирования подразумевает составление чёткого расписания и содержания проекта. Благодаря этому, заказчики и пользователи привыкли включать в требования всё, что только можно. И после принятия плана и потери контроля над разработкой – ведь он теперь у команды проекта – не желают добавлять туда что-то ещё. К тому-же, чаще всего добавить туда уже нечего. В таком случае, при приёмке клиент будет ожидать наличия всех оговорённых в начале проекта функций. Следовательно, нет необходимости в оценке ценности каждого отдельного элемента и порядок выполнения требований абсолютно не важен.
Но на самом деле, с точки зрения удобства и актуальности, порядок разработки крайне важен. Это происходит потому, что вполне вероятно, не все функции и элементы, обсуждаемые в начале проекта будут востребованы в момент их разработки. И в таком случае, ненужная функция или элемент не принесут никакой ценности владельцам продукта, при этом на них будет потрачено время, средства, а также проект понесёт все риски, связанные с из разработкой. Чтобы этого избежать, необходимо провести оценку ценности для каждого элемента. Для этого существует метод MoSCoW.
MoSCoW – это аббревиатура для четырёх основных этапов приоритизации элементов в процессе разработки:
- «MUST». Первая буква означает те элементы, которые непременно должны быть включены в продукт, иначе он не будет выполнять наиболее важные функции и приносить пользователю ценность. Также к данной категории относятся требования законодательства, необходимые для реализации проекта. Эта категория имеет наивысший приоритет.
- «SHOULD». В данной группе находятся те элементы, которые следует включить в финальную версию продукта. Это те элементы, которые важны для заказчика, и продукт не будет полноценным, но при этом будет работать. Вторая группа по уровню приоритета.
- «COULD». Те элементы и опции, которые клиент хотел бы видеть в своём продукте. Наличие опций из этой группы приносит наибольшее удовлетворение клиенту или заказчику. Эти опции можно сказать, «вишенка на торте», имеют низкий приоритет, но для удовлетворения заказчика, необходимы.
- «WON’T». В эту группу включаются те опции, которые решено было не включать в нынешнюю версию продукта.
Рисунок 1. Пирамида MoSCoW
Когда элементы продукта сгруппированы, команда проекта проводит сравнительную оценку каждого из них при помощи story point – абстрактной единицы измерения, имеющей смысл только для данного конкретного проекта. На первом этапе выбирается элемент, для выполнения которого требуется наименьшее количество времени или сил. Сложность его выполнения принимается за 1 story point. То, что именно брать за базу, полностью зависит от команды и её особенностей. Главное, чтобы эта оценка отражала трудность и/или длительность работы над элементом. На следующем этапе проводится оценка оставшихся элементов путём сравнения их с базой.
После того, как все элементы были оценены, можно приступать к оценке всего проекта. Выглядит это следующим образом:
Мультипликаторы:
В заключении приведём пример, как примерно выглядит этот процесс:
Таким же образом можно произвести оценку затрат проекта или потребности в ресурсах.
Данный метод планирования проекта позволяет серьёзно снизить риски для владельца продукта. Даже если случится нечто непредвиденное, из-за чего дальнейшая реализация проекта будет невозможна, с высокой долей вероятности, клиент получит рабочую версию продукта.
После того, как все элементы были оценены, можно приступать к оценке всего проекта. Выглядит это следующим образом:
- Из элементов продукта выбираются 3-4 элемента с наименьшей степенью неопределённости.
- Команда проводит декомпозицию работ по каждому элементу, чтобы затем провести оценку времени, стоимости и ресурсов для реализации данного элемента в продукте. В данном случае требуется «идеальная» оценка времени и затрат, при самых благоприятных условиях.
- По результатам данной оценки определяется стоимость 1 story point’a в часах. Время работы над элементом делится на количество story point’ов. Если у взятых 3-4 элементов эти значения немного расходятся, чаще всего берут среднее значение. То же самое повторяется для оценки затрат.
- Сумма story point’ов по продукту умножается на стоимость в часах – таким образом получается предварительная оценка проекта. Аналогично проводится оценка затрат.
Мультипликаторы:
- Х*1.25 – Типовой проект. Такое значение авторы предлагают для случая, когда команда реализует привычный для них продукт, который они производили уже не раз, с минимальными отличиями. В таком случае степень неопределённости невысока, а команда уже знает о возможных трудностях, а потому их оценка требует лишь небольшой корректировки.
- Х*1.5 — Чётко определённый проект. Чтобы получить такой мультипликатор, проект должен иметь невысокую неопределённость, но не быть типовым для команды. Например, если у команды не так много опыта с конкретным типом продукта или клиент просить серьёзно модифицированный продукт, что вносит некоторую степень риска.
- Х*2.0 – Новые разработки. Данный мультипликатор используется в случае, если команда вынуждена столкнуться с чем-то абсолютно новым для себя в рамках работы над продуктом.
- Х*2.0 и выше – Быстрый старт. Используется тогда, когда нет времени на тщательную декомпозицию работ и проработку проекта. В таком случае проводится грубая оценка проекта с подобным мультипликатором.
В заключении приведём пример, как примерно выглядит этот процесс:
- Пусть суммарная оценка всего проекта составляет 150 story point’ов.
- Если проект чётко определён, то с учётом мультипликатора, оценка станет 225 story point’ов.
- Пусть 1 story point будет равен 10 часам. Тогда по плану, вся работа над нашим проектом должна уложиться в 2250 часов, или 282 рабочим дням.
Таким же образом можно произвести оценку затрат проекта или потребности в ресурсах.
Данный метод планирования проекта позволяет серьёзно снизить риски для владельца продукта. Даже если случится нечто непредвиденное, из-за чего дальнейшая реализация проекта будет невозможна, с высокой долей вероятности, клиент получит рабочую версию продукта.
Скачайте бесплатный мини-курс по Agile, Scrum и Kanban
Скачайте бесплатный мини-курс по Agile, Scrum и Kanban
Заполняя данную форму , вы даете согласие на обработку своих персональных данных, соглашаетесь с Политикой конфиденциальности и подписываетесь на новостную рассылку
Обучение Agile, Scrum, Kanban и международная сертификация ICAgile
Научитесь правильно применять Scrum и Kanban на практике, чтобы сделать рывок в карьере или бизнесе на ближайшем тренинге.
В результате обучения вы:
узнаете:
В результате обучения вы:
узнаете:
- принципы Agile и откроете для себя мир гибкого управления
- как управлять проектами и продуктами в условиях неопределенности с помощью гибких подходов
- как внедрить Agile в своей компании
- применять Scrum и Kanban на практике
- улучшить процессы своей команды и ускорить разработку продуктов
- претендовать на карьерное продвижение
- международный сертификат от консорциума ICAgile
- сертификат от Product Lab
Больше статей по теме
Получить консультацию
Заполните форму и получите ответы
на все вопросы.
на все вопросы.
Прорывной продукт быстрее, чем у конкурентов
Узнайте, как системно создавать продукты, которые взлетят, избегая распространенных ошибок!
БЕСПЛАТНО
МИНИ-КУРС