О методологии Agile простыми словами

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

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

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

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

Почему именно Agile?

TL;DR — чтобы подстраиваться под постоянно меняющиеся требования.

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

Более традиционные подходы вроде Waterfall (каскадная модель) диктуют тотальное планирование, когда вы ничего не можете сделать, если этого нет в плане.

В любом проекте, будь то программное обеспечение, маркетинговая кампания или рекрутинговая стратегия, появятся дополнительные возможности или поменяются требования. Особенно в случае с крупными проектами. Поэтому новые факторы приходится либо игнорировать (обычно неидеально), либо ужимать план, погружая работу в хаос. Так зачем тогда вообще планировать, правда?

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

Что такое Agile?

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

Agile — способность меняться легко и быстро.

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

Определение приоритетов очень важно, по сути это и есть самое главное в гибкой методологии разработки. Вам нужно убедиться, что команда сфокусирована на одном спринте или на наиболее важном на данный момент результате. Это будет гарантией того, что вы достигнете ваших бизнес-целей. Так ваша команда не потеряется в потоке запросов и требований и будет знать, что каждая подзадача, над которой она работает в данный момент, важна для прогресса всего проекта.

Пользовательские истории поставляются либо непрерывно, либо маленькими циклами, которые называются спринтами.

Как работает Agile?

TL;DR — Требования > План > Работа > Ревью > Повтор

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

Оцените каждый этап: по часам или по так называемым story point’ам (относительные оценки, которые выставляются в сравнении и отношении к другим историям). Есть вероятность, что результат будет несколько неточным и даст вам слабое представление о том, сколько времени займёт работа над проектом.

Установите приоритетность задач, самые важные — в начало очереди. Обычно в этой среде всё постоянно меняется, поэтому проверяйте приоритеты быстро и часто. Kanban очень реагирует на эту частоту. Scrum же основан на фиксированных циклах (спринтах), которые обычно длятся две недели.

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

Scrum vs Kanban

TL;DR — это два основных фреймворка для Agile.

Scrum

• Деление работы на части, которые называются спринтами (обычно в спринте две недели);
• Спринты планируются исходя из требований для этого конкретного момента времени;
• Относительная оценка времени выполнения работ;
• Ревью каждого спринта, чтобы понять, как он прошёл и что можно было бы улучшить;
• Фидбек по поставляемому продукту;
• Ежедневные собрания (очень короткие).

Kanban

• Еженедельные собрания;
• Непрерывная разработка;
• Визуализация процесса на доске;
• Решение сначала самых важных задач;
• Поэтапные улучшения.

Заключение

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