Гибкая методология разработки Agile

В статье рассматривается понятие Agile — какие имеет значения, как связано с методологиями гибкой разработки. Рассматриваются вопросы области применения, внедрения, основные преимущества и недостатки. В качестве примера гибкой методологии дано краткое описание фреймворка Scrum.

Содержание:
1. Что такое Agile?
2. Жизненные циклы разработки ПО
3. Методы и средства для реализации
4. Scrum
5. Agile-показатели
6. Область применения Agile
7. Преимущества и недостатки Agile
8. Советы по применению Agile
9. Как стать Agile-разработчиком?

1. Что такое Agile?

Agile (читается как «АджАйл») — это обобщающее название для совокупности всех технологий, следующих принципам и ценностям «Манифеста гибкой разработки программного обеспечения» (с англ. Agile Manifesto).

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

Agile-манифест был опубликован 13 февраля 2001 года. Его совместно сформулировали на горнолыжном курорте 17 IT-специалистов, представляющих различные методологии разработки ПО.

Манифест — это публичная декларация принципов и намерений человека или сообщества людей. Манифест гибкой разработки содержит 4 ценности и 12 принципов.

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

Ценности.

1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.

Принципы.

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

Перед тем, как перейти к рассмотрению особенностей Agile, необходимо немного «теории» для раскрытия понятия жизненного цикла ПО, которое лежит в основе любой методологии разработки.

2. Жизненные циклы разработки ПО

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

Например, каскадная модель (еще называют «водопад»). В этой модели все стадии и последовательность их выполнения жестко закреплены. Каждая стадия, начиная с «Требований» и заканчивая «Развертыванием», выполняется однократно. «Водопад» — максимально жесткая модель, она не предусматривает сколь-нибудь существенного уточнения или модификации ТЗ в процессе выполнения.

Противоположный пример — модель code&fix. Суть ее в отсутствии каких-то ограничений и системы. Главное, начать кодить, а дальше «как кривая вывезет», в надежде, что заказчик примет получившийся продукт до дедлайна.

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

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

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

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

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

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

3. Методы и средства для реализации

Для Agile-разработки характерно применение следующих подходов:

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

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

Характеристики проекта	Традиционные модели	Гибкие модели
Подход	Прогнозирующий	Адаптивный
Критерии успеха	Следование плану	Ценность для бизнеса
Риски	Риски определены	Риски не определены
Контроль	Легко контролировать	Зависит от профессионального уровня специалистов
Заказчики	Низкая вовлеченность	Высокая вовлеченность
Документация	Детальная с начала работы проекта	Доработка по мере развития проекта
Требования	Известны заранее, стабильны	Не всегда известны заранее, легко изменяемые
Команда проекта	Включение новых специалистов на любом этапе	Опытные специалисты, стабильный состав
Рефакторинг	Дорого	Недорого

Принципы и ценности Agile воплощены в форме конкретных гибких методологий, таких как: Scrum, экстремальное программирование, Kanban, RUP, DSDM, FDD и др.

Наиболее полно концепция Agile реализована в популярной методологии Scrum. Рассмотрим, как работает методология Agile, на примере Scrum.

4. Scrum

Сегодня Scrum — наиболее популярная методология гибкой разработки. В мире на 2021 год Scrum применяют 66% Agile-разработчиков. Изначально Scrum был разработан для IT-сферы, но сейчас применяется в разных сферах бизнеса. Метод изобрели программисты Кен Швабер и Джефф Сазерленд. Они наблюдали за тем, как работают американские военные и спецназ, и пришли к выводу, что основа успеха состоит в качественной командной работе. Сам термин пришел из регби и в переводе с английского означает «схватка».

В основе Scrum лежит гибридная итерационно-инкрементальная модель разработки. Итерации здесь называются «спринтами» (от англ. sprint, бег на короткую дистанцию).

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

Роли.

В Scrum можно выделить четыре главных роли:

1. Клиент — он же заказчик, инициирует проект и дает на него деньги.
2. Владелец продукта (Product owner) — в классическом понимании это постановщик задачи. Он взаимодействует с заказчиком и формулирует задачи для команды разработчиков.
3. Scrum-мастер — управляет процессом разработки. Назначает и проводит разные организационные мероприятия, координирует работу команды. Самый близкий аналог Scrum-мастера — это руководитель либо менеджер проекта. Scrum-мастер контролирует, чтобы команда следовала предусмотренному протоколу разработки.
4. Scrum-команда — сплоченная команда высококлассных и разносторонних разработчиков, обычно 5–10 человек, работающая в плотном взаимодействии друг с другом.

Цикл разработки.

Цикл разработки по Scrum выглядит следующим образом: в начале каждой итерации производится планирование спринта (Sprint Planning) и оценка задач по дальнейшему развитию продукта бэклогов (Product Backlog).

Бэклог изначально состоит из эпиков (Epic). «Эпик» — большая автономная часть функционала, которая может быть завершена в рамках разработки продукта. Затем проводится декомпозиция, каждый «эпик» разбивается на меньшие компоненты, которые называются сториз (User Story).

Для сториз часто используется шаблон: «Я, как <роль/тип пользователя>, хочу <выполнить действие/получить результат>, чтобы <достигать цели>». Так простым человеческим языком формулируются задачи проекта. Любой сториз подвергается дальнейшей декомпозиции, до тех пор, пока не будет разбит на наименьшие сущности («таски» или задачи).

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

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

Важно не забывать и про недостатки Scrum, которые часто забывают учесть заранее.

5. Agile-показатели

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

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

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

6. Область применения Agile

Опираясь на все вышесказанное, можно сделать очевидный вывод: Agile эффективен в областях с высокой долей неопределенности (это почти наверняка касается всех больших проектов, предусмотреть в которых все заранее не представляется реальным):

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

7. Преимущества и недостатки Agile

Преимущества.

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

Недостатки.

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

8. Советы по применению Agile

1. Больше планируйте. Уделяйте больше усилий планированию, проектированию, разработке технических характеристик.
2. Формируйте культуру сотрудничества. Социальные навыки — ключ к успеху проектов Agile. Это неудивительно. Согласно Agile-манифесту, люди и совместная работа имеют большую ценность, чем методики и инструменты.
3. Используйте итерационный подход.
4. Доносите до команды исследования пользователей. Проверка системы с точки зрения удобства для пользователя (юзабилити) оказывает положительный эффект на принятие решений по словам практиков Agile.
5. Постоянно взаимодействуйте с заказчиком проекта.
6. Установите четкие роли и обязанности в команде. Важно, чтобы члены команды полностью понимали свою роль и роли коллег. Чтобы Agile мог эффективно работать, участники проекта должны со старта знать, что от них ждут и что входит в их сферу влияния.
7. Совершенствуйте методологию. По мере развития команды Agile экспериментируют с различными приемами и адаптируют их к своей среде.

9. Как стать Agile-разработчиком?

Перейти на Agile — значит, сформировать определенную культуру разработки в организации.

Agile не является конкретной технологией, вроде языка программирования — это и философия разработки, и набор методологий, и ряд конкретных практик. Простого и однозначного ответа на вопрос «Как стать Agile-разработчиком?» не существует.

В общем случае вам достаточно иметь некоторое представление о гибких методологиях, ну и прокачанные навыки работы в команде (желательно лидерские).

Если вы видите себя в роли специалиста по внедрению Agile (Agile-коуч) или решили перейти на гибкую разработку, то можете начать либо с курсов, либо заняться самостоятельным изучением:

• Курсы. Думаю, это лучший способ начать изучение гибких методологий. Тема очень обширная. В интернете море информации, но сориентироваться в ней непросто. Курсы же дают своего рода «дорожную карту», знания в них отобраны и структурированы; как правило, они содержат только самое ценное и проверенное временем. После изучения пары курсов вам будет гораздо проще продолжить свое развитие самостоятельно.
  Также курсы подразумевают выполнение заданий, так что у вас появятся некоторые практические навыки. Найти курсы не составляет проблем.
• Самостоятельное изучение. Статьи, книги, YouTube, тематические форумы и т.д. Самостоятельное обучение будет носить более стихийный и хаотичный характер. С другой стороны, можно сразу сфокусироваться на нужных именно для вас темах. Кроме того, постоянное самообразование необходимо любому специалисту, который хочет поддерживать свой профессиональный уровень в актуальном состоянии.

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

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

Изучайте и другие методологии. «Серебряной пули» не существует. Agile эффективен для своего круга задач. Важно уметь понимать, когда и что применимо. Появляются и новые перспективные гибридные подходы, такие как Water-Scrum-Fall. Возможно, какие-то из них со временем станут новым стандартом. Держите руку на пульсе.

В заключение полезные тематические видео на YouTube, которые здорово дополнят сказанное:

«Agile и Scrum на пальцах / О ГИБКИХ методологиях разработки ПО понятным языком»:

«SCRUM — метод управления проектами. Обучающий мультик для вас и ваших сотрудников!»: