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

Методика Agile – это некая философия разработки программного обеспечения. Методология, которая основывается на цикличном методе взаимодействия.

Agile methodologies появилась, как альтернатива подходу к работе, движимой планами и документаций, примером которых является водопадный подход (Waterfall).

И тогда в феврале 2001 году выпустили Манифест гибкой разработки программного обеспечения. Хотя зарождение методики, по разным источникам, началось еще в 1960-х годах, активное ускорение развития Agile Software Development считается с момента издания манифеста.

Начиная с 2016 года про и Agile не говорит только ленивый. И в этом плане многие говорят, но не все действительно понимают, что же такое этот подход.

Как было раньше? В каких случаях лучше Agile?

Раннее при воплощении проекта в жизнь применялась модель разработки Waterfall. Давайте посмотрим, как этот подход выглядел.

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

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

Выглядит классно. Но увы, этот подход работает только когда нам все известно в самом начале. Мы не ожидаем никаких сюрпризов, и мы точно знаем, куда мы идем. В запутанном окружении, таком как ИТ, с большим количеством взаимосвязей и возможностью ошибиться – это просто самоубийственно. Действительно, применение подхода основанного на детальном планировании ведет нас большому количеству проблем.

Стоимость нашего проекта растет линейно и складывается из: аккумулирования рабочего времени людей, стоимости рабочего окружения, лицензий. При этом поставленная заказчику ценность постоянно равна нулю до окончания проекта. Если все идет по плану и заказчику нравятся то, что мы сделали, то мы должны получить больше, чем потратили на этот проект. Но до окончания проекта мы не знаем получиться это или нет. Такая стратегия получила название стратегии большого взрыва.

Исходя из этого, каскадная модель управления проектами имеет очевидные недостатки: у нас нет обратной связи от заказчика до окончания проекта. Поэтому в ходе проекта мы аккумулируем очень большое количество рисков. Например, конце проекта на этапе приемки заказчиком мы можем узнать наш продукт не решает проблему клиента, и продукт становится никому не нужен. Мы слишком поздно можем узнать, что над проектом трудятся не те люди, не с теми навыками, и они не могут завершить проект и сделать поставку. Мы можем поздно понять, что наше предположение о сроках и бюджете были заблуждением и так далее. То есть, при использовании технологии Waterfall нужно продумать всё до мелочей, что безумно усложняет работу специалистов. А иногда и делает ее невозможной.

Метод Agile предлагает гибкий подход к управлению проектами. Так называемый, итеративный подход в управлении, когда мы делаем небольшие приращения. Мы идем по шагам, этапам. Гибкая методология разработки предполагает деление проекта на короткие этапы – итерации. У разработчиков появляется ретроспектива в конце каждой из них. Некий отзыв от клиента. В таком случае, если заказчика что-то не устроит, легко можно будет внести правки, не дожидаясь конечного продукта.

Ценности в Agile

  1. Люди и взаимодействие важнее процессов и инструментов. В классических организациях уровень коммуникации в компании обычно представляет собой некий зарегламентированный последовательный процесс. То есть для того чтобы, например, договориться чтобы из отдела аналитики в отдел разработки попала задача, есть целый определенный процесс, когда человек приходит в отдел разработки общается с руководителем, он оценивает ресурсы, затем приоритизирует задачи. В аджаил команде всё по-другому. У нас есть все необходимые специалисты и команда автономно.
  2. Работающий продукт важнее исчерпывающей документации. Для эджайл команды, в первую очередь, важно, чтобы в конце итерации был работающий продукт. А документация это уже вторичная история, которая подразумевает сохранение знаний.
  3. Сотрудничество с заказчиком важнее согласования условий контракта. В эйджил сотрудничество организовывается не путем согласования какого-то жесткого плана, за деньги и за объем работ, а, как правило, выстраиваются доверительные отношения. Заказчик включается в регулярную работу команды, то есть он видит, кто работает над проектом, он видит, как движется проект, он регулярно участвует в демонстрациях и видит результат. За счет этого он может, в целом, регулярно менять требования на каждую итерацию.
  4. Готовность к изменениям важнее следования первоначальному плану. Википедия говорит нам, что технология аджайл в принципе предполагает собой гибкость. Простыми словами, если мы понимаем, что мы движемся не туда, у нас НЕ должно быть каких-то, процессов регламентов, которые не позволят нам это сделать. У команды первичная цель – удовлетворенный заказчик и пользователь.

12 принципов методики

Так же, существуют принципы agile, которые по своей сути раскрывают вышеперечисленные ценности агила. Рассмотрим же их чуть подробнее:

  1. Удовлетворение потребностей пользователей, путем поставки ПО – наивысший приоритет. Если вы не занимаетесь разработкой программного обеспечения, то можете с легкостью переложить это пункт на другой вид деятельности, так как agile применима для любого проекта. Здесь речь о том, что фокус на заказчике, на быстрые регулярные поставки ценности. Всё делается, чтобы выстраивать доверительные отношения с заказчиком, чтобы он видел результат, и чтобы вы понимали, что вы делаете именно то, что ему нужно.
  2. Изменения приветствуются даже на поздних стадиях разработки. Когда используется каскадная система планирования сложно, а иногда и невозможно реализовать запросы от заказчика, полученные на финальном этапе разработки. Гибкая модель же позволяет это сделать с легкостью.
  3. Выпуск рабочего продукта как можно чаще. Менеджмент, построенный на основании принципов Agile, обычно предполагает предоставление промежуточных результатов сроком до месяца.
  4. Заказчики в бизнесе и разработчики должны работать совместно каждый день. Мы вовлекаем заинтересованных лиц, заказчиков в работу команды, на проработку задач, и в регулярно показываем им то, что у нас получается.
  5. В работе только мотивированные профессионалы. Эффективность Agile в образовании качественного продукта строится на работе действительно мастеров своего дела, которые действительно заинтересованы в его создании. При наборе людей в команду, мы стараемся доверять им.
  6. Непосредственное общение как внутри команды, так и вне ее. Коммуникациям уделяется большое внимание.
  7. Показатель прогресса – работающий продукт.
  8. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок. Когда вы выбираем итерации, то они должны быть стабильными. Например, если вы выбрали итерацию в две недели, то вы должны на протяжении достаточно долгого времени работать с итерациями в две недели. Вы не должны продолжительность менять, потому что это обеспечивает устойчивый ритм, обеспечивает понимание, как часто мы поставляем, когда вообще будет происходить показ продукта и так далее.
  9. Регулярное техническое совершенствование. Фокус команды не только на бизнес-ценности, но и на качестве продукта. Ведь IT в наше время не стоит на месте.
  10. Необходима простота. Трайб, команду agile нужно фокусировать на то, чтобы она выпускала такие продукты и проекты, которые максимально простые. Проекты, которые ориентированы не на то, чтобы засунуть побольше разной функциональности внутрь, а на том, чтобы максимально простым способом решить задачу заказчика или клиента. Что позволяет и вам быстрее это сделать и сэкономить деньги заказчику, и, в целом, сделать простое управляемое решение.
  11. Лучшие решения у самоорганизующихся команд. Принцип подразумевает, что участники внутри команды должны самостоятельно уметь принимать решения о том, как они будут делать этот проект или продукт с точки зрения технической реализации. Они должны уметь принимать решения, у них должны быть полномочия.
  12. Регулярно команда анализирует, как можно улучшить эффективность работы. После каждой итерации у команды должна быть ретроспектива, в ходе которой они уже вырабатывают методы разработки и улучшения своей работы. Они общаются и продумывают некий план действий по тому, как им улучшить свою работу, как работать эффективней.

Подходы аджаил working

По своей сути мы объединяем множество подходов в agile, что дает ему стать неким базовым фундаментом для этих подходов.

  • Scrum
  • LeSS — масштабируемый Scrum, когда у нас больше девяти людей в команде
  • SAFe (Scaled Agile Framework) – от 150 человек
  • TDD — test-driven development – разработка, основанная на тестах, когда сначала пишутся тесты, а потом идет уже идёт разработка под эти тесты.
  • Экстремальное программирование. Сюда также входит парное программирование, когда люди внутри команды садятся вместе, например, 2 разработчика и начинают делать одну функциональность совместно. Это позволяет улучшить качество и обучаемость внутри команды.

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

Подведем итоги. Мы с вами рассмотрели, что такое Agile. И показали, что Agile манифест содержит 4 ценности и 12 принципов, которые составляют основу Agile и являются базой для построения здоровой и продуктивной команды специалистов. Также, есть множество Agile подходов, которые помогают быть Agile. Например, Scrum, LeSS, TDD и другие.