обеспечение, которое не делало то, чего хотел заказчик.
Типичный провал тяжеловесного процесса
Третьего февраля 2005 года Роберт С. Мюллер III, директор Федерального бюро расследований, предстал перед подкомитетом Сената США, чтобы объяснить, как ФБР умудрилось потратить впустую 104,5 миллиона долларов[7].
Это явно было не комфортно для компании. В июне 2001-го ФБР запустило проект VCF с целью заменить программное обеспечение для управления делами. Через четыре года он был отменен. Общие затраты составили 170 миллионов долларов; 104,5 миллиона из них были полностью невозвратными.
Сроки и последовательность событий проекта могут рассказать нам хорошо знакомую историю. Проект начался в июне 2001 года. Через 17 месяцев, в ноябре 2002-го, были определены «четкие требования». Программное обеспечение было поставлено год спустя, в декабре 2003-го, но «ФБР сразу обнаружило некоторое количество недостатков в VCF, которые делали его непригодным для использования». Подрядчик, разрабатывавший программу, согласился исправить недостатки, но только за дополнительную плату в размере 56 миллионов долларов и в срок один год. В конце концов ФБР отказалось от идеи исправлять недочеты, фактически перечеркнув годы работы.
Несмотря на существование большого разнообразия подходов к Agile (и некоторые из них больше используют популярное название, чем действительно следуют философии), у них есть кое-что общее. Они фокусируются на том, чтобы делать прогресс в работе видимым, позволяя всем стейкхолдерам проекта корректировать его на ходу. Казалось бы, это мелочь, но она невероятно эффективна. Именно благодаря ей мы больше не слышим о кризисе ПО. Сроки разработки программ все еще задерживаются. Бюджеты все еще перерасходуются. Но Agile-команды демонстрируют прогресс, используя работающие программы, а не документы. С самого начала. И это огромное достижение.
Agile имеет и другие преимущества, помимо наглядности процесса. Но даже одного этого оказалось достаточно, чтобы все захотели стать Agile.
Почему Agile работает
Первым прорывным успехом Agile стало экстремальное программирование, метод со слоганом «Примите изменения». В нем смешались здоровая доза философских размышлений о разработке программ и прагматичное стремление изменить ситуацию к лучшему. В предисловии к первой книге по экстремальному программированию было сказано:
«Если коротко, то экстремальное программирование обещает снизить риски проекта, улучшить отклик на потребности бизнеса и повысить продуктивность в течение всего срока жизни системы, сделать приятным создание ПО в команде – и все это одновременно. Это правда. Прекратите смеяться» [Beck2000a].
Одни действительно смеялись. А другие попробовали и обнаружили, что (вопреки всеобщему мнению о том, как должна вестись разработка ПО) экстремальное программирование реально выполняло все, что
Источники: Mueller’s February 3, 2005, testimony to Congress (https://oreil.ly/GlQSa) и Inspector General Glenn Fine’s May 2, 2005, testimony to Congress (https://oig.justice.gov/node/672).
