Адаптивность вместо предиктивности
Помните, в CHAOS Report утверждалось, что всего одна шестая часть проектов в области программного обеспечения успешна? В отчете успешность определена очень специфическим образом:
• успешный – проект выполнен вовремя и в рамках бюджета, все характеристики и функциональности соответствуют изначально запланированным;
сомнительный – проект завершен, результаты переданы в эксплуатацию, но количество характеристик и функциональностей меньше, чем было заявлено изначально. Запланированные бюджет и сроки проекта превышены;
неуспешный – проект отменен в какой-либо момент в течение цикла разработки.
Эти определения прекрасно иллюстрируют предиктивный тип мышления. Они все говорят о соответствии запланированному. Если вы сделали то, что собирались сделать, то вы успешны. А если нет, то неуспешны! Все просто.
На первый взгляд, это разумно. Но посмотрим повнимательнее. Тут чего-то не хватает. Райан Нельсон писал в журнале CIO Magazine [Nelson2006]:
Как обнаружилось, проекты, отвечающие всем традиционным критериям успешности – время, бюджет и технические спецификации, – могут по завершении все же быть провальными, поскольку оказываются неактуальными для пользователей, которым предназначались, или потому, что в итоге не приносят особых выгод бизнесу… С другой стороны, проекты, считающиеся неуспешными согласно традиционным метрикам информационных технологий, могут оказаться успешными, поскольку, несмотря на проблемы с бюджетом, графиком или техническими характеристиками, получившаяся система нравится конечным пользователям или имеет какую-либо непредвиденную ценность.
Команды Agile определяют успех как поставку ценности, а не соответствие плану. Фактически команды, действительно достигнувшие Agile, активно ищут возможности повысить ценность продукта, изменив планы.
Взгляните еще раз на Манифест (см. рис. 1.1 и 1.2). Найдите пару минут, чтобы вдумчиво изучить ценности и принципы Agile. Сколько из них относятся к поставкам ценного программного обеспечения и адаптации к полученной обратной связи?
Ориентированность на людей, а не на процессы
В случае тяжеловесных процессов люди пытались избежать ошибок, тщательно определяя каждый аспект разработки ПО. При добавлении в процессы регламента индивидуальные навыки становились менее важными. В теории вы могли применять один и тот же процесс снова и снова с разными людьми и получать одни и те же результаты. (Если вдуматься, то они и получали. Просто не те результаты, которые хотели.)
Agile заявляет, что люди – главный фактор успеха в разработке программного обеспечения. Не только их знания и навыки, но и все аспекты человеческой природы. Насколько хорошо сработались члены команды. Насколько часто они отвлекаются. Насколько комфортно и безопасно для них высказывать свое мнение. Насколько они увлечены своей работой.
У Agile-команд тоже есть процессы (у любой команды они есть, пусть и неявные), но они находятся на службе у человека, а не наоборот. И Agile-команды сами отвечают за свои процессы. Желая улучшить методы работы, люди меняют процессы.
Посмотрите на Манифест еще раз (см. рис. 1.1 и 1.2). Какие ценности и принципы имеют отношение к концепции «люди на первом месте»?
Почему Agile победил
В течение первых десяти лет после появления Манифеста Agile столкнулся с небывалой критикой. Его называли «недисциплинированным». Говорили, что он никогда не будет работать. Следующие десять лет критики молчали. Agile был уже везде, по крайней мере это название. Тяжеловесные водопадные методы практически умерли. Молодые программисты вообще не верили в то, что кто-то когда-то мог работать таким образом.
Не то чтобы основанные на фазах процессы неполноценны по сути. У них, безусловно, есть свои недостатки, но если ограничивать их объем, при этом действуя в хорошо изученной предметной области, то методы водопадного стиля тоже могут работать. Проблема была в самом тяжеловесном процессе, который применяли крупные компании. Словно по иронии судьбы, процессы, предназначенные для того, чтобы избегать проблем, на самом деле сами вызывали большинство проблем, с которыми сталкивались компании.
Трудно представить, как будет работать программа, до того, как вы начнете ее использовать на практике, и еще тяжелее продумать абсолютно все, что она должна будет делать. И это вдвойне сложнее для людей, которые не вовлечены в разработку программного обеспечения. В результате критически важно как можно скорее предоставить людям работающую программу. Вам просто необходимо получить от них обратную связь о том, что не работает и чего не хватает, и затем скорректировать ваши планы в зависимости от полученной информации. Как говорится в Манифесте, «работающее программное обеспечение – основной показатель прогресса». Получение информации и реакция на изменения лежат в основе всего того, что называется Agile.
В случае тяжеловесных процессов придавалось настолько большое значение контролю над процессами и согласованию документации, что порождались значительные задержки и расходы. На то, чтобы получить работающее ПО, уходили годы, и заказчику не показывали ничего конкретного почти до самого конца проекта. Вместо того чтобы приветствовать изменения, в этих процессах делалось все, чтобы их избежать. Была даже отдельная составная часть процессов «Совет по контролю за изменениями» (Change Control Board), чьей основной задачей было сказать «нет» запросам на изменения. (Точнее, «да, но за это понадобится доплатить».)
Все это наслаивалось друг на друга в проектах, где люди годами вели разработку, прежде чем могли что-то показать клиенту. И когда они это делали, было уже слишком поздно и дорого что-то менять. В конечном итоге они выдавали программное обеспечение, которое не делало то, чего хотел заказчик.
Типичный провал тяжеловесного процесса
Третьего февраля 2005 года Роберт С. Мюллер III, директор Федерального бюро расследований, предстал перед подкомитетом Сената США, чтобы объяснить, как ФБР умудрилось потратить впустую 104,5 миллиона долларов[7].
Это явно было не комфортно для компании. В июне 2001-го ФБР запустило проект VCF с целью заменить программное обеспечение для управления делами. Через четыре года он был отменен. Общие затраты составили 170 миллионов долларов; 104,5 миллиона из них были полностью невозвратными.
Сроки и последовательность событий проекта могут рассказать нам хорошо знакомую историю. Проект начался в июне 2001 года. Через 17 месяцев, в ноябре 2002-го, были определены «четкие требования». Программное обеспечение было поставлено год спустя, в декабре 2003-го, но «ФБР сразу обнаружило некоторое количество недостатков в VCF, которые делали его непригодным для использования». Подрядчик, разрабатывавший программу, согласился исправить недостатки, но только за дополнительную плату в размере 56 миллионов долларов и в срок один год. В конце концов ФБР отказалось от идеи исправлять недочеты, фактически перечеркнув годы работы.
Несмотря на существование большого разнообразия подходов к Agile (и некоторые из них больше используют популярное название, чем действительно следуют философии), у них есть кое-что общее. Они фокусируются на том, чтобы делать прогресс в работе видимым, позволяя всем стейкхолдерам проекта корректировать его на ходу. Казалось бы, это мелочь, но она невероятно эффективна. Именно благодаря ей мы больше не слышим о кризисе ПО. Сроки разработки программ все еще задерживаются. Бюджеты все еще перерасходуются. Но Agile-команды демонстрируют прогресс, используя работающие программы, а не документы. С самого начала. И это огромное достижение.
