Управление изменениями требований

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

Изменения — не враг#

Определить все требования заранее невозможно, а рынки, нормативы и потребности бизнеса меняются по ходу проекта. Цель — сделать изменения видимыми и осознанными. Настоящая опасность — изменения «с чёрного хода»: разработчик тихо соглашается на просьбу пользователя и обходит процесс. Вигерс и Битти описывают заказчика и подрядчика, чьи закулисные договорённости такого рода закончились судом.

Разрастание границ#

Разрастание границ (scope creep) — это новая функциональность или существенная модификация, предложенная после того, как появилась базовая версия требований (baseline), то есть согласованный и утверждённый набор. Ссылаясь на Каперса Джонса (Capers Jones), авторы отмечают, что требования в проектах информационных систем обычно растут на 1–3% в месяц. Болезнь — не сам рост, а рост без корректировки графика, ресурсов или качества. Защита: задокументированные бизнес-цели и границы как фильтр для каждого запроса, участие заказчика в выявлении, прототипы, короткие инкрементные циклы и умение сказать «нет» или «не сейчас, возможно, в одном из следующих релизов». Заморозить требования сразу после первого раунда выявления — противоположная ошибка.

Короткая политика#

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

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

Совет по управлению изменениями#

Совет по управлению изменениями (change control board, CCB) — группа, а иногда один человек, которая принимает решение по каждому запросу. Держите его небольшим. Включите в него управление продуктом или аналитику, разработку, тестирование, заказчика или маркетинг и поддержку. В крупных программах бывает два уровня: советы проектов для локальных вопросов и совет программы для межпроектных вопросов и превышения бюджета или сроков. Напишите короткий устав: цель, границы полномочий (что совет решает сам, а что передаёт выше), состав, периодичность заседаний, кворум и правило принятия решений.

Типичные роли: председатель, члены совета, оценщик (проводит анализ влияния), исполнитель изменения, инициатор, приёмщик запросов (единая точка входа) и проверяющий. В небольших проектах один человек совмещает несколько ролей.

Жизненный цикл запроса#

Подан → Оценён → Утверждён, Отклонён или Отменён → Изменение внесено → Проверен → Закрыт. Неудачная проверка возвращает запрос назад. Переводите запрос в следующий статус, только когда выполнены критерии выхода текущего шага.

Анализ влияния#

Прежде чем сказать «конечно, без проблем»: 1. Поймите последствия: конфликты с другими требованиями или с базовой версией, влияние на атрибуты качества и график, а также риск того, что изменение не будет внесено. 2. Найдите все затронутые элементы: требования, экраны, отчёты, базу данных, дизайн, код, файлы сборки, тесты, документацию, сторонние компоненты, планы проекта. 3. Перечислите задачи и оцените трудоёмкость.

Пример авторов: «простая» правка текста сообщения об ошибке в одной из языковых версий продукта превысила максимальную длину поля — и на экране, и в базе данных.

Измеряйте изменения#

Отслеживайте открытые и закрытые запросы, добавленные, удалённые и изменённые требования, а также запросы по источникам. График изменчивости (число новых запросов в неделю после фиксации базовой версии) по мере приближения поставки должен падать к нулю; если он остаётся высоким, исправляйте выявление, а не только управление изменениями. График источников даёт нейтральную, основанную на фактах почву для разговора с подразделением, от которого приходит больше всего изменений.

В гибких проектах#

Кросс-функциональная гибкая команда уже работает как CCB, а короткие итерации делают каждое изменение небольшим. Команды сами решают, замораживать ли содержимое итерации или допускать корректировки; если изменения посреди итерации случаются часто, сократите итерации. Решения по бэклогу принимает владелец продукта, но изменения общих границ, бюджета или сроков по-прежнему уходят на уровень выше.