Когда химик изобретает новую химическую реакцию, которая преобразует одно вещество в другое, он пишет документ, в который входит раздел «Рамки и ограничения», где описывает, что получится и не получится в результате этой реакции. Точно так же для проекта по разработке ПО следует определить его рамки и ограничения.
Вам необходимо указать, что может делать система, а что не может.
Многие проекты страдают «распуханием границ» — резким ростом из-за активного расширения функциональности продукта. Первый шаг на пути к обузданию распухания границ — определение рамок проекта. Границы проекта определяют концепцию и круг действия предложенного решения. В ограничениях указываются определенные возможности, которые не будут включены в продукт. Рамки и ограничения помогают установить реалистичные ожидания заинтересованных лиц, потому что иногда клиенты запрашивают функции, слишком дорогостоящие или выходящие за предполагаемые границы продукта.
Рамки проекта могут представляться различными способами. На самом высоком уровне границы определяются, когда клиент решает, какие бизнес-цели преследовать. На низком уровне границы определяются на уровне функций, пользовательских историй, вариантов использования или событий и реакции на них.
В конечном итоге границы определяются через набор функциональных требований, которые планируется реализовать в определенном выпуске или итерации. На каждом уровне границы не должны выходить за рамки более высокого уровня.
Например, находящиеся в границах пользовательские требования должны соответствовать бизнес-целям, а функциональные требования — пользовательским требованиям в заданных границах.
Однажды менеджер в компании-разработчике, проект которого страдал от практически катастрофического распухания границ, печально сказал: «Мы слишком нереалистично отнеслись к требованиям». Он имел в виду, что все идеи, какие у кого-либо были, включили в требования. У компании крепкая концепция продукта, но в ней не управляли границами проекта путем планирования серии выпусков и откладывания некоторых функций на более поздние выпуски (или навсегда). В конце концов, команда выпустила «перекачанный» продукт лишь после четырех лет разработки.
Может оказаться ценным учесть нереалистичные требования в будущих выпусках, но вдумчивое управление границами проекта и поэтапный подход к разработке позволил бы команде выпустить продукт намного раньше.
Опишите основные функции продукта или возможности пользователей, уделив основное внимание тому, что отличает продукт от предыдущей версии или конкурирующих продуктов.
Подумайте, как пользователи будут работать с этими функциями, чтобы убедиться, что список функций полон и не содержит ненужных функций, которые интересны, но не приносят пользы пользователям. Назначьте каждой функции уникальное и постоянное название, чтобы ее можно было отслеживать в других компонентах системы. Можно создать древовидную схему, как показано далее в этой главе.
Обобщает основные запланированные функции, включенные в первоначальную версию продукта. Границы проекта обычно определяются как набор функций, но их можно также определять в терминах пользовательских историй, вариантов использования, потоков вариантов использования или внешних событий. Также можно описать характеристики качества, которые позволят продукту предоставлять предполагаемые преимущества различным классам пользователей.
Если ваша задача — сосредоточиться на разработке и уложиться в график, вам следует избегать искушения включить в версию 1.0 каждую функцию, которая когда-нибудь в будущем может понадобиться какомуто потенциальному покупателю. Распухание кода и сдвиг графика — типичные исходы такого коварного набивания объема. Сосредоточьтесь на наиболее ценных функциях, имеющих максимально приемлемую стоимость, годных для самой широкой целевой аудитории, которые удастся создать как можно раньше.
В качестве иллюстрации приведем недавний проект, в котором команда решила, что пользователи должны иметь возможность запускать собственную службу доставки в первой версии ПО. Версия 1 не обязательно должна быть быстрой, красиво оформленной или легкой в использовании, но она должна быть надежной; этим принципам команда следовала четко. Первая версия системы выполняет лишь основные задачи. В будущие выпуски будут включены дополнительные функции, возможности и средства, обеспечивающие легкость и простоту использования. Но в первом выпуске важно не забыть о нефункциональных требованиях. Тех, что непосредственно влияют на архитектуру, их особенно важно установить с самого начала. Переделка архитектуры для исправления недостатков качества может стоить столько же, сколько написание продукта с нуля.
Если вы ожидаете поэтапную эволюцию продукта или если используете итеративную модель разработки, создайте план выпуска, в котором укажите, какие функции будут отложены и желательные сроки последующих выпусков. В последующих версиях вы сможете реализовать дополнительные варианты использования и функции и расширить возможности первоначальных вариантов использования и функций. Чем дальше вы заглядываете, тем более расплывчатыми будут границы проекта. Вам наверняка придется передвинуть функциональность с одного запланированного выпуска до другого и, возможно, добавлять незапланированные функции. Короткие циклы выпусков часто предоставляют удобные случаи для накопления знаний, основанных на отзывах клиентов.
Перечислите все возможности или характеристики, которых могут ожидать заинтересованные в проекте лица, но включение которых в продукт или в определенную версию не запланировано.
Перечислите изъятые элементы, чтобы не забыть решения по границам проекта. Если пользователь запросил возможность доступа к системе с телефона, когда он не находится на рабочем месте, и эта функция была признанной не входящей в границы проекта, тогда четко запишите в соответствующем разделе: «Новая система не поддерживает доступа с мобильных устройств».
| 1. Бизнес-требования | 3. Бизнес-контекст |