Не пропусти новый курс по Instagram
Методология Agile как основа большинства гибких методологий
Баженова Маргарита
Директор по развитию LEADHUNTER GROUP
Левина Ильяна
Та самая королева конверсии
Как стать клиенто-ориентированной компанией?
История Agile берет свое начало с начала XXI столетия, когда был напечатан и опубликован «Манифест гибкой разработки ПО», включающий в себя 12 главных ступеней. Безусловно, единичные подходы Agile существовали и ранее, но данный документ систематизировал все материалы и понятно изложил их. В итоге их стали применять многие ведущие компании. Ежегодно под документом ставят свою подпись новые организации, программисты и менеджеры проектов. Обновляется методика и модифицируется разрабатываемая система.
Суть методологии Agile
Agile — диалоговый принцип разработки, при котором программы разрабатывают поэтапно, с начальной ступени проекта. Это ее основное отличие от каскадных принципов, где код становится доступным только по окончании цикла работы.

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

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

  • превосходство живого общения над технологиями и инструментарием;

  • превосходство действующего продукта над пакетом документов;

  • превосходство работы с клиентами над подписанием договора;

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

Методы работы Agile:

Scrum

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

Метод используют организации-гиганты, такие как Майкрософт, Сименс, а руководитель проектной группы Амазон даже создал описание методов включения Scrum в рабочий процесс, опираясь на приобретенные практические знания.

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

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

1) Выбор обладателя продукта — он имеет полное представление о целях работы и предполагаемом результате.

2) Сбор рабочей группы — до 10 пользователей, которые имеют нужные умения для изготовления качественного продукта.

3) Поиск скрам-специалиста — он отслеживает ход работы, оказывает помощь команде в преодолении трудностей.

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

5) Составить план итераций – временных отрезков на реализацию поставленных целей.

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

7) Разрабатывайте обзоры готовых частей приложения, просматривайте и обсуждайте преимущества и недостатки с командой и стейкхолдерами.

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

  • Product Backlog — перечень проектных правил;

  • Sprint Backlog — перечень условий, которые необходимо реализовать в ближайший спринт;

  • Sprint Goal — задача спринта;

  • Sprint Burndown Chart — график, обновляемый в зависимости от темпа достижения целей. По нему удобно отслеживать развитие и уровень движения группы в разработке продукта.
eXtreme Programming
Кенк Бек, создатель методики, разработал экстремальное программирование, главная задача которого — управление регулярно изменяющимися требованиями к программам и приложениям и повышение качества разрабатываемого продукта.

Он используется только в сфере создания программ и выстраивается вокруг четырех этапов:

  • кодирование — по единым командным стандартам создания;

  • тестирование — тесты составляются разработчиками до создания кода, который будут проверять;

  • создание плана — планировать следует не только финальную стадию, но и промежуточные итерации;

  • слушание — как членов команды, так и потребителей. На данном этапе проясняются проблемные моменты, определяются задачи и ценностные ориентиры.
Crystal Methodologies
Эта совокупность методологий была создана одним из соавторов «Манифеста гибкой разработки ПО» Алистером Кокберном. Ее нечасто используют российские разработчики проектов. Кокберн считает, что нужно классифицировать по оттенкам цветов число участников в команде: от 2 (кристально белый) до 100 (красный). Под наиболее глобальные работы определены оттенки бордовый, голубой и фиолетовый.

Эти продукты разрабатываются в соответствии с тремя главными характеристиками:

  • рабочий код доставляется оперативно — формирование идеи поэлементного принципа разработки Agile;

  • совершенствование через самоанализ — обновленная версия программы становится более усовершенствованной, основываясь на информации о предшествующей;

  • высокоэффективная взаимосвязь— новая разработка Алистера, метафора коммуникативного процесса и обмена материалами между членами команды разработки программ в одном помещении.

Все подробности о данных методиках описываются в издании Алистера "Crystal Clear: A Human-Powered Methodology for Small Teams".
Dynamic Software Development Method
Над созданием DSDM работала не просто группа людей, а целый консорциум, в который было включено 17 британских организаций. DSDM, как и методология Кенка Бека, применяется, в основном, для разработки ПО.

Центральная роль принадлежит потребителям, которые должны участвовать в процессе разработки. Кроме этой основы, ключевыми правилами являются:

  • обновленные рабочие версии продукта выпускаются довольно часто;

  • разработчики принимают решения автономно;

  • ПО тестируется на протяжении всего периода работы.

  • DSDM подразделяется на версии, обновляемые вместе с развитием технологий, выхода новых пожеланий к разрабатываемым программам. Сегодня последней версией является DSDM Atern, которую выпустили в 2007 году, но и предшествующая, появившаяся в 2003 году, также используется.

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

  • этап функциональной модели — разработка аналитических документов и прототипов;

  • этап создания проектов и конструкций система приводится в состояние, способное к работе;

  • этап реализации — действие системы.
Feature Driven Development
Методология, которая была разработана еще до появления "Манифеста».

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

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

FDD включает в себя следующие цикличные стадии:

  • Разработка общей модели — представление будущего продукта, основываясь на предварительной информации.
  • Написание списка свойств — аналогичный продукт backlog в методологии скрам.
  • Создание плана по свойствам — оценивание трудности свойств каждым участником рабочей группы.
  • Создание методики по каждому свойству в отдельности — техническое оформление и последующая реализация — заключительный этап, на котором свойство отправляется в программу, и после этого цикл начинается снова.
Lean Software Development
LSD — больше не методика, а совокупность принципов бережной производительности. Она направлена на увеличение эффективности процесса создания, призвана минимизировать расходы.

В набор включены семь стадий:

  • нужно избавиться от потерь — всего, что не добавляет ценности продукту для потребителей;

  • непрерывное обучение — члены команды всегда должны совершенствовать свои навыки для повышения эффективного достижения целей;

  • принятие окончательного решения как можно позже — важны не стихийные решения, а хорошо обдуманные, проработанные на основе имеющегося опыта;

  • оперативная доставка — фундамент поэтапной модели;

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

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

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

Виды методологий гибкой разработки

Agile Modeling

AM — совокупность ценностных ориентиров, принципов и практических действий для формирования моделей ПО.

AM применяют как часть полной методологии разработки программ — к примеру, eXtreme Programming или RAD.

Принципы данной методологии гласят:

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

  • нужно стремиться создать самое понятное из возможных решений, которое будет применимо ко всем требованиям;

  • нужно непрерывно получать обратную связь;

  • важно нести ответственность и без страха отвечать за принятые решения; необходимо понимать, что абсолютно все знать невозможно.
Agile Unified Process
AUP — более простая версия еще одной методики Rational Unified Process. Несколько лет назад произошла замена на Disciplined Agile Delivery, но некоторые до сих пор используют AUP.

По мнению Скотта Амблера, автора методики, в ней выделяются следующие основные позиции:

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

В данной методологии можно выделить следующие главные принципы:

  • Информация — фундамент разработки любого приложения.

  • Сложности с продуктом — они становятся заметны, только когда есть четкое видение задач и концепции проекта.

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

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

  • Командная работа — коллективное взаимодействие принесет больше положительного эффекта, чем одиночная разработка.

  • «Сладкое пятно» — нужно искать подходящее решение проблемы, не доходя до крайних мер.
Essential Unified Process
Эту методологию создал Ивар Якобсон, программист из Швеции. Ее основная задача – усовершенствование Rational Unified Process.

EssUP использует понимание практических действий, в которое включены:

  • сценарий применения — описание поведенческой системы;
  • поэтапная работа — формирование рабочих частей кода частями в пару недель;
  • практики внутри команды — нужны для сплочения группы и увеличения эффективности работы;
  • практики внутри процесса, которые гласят, что начинать необходимо с малого, но при этом важно мыслить глобально.

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

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

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

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

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

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

Agile показатели

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

Для многих продуктов достаточно четырех направлений:

  • Производительность — сюда входят Velocity и WIP. Velocity будет подходящей не для всех программ, так как происходит измерение числа решенных задач за один этап, а их значимость различная.

  • Метрика Work-in-Progress занимается определением лимита задач на разных этапах. Чем выше лимит, тем хуже для проекта.

  • Создание прогнозов — метрика capacity: она определяет число идеальных часов, которые будут доступны в следующем спринте. То есть, можно точно знать, сколько часов еще имеется для выполнения работы, насколько эффективно решаются поставленные задачи и как установить подходящее число задач для одного спринта.

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

  • Ценностные ориентиры — в каждом проекте они индивидуальны. К примеру, молодая фирма AirBnb в качестве метрики, которая определяет итоговую ценность продукта для потребителей, отобрала число высококачественных загруженных снимков. Когда их количество возрастало, увеличивалось и число пользователей.

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

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

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

Это неверная информация. Ни один метод Agile сам по себе не сможет добавить ценности конечному продукту или мотивации рабочей группе.
Миф второй: Agile не использует документацию.

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

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

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

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

  • оперативная и ожидаемая доставка — поэтапная модель разработки делает продукт более гибким, ускоряет темпы выпуска тестовой версии;

  • фокусировка на бизнес-ценности — коллаборация с пользователями позволяет разработчикам понять, что именно нужно потребителям;

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

Недостатки:

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

  • нельзя использовать для аутсорса и проектов, где взаимодействие участников происходит только в режиме онлайн;

  • риск никогда не создать итоговую версию программы — этот недостаток возникает из-за того, что продукт все время совершенствуется и обновляется;

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

Гибкая методология отлично подходит для работы в маркетинговых, рекламных, дизайнерских, seo или digital компаниях.

Вот пара советов, как провести настройку Agile в Worksection:

  • нужно настроить метки и статусы, которые будут соответствовать рабочему процессу именно вашей организации;
  • важно определить цели, задачи и основные шаги в списке функций;
  • на встречах с командой нужно ставить цели и переносить их из беклога в спринт;
  • надо применять гостевой доступ потребителей к задачам, чтобы постоянно иметь конструктивные и реальные замечания по продукту;
  • нужно назначать ответственных людей за каждую конкретную задачу. Так каждый участник группы будет понимать свою ответственность и ощущать свое участие к разработке продукта.
Итоги
С методологией Agile маленькие проектные организации могут достичь максимальной эффективности. Реализация Agile происходит через иные гибкие методы: Scrum, XP, Lean и т.п.

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

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