Данный материал является первой частью цикла статей, посвящённых весьма популярной в настоящее время теме гибких (agile) методологий разработки программного обеспечения. Цель первой части - описать проблему, для решения которой появились гибкие методологии: выяснить, как разрабатывали программное обеспечение до их появления, почему назрела необходимость в появлении новых подходов и чем эти новые подходы принципиально отличаются от традиционных. Последующие части статьи будут посвящены подробному изложению ценностей и принципов, лежащих в основе гибких подходов, описанию конкретных методологий, таких, как XP и Scrum, а также практическим вопросам использования гибких методологий. В частности, будут затронуты вопросы применимости гибких методологий в зависимости от типа проекта.

Кризис программного обеспечения и инженерные методологии

Прежде, чем рассказывать непосредственно про гибкие методологии, необходимо пояснить, для решения какой, собственно, проблемы они появились. Если коротко, суть проблемы состоит в том, что, начиная с самых первых программных проектов и по нынешний день, разработка программного обеспечения была и остаётся мало предсказуемым и далеко не всегда успешным делом. Значительный процент проектов по созданию программного обеспечения по-прежнему заканчивается с превышением бюджета, сроков, а созданные в результате программы часто не до конца отвечают требованиям пользователей либо приносят мало реальной пользы бизнесу. Перечисленные проблемы являются основными проявлениями так называемого кризиса программного обеспечения. Несмотря на значительные интеллектуальные усилия, потраченные на поиск способов преодоления кризиса, до сих пор так и не найдено сколько-нибудь универсальное решение (как часто говорят, "серебряной пули"). Гибкие методы - это современный ответ программной индустрии на вопрос как же всё-таки надо выполнять проекты, чтобы они с большей долей вероятности завершались успехом и приносили удовлетворение всем заинтересованным сторонам - и прежде всего, заказчику и команде проекта.

Рис. 1. Одна из вариаций знаменитой карикатуры, иллюстрирующей типичные проблемы программных проектов

Однако обо всём по порядку. Как известно, человечество стало разрабатывать программное обеспечение относительно недавно - разработка больших программных систем началась всего около 50 лет назад. Вполне естественно, что ранние подходы к разработке были мало формализованы и представляли собой процесс, который принято называть Code-and-Fix (кодирование и исправление). При таком подходе разработка программного обеспечения начинается непосредственно с кодирования (без предварительного планирования, анализа требований и проектирования). После этого найденные в коде проблемы (дефекты, несоответствие требованиям и т.п.) исправляются путём внесения множественных изменений в код. Неудивительно, что после некоторого количества таких изменений система становится запутанной, её сложно поддерживать и расширять. Со временем стало понятно, что для создания больших устойчивых программных систем нужны более продуманные и формальные подходы. В поисках решения проблемы внимание было обращено на более зрелые к тому времени области человеческой деятельности, связанные со сложным производством - прежде всего, на системотехнику (systems engineering), а также другие инженерные дисциплины, такие как проектирование и строительство мостов, сооружений и т.д. В результате попытки использовать проверенные в других областях инженерные методы для разработки программного обеспечения появилась новая дисциплина - программная инженерия (software engineering), а в качестве фактического стандарта на долгие годы утвердились так называемые инженерные методологии разработки программного обеспечения. Эти методологии также часто называют основанными на плане (plan-driven), потому что в их основе лежит предположение о том, что процесс разработки программного обеспечения является детерминированным инженерным процессом, который можно спланировать от начала и до конца и выполнить в соответствии с планом, используя формальные инженерные подходы. В качестве основного варианта построения жизненного цикла использовался водопадный жизненный цикл, предполагающий однократный проход по фазам анализа требований, проектирования, кодирования, тестирования и т.д. Таким образом, как показано на рисунке 2, первый фундаментальный сдвиг в области методологий разработки представлял собой переход от хаоса подхода code-and-fix к строго формализованному подходу, принятому в инженерных методологиях.

Рис. 2. Переход к инженерным методологиям

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

Проблемы инженерных методологий

Переход к инженерным методологиям и водопадной модели, несомненно, был шагом вперёд. Он внёс определённую упорядоченность и организованность в процесс разработки, а также исключил многие проблемы подхода code-and-fix. Однако инженерные методологии по определению не могли решить всех проблем программных проектов, прежде всего, из-за заложенного в них внутреннего конфликта. Дело в том, что они изначально создавались по образцу других инженерных дисциплин и не до конца учитывали особенности, присущие именно программному обеспечению как уникальному виду продукции. Не вступая в вечный спор о том, является разработка программного обеспечения искусством или ремеслом, согласимся с тем, что едва ли справедливым будет использование одинаковых подходов к разработке нового приложения Java EE, которое делается впервые, один раз и только для данного заказчика и, скажем, к серийному производству холодильников, в котором каждый шаг процесса известен, предсказуем и неоднократно пройден в прошлом. Конфликт уникальности программного обеспечения с подходами инженерных методологий имеет, как минимум, два основных проявления:

1. Недооценка роли человеческого фактора. Инженерные методологии рассматривали процесс разработки как последовательность шагов, выполняемую абстрактным исполнителем, т.е. основное внимание фокусировалось на том, что нужно сделать в процессе разработке, а не на том, кто это будет делать. В действительности же большинство проблем программных проектов имеют социальную, а отнюдь не технологическую природу. Именно участники проекта и отношения между ними являются основным фактором, влияющим на успех проекта. Приведём только один факт из широко известной и уважаемой книги [2]. Как показывают исследования, производительность лучших разработчиков в компании может быть в 10 и более раз выше, чем худших, и в 2.5 раза выше, чем средних. При этом основными факторами, влияющими на производительность, являются отнюдь не средства и методологии разработки, а качество рабочего места, психологическая обстановка в команде, эффективные коммуникации и прочие социальные факторы.
2. Несоответствие водопадного жизненного цикла природе программного обеспечения. В целях экономии места и времени читателя мы не будем перечислять здесь многочисленные проблемы, характерные для водопадного жизненного цикла (их можно найти практически в любой современной книге по управлению проектами или методологиям разработки [3]). Отметим лишь, что принципиальным моментом в данном случае является уникальность и новизна практически любого программного продукта. Разработка ведётся в условиях высокой неопределённости, и попытка учесть все факторы в начале проекта (составить детальные требования, затем полностью разработать дизайн системы и т.д.) заранее обречена на провал. Самое неприятное заключается в том, что недостатки водопадной модели не только затрудняют процесс разработки сами по себе, но вдобавок ещё и угнетают человеческие отношения (которые, как мы выяснили, даже более важны, чем модель жизненного цикла). Например, создание и утверждение детальных требований в начале проекта часто приводит к противостояниям между заказчиком и исполнителем в случае необходимости внесения изменений на стадии реализации. Споры вокруг потенциальных изменений ведут к ухудшению отношений и разрушают слаженное взаимодействие команды с заказчиком. Справедливости ради отметим, что существуют проекты, для которых водопадный жизненный цикл может неплохо работать, однако для большинства проектов упомянутые выше проблемы являются актуальными и в большом количестве случаев приводят к провалу проектов.

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

Лёгкие-лёгкие

По мере осознания проблем инженерных методологий стали появляться альтернативные подходы к разработке, призванные устранить их недостатки. Особенную скорость этот процесс приобрёл во второй половине 90-х годов, когда сформировалась и обрела популярность целая группа так называемых лёгких (или легковесных) методологий, таких, как Scrum, XP, DSDM, Crystal и др. Несмотря на некоторые отличия в используемых практиках, эти подходы были схожи в том, что в качестве альтернативы тяжеловесным и излишне формализованным инженерным методологиям они стремились предложить адаптивные, итерационные, ориентированные на человека подходы. Лидеры и создатели легковесных подходов активно встречались и обменивались опытом, стремясь найти точки соприкосновения и выработать общие подходы. Одна из таких встреч состоялась в феврале 2001 года на лыжном курорте Сноубёрд в штате Юта и собрала 17 ярких представителей программистской мысли (таких, как М. Фоулер, К. Бек, А. Коуберн и др.). Результат этой встречи во многом повлиял на то, как выполняются сегодня программные проекты по всему миру. Несмотря на существенную разницу в позициях, участники смогли достичь ряда важных договорённостей. Прежде всего, в качестве общего названия для своих течений они выбрали термин agile (гибкий). Фундаментальные общие ценности, объединяющие их подходы, были сведены в документ, названный Манифестом гибкой разработки [4]. Чуть позже к Манифесту добавился и список Принципов, детализирующих особенности гибкой разработки.

Обсуждение Манифеста и Принципов гибкой разработки - тема следующей части нашей статьи.

Константин РАЗУМОВСКИЙ,
[email protected]

Ссылки:

1. martinfowler.com/articles/newMethodology.html - известная статья одного из создателей манифеста гибкой разработки М.Фоулера, посвящённая истории возникновения и принципам гибкой разработки.
2. Peopleware: productive projects and teams. Tom DeMarco & Timothy Lister. - 2nd ed. Dorset House Publishing Co, 1999.
3. Agile and Iterative Development: A Manager's Guide. Craig Larman. Addison Wesley, 2003.
4. agilemanifesto.org - Манифест и принципы гибкой разработки программного обеспечения.