Московский метод

Начну с истории из реальной жизни. Был у нас один заказчик, который предпочитал сам выставлять приоритеты требованиям и багам. Все начиналось классически — High, Medium, Low. Однако в какой-то момент он решил усовершенствовать эту систему и добавил Very High. Но со временем и этого оказалось мало, появился приоритет Urgent. Наверное, это может продолжаться и дальше.

MoSCoW methodВ другом проекте, при приоритизации требований, использовались аналогичные приоритеты (1,2,3). И нам как разработчикам не всегда удавалось определить логику которая двигала людьми из бизнеса при приоритизации, особенно вызывал внутренний конфликт высокий приоритет юзабилити требований, при низких приоритетах функциональных.

Однако прогресс не стоит на месте. И один из консультантов Oracle UK Consulting, Dai Clegg предложил логичный и понятный метод приоритизации для бизнес анализа и разработки ПО — MoSCoW prioritization.

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

MoSCoW — легко запоминающаяся аббревиатура:

M — MUST have this.

S — SHOULD have this if at all possible.

C — COULD have this if it does not affect anything else.

W — WON’T have this time but WOULD like in the future.

Must have — Жизненно необходимые

Требования отмеченные как MUST have должны быть включены в текущую поставку. Если хоть одно из требований не сделано, поставка считается провальной.

Should have — Обязательные

Требования SHOULD have также критичны для успеха проекта, но не необходимы в ближайших поставках. Такие требования имеют workarounds, то есть имеются обходные пути для выполнения требований, и могут быть отложены на будущие поставки продукта.

Could have — Пожалуй можно реализовать

Требования COULD have менее критичные требования, обычно относящиеся к «nice to have». Чаще всего менее трудоёмки чем первые 2 категории.

Won’t have (but Would like) — Можно и не делать, но хотелось бы

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

Ссылки:

http://en.wikipedia.org/wiki/MoSCoW_Method

http://www.projectsmart.co.uk/moscow-method.html

http://www.coleyconsulting.co.uk/moscow.htm

One Comment

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *