Гибкая методология разработки 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-манифеста, это несущая конструкция всей методологии.
Ценности.
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
Принципы.
- Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
- Изменение требований приветствуется, даже на поздних стадиях разработки. 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 можно выделить четыре главных роли:
- Клиент — он же заказчик, инициирует проект и дает на него деньги.
- Владелец продукта (Product owner) — в классическом понимании это постановщик задачи. Он взаимодействует с заказчиком и формулирует задачи для команды разработчиков.
- Scrum-мастер — управляет процессом разработки. Назначает и проводит разные организационные мероприятия, координирует работу команды. Самый близкий аналог Scrum-мастера — это руководитель либо менеджер проекта. Scrum-мастер контролирует, чтобы команда следовала предусмотренному протоколу разработки.
- 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 эффективен в областях с высокой долей неопределенности (это почти наверняка касается всех больших проектов, предусмотреть в которых все заранее не представляется реальным):
- на сложных меняющихся рынках (например, рынка технологий);
- при разработке принципиально новых продуктов;
- в проектах с неясным результатом, когда сам заказчик плохо понимает, что должно получиться в конце.
7. Преимущества и недостатки Agile
Преимущества.
- Гибкость. Готовность к постоянным изменениям для удовлетворения запросов конечного пользователя является одним из базовых принципов концепции Agile.
- Экономия на менеджменте. Agile стремится минимизировать объем документооборота и количество управляющего персонала. Вместо этого упор делается на личное общение между участниками команды.
- Минимально жизнеспособный продукт. Уже в результате первой итерации может быть получен рабочий продукт, хоть и с ограниченной функциональностью (MVP). В результате обратная связь от пользователей будет получена раньше, чем при традиционной разработке.
Недостатки.
- В общем случае дольше реализуется. Из-за постоянных корректировок ТЗ больше времени может уходить на рефакторинг кода, из-за чего будут раздуваться сроки разработки.
- Юридические сложности. Отсутствие фиксированного бюджета и технического задания затрудняет юридическое оформление такого рода проектов.
- Сложно оценить сроки работ. Agile не подразумевает оценку срока работ и его фиксацию. В целом фиксированные сроки разработки плохо соответствуют концепции гибкой разработки (четвертый пункт ценностей Agile-манифеста).
- Заказчик не всегда готов так активно участвовать в разработке, как это предполагается методологией.
8. Советы по применению Agile
- Больше планируйте. Уделяйте больше усилий планированию, проектированию, разработке технических характеристик.
- Формируйте культуру сотрудничества. Социальные навыки — ключ к успеху проектов Agile. Это неудивительно. Согласно Agile-манифесту, люди и совместная работа имеют большую ценность, чем методики и инструменты.
- Используйте итерационный подход.
- Доносите до команды исследования пользователей. Проверка системы с точки зрения удобства для пользователя (юзабилити) оказывает положительный эффект на принятие решений по словам практиков Agile.
- Постоянно взаимодействуйте с заказчиком проекта.
- Установите четкие роли и обязанности в команде. Важно, чтобы члены команды полностью понимали свою роль и роли коллег. Чтобы Agile мог эффективно работать, участники проекта должны со старта знать, что от них ждут и что входит в их сферу влияния.
- Совершенствуйте методологию. По мере развития команды Agile экспериментируют с различными приемами и адаптируют их к своей среде.
9. Как стать Agile-разработчиком?
Перейти на Agile — значит, сформировать определенную культуру разработки в организации.
Agile не является конкретной технологией, вроде языка программирования — это и философия разработки, и набор методологий, и ряд конкретных практик. Простого и однозначного ответа на вопрос «Как стать Agile-разработчиком?» не существует.
В общем случае вам достаточно иметь некоторое представление о гибких методологиях, ну и прокачанные навыки работы в команде (желательно лидерские).
Если вы видите себя в роли специалиста по внедрению Agile (Agile-коуч) или решили перейти на гибкую разработку, то можете начать либо с курсов, либо заняться самостоятельным изучением:
- Курсы. Думаю, это лучший способ начать изучение гибких методологий. Тема очень обширная. В интернете море информации, но сориентироваться в ней непросто. Курсы же дают своего рода «дорожную карту», знания в них отобраны и структурированы; как правило, они содержат только самое ценное и проверенное временем. После изучения пары курсов вам будет гораздо проще продолжить свое развитие самостоятельно.
Также курсы подразумевают выполнение заданий, так что у вас появятся некоторые практические навыки. Найти курсы не составляет проблем. - Самостоятельное изучение. Статьи, книги, YouTube, тематические форумы и т.д. Самостоятельное обучение будет носить более стихийный и хаотичный характер. С другой стороны, можно сразу сфокусироваться на нужных именно для вас темах. Кроме того, постоянное самообразование необходимо любому специалисту, который хочет поддерживать свой профессиональный уровень в актуальном состоянии.
Напоследок — совет: развивайтесь не только вглубь, но и вширь. Например, если вы работаете в сфере IT, важно иметь представление о методах проектирования программного обеспечения, системах контроля версий, тестировании, рефакторинге и т.д. Даже если вы не участвуете непосредственно в разработке, вы должны говорить с командой на одном языке.
Знания основ психологии общения тоже будут весьма полезны. Так как обсуждений и разного рода коммуникаций со всеми участниками процесса предстоит много.
Изучайте и другие методологии. «Серебряной пули» не существует. Agile эффективен для своего круга задач. Важно уметь понимать, когда и что применимо. Появляются и новые перспективные гибридные подходы, такие как Water-Scrum-Fall. Возможно, какие-то из них со временем станут новым стандартом. Держите руку на пульсе.
В заключение полезные тематические видео на YouTube, которые здорово дополнят сказанное:
«Agile и Scrum на пальцах / О ГИБКИХ методологиях разработки ПО понятным языком»:
«SCRUM — метод управления проектами. Обучающий мультик для вас и ваших сотрудников!»:
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: