Краткий ответ
Выбор стоит не между двумя идеологиями, а между двумя типами решений. Существуют решения, стоимость изменения которых резко возрастает со временем — модель данных, разрешения, интеграции — и их необходимо фиксировать на ранней стадии. И есть решения, стоимость изменения которых низка — экраны, поля, отчеты, формулировки — и их предпочтительнее определять по ходу проекта.
Отсюда следует, что модель, которая эффективно работает в большинстве проектов Salesforce, является гибридной не из компромисса, а из-за своей структуры: фиксированная основа, итеративное содержание.
Три определяющих фактора
| Фактор | Способствует раннему планированию | Способствует итерациям |
|---|---|---|
| Четкость процесса | Регламентированный и документированный процесс | Изменяющийся или несогласованный процесс |
| Доступность пользователей | Низкая, ограниченное время | Высокая, возможность еженедельного обзора |
| Регуляторное воздействие | Аудит, соответствие, одобрения | Минимальное |
Второй фактор более решающий, чем принято считать. Agile без доступности пользователей — это не Agile; это серия спринтов, по окончании которых ничего не проверялось, и вся обратная связь поступает на UAT сразу.
Гибридная структура на практике
Эффективный подход разделяет проект на две части с разным темпом:
Этап формирования основы (4-6 недель, плановый) – модель данных, модель разрешений и видимости, карта интеграций, стратегия миграции, а также определение процессов, которые войдут в первый этап. Результаты документируются и утверждаются.
Этапы поставки (двухнедельные спринты) – каждый этап обеспечивает полный сценарий для профиля пользователя, включая тестирование и обратную связь. Изменения внутри этапа не требуют повторного утверждения, если они не затрагивают основу.
Правило, которое поддерживает эту структуру: изменение основы — это управляемое решение, изменение содержания — это текущая работа. Без этого различия каждый мелкий запрос попадает в управляющий комитет, а каждое структурное изменение остается незамеченным.
Где каждая модель дает сбой
Чистый Waterfall дает сбой на этапе UAT: разрыв между тем, что было написано в документе полгода назад, и тем, что ожидает пользователь, обнаруживается слишком поздно для дешевых исправлений.
Чистый Agile дает сбой в модели данных: после шести спринтов локальных решений обнаруживается, что структура не поддерживает межпроцессную отчетность, и исправление требует миграции.
Гибридная модель дает сбой, когда основа не была по-настоящему завершена — когда она является "основой" только по названию, но открывается заново на каждом этапе. В этом случае получаются недостатки обеих моделей.
Что измерять по ходу проекта
Трех показателей достаточно, чтобы понять, работает ли модель: соотношение между завершенными и повторно открытыми элементами, время от получения обратной связи от пользователя до исправления, и количество изменений, затронувших основу. Рост третьего показателя является самым ранним признаком того, что раннее планирование было поверхностным. Связь с управлением объемом работ подробно описана в статье Scope Creep и контроль изменений, а сроки – в статье График проекта Salesforce.
Заключение
Верный вопрос не в том, какая методология более современна, а в том, какие решения в данном проекте дорого изменять на поздних этапах. Тот, кто умеет на него ответить, получает модель поставки почти автоматически — и почти всегда это гибридная модель с четкой границей между основой и содержанием.