Искусство Agile-разработки. Теория и практика гибкой разработки ПО

Суть Agile

Мартин Фаулер сделал карьеру, превращая сложные вопросы о программировании в тщательно продуманные, беспристрастно точные объяснения. Его определение «Суть разработки программного обеспечения по Agile» – одно из лучших:

Agile-разработка является скорее адаптивной, чем предиктивной; ориентированной скорее на людей, чем на процессы[6 - Фаулер выражал эту идею множество раз в течение нескольких лет. Оригинальную версию можно найти в статье [Fowler2000].].

    Мартин Фаулер

Адаптивность вместо предиктивности

Помните, в CHAOS Report утверждалось, что всего одна шестая часть проектов в области программного обеспечения успешна? В отчете успешность определена очень специфическим образом:

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

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

неуспешный – проект отменен в какой-либо момент в течение цикла разработки.

Эти определения прекрасно иллюстрируют предиктивный тип мышления. Они все говорят о соответствии запланированному. Если вы сделали то, что собирались сделать, то вы успешны. А если нет, то неуспешны! Все просто.

На первый взгляд, это разумно. Но посмотрим повнимательнее. Тут чего-то не хватает. Райан Нельсон писал в журнале CIO Magazine [Nelson2006]:

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

Команды Agile определяют успех как поставку ценности, а не соответствие плану. Фактически команды, действительно достигнувшие Agile, активно ищут возможности повысить ценность продукта, изменив планы.

Взгляните еще раз на Манифест (см. рис. 1.1 и 1.2). Найдите пару минут, чтобы вдумчиво изучить ценности и принципы Agile.