Введение в Agile

1.5. Как развивалась Agile

Описание процесса зарождения и развития Agile стоит начать с ситуации, происходившей в отрасли в середине прошлого века.

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

Затем произошел прорыв развития электроники и, как следствие, увеличилась производительность компьютеров, а стоимость их стала резко снижаться. Ограничения на разработку, связанные с аппаратными средствами, стали исчезать или трансформироваться в ограничения на ПО. Таким образом, умение разрабатывать новые программы диссонировало с теми требованиями, которые заказчики предъявляли к этим самым программам. Это привело к тому, что разработка программного обеспечения перестала быть просто "кодированием", а стала формироваться в виде конкретных концепций, поддерживающих полный жизненный цикл разрабатываемых программ (формирование идеи, анализ требований, проектирование функциональности, разработка ПО, тестирование ПО, внедрение, поддержка с последующей утилизацией).

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

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

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

Если мы рассмотрим любую современную методологию управления проектом или моделями жизненного цикла проекта по разработке информационных систем, согласно SWEBOK, то выглядеть она будет следующим образом:

• традиционная (каскадная, водопадная) модель;
• спиральная модель;
• итеративная и инкрементная модель.

Каскадная модель ( рис. 1.1) разработки программного обеспечения является первой и, как следствие, самой критикуемой. При работе с данной методологией предполагается последовательное выполнение этапов разработки. Такая структура не дает изменить требования к программному продукту до самого релиза.

увеличить изображение
Рис. 1.1. Каскадная модель разработки

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

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

Традиционная модель внесла фундаментальный вклад в понимание процессов разработки следующими утверждениями:

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

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

увеличить изображение
Рис. 1.2. Спиральная модель разработки

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

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

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

Стоит отметить, что Agile-семейство, по сути, является ответвлением итеративной модели разработки программного обеспечения. При описании любой из гибких методологий упоминается принцип разделения на итерации, который нашел отражение во многих артефактах, применяемых в Agile (task board и пр.).

Следующие вехи в развитии Agile заслуживают упоминания:

• 1992 год:
  • Crystal Methods. Семейство методологий Crystal послужило основой для развития современных методологий разработки программного обеспечения. Agile была создана людьми, которые "вышли" из движения Crystal. Автором Crystal является Алистер Коберн. Методология может быть применима к командам, состоящим из шести-восьми участников, расположенных в одном месте, работающих над созданием программных систем, не являющихся критичными для жизни пользователей.

Crystal фокусируется на:

• частой поставке работающего кода конечным пользователям;
• разумных улучшениях;
• всепроникающей коммуникации (osmotic communication) между членами команды, расположенными в одном месте.

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

• 1993 год:
  • Refactoring. Термин "рефакторинг" был введен Билом Опдайком в статье под названием "Creating Abstract Superclasses by Refactoring". В Википедии приведено следующее описание рефакторинга: "Процесс изменения внутренней структуры программы, не затрагивающий ее внешнего поведения и имеющий целью облегчить понимание ее работы".
• 1994 год:
  • Dynamic Systems Development Method (DSDM). DSDM был разработан консорциумом, являющимся объединением поставщиков и производителей программного обеспечения. Цель их работы - совместными усилиями разработать и распространить независимый framework для быстрой разработки приложений с использованием накопленного опыта.

DSDM фокусируется на восьми основных принципах:

• учитывать потребности бизнеса;
• поставлять вовремя;
• взаимодействовать;
• никогда не снижать качество;
• создавать постепенно с самых основ;
• разрабатывать итерационно;
• непрерывно и ясно общаться;
• демонстрировать управляемость.

• 1995 год:
  • Scrum and Pair Development. Scrum был разработан совместно Джефом Сазерлендом и Кеном Швабером, которые представили доклад на конференции OOPSLA'95 в Остине, штат Техас.
• 1997 год:
  • Feature Driven Development. Методология Feature Driven Development (FDD) изначально была разработана Джефом ДеЛукой.

Основные практики, описанные в FDD, следующие:

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

• 1999 год:
  • Adaptive Software Development. Джим Хэнгсмит сформулировал концепцию Adaptive System Development и опубликовал книгу с таким же названием. Идея выросла из его работы по методологиям быстрого создания приложений (RAD).
• 2002 год:
  • Новые идеи в Agile. Test Driven Development (TDD). Концепция разработки через тестирование изначально появилась в XP в виде подхода "сначала тест". Чуть позже эта техника была описана более подробно Кентом Беком в его книге "Test Driven Development: By Example".
• 2003 год:
  • Lean Software Development. Последователи Agile считали, что следующим витком ее развития будет являться трансформация с процессной методологией Lean. Время подтвердило обоснованность этой идеи. Термин такого ответвления Agile был введен Мэри и Томом Поппендик в 2003 году.

Это адаптация бережливых принципов производства к разработке программного обеспечения. Рассматриваются семь основных принципов:

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

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