22 сентября 2017   •   Ярослав Борута   •   22 min read

Методология Agile. Матерь драконов или всех гибких методологий

История Agile начинается с публикации в 2001 году «Манифеста гибкой разработки ПО», состоящего из 12 принципов. Конечно, отдельные положения Agile-подхода появились появлялись и до этого, но только этот документ систематизировал и изложил их в достаточной для использования мере. Каждый год под манифестом подписываются новые компании, IT-специалисты и проектные менеджеры. Появляются новые методы и модификации гибкой системы разработки.

Что такое Agile Methodology (гибкая методология)?

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

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

12 принципов, которые составляют Agile Methodology, можно поделить на 4 главные идеи:

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

Методы присутствующие в Agile:

Scrum

Своему термину «Scrum» обязан регби, в котором это слово означает метод командной игры в виде построения трех линий каждым из соперников и попытке захватить мяч. Для успешного перехвата нужна не только хорошая физическая подготовка, но и слаженность каждого участника схватки и четкое понимание цели.

Метод успешно применяют такие компании как Microsoft, Yahoo, Siemens Healthcare, а проектный менеджер в Amazon даже описал кейс внедрения Scrum на основе полученного опыта.

Так как скрам — каркас разработки, в каждом последующем примере он может значительно отличаться от предыдущего.

Scrum. Революционный метод управления проектами Сазерленд

Джефф Сазерленд, автор книги «Scrum. Революционный метод управления проектами» выделил 8 шагов по использованию методики:

  1. Выберите владельца продукта — он знает о цели проекта и ожидаемом результате.
  2. Соберите команду — до 10 человек с необходимыми для создания работоспособного продукта навыками.
  3. Найдите скрам-мастера — он следит за ходом проекта, помогает проектной команде бороться с трудностями.
  4. Составьте бэклог продукта — на Agile-доске расставьте приоритеты по каждому требованию к продукту. В этом большую роль играет владелец продукта, который собирает пожелания к продукту для оценки командой бэклога.
  5. Запланируйте спринты (итерации) — отрезки времени на выполнение определенного ряда задач.
  6. Организовывайте ежедневные пятнадцатиминутные «мит-апы» — задавайте по 3 вопроса каждому из команды: что делал вчера, что будет сегодня, что мешает выполнить задачу.
  7. Делайте обзоры рабочих частей продукта — с вовлечением в просмотр и обсуждение стейкхолдеров.
  8. Проводите ретроспективу — обсуждение проблемы и поиск решения после каждого спринта. Полученный план изменения внедряете на следующем спринте.
Ретроспектива в Agile
Ретроспектива в Agile

В скрам есть 4 ключевых элемента:

  • Product Backlog — список требований по проекту
  • Sprint Backlog — список требований, которые нужно выполнить в ближайший спринт
  • Sprint Goal — цель спринта
  • Sprint Burndown Chart — диаграмма, которая обновляется по мере завершения задач. По ней легко понять динамику и уровень продвижения команды в проекте.

eXtreme Programming (XP)

Разработчик методики, Кент Бек, создал метод экстремального программирования, цель которого — справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки.

Он применим исключительно в сфере разработки ПО, и строится вокруг 4 процессов:

  1. кодирование — согласно единым в команде стандартам оформления;
  2. тестирование — тесты пишутся самими программистами до написания кода, который будут тестировать;
  3. планирование — как финального билда, так и отдельных итераций. Последнее проходит в среднем раз в две недели.
  4. слушание — как разработчиков, так и клиента, в ходе которого исчезают неясности, определяются требования и ценности.

Crystal Methodologies

Малоизвестное на отечественных просторах проектного менеджмента семейство методологий, разработанное Алистером Кокберном, одним из автором «Манифеста гибкой разработки ПО». Классификацию Кокберн предлагает проводить по цветам за критерием количества человек в команде: от 2 (Crystal Clear) до 100 (Crystal Red). Под более масштабные проекты выделены цвета Maroon, Blue и Violet.

Crystal-проекты должны соответствовать 3 основным показателям:

  1. быстрая доставка рабочего кода — развитие идеи итеративной модели разработки Agile.
  2. совершенство через рефлексию — новая версия ПО улучшается на основе данных о предыдущей.
  3. «осмотическое» взаимодействие — нововведение Алистера, метафора коммуникации и обмена информацией между разработчиками ПО в одной комнате.

Подробно семейство методологий описано в книге Алистера "Crystal Clear: A Human-Powered Methodology for Small Teams".

Dynamic Software Development Method (DSDM)

Над разработкой DSDM трудился не один человек и даже не команда, а консорциум из 17 английских компаний. DSDM, как и экстремальное программирование, используется преимущественно для создания программного обеспечения.

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

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

DSDM делится на версии, которые обновляются по мере развития технологий, появления новых требований к разработке ПО. Последняя на сегодня — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) еще в строю.

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

  1. цикл функциональной модели — создание аналитической документации и прототипов.
  2. цикл проектирования и конструирования — приведение системы в рабочее состояние.
  3. цикл реализации — развертывание системы.

Feature Driven Development (FDD)

Методология, которая появилась даже раньше, чем "Манифест гибкой разработки ПО«.

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

  • больше внимания предварительному моделированию
  • повышенная (по сравнению с Agile) важность построения отчётности и графиков
  • нацелено на корпоративную разработку.

Feature Driven Development состоит из таких цикличных этапов:

  1. Создание общей модели — видение проекта на основе предварительных данных.
  2. Разработка списка свойств — аналог product backlog в методике скрам.
  3. Планирование по свойствам — оценка сложности свойств каждым членом команды.
  4. По каждому свойству — технический дизайн и реализация — финальная стадия, по окончанию которой свойство уходит в продукт и цикл повторяется.

Lean Software Development

Lean Software Development — скорее не методология, а набор принципов бережливого производства, который направлен на повышение эффективности процесса разработки, минимизацию затрат.

В набор входят следующие 7 принципов:

  1. избавление от потерь — всё, что не прибавляет ценности продукту для конечного потребителя.
  2. постоянное обучение — непрерывное развитие команды увеличивает возможности эффективного выполнения задач.
  3. принятие решения так поздно, как только можно — приоритет не спонтанным решениям, а продуманным, разработанным на основе полученных знаний.
  4. быстрая доставка — по сути основа итеративной модели.
  5. усиление команды — один из принципов «Манифеста...» гласит, что люди и взаимодействие важнее процессов и инструментов. Проектная команда — основа успешного завершения задач.
  6. целостность и качество — нужно изначально делать качественный продукт, чтобы не тратить время и ресурсы на дальнейшее тестирование и избавление от багов.
  7. видение цельной картины — разбиение проекта на отдельные части невозможно без понимания текущего статуса разработки, целей, концепции и стратегии разрабатываемого ПО.

Разновидность методологий гибкой разработки

Agile Modeling (AM)

Agile Modeling — набор ценностей, принципов и практик для моделирования программного обеспечения.

AM используют как составляющую полноценной методики разработки ПО — например, экстремального программирования или Rapid Application Development.

Принципы Agile Modeling таковы:

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

Agile Unified Process (AUP)

AUP — упрощённая версия другой методологии разработки ПО — Rational Unified Process (RUP). С 2012 года её заменили на Disciplined Agile Delivery (DAD), но кое-где AUP еще встречается.

Автор методики, Скотт Амблер, выделил следующие ключевые позиции Agile Unified Process:

  • Ваша команда знает, что делает;
  • Простота превыше всего.
  • Соответствие принципам гибкой методологии разработки.
  • Сфокусированность на ценных для проекта активностях.
  • Независимость в выборе инструментов.
  • Индивидуальная настройка AUP под нужды конкретного проекта.

Agile Data Method (ADM)

ADM — набор итеративных методик гибкой разработки программного обеспечения, которые делают упор на формирование требования и решений по проекту через сотрудничество отдельных команд. Как и AUP, это не самоценная методика.

Суть Agile Data Method определяется шестью положениями:

  1. Данные — основа создания любого приложения.
  2. Проблемы с проектом — их можно обнаружить только при чётком понимании цели и концепции проекта.
  3. Рабочие группы — помимо непосредственной команды разработчиков есть enterprise groups, которые поддерживают другие рабочие группы.
  4. Уникальность — нет идеальной методики, под каждый проект нужно комбинировать инструменты с разных методологий.
  5. Работа в команде — совместная работа гораздо эффективнее, чем поодиночке.
  6. «Сладкое пятно» — поиск оптимального решения проблемы («сладкого пятна»), избегая крайностей.

Essential Unified Process (EssUP)

Разработка шведского учёного Ивара Якобсона, созданная для улучшения Rational Unified Process.

EssUP оперирует понятием практики, в которые входят:

  • сценарий использования — описание поведения системы.
  • итерационная разработка — создание рабочих кусков кода короткими циклами в несколько недель.
  • командные практики — направленные на сплочение команды и повышение её эффективности.
  • процессуальные практики — например, «Думай глобально, начинай с малого» или «Вовлекайте стейкхолдеров в бизнес-процессы».

Все практики в том или ином виде встречаются в методологиях RUP, CMMI и гибкой методике разработки.

Getting Real (GR)

Эффективная для стартапов и начинающих команд методология, которая предлагает по максимуму использовать особенности небольших проектов и компаний: мобильность, гибкость, поиск новых решений, отсутствие жёсткой запутанной иерархии и т.д. Джейсон Фрид и Давид Ханссон, основатели компании 37signals (теперь — Basecamp), определили Getting Real как систему для решения реальных задач: максимально простую, понятную и функциональную.

GR — сборная солянка из десятка инструментов гибкой разработки, которые используются для минимизации:

  • возможностей
  • опций и настроек
  • структуры компании
  • встреч
  • обещаний.

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

OpenUP (OUP)

Независимая от инструментов методология разработки ПО без жесткой структуры, которая содержит такие практики:

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

Практики реализуются на основе четырех принципов:

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

Agile показатели

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

Для большинства проектов хватит 4 направлений метрик:

  1. Производительность — сюда относятся Velocity и WIP. Первая подойдёт не для всех проектов, так как идет измеряются количество выполненных задач в итерацию, а они неравнозначны. Метрика Work-in-Progress определяет лимит задач на разных стадиях: и чем он выше, тем хуже;
  2. Прогнозирование — метрика capacity: определение количества идеальных часов, доступных в следующем спринте. Соответственно, можно понять, сколько времени есть на работу, насколько эффективно выполнение задач и как спланировать количество задач для спринта;
  3. Качество — например, индекс стабильности требований, который рассчитывается по формуле = (Общее количество оригинальных бизнес-требований + Число требований, которые поменялись к этому времени + Число добавленных требований + Число убранных требований) / (общее число оригинальных требований). С помощью метрики определяется количество времени, затраченное на переделывание задач;
  4. Ценности — в каждом случае просчитывается индивидуально, зависимо от формата проекта. Например, стартап AirBnb в качестве метрики, определяющую конечную ценность продукта для пользователей, выбрала количество загруженных фотографий высокого качества. С их увеличением пропорционально росло и количество потребителей.

К метрикам применимы те же правила, что и к другим Agile-инструментам.

Нет единственно верной или нужной вашему проекту метрики.

Их нужно постоянно пересматривать, отбрасывать устаревшие и добавлять новые по мере необходимости. Она должна быть понятна и доступна всей всей команде, не превращаться в самоцель. Метрика ради метрики — плохое решение.

 Метрика ради метрики — плохое решение.

Разрушители мифов: Agile

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

Миф № 1: Agile подойдет для всех проектов.

Самое упорное заблуждение. Ни один метод Agile не добавит сам по себе ценности продукту и не смотивирует команду.

Миф № 2: Agile против документации.

Гибкая методология разработки не против документации, она против документации как самоцели. А вот при выборе документации как средства коммуникации Agile действительно отдаёт приоритет живому общению.

Миф № 3: Agile и планирование несовместимы.

Опровержением этого мифа служат дневные планирования с 10-минутными стэндапами, итерационное планирование каждые две недели, спринт-встречи и т.д.

Миф № 4: Agile требует много переделывания (re-work).

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


Плюсы и минусы использования Agile

Плюсы:

  1. вовлечение стейкхолдеров — у команды появляется больше возможностей понять желания клиента. А ранняя и частая доставка ПО усиливает доверие стейкхолдеров к проектной команде и еще глубже вовлекает в проект.
  2. ранняя и предсказуемая доставка — модель разработки через итерации (короткие промежутки от 1 до 6 недель) дает гибкость, ускоряет выпуск релиза продукта.
  3. фокусирование на бизнес-ценности — коллаборация с клиентом обеспечивает понимание командой того, как сделать продукт максимально ценным для потребителя.
  4. непрекращающееся улучшение качества — тестирование во время каждой итерации, деление финального билда на отдельные куски рабочего кода позволяют улучшать и справляться с ошибками ПО до выхода финального продукта.

Минусы:

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

Приложения

Для ведения проектов с Agile подходят далеко не все сервисы или программы для проектного менеджмента, ведь у каждого есть своя специфика.

Если ваш бизнес относится к маркетинг и рекламным, дизайнерским, seo или digital агентствам, то saas-сервис Worksection можно применить для работы всей команды целиком. Нас рекомендуют COXO Digital, Royal ® Advertising и Prozorro.

Вот пара лайфхаков, чтобы настроить Agile в Worksection:

  1. настройте метки и статусы, которые необходимы для работы именно вашей компании.
    Статусы могут быть такими: в работе, проверка, выполнено, требует доработки, критично, фича, оплатить.
    Метки часто выглядят как: верстка, тестирование, продакшен, концепт, код.
  2. создайте проект-беклог и проект-спринг.
  3. создавайте задачи и предварительные чеклисты, скетчи и прочее в беклоге.
  4. на мит-апах определяйте задачи на спринг и переносите их из беклога в спринт.
  5. используйте гостевой доступ клиентов к задачам, чтобы всегда иметь согласованные и актуальные комментарии по проекту.
  6. отмечайте ответственных в задачах, чтобы каждый коллега знал зону своей ответственности и чувствовал причастность к результату спринта.

Worksection

Вердикт

С гибкой методологией разработки программного обеспечения небольшие проектные команды добиваются максимальной эффективности. Agile реализуется через другие гибкие методы: Scrum, XP, Lean и т.п.

Её невозможно реализовать с наскока, неопытной командой, за короткий отрезок времени, но внедрение Agile улучшит взаимодействие между IT и бизнесом, ускорит выход продукта на рынок, повысит ценность продукта для конечного пользователя.

Опубликовать

Бизнес-кейсы
О компании: Digital агентство120 сотрудников13 лет на рынкеБолее 6 лет с WorksectionКлиенты: Toshiba, PepsiCo, Freshline, Prostor, Morosha и другие ArtJoker на рынке с 2006 года. Мы занимаемся разработкой...
10 апреля 2019   •   6 min read
Бизнес-кейсы
Большинство task-менеджеров заточены под IT-компании и плохо приспособлены для реалий работы digital-агентства. Мы нашли наш инструмент, это — Worksection!
8 апреля 2019   •   8 min read
Бизнес-кейсы
Каждый руководитель должен контролировать работу команды, знать, что и когда происходит, кто и чем занимается, понимать, сколько на это требуется времени.
9 января 2019   •   5 min read
Мы в соц-сетях
esc
Поделиться в
esc
Лучшая система управления проектами
Worksection
Попробовать бесплатно
уже есть аккаунт
Войти
Новинки Кейсы PM Книги
Найти
Видео Диаграмма Ганта Отчёт План Интеграции Уведомления Еще 47...
Видео Диаграмма Ганта Отчёт План Интеграции Уведомления Бизнес процесс Проектный менеджмент Roman.ua Теория Рецензия Шесть Сигм Бережливое производство App Android IOS Задачи Календарь Связи Подзадачи UI Статусы Метки Отчёты Затраты Учёт времени Учёт финансов Горящие задачи Экспорт Фильтр Комментарии Сhecklist Таймер Документы Топ 10 Файлы Ответственный Поиск Безопасность Интервью Развитие команды Развитие лидера Саморазвитие Креативные команды Маркетинг команды IT команды Сервисные компании TOP 10 Рецензии Бизнес-процесс Акции Советы Партнерство Канбан
Лучшая система управления проектами
Worksection
Попробовать бесплатно
уже есть аккаунт
Войти