Responding to change over following a plan
А это самый простое убеждение аджайлиста. Следуй изменениям, чем установленному плану. С одной стороны это самое простое убеждение из четырёх, которыеми следует истинный аджайлист. Но с другой это самый большой вызов команде. Конечно же, кому нужна программа по согласованному плану, когда требования рынка другие. Важнее получить продукт как можно быстрее и как можно более соответствующий нащих текущим нуждам, а не тем нуждам, которые были год назад во время согласования плана.
Классический пример: нам поставили задачу. Мы её декомпозировали. Запланировали ресурсы. Прибросили проект. Нарисовали архитектуру и понеслось. Но уже через 2-3 недели реальной разработки начинают появляться непонятки, куда прикрутить то или иное. Заказчик изменил требования и вся наша разработка начала плыть. А плыть она начала, что в классическом подходе не закладывается идея, что все может поменяться. Мы конечно делаем up-front дизайн, чтобы предусмотреть все, что только можно. Но тяжесть самого up-front дизайна начинает очень сильно давить. И мы начинаем теряться, мы полезный функционал реализуем, или поддерживаем гибкость дизайна. Парадоксально. Но заказчик не платит за гибкость дизайна, он платит за функционал.
Отвечать изменяющимся требованиям - это вызов. Только сильные команды готовы работать следуя такому убеждению. Это отличает аджайл команды от других. Конечно классический подход защищается от изменений. Там это все оцениваться и вводиться целый процесс - "процесс управления изменяющимися требованиями". В аджайле же поступают проще, и в тоже время сложнее.
Для того, чтобы заказчик был удовлетворён, конечно же нужно реагировать на изменяющиеся требования. Мы должны создать не только архитектуру, которая может поддерживать такие изменения. Мы должны создать культуру разработки, которая позволяет следовать изменяющимся требованиями. Мы должны создать культуру - "разработка посредством меняющихся требований". Очень просто породить хаос и потерять контроль на приложением в такой ситуации. Стоит вопрос - как можно быть готовым к такому?
Ответ - очень простой. Ответ я дам, но попробуйте сами догадаться, как этот ответ влечёт гибкость разработки и её качества, даже в условиях постоянно меняющихся требования:
1. Custom collaboration
2. Release planning.
3. Demo meetings.
4. Test Driven Design.
5. FIT and acceptance testing
6. Modeling sessions.
7. Refactoring.
8. Continuous Integration
9. Pair Programming
10. Simple design
... Ваш вариант :)
Возьмём первый случай. Присутствие клиента в команде, тесное сотрудничество с ним сделает возможность не просто делать гибкое программное обеспечение и бороться с изменяющимися требованиями. А вы станете клиентом, вам легче будет стать экспертом и партнером в его бизнесе. И тогда не нужно будет управлять изменениями требований, вы будете создателями требований. И будете чувствовать, ожидать и знать все что может вам сказать вам клиент намного заранее.
Вывод следующей - совокупность данных техник позволяет создать окружение, которое не просто может переносить изменение требований. А живёт посредством изменяющихся требований.
Вопрос для обсуждений: А как вы думаете - какие практики и подходы позволяют аджайлисту реализовать данное убеждение и почему?