История Agile восходит к публикации «Манифеста гибкой разработки программного обеспечения», состоящего из 12 основных принципов в 2001 году. Безусловно, определенные элементы Agile-метода появились до этого момента, но только этот документ систематизировал и представил их в такой степени, которая была достаточна для применения. Год за годом все новые компании, IT-специалисты и менеджеры проектов следуют за Манифестом. Появляются новые методы и версии системы гибкой разработки.
Что такое Agile (гибкая) методология?
Agile — это интерактивная модель разработки, в которой программное обеспечение создается поэтапно с самого начала проекта, в отличие от каскадных моделей, где код передается в конце рабочего цикла.
Гибкая методология основана на разбиении проектов на небольшие операционные части, называемые историями пользователей. В зависимости от приоритетов задачи решаются в краткосрочных двухнедельных циклах (итерациях).
12 принципов, составляющих Agile-методологию, можно сгруппировать в 4 основные идеи:
- Приоритет людей и общения над инструментами и процессами;
- Приоритет функционального продукта над избыточной документацией;
- Приоритет сотрудничества с клиентами над подтверждением контракта;
- Приоритет готовности к изменениям над следованием первоначальному плану.
Методы, присущие Agile:
Scrum
Термин Scrum заимствован из регби, где это слово означает метод командной игры, состоящий из трех линий, построенных каждым соперником, пытающимся захватить мяч. Для успешного захвата необходимо не только хорошее физическое состояние — каждый игрок, участвующий в scrum, должен действовать согласованно с другими, четко понимая цель.
Этот метод успешно используется такими компаниями, как Microsoft, Yahoo, Siemens Healthcare. Менеджер проекта из Amazon даже описал случай внедрения Scrum на основе полученного опыта.
Поскольку Scrum является рамочной структурой для разработки, каждый следующий пример может отличаться от предыдущего.
Джефф Сазерленд, автор книги «Scrum. Искусство делать вдвое больше за половину времени», выделил 8 шагов к использованию методологии:
- Выберите владельца продукта, который осведомлен о цели проекта и ожидаемом результате.
- Организуйте команду — до 10 человек с навыками, необходимыми для создания работающего продукта.
- Назначьте Scrum-мастера, который будет контролировать рабочий процесс проекта и помогать команде решать проблемы.
- Составьте бэклог продукта — для каждого требования к продукту установите приоритеты на доске Agile. В этом процессе важна роль владельца продукта, поскольку он собирает запросы на продукт для оценки командой бэклога.
- Запланируйте спринты (итерации) — временные фрагменты для выполнения определенных цепочек задач.
- Организуйте ежедневные пятнадцатиминутные встречи — задавайте каждому участнику команды 3 вопроса: что он делал вчера, что он будет делать сегодня, что мешает выполнению задач.
- Проводите обзоры операционных частей продукта — с участием заинтересованных сторон в таких обзорах.
- Проводите ретроспективы — обсуждение проблем с поиском решений после каждого спринта. Реализуйте полученный план модификаций в следующем спринте.
Ретроспектива в Agile
Scrum состоит из 4 ключевых элементов:
- Бэклог продукта — список требований к проекту
- Бэклог спринта — список требований, которые должны быть выполнены в предстоящем спринте
- Цель спринта — цель спринта
- График выполнения спринта — диаграмма, которая обновляется по мере выполнения задач. Она облегчает понимание динамики и уровня продвижения команды в проекте.
Экстремальное программирование (XP)
Кент Бек, разработчик этой методологии, создал метод экстремального программирования, нацеленный на решение нестабильных требований к программному продукту и улучшение качества разработки.
Он применяется только в области разработки программного обеспечения и основан на 4 процессах:
- кодирование — в соответствии с общими стандартами компоновки команды;
- тестирование — тесты, как правило, создаются программистами до написания кода, который будет протестирован;
- планирование — как для окончательной сборки, так и для отдельных итераций. Последние происходят в среднем каждые две недели.
- аудит — как разработчиков, так и клиента, чтобы устранить неясные моменты и определить требования и ценности.
Кристаллические методологии
Эта семья методологий, разработанная Алистайром Кокберном, одним из авторов «Манифеста гибкой разработки программного обеспечения», малоизвестна в некоторых локальных областях управления проектами. Кокберн предлагает провести классификацию по цветам, основанную на таком критерии, как количество человек в команде: от 2 (Crystal Clear) до 100 (Crystal Red). Цвета каштановый, синий и фиолетовый присваиваются более масштабным проектам.
Кристаллические проекты должны соответствовать 3 основным характеристикам:
- быстрая доставка рабочей версии кода — эволюционная идея для итеративной модели в гибкой разработке.
- улучшение через рефлексию — новая версия программного обеспечения улучшается на основе информации о предыдущей.
- «осмотическое» взаимодействие — новшество Алистайра, метафора для общения и обмена информацией между разработчиками программного обеспечения в одной комнате.
Эта семья методологий подробно описана в книге «Crystal Clear: методология на основе взаимодействия человека для малых команд» Алистайра.
Метод динамичной разработки программного обеспечения (DSDM)
Не одна лишь личность, а даже не команда, а консорциум из 17 британских компаний работал над разработкой DSDM. Как и экстремальное программирование, DSDM в основном используется для создания программного обеспечения.
Конечный потребитель (пользователь) получает особую роль в процессе разработки. Этот основной принцип дополняется следующими основными:
- частые релизы рабочей версии продукта
- автономия разработчиков в принятии решений
- тестирование на протяжении всего рабочего цикла.
DSDM делится на версии, которые обновляются по мере развития технологий и появления новых требований к разработке программного обеспечения. В настоящее время последняя версия — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) все еще в использовании.
С самого начала команда рассматривает целесообразность разработки приложения и его области применения. Затем работа делится на три взаимосвязанных цикла:
- цикл функциональной модели — создание аналитических документов и прототипов.
- цикл проектирования и инженерии — приведение системы в эксплуатацию.
- цикл внедрения — развертывание системы.
Разработка, ориентированная на функции (FDD)
Эта методология появилась даже раньше, чем «Манифест гибкой разработки программного обеспечения».
Хотя FDD также использует итеративную модель разработки, она отличается от Agile следующими особенностями:
- большее внимание к предварительному моделированию
- повышенная (по сравнению с Agile) значимость построения отчетов и диаграмм
- методология предназначена для корпоративной разработки.
Разработка, ориентированная на функции, состоит из следующих циклических фаз:
- Создание общей модели — видение проекта на основе предварительных данных.
- Разработка списка свойств — аналогично бэклогу продукта в методологии Scrum.
- Планирование по свойствам — сложность свойств оценивается каждым членом команды.
- Для каждого свойства — технический дизайн и внедрение – окончательная фаза, по завершении которой свойство объединяется в продукт, и цикл повторяется.
Бережливая разработка программного обеспечения
Бережливая разработка программного обеспечения — это набор принципов бережливого менеджмента (скорее, чем методология), направленных на повышение эффективности процесса разработки и минимизацию затрат.
Этот набор включает следующие 7 основных принципов:
- исключение потерь — все, что не добавляет ценности продукту для конечного потребителя.
- постоянное обучение — постоянное развитие команды увеличивает возможности для эффективного выполнения задач.
- принятие решений как можно позже — приоритет отдается взвешенным решениям, которые хорошо разработаны и основаны на полученных знаниях, а не спонтанным.
- быстрая доставка — это, по сути, основной принцип итеративной модели.
- укрепление команды — один из принципов «Манифеста…» заключается в том, что люди и их взаимодействия важнее процессов и инструментов. Команда проекта является наилучшей гарантией успешного выполнения задач.
- целостность и качество — важно создать изначально качественный продукт, чтобы не тратить время и ресурсы на дальнейшее тестирование и устранение ошибок.
- видение общей картины — проект не может быть разбит на отдельные части без понимания текущего состояния разработки, а также целей, концепции и стратегий разрабатываемого программного обеспечения.
Версии методологий гибкой разработки
Гибкое моделирование (AM)
Гибкое моделирование — это набор ценностей, основ и практик для моделирования программного обеспечения.
AM используется как элемент в полноценной методологии разработки программного обеспечения — например, в экстремальном программировании или быстрой разработке приложений.
Гибкое моделирование имеет следующие основные характеристики:
- эффективное взаимодействие между заинтересованными сторонами проекта;
- стремление к разработке в конечном итоге простого решения из всех возможных, которое удовлетворит всем требованиям;
- постоянное получение обратной связи;
- смелость принимать решения и брать на себя ответственность за них;
- осознание того, что вы знаете абсолютно все.
Гибкий унифицированный процесс (AUP)
AUP — это упрощенная версия другой методологии разработки программного обеспечения — рационального унифицированного процесса (RUP). С 2012 года он был заменен упорядоченной бережливой доставкой (DAD), но AUP все еще существует здесь и там.
Скотт Амблер, автор методологии, выделил следующие ключевые моменты в Гибком унифицированном процессе:
- Ваша команда знает, что она делает;
- Простота выходит на первый план.
- Соответствие основам гибкой методологии разработки.
- Фокус на действиях, ценных для проекта.
- Независимость в выборе инструментов.
- Индивидуальная настройка AUP под требования конкретного проекта.
Гибкий метод данных (ADM)
ADM — это набор итеративных методологий разработки программного обеспечения, которые подчеркивают формирование требований и решений в проекте через сотрудничество различных команд. Как и AUP, эта методология также не является самоохранной.
Принцип метода гибких данных определяется шестью основами:
- Данные — основа для создания любого приложения.
- Проблемы в проекте — они могут быть обнаружены только в том случае, если цель и концепция проекта четко понимаются.
- Рабочие группы — помимо основной команды разработчиков, есть корпоративные группы, которые поддерживают другие рабочие группы.
- Уникальность — не существует идеальной методологии, поэтому каждый проект требует сочетания инструментов из различных методологий.
- Командная работа — совместная работа гораздо эффективнее, чем индивидуальная деятельность.
- «Сладкое место» — поиск оптимального решения проблемы («сладкое место») путем избегания крайностей.
Существенный унифицированный процесс (EssUP)
Он был разработан Иваром Якобсоном, шведским ученым, для улучшения рационального унифицированного процесса.
EssUP использует концепцию практики, которая включает:
- сценарий использования — описание поведения системы.
- итеративная разработка — создание рабочих частей кода в коротких циклах в течение нескольких недель.
- командные практики — направленные на сплочение команды и повышение ее эффективности.
- процедурные практики — например, «Думайте глобально, начните с малого» или «Вовлекайте заинтересованных сторон в бизнес-процессы».
В той или иной форме все практики присутствуют в методологиях RUP и CMMI, а также в гибкой методологии разработки.
Мысли на реальность (GR)
Это методология, эффективная для стартапов и начинающих команд, которая предполагает максимальное использование специфических особенностей малых проектов и компаний, таких как мобильность, гибкость, поиск новых решений, отсутствие строгой и запутанной иерархии и т. д.
Джейсон Фрид и Дэвид Хенссон, основатели компании 37signals (в настоящее время Basecamp), определили Getting Real как систему решения выполнимых задач, которая в конечном итоге является простой, универсальной и функциональной.
GR — это смесь дюжины инструментов гибкой разработки, которые используются для минимизации следующего:
- альтернатив
- опций и настроек
- структуры компании
- встреч
- обязательств.
Такое выдающееся понятие не стало мейнстримом, хотя некоторые из его элементов слились в другие методологии.
OpenUP (OUP)
Это методология разработки программного обеспечения, независимая от инструментов и свободная от строгой структуры, которая предоставляет следующие практики:
- измерение скорости работы команды;
- проведение ежедневных встреч и ретроспектив по завершении итераций;
- концепция микрошагов и раннего тестирования с использованием контрольных списков;
- методология гибкой модели, ориентированной на разработку (AMDD).
Эти практики реализуются на основе четырех принципов:
- примирение интересов и достижение общего видения в совместной работе;
- постоянное улучшение через обратную связь;
- фокус на архитектуре приложения на ранних стадиях для минимизации рисков;
- максимизация ценности для конечного потребителя.
Гибкие индикаторы
Учитывая разнообразие инструментов Agile, практик, методов и методологий, необходимо выбрать инструмент, который поможет нам определить, насколько эффективен каждый из них.
Метрики используются в качестве такого инструмента.
Для большинства проектов этих 4 категорий метрик будет достаточно:
- Продуктивность — она сопоставляется с метриками Velocity и WIP. Первая не подойдет не всем проектам, поскольку измеряется количество выполненных задач за итерацию, а итерации не равны. Метрика Work-in-Progress определяет предел задач на разных стадиях: чем выше это значение, тем хуже идет;
- Прогнозирование — метрика Capacity, которая заключается в определении количества идеальных часов, доступных в следующем спринте. Соответственно, можно понять, сколько времени доступно для работы, степень эффективности выполнения задач, а также запланировать количество задач на спринт;
- Качество — например, индекс стабильности требований, который рассчитывается по формуле = (Общее количество исходных бизнес-требований + Количество требований, измененных к данному времени + Количество добавленных требований + Количество исключенных требований) / (общее количество исходных требований). Эта метрика используется для определения количества времени, затраченного на переработку задач;
- Ценности — эта метрика вычисляется индивидуально в каждом случае, в зависимости от формата проекта. Например, в стартапе AirBnb количество загруженных качественных фотографий было выбрано в качестве метрики, определяющей конечную ценность продукта для пользователей. Поскольку это число увеличивалось, число пользователей возрастало пропорционально.
Правила, применимые к метрикам, таковы же, как и для других инструментов Agile.
Не существует единой метрики, которая была бы безусловно правильной и актуальной для вашего проекта.
Метрики должны пересматриваться на постоянной основе, устаревшие должны исключаться, а новые добавляться по мере необходимости. Они должны быть всеобъемлющими и доступны всей команде, не превращаясь в целую цель. Метрики ради метрик — это плохое решение.
Мифы о Agile
Популярность методологии гибкой разработки сыграла с ней злую шутку, и мифы о некоторых аспектах Agile можно увидеть даже на специализированных порталах. Давайте разберемся!
Миф №1: Agile подойдет всем проектам.
Это самое настойчивое заблуждение. Только один метод Agile сам по себе не добавит ценности продукту и не будет мотивировать команду.
Миф №2: Agile недовольствует документацией.
Гибкая методология разработки не противоречит документации, она отрицает документацию как цель сама по себе. Когда речь идет о выборе документации как средства общения, Agile действительно отдает предпочтение личному общению.
Миф №3: Agile и планирование несовместимы.
Этот миф опровергается ежедневными планировками с 10-минутными стендапами, а также планированием итераций, происходящим каждые две недели, совещаниями спринта и т. д.
Миф №4: Agile требует много переделок.
Гибкая методология разработки программного обеспечения предусматривает переработки в двух формах: переработка требований (пользователи понимают, что им на самом деле нужно) и переработка программного обеспечения (команды разработчиков находят более совершенные способы написания и проектирования приложений). Но такая ситуация также может возникать и в других методологиях! Более того, такая новизна Agile, как итеративная модель, служит для уменьшения негативного влияния переработок.
Преимущества и недостатки Agile в использовании
Преимущества:
- вовлечение заинтересованных сторон — команда становится более способной понять требования заказчика. Более того, ранняя и частая доставка программного обеспечения повышает доверие заинтересованных сторон к команде проекта и делает участие в проекте более глубоким.
- ранняя и предсказуемая доставка — итеративная модель разработки (в короткие периоды от 1 до 6 недель) обеспечивает гибкость и способствует выпуску продукта.
- ориентация на бизнес-ценность — сотрудничество с заказчиком обеспечивает понимание команды о том, как сделать продукт в конечном итоге ценным для потребителя.
- непрерывное улучшение качества — тестирование в каждой итерации с делением окончательной сборки на отдельные части рабочего кода облегчает улучшение и устранение ошибок программного обеспечения до выпуска финального продукта.
Недостатки:
- строгие требования к команде и клиентам — без тесного взаимодействия между командой проекта и пользователями невозможно обеспечить выпуски высококачественного продукта с высокой ценностью. Более того, обилие инструментов и методов Agile предполагает, что команда должна быть опытной для их правильного внедрения.
- не подходит для аутсорсинга и для проектов, где участники взаимодействуют друг с другом только в онлайн-режиме.
- риск того, что окончательная версия программного обеспечения никогда не будет выпущена — неожиданно, этот недостаток возникает из таких преимуществ Agile, как итеративная разработка и непрерывное улучшение продукта.
- он проваливается без четкого видения бизнес-целей проекта — поскольку команда Agile руководствуется заинтересованными сторонами, невозможно разработать продукт без четко сформулированной цели и концепции.
Применения
Не все сервисы или программы управления проектами подходят для управления проектами на основе Agile, потому что у каждого из них есть свои специфические особенности.
Если ваш бизнес связан с маркетингом и рекламой, дизайном, SEO или цифровыми технологиями, вы можете использовать SaaS-сервис от Worksection, чтобы вся команда могла работать в нем. На данный момент нас рекомендуют COXO Digital, Royal ® Advertising и Prozorro.
Вот несколько советов по настройке Agile в Worksection:
- настройте теги и статусы, которые необходимы для работы в вашей компании. Статусы могут быть: в процессе, проверка, завершено, требуется переработка, критично, функции, задолженность по платеже. Теги часто звучат так: компоновка, тестирование, производство, концепция, код.
- создайте бэклог проекта и проектный спринт.
- создайте задачи и предварительные контрольные списки, эскизы и т. д. в бэклоге.
- в ходе встреч определите задачи спринта и перенесите их из бэклога в спринт.
- используйте гостевой доступ клиентов к задачам, чтобы вы всегда имели согласованную и актуальную обратную связь по проекту.
- отмечайте ответственных лиц в задачах, чтобы каждый коллега знал свою зону ответственности и чувствовал свою вовлеченность в результат спринта.
Вердикт
Благодаря методологии гибкой разработки программного обеспечения, небольшие команды проектов достигают максимальной эффективности. Agile реализует себя через такие другие гибкие методы, как Scrum, XP, Lean и т.д.
Его нельзя внедрять поспешно, неопытной командой, за короткий период времени,
но когда он внедрен, Agile улучшит взаимодействие между IT и бизнесом, поспособствует выпуску продукта на рынок и добавит ценность продукта для конечного потребителя.