требований, однако контрактные рамки позволяют цивилизованно и к обоюдной выгоде разрешать такие отклонения. Документирование требований, в частности, являющееся приложением к контракту, эти рамки создает.
«Готовность к изменениям важнее следования первоначальному плану» указывает, как и предыдущее, что изменения неизбежны и к ним нужно быть готовыми. Тем не менее, чтобы изменить первоначальный план, его нужно сначала выстроить. А если изменять планы и не отслеживать (документировать) отклонения, вполне возможно начать ходить по кругу, зациклиться в изменениях, и цель не будет достигнута.
Таким образом, Agile придерживается позиции постоянной готовности к изменениям ради движения к цели в целом, и, для обеспечения этого, предлагает использование разумного объема документирования, исходя из текущей ситуации (и этот объем может меняться по ходу работ вместе с ситуацией).
Agile позволяет совместить преимущества ранее описанных подходов «со слов» и письменной спецификации, устранив часть недостатков.
Однако, существенным ограничением применения Agile является существование факторов, влияющих на него, которые невозможно изменить в ходе проекта. Это могут быть как внутренние ограничения, например, размер бюджета или нормативные акты внутри компании, так и внешние, например, требования законодательства.
Выявление таких требований на поздних этапах разработки может привести к необходимости начать ее полностью или в значительной части с начала, что никак не приближает к цели, поэтому «полный Agile», исключающий такие факторы из рассмотрения может быть успешен лишь на небольших обособленных задачах.
Наш опыт свидетельствует, что оптимальным является подход письменной спецификации общей структуры решения с последующими Agile итерациями в реализации отдельных задач. В этом случае минимизируется риск не учета в требованиях существенных факторов, влияющих на процесс, но сохраняются преимущества и гибкость Agile подхода при решении частных задач.
Когда же разумно начинать разработку?
Привести формальный критерий начала разработки и просто, и сложно одновременно. Кажется, что чем быстрее начнем разработку, тем быстрее придем к цели.
И это было бы верно, если бы путь к цели был фиксирован, а его длительность и затраты не зависели от исходной постановки требований. Увы, зависимость есть, и она не линейна. Вплоть до того, что при существенных неточностях можно двигаться кругами сколь угодно долго.
Поэтому нужен какой-то критерий. Сформулировать его нам поможет представление о рисках проекта, которое поверхностно сводится к тому, что:
– выполняя какую-то работу для снижения рисков, мы тратим дополнительно ресурсы и время, но верим, что возможные затраты ресурсов и времени на ликвидацию последствий срабатывания риска существенно выше, а вероятность срабатывания не позволяет риском пренебречь.
– не делая ничего для снижения риска, мы
