Гибкие методологии дают вашей команде получать отклик о разрабатываемом продукте. В этом вся суть. Обратная связь работает на разных уровнях. Разработчики, практикующие парное программирование, получают непосредственную оценку своего кода. "Истории" представляют собой участки работы, на которых разработчики получают обратную связь от тестировщиков и аналитиков. Итеративные релизы позволяют команде получить отклик снаружи. Большинство гибких техник ценны в первую очередь тем, что создают потоки обратной связи, помогающие команде реагировать на изменения.

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

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

В недавнем проекте мы сформулировали "истории" так, что они были понятны каждому. Аналитики, тестировщики и разработчики - все были способны понять и оценить конкретные истории. Тем не менее, нам пришлось сгруппировать их в укрупненные функциональные возможности, чтобы получить адекватную обратную связь от людей, не входящих в команду. Прежде чем попросить отзыв о функционале, мы добивались реализации всех историй, в нем участвующих.

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

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

Сами по себе гибкие мектодологии ничуть не быстры. От них бывает отдача только в окружении, понимающем пользу изменений. И это понимание должно распространяться до самых верхов, оплачивающих проект. Недостаточно иметь "гибкую" команду разработчиков, спонсоры тоже должны быть гибкими. Действительно ли все требования так необходимы? Представляете ли вы уже сейчас, как должен выглядеть продукт?

Аджайл дает быстрые результаты засчет того, что обратная связь позволяет выделить наиболее важную функциональность и сконцентрироваться на ней. Если кажется, что вы точно знаете, что должны получить в результате - это не аджайл. Если тебе некогда собрать и обработать отзывы клиентов, это тоже не гибкий процесс. Думаешь, что все точно понимают с самого начала проекта, что должно получиться? Не аджайл.

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

Переведено на Нотабеноиде
http://notabenoid.org/book/3234/10402

Переводчики: rlabs