Требования в проектах доработки и замены систем

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

Чем отличаются такие проекты#

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

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

Знакомые техники, особые цели#

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

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

Приоритизация по бизнес-целям#

В проектах доработки следите за «позолотой» (лишними функциями, о которых никто не просил), выдаваемой за улучшение; в проектах замены — за разрастанием границ (scope creep): «раз уж мы всё равно переделываем…». Не переносите функции по умолчанию. Спросите пользователей, пользуются ли они функцией на самом деле, и проверьте данные об использовании.

Анализ расхождений#

Анализ расхождений (gap analysis) сравнивает существующую и желаемую систему. Для замены авторы делят требования на четыре группы: переносятся без изменений, переносятся с изменениями, новые и исключаемые. Затем приоритеты закрытия расхождений расставляют обычными техниками.

Сохраните уровень производительности#

Модель ключевых показателей эффективности (KPIM) Битти и Чена (Chen) связывает шаги бизнес-процесса с показателями, которые заинтересованные стороны рассчитывают сохранить или улучшить. Поучительный случай от авторов: задание синхронизации, которое изначально выполнялось примерно за час и спокойно укладывалось в срок ранним утром, после серии «улучшений» стало занимать около 20 часов. Все подразумевали ограничение по времени, но никто никогда не записал его как требование.

Программная археология#

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

Итерации — с осторожностью#

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

Принятие и переход#

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