Жизненные циклы поставки решения

Главные идеи#

Подход определяют два вопроса#

Книга BCS предлагает сначала посмотреть на контекст: организационную культуру, бизнес-причину изменения, ограничения проекта и движущие факторы — например, срок, установленный регулятором, или гонку за конкурентным преимуществом. Затем выбор сужают два вопроса:

• Поставка: один релиз или несколько инкрементов?
• Разработка: может ли команда тесно работать с бизнес-пользователями и достаточно ли ясны требования, чтобы определить их заранее?

Ракурс информационных технологий в Руководстве BABOK® проводит похожую границу между предиктивными подходами (структурированными, формально документированными, последовательными) и адаптивными (итеративными и инкрементными), а между ними есть гибриды.

Каскадная модель (waterfall)#

Этапы идут последовательно: технико-экономическое обоснование, анализ, проектирование, разработка, тестирование, внедрение. Каждый этап опирается на подписанные результаты предыдущего. Аналитик в основном участвует в обосновании и анализе, а затем снова — в приёмочном тестировании и поддержке внедрения.

• Сильная сторона: строгий контроль на каждом этапе, что поддерживает качество.
• Слабая сторона: долгий цикл, в течение которого бизнес ждёт, а изменения дороги, потому что приходится пересматривать целую цепочку документов.

V-модель#

Вариант каскадной модели, «сложенный» после этапа разработки, чтобы показать, какой этап тестирования проверяет какой из ранних этапов: пользовательская приёмка проверяет требования, системное тестирование — проект решения, модульное тестирование — модули. Расширенная V-модель добавляет слева анализ бизнес-потребностей и бизнес-кейс, а справа — обзор выгод. В этой версии аналитик участвует на всём протяжении: от определения потребностей через поддержку проектирования и оценку влияния до приёмки и обзора выгод.

Инкрементная поставка#

Анализ и высокоуровневое проектирование выполняются один раз для всего решения; затем решение создаётся, тестируется и развёртывается несколькими инкрементами, начиная с самых срочных требований. Книга BCS предупреждает о скрытой цене: общая стоимость выше, чем при единой поставке, потому что каждый инкремент требует регрессионного тестирования, а высокоуровневый проект должен предусматривать последующие инкременты, иначе ранние придётся переделывать.

Спиральная модель#

Спиральная модель Боэма (1986) не требует полного набора требований на старте. На каждом витке по приоритету согласуется набор требований, технические варианты и риски исследуются через прототипы вместе с бизнес-пользователями, прототип оценивается и на его основе создаётся решение, после чего развёртывается релиз или инкремент. Книга BCS называет причины, по которым итеративные подходы стали популярны: нет времени заранее определить всё; бизнес часто сам точно не знает, чего хочет, особенно в новых областях; ранние результаты помогают сохранить поддержку заинтересованных сторон; когда бизнес быстро меняется, требования быстро устаревают.

По мнению книги BCS, наиболее гибкий вариант — сочетание итеративной разработки с инкрементной поставкой.

Unified Process и Agile#

Unified Process — итеративный и инкрементный процесс, который настраивается под каждую организацию и даёт рекомендации по применению UML (см. RUP: коротко). Гибкие методы (Agile), такие как DSDM Atern и Scrum, отвечают на быстро меняющиеся потребности бизнеса и оставляют свободу в выборе того, как реализовать каждое требование. Книга BCS приводит правило 80/20: 80% полного решения часто можно поставить за 20% усилий, нужных для полной разработки. Ключевые техники — эволюционное прототипирование, тайм-боксинг и приоритизация по MoSCoW. Возврат к предыдущим шагам — норма, а не исключение, требующее формального управления изменениями. Книга также предупреждает, что прототипы без должной документации и тестирования создают проблемы в эксплуатации.

MoSCoW и инкременты#

Книга BCS связывает категории MoSCoW с инкрементной поставкой:

Покупка или разработка#

Готовые пакеты (COTS) обычно дешевле, быстрее внедряются, поддерживаются вендором и обновляются вслед за изменениями законодательства. Но они никогда не подходят идеально: приходится либо адаптировать свои процессы, либо платить за доработку, а пакет, доступный конкурентам, редко даёт конкурентное преимущество. Книга BCS советует, чтобы требования к пакету описывали, что нужно, а не как, и чтобы организация была готова адаптировать свои процессы.