Kitobni o'qish: «Искусство Agile-разработки. Теория и практика гибкой разработки ПО», sahifa 2

От издательства

Ваши замечания, предложения, вопросы отправляйте по адресу comp@piter.com (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.

I
Улучшая гибкость

Глава 1. Что есть Agile

Agile везде. И, как ни парадоксально, нигде.

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

Исправим это.

Происхождение Agile

В 1990-е считалось, что разработка ПО находится в кризисе. Это явление так и называлось: «Кризис программного обеспечения». Проекты разработки выходили за рамки бюджетов, задерживались, не отвечали требованиям, и (согласно часто цитируемому и зловеще именуемому «Отчету о Хаосе» (CHAOS Report)) почти треть их была полностью отменена [Standish1994].

Agile не был ответом на этот кризис. Отнюдь нет. Agile стал ответным подходом.

Чтобы взять под контроль разработку ПО, большие организации придумали высокодетализированный процесс, точно определявший, как ПО должно создаваться. Все жестко контролировалось, чтобы исключить возможность ошибки. (Во всяком случае, в теории.)

Сначала бизнес-аналитики должны были опрашивать стейкхолдеров (stakeholders, заинтересованные стороны) и документировать системные требования. Далее архитекторы программного обеспечения должны были изучить документы с требованиями и создать подробную проектную документацию, определяющую каждый компонент системы и их взаимосвязь друг с другом. Затем программисты должны были конвертировать проектную документацию в код. В некоторых организациях такое выполнение механического перевода считалось низкоквалифицированной работой.

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

Подход, основанный на фазах, получил название водопадной (waterfall development) или каскадной разработки (phase-gate development)⁴. Если вам это кажется похожим на нелепое пугало – считайте, что вам повезло. Не все команды применяли в 1990-х перегруженный документацией каскадный процесс, но он широко признавался как логичный и разумный метод работы. Конечно, нужно было определить требования, разработать проект, затем выполнить реализацию и следом – тестирование. Конечно, нужно было документировать каждую фазу. Это была дисциплина. Это была инженерия. Как еще можно было добиться успеха?

Рожденный из кризиса

Крупные компании расписывали свои процессы в мельчайших деталях. Роли, ответственности, шаблоны документов, языки моделирования, советы по контролю за изменениями… каждый аспект разработки строго регламентировался и контролировался. Если проект заканчивался провалом (а согласно CHAOS Report, менее одной шестой доли проектов были успешны), причиной считалась недостаточная детализация процесса: нужно больше документов, больше согласований. Это порождало огромное количество документации. Мартин Фаулер описывал это в своей статье The Almighty Thud [Fowler1997].

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

И тогда несколько человек создали более простые, изящные и менее директивные методы разработки программного обеспечения. Они назывались легковесными в отличие от тяжеловесных, использовавшихся большими компаниями. Эти методы носили такие названия, как адаптивная разработка программного обеспечения (Adaptive Software Development), Crystal, разработка на основе функциональности (Feature-Driven Development, FDD), метод разработки динамических систем (Dynamic Systems Development Method, DSDM), экстремальное программирование (ХР) и Scrum.

К концу 1990-х эти методы стали привлекать серьезное внимание. Экстремальное программирование, в частности, вызвало вспышку массового интереса среди программистов. В 2001 году 17 сторонников легковесной методологии встретились на горнолыжном курорте в штате Юта, чтобы обсудить объединение усилий.

Манифест Agile

«Лично я не ожидал, что эта конкретная группа [людей] сможет договориться о чем-либо по существу», – позже говорил Алистер Кокберн.

И действительно, за два дня они смогли договориться только о двух вещах: названии Agile и заявлении о четырех ценностях новой методологии (рис. 1.1). В течение следующих нескольких месяцев, переписываясь по электронной почте, эти люди сформулировали 12 сопутствующих принципов (рис. 1.2) [Beck2001].

Рис. 1.1. Ценности Agile

Рис. 1.2. Принципы Agile

Это стало Манифестом Agile, который изменил мир. «Таким образом, – продолжил Алистер, – они в конце концов все же смогли договориться о чем-то по существу»⁵.

Однако единого метода Agile не было. Его никогда не было и никогда не будет. Agile подразумевает три составляющие: название, ценности и принципы. И все. Это не что-то, что можно делать. Это философия. Это способ мышления, посвященный разработке программного обеспечения. Невозможно «использовать» Agile или «делать» Agile… вы только можете быть Agile. Или не быть. Если ваши команды воплощают философию Agile, то вы – Agile. Если не воплощают – то нет.

Суть Agile

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

Agile-разработка является скорее адаптивной, чем предиктивной; ориентированной скорее на людей, чем на процессы⁶.

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

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

Помните, в 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 миллиона долларов⁷.

Это явно было не комфортно для компании. В июне 2001-го ФБР запустило проект VCF с целью заменить программное обеспечение для управления делами. Через четыре года он был отменен. Общие затраты составили 170 миллионов долларов; 104,5 миллиона из них были полностью невозвратными.

Сроки и последовательность событий проекта могут рассказать нам хорошо знакомую историю. Проект начался в июне 2001 года. Через 17 месяцев, в ноябре 2002-го, были определены «четкие требования». Программное обеспечение было поставлено год спустя, в декабре 2003-го, но «ФБР сразу обнаружило некоторое количество недостатков в VCF, которые делали его непригодным для использования». Подрядчик, разрабатывавший программу, согласился исправить недостатки, но только за дополнительную плату в размере 56 миллионов долларов и в срок один год. В конце концов ФБР отказалось от идеи исправлять недочеты, фактически перечеркнув годы работы.

Несмотря на существование большого разнообразия подходов к Agile (и некоторые из них больше используют популярное название, чем действительно следуют философии), у них есть кое-что общее. Они фокусируются на том, чтобы делать прогресс в работе видимым, позволяя всем стейкхолдерам проекта корректировать его на ходу. Казалось бы, это мелочь, но она невероятно эффективна. Именно благодаря ей мы больше не слышим о кризисе ПО. Сроки разработки программ все еще задерживаются. Бюджеты все еще перерасходуются. Но Agile-команды демонстрируют прогресс, используя работающие программы, а не документы. С самого начала. И это огромное достижение.

Agile имеет и другие преимущества, помимо наглядности процесса. Но даже одного этого оказалось достаточно, чтобы все захотели стать Agile.

Почему Agile работает

Первым прорывным успехом Agile стало экстремальное программирование, метод со слоганом «Примите изменения». В нем смешались здоровая доза философских размышлений о разработке программ и прагматичное стремление изменить ситуацию к лучшему. В предисловии к первой книге по экстремальному программированию было сказано:

«Если коротко, то экстремальное программирование обещает снизить риски проекта, улучшить отклик на потребности бизнеса и повысить продуктивность в течение всего срока жизни системы, сделать приятным создание ПО в команде – и все это одновременно. Это правда. Прекратите смеяться» [Beck2000a].

Extreme Programming Explained, первое издание

Одни действительно смеялись. А другие попробовали и обнаружили, что (вопреки всеобщему мнению о том, как должна вестись разработка ПО) экстремальное программирование реально выполняло все, что обещало. Так, несмотря на смех, оно пользовалось спросом, а вместе с ним Agile.

Экстремальное программирование было живым примером Agile, заложившим основу идей и терминологии, которые используются до сих пор. Однако сила сообщества Agile в том, что оно всегда было широкой коалицией. Agile не ограничивается каким-то одним методом. Он постоянно расширяется, включая в себя новых людей и свежие идеи. «Бережливая разработка программного обеспечения» (Lean software development), Scrum, Kanban, «Бережливый стартап» (Lean Startup), DevOps и многие-многие другие подходы внесли свой вклад в то, что сейчас известно под общим названием Agile.

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

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

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

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

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

• Совершенствуйте ваши процессы. Экспериментируйте с новыми идеями. Настраивайте и адаптируйте то, что работает. Никогда не считайте, что отлаженный, популярный способ будет самым лучшим и для вас.

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

Почему Agile терпит неудачу

Agile начинался как общественное движение. Первоначально он был успешным в значительной степени благодаря программистам, стремящимся к лучшим результатам и лучшему качеству жизни. По мере роста этого успеха акцент сместился с основополагающих идей в сторону ажиотажа. Вместо того чтобы сказать: «Давайте добьемся лучших результатов, адаптируя наши планы и ставя интересы людей превыше всего», – лидеры компаний стали говорить: «Все обсуждают Agile. Дайте мне этот Agile».

Дело в том, что нет такого Agile, который можно было бы где-то взять. Это просто набор идей. Существуют специфические подходы Agile, такие как экстремальное программирование и Scrum, которые могут вам объяснить, как быть Agile, но вам все же придется принять лежащую в его основе философию.

А для многих организаций эта основополагающая философия (адаптировать планы и ставить интересы людей превыше всего) на самом деле реально чуждая.

Карго-культы

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

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

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

Такая же трагедия случается с Agile. Люди хотят Agile-карго: лучшие результаты, больше наглядности происходящего процесса, меньше неудач бизнеса. Но они не понимают лежащую в основе всего этого философию и зачастую не согласились бы с ней, даже если бы поняли. Они хотят купить Agile, но идею нельзя купить.

Что можно купить, так это внешние символы Agile. Стендап-митинги! Истории! Инструменты! Сертификации! Есть множество вещей с маркировкой Agile и достаточно людей, жаждущих вам их продать. Их часто продают как элементы «корпоративного уровня», что является способом сказать: «Не беспокойтесь, вам не придется ничего менять». Неудобные идеи, вроде «адаптивного планирования» или «ориентированности на людей», игнорируются.

Так и получается карго-культ. Много действий, ноль результата. Относящаяся к Agile составляющая отсутствует.

«В моей предыдущей компании огромное количество человеко-часов тратилось на совещания».

«Из-за этого [Agile] целая команда (30+ человек) лишилась работы, поскольку они не произвели почти ничего в результате почти года работы».

«Все это [Agile] означает, что разработчиков просто обманули, когда проект изменился… за день до поставки».

Реальные комментарии об Agile из сети

Слово Agile – повсюду. Идеи Agile – нет. Это вечный самообман для многих: единственный Agile, который они знают, – это карго-культ Agile.

Настало время это исправить. В этой книге я расскажу вам, как применять идеи Agile по-настоящему. Будьте начеку, чтобы не поддаться поборникам карго-культа Agile, которых вы встретите в книге. Они покажут вам, как делать не надо.

Готовы? Поехали.