«Готовность к изменениям важнее следования первоначальному плану» указывает, как и предыдущее, что изменения неизбежны и к ним нужно быть готовыми. Тем не менее, чтобы изменить первоначальный план, его нужно сначала выстроить. А если изменять планы и не отслеживать (документировать) отклонения, вполне возможно начать ходить по кругу, зациклиться в изменениях, и цель не будет достигнута.

Таким образом, Agile придерживается позиции постоянной готовности к изменениям ради движения к цели в целом, и, для обеспечения этого, предлагает использование разумного объема документирования, исходя из текущей ситуации (и этот объем может меняться по ходу работ вместе с ситуацией).

Agile позволяет совместить преимущества ранее описанных подходов «со слов» и письменной спецификации, устранив часть недостатков.

Однако, существенным ограничением применения Agile является существование факторов, влияющих на него, которые невозможно изменить в ходе проекта. Это могут быть как внутренние ограничения, например, размер бюджета или нормативные акты внутри компании, так и внешние, например, требования законодательства.

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

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

Привести формальный критерий начала разработки и просто, и сложно одновременно. Кажется, что чем быстрее начнем разработку, тем быстрее придем к цели.

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

Поэтому нужен какой-то критерий. Сформулировать его нам поможет представление о рисках проекта, которое поверхностно сводится к тому, что:

– выполняя какую-то работу для снижения рисков, мы тратим дополнительно ресурсы и время, но верим, что возможные затраты ресурсов и времени на ликвидацию последствий срабатывания риска существенно выше, а вероятность срабатывания не позволяет риском пренебречь.

– не делая ничего для снижения риска, мы понимаем и принимаем необходимые затраты ресурсов и времени на устранение последствий срабатывания риска с учетом его вероятности и готовы в случае срабатывания эти затраты понести или смириться с тем, что проект не достигнет цели. Причины могут быть самые разные, начиная от реальной невозможности что-то сделать и до обычной лени и самоуверенного игнорирования риска, но важен результат – не делаем.

Начать разработку означает «начать что-то делать» для снижения риска «не разработать никогда, потому что не начали», а этот риск реален. Для проекта этот риск выглядит скорее с временным ограничением – «не успеть разработать вовремя».

Не начать разработку, но уточнять требования, означает «делать что-то» для снижения риска «разработать не то, что нужно, но потратить ресурсы и время».

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