История Agile начинается с публикации в 2001 году «Манифеста гибкой разработки ПО», состоящего из 12 принципов. Конечно, отдельные положения Agile-подхода появились появлялись и до этого, но только этот документ систематизировал и изложил их в достаточной для использования мере. Каждый год под манифестом подписываются новые компании, IT-специалисты и проектные менеджеры. Появляются новые методы и модификации гибкой системы разработки.
Что такое Agile Methodology (гибкая методология)?
Agile — итеративная модель разработки, в которой программное обеспечение создают инкрементально с самого начала проекта, в отличии от каскадных моделей, где код доставляется в конце рабочего цикла.
Основа гибкой методологии — разбиение проектов на маленькие рабочие кусочки, называемые пользовательскими историями. Согласно приоритетности задачи решают в рамках коротких двухнедельных циклов (итераций).
12 принципов, которые составляют Agile Methodology, можно поделить на 4 главные идеи:
- Приоритет людей и общения над инструментами и процессами;
- Приоритет работающего продукта над полной документацией;
- Приоритет сотрудничества с заказчиков над утверждением контракта;
- Приоритет готовности меняться над следованием первоначально созданному плану.
Методы присутствующие в Agile:
Scrum
Своему термину «Scrum» обязан регби, в котором это слово означает метод командной игры в виде построения трех линий каждым из соперников и попытке захватить мяч. Для успешного перехвата нужна не только хорошая физическая подготовка, но и слаженность каждого участника схватки и четкое понимание цели.
Метод успешно применяют такие компании как Microsoft, Yahoo, Siemens Healthcare, а проектный менеджер в Amazon даже описал кейс внедрения Scrum на основе полученного опыта.
Так как скрам — каркас разработки, в каждом последующем примере он может значительно отличаться от предыдущего.
Джефф Сазерленд, автор книги «Scrum. Революционный метод управления проектами» выделил 8 шагов по использованию методики:
- Выберите владельца продукта — он знает о цели проекта и ожидаемом результате.
- Соберите команду — до 10 человек с необходимыми для создания работоспособного продукта навыками.
- Найдите скрам-мастера — он следит за ходом проекта, помогает проектной команде бороться с трудностями.
- Составьте бэклог продукта — на Agile-доске расставьте приоритеты по каждому требованию к продукту. В этом большую роль играет владелец продукта, который собирает пожелания к продукту для оценки командой бэклога.
- Запланируйте спринты (итерации) — отрезки времени на выполнение определенного ряда задач.
- Организовывайте ежедневные пятнадцатиминутные «мит-апы» — задавайте по 3 вопроса каждому из команды: что делал вчера, что будет сегодня, что мешает выполнить задачу.
- Делайте обзоры рабочих частей продукта — с вовлечением в просмотр и обсуждение стейкхолдеров.
- Проводите ретроспективу — обсуждение проблемы и поиск решения после каждого спринта. Полученный план изменения внедряете на следующем спринте.
Ретроспектива в Agile
В скрам есть 4 ключевых элемента:
- Product Backlog — список требований по проекту
- Sprint Backlog — список требований, которые нужно выполнить в ближайший спринт
- Sprint Goal — цель спринта
- Sprint Burndown Chart — диаграмма, которая обновляется по мере завершения задач. По ней легко понять динамику и уровень продвижения команды в проекте.
eXtreme Programming (XP)
Разработчик методики, Кент Бек, создал метод экстремального программирования, цель которого — справиться с постоянно меняющимися требованиями к программному продукту и повысить качество разработки.
Он применим исключительно в сфере разработки ПО, и строится вокруг 4 процессов:
- кодирование — согласно единым в команде стандартам оформления;
- тестирование — тесты пишутся самими программистами до написания кода, который будут тестировать;
- планирование — как финального билда, так и отдельных итераций. Последнее проходит в среднем раз в две недели.
- слушание — как разработчиков, так и клиента, в ходе которого исчезают неясности, определяются требования и ценности.
Crystal Methodologies
Малоизвестное на отечественных просторах проектного менеджмента семейство методологий, разработанное Алистером Кокберном, одним из автором «Манифеста гибкой разработки ПО». Классификацию Кокберн предлагает проводить по цветам за критерием количества человек в команде: от 2 (Crystal Clear) до 100 (Crystal Red). Под более масштабные проекты выделены цвета Maroon, Blue и Violet.
Crystal-проекты должны соответствовать 3 основным показателям:
- быстрая доставка рабочего кода — развитие идеи итеративной модели разработки Agile.
- совершенство через рефлексию — новая версия ПО улучшается на основе данных о предыдущей.
- «осмотическое» взаимодействие — нововведение Алистера, метафора коммуникации и обмена информацией между разработчиками ПО в одной комнате.
Подробно семейство методологий описано в книге Алистера «Crystal Clear: A Human-Powered Methodology for Small Teams».
Dynamic Software Development Method (DSDM)
Над разработкой DSDM трудился не один человек и даже не команда, а консорциум из 17 английских компаний. DSDM, как и экстремальное программирование, используется преимущественно для создания программного обеспечения.
Особая роль отводится участия конечного потребителя (пользователя) в процессе разработки. Помимо этого принципа, к базовым относятся:
- частые выпуски рабочих версий продукта
- автономность разработчиков в плане принятия решений
- тестирование на протяжении всего рабочего цикла.
DSDM делится на версии, которые обновляются по мере развития технологий, появления новых требований к разработке ПО. Последняя на сегодня — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) еще в строю.
В начале команда изучает реальность разработки приложения и область применения. Дальше работа делится на три взаимосвязанных цикла:
- цикл функциональной модели — создание аналитической документации и прототипов.
- цикл проектирования и конструирования — приведение системы в рабочее состояние.
- цикл реализации — развертывание системы.
Feature Driven Development (FDD)
Методология, которая появилась даже раньше, чем «Манифест гибкой разработки ПО».
Хоть в FDD тоже применяется итерационная модель разработки, от Agile она отличается в следующем:
- больше внимания предварительному моделированию
- повышенная (по сравнению с Agile) важность построения отчётности и графиков
- нацелено на корпоративную разработку.
Feature Driven Development состоит из таких цикличных этапов:
- Создание общей модели — видение проекта на основе предварительных данных.
- Разработка списка свойств — аналог product backlog в методике скрам.
- Планирование по свойствам — оценка сложности свойств каждым членом команды.
- По каждому свойству – технический дизайн и реализация — финальная стадия, по окончанию которой свойство уходит в продукт и цикл повторяется.
Lean Software Development
Lean Software Development — скорее не методология, а набор принципов бережливого производства, который направлен на повышение эффективности процесса разработки, минимизацию затрат.
В набор входят следующие 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 определяется шестью положениями:
- Данные — основа создания любого приложения.
- Проблемы с проектом — их можно обнаружить только при чётком понимании цели и концепции проекта.
- Рабочие группы — помимо непосредственной команды разработчиков есть enterprise groups, которые поддерживают другие рабочие группы.
- Уникальность — нет идеальной методики, под каждый проект нужно комбинировать инструменты с разных методологий.
- Работа в команде — совместная работа гораздо эффективнее, чем поодиночке.
- «Сладкое пятно» — поиск оптимального решения проблемы («сладкого пятна»), избегая крайностей.
Essential Unified Process (EssUP)
Разработка шведского учёного Ивара Якобсона, созданная для улучшения Rational Unified Process.
EssUP оперирует понятием практики, в которые входят:
- сценарий использования — описание поведения системы.
- итерационная разработка — создание рабочих кусков кода короткими циклами в несколько недель.
- командные практики — направленные на сплочение команды и повышение её эффективности.
- процессуальные практики — например, «Думай глобально, начинай с малого» или «Вовлекайте стейкхолдеров в бизнес-процессы».
Все практики в том или ином виде встречаются в методологиях RUP, CMMI и гибкой методике разработки.
Getting Real (GR)
Эффективная для стартапов и начинающих команд методология, которая предлагает по максимуму использовать особенности небольших проектов и компаний: мобильность, гибкость, поиск новых решений, отсутствие жёсткой запутанной иерархии и т.д. Джейсон Фрид и Давид Ханссон, основатели компании 37signals (теперь — Basecamp), определили Getting Real как систему для решения реальных задач: максимально простую, понятную и функциональную.
GR — сборная солянка из десятка инструментов гибкой разработки, которые используются для минимизации:
- возможностей
- опций и настроек
- структуры компании
- встреч
- обещаний.
Необычная концепция не получила широкого распространения, хотя отдельные элементы используют другие методики.
OpenUP (OUP)
Независимая от инструментов методология разработки ПО без жесткой структуры, которая содержит такие практики:
- измерение скорости работы команды;
- проведение ежедневных встреч и ретроспектив по завершению итераций;
- концепция микрошагов и раннего тестирования с использованием чеклистов;
- методика гибкого моделирования (AMDD).
Практики реализуются на основе четырех принципов:
- согласование интересов и достижение общего видения во время совместной работы
- непрерывное совершенствование через постоянную обратную связь
- фокусирование на архитектуре приложения на ранних стадиях для минимизации рисков
- максимизация ценности для конечного потребителя.
Agile показатели
Учитывая разнообразие инструментов, практик, методов и методологий в Agile, нужно выбрать инструмент, который поможет определить эффективность каждого из них. Таким инструментом выступают метрики.
Для большинства проектов хватит 4 направлений метрик:
- Производительность — сюда относятся Velocity и WIP. Первая подойдёт не для всех проектов, так как идет измеряются количество выполненных задач в итерацию, а они неравнозначны. Метрика Work-in-Progress определяет лимит задач на разных стадиях: и чем он выше, тем хуже;
- Прогнозирование — метрика capacity: определение количества идеальных часов, доступных в следующем спринте. Соответственно, можно понять, сколько времени есть на работу, насколько эффективно выполнение задач и как спланировать количество задач для спринта;
- Качество — например, индекс стабильности требований, который рассчитывается по формуле = (Общее количество оригинальных бизнес-требований + Число требований, которые поменялись к этому времени + Число добавленных требований + Число убранных требований) / (общее число оригинальных требований). С помощью метрики определяется количество времени, затраченное на переделывание задач;
- Ценности — в каждом случае просчитывается индивидуально, зависимо от формата проекта. Например, стартап AirBnb в качестве метрики, определяющую конечную ценность продукта для пользователей, выбрала количество загруженных фотографий высокого качества. С их увеличением пропорционально росло и количество потребителей.
К метрикам применимы те же правила, что и к другим Agile-инструментам.
Нет единственно верной или нужной вашему проекту метрики.
Их нужно постоянно пересматривать, отбрасывать устаревшие и добавлять новые по мере необходимости. Она должна быть понятна и доступна всей всей команде, не превращаться в самоцель. Метрика ради метрики — плохое решение.
Разрушители мифов: Agile
Популярность семейства гибкой методологии разработки сыграла с ним злую шутку, и даже на специализированных порталах встречаются мифы о том или ином аспекте Agile. Будем разбираться!
Миф №1: Agile подойдет для всех проектов.
Самое упорное заблуждение. Ни один метод Agile не добавит сам по себе ценности продукту и не смотивирует команду.
Миф №2: Agile против документации.
Гибкая методология разработки не против документации, она против документации как самоцели. А вот при выборе документации как средства коммуникации Agile действительно отдаёт приоритет живому общению.
Миф №3: Agile и планирование несовместимы.
Опровержением этого мифа служат дневные планирования с 10-минутными стэндапами, итерационное планирование каждые две недели, спринт-встречи и т.д.
Миф №4: Agile требует много переделывания (re-work).
В гибкой методологии разработки ПО переделывание проявляется в двух формах: переделывание требований (пользователи понимают, что им действительно нужно) и программного обеспечения (команды разработчиков находят улучшенные способы написать и спроектировать приложение). Но с этим приходится сталкиваться и в других методиках! Более того, для уменьшения негативного влияния rework и нужна итерационная модель, которая является особенностью Agile.
Плюсы и минусы использования Agile
Плюсы:
- вовлечение стейкхолдеров — у команды появляется больше возможностей понять желания клиента. А ранняя и частая доставка ПО усиливает доверие стейкхолдеров к проектной команде и еще глубже вовлекает в проект.
- ранняя и предсказуемая доставка — модель разработки через итерации (короткие промежутки от 1 до 6 недель) дает гибкость, ускоряет выпуск релиза продукта.
- фокусирование на бизнес-ценности — коллаборация с клиентом обеспечивает понимание командой того, как сделать продукт максимально ценным для потребителя.
- непрекращающееся улучшение качества — тестирование во время каждой итерации, деление финального билда на отдельные куски рабочего кода позволяют улучшать и справляться с ошибками ПО до выхода финального продукта.
Минусы:
- повышенные требования к команде и клиентам — без тесного взаимодействия между проектной командой и пользователями невозможно добиться выхода качественного продукта с высокой ценностью. А обилие инструментов и методов в Agile для внедрения требует опытную команду.
- не подходит для аутсорса и проектов, где участники взаимодействуют друг с другом только онлайн.
- риск никогда не выпустить финальную версию ПО — этот минус, как ни странно, выплывает из итеративной разработки и непрерывного совершенствования продукта — плюсов Agile.
- не работает без четкого видения бизнес-целей проекта — так как Agile-команда ориентируется на стейкхолдеров, то без выработки целей и концепции продукта разработка невозможна.
Приложения
Для ведения проектов с Agile подходят далеко не все сервисы или программы для проектного менеджмента, ведь у каждого есть своя специфика.
Если ваш бизнес относится к маркетинг и рекламным, дизайнерским, seo или digital агентствам, то saas-сервис Worksection можно применить для работы всей команды целиком. Нас рекомендуют COXO Digital, Royal ® Advertising и Prozorro.
Вот пара лайфхаков, чтобы настроить Agile в Worksection:
- настройте метки и статусы, которые необходимы для работы именно вашей компании.
Статусы могут быть такими: в работе, проверка, выполнено, требует доработки, критично, фича, оплатить.
Метки часто выглядят как: верстка, тестирование, продакшен, концепт, код. - создайте проект-беклог и проект-спринг.
- создавайте задачи и предварительные чеклисты, скетчи и прочее в беклоге.
- на мит-апах определяйте задачи на спринг и переносите их из беклога в спринт.
- используйте гостевой доступ клиентов к задачам, чтобы всегда иметь согласованные и актуальные комментарии по проекту.
- отмечайте ответственных в задачах, чтобы каждый коллега знал зону своей ответственности и чувствовал причастность к результату спринта.
Вердикт
С гибкой методологией разработки программного обеспечения небольшие проектные команды добиваются максимальной эффективности. Agile реализуется через другие гибкие методы: Scrum, XP, Lean и т.п.
Её невозможно реализовать с наскока, неопытной командой, за короткий отрезок времени, но внедрение Agile улучшит взаимодействие между IT и бизнесом, ускорит выход продукта на рынок, повысит ценность продукта для конечного пользователя.