Agile
Agile — семейство гибких подходов к разработке: продукт делают короткими циклами и меняют по обратной связи. Основа — Agile Manifesto: 17 разработчиков подписали его в феврале 2001 года в штате Юта.
Содержание
- 01Что такое Agile и откуда он взялся
- 02Четыре ценности манифеста и что они значат для заказчика
- 03Scrum, Kanban, XP: фреймворки на общей философии
- 04Как выглядит Agile-проект: личный кабинет за шесть спринтов
- 05Когда Agile подходит заказной разработке, а когда выигрывает последовательный план
- 06Чем Agile не является: прототип, MVP и «работа без ТЗ»
- 07Частые вопросы
Что такое Agile и откуда он взялся
Agile (от англ. agile — «гибкий, проворный») — семейство подходов к разработке, где продукт создают короткими циклами, показывают заказчику рабочий результат после каждого цикла и корректируют план по его обратной связи. Это не одна методика с жёсткими правилами и не должность в команде, а система ценностей, на которой строятся конкретные фреймворки.
Слово закрепилось в феврале 2001 года. Семнадцать разработчиков, среди них Кент Бек, Мартин Фаулер, Кен Швабер и Джефф Сазерленд, собрались на горнолыжном курорте Сноуберд в штате Юта и за три дня написали Agile Manifesto, «Манифест гибкой разработки программного обеспечения». Идея простая: план на год и горы документации не спасают проект, если к релизу требования уже изменились.
Четыре ценности манифеста и что они значат для заказчика
Манифест умещается в четыре строки, и в каждой левая часть важнее правой. Авторы оговаривают: правая часть тоже имеет ценность, просто левая весит больше.
| Ценность манифеста | Что это значит в проекте | Что будет, если перегнуть |
|---|---|---|
| Люди и взаимодействие важнее процессов и инструментов | Вопрос решается разговором, а не цепочкой согласований в трекере | Договорённости теряются |
| Работающий продукт важнее исчерпывающей документации | Заказчик оценивает страницу, которую можно нажать, а не отчёт о ней | Продукт не передать другой команде |
| Сотрудничество с заказчиком важнее согласования условий контракта | Заказчик участвует в проекте каждые две недели, а не только на приёмке | Без договорённости о бюджете спор неизбежен |
| Готовность к изменениям важнее следования плану | Приоритеты пересматривают по ходу проекта | Переделки без границ объёма |
К четырём ценностям добавлены двенадцать принципов. Среди них поставка рабочего продукта «от пары недель до пары месяцев» (чем короче, тем лучше), ежедневная совместная работа бизнеса и разработчиков и формула «простота — искусство не делать лишнего».
Scrum, Kanban, XP: фреймворки на общей философии
Манифест не говорит, во сколько проводить планёрку. Это делают фреймворки: каждый переводит ценности в конкретный порядок работы.
| Подход | Как устроена работа | Где работает лучше всего |
|---|---|---|
| Scrum | Спринты не длиннее месяца, три роли, набор встреч | Новый продукт с меняющимися требованиями |
| Kanban | Непрерывный поток задач на доске, лимит задач «в работе» | Поддержка сайта, поток мелких правок |
| Экстремальное программирование (XP) | Парная работа, автотесты, частые релизы | Сложная логика, где ошибка дорого стоит |
Kanban пришёл из производственной системы Toyota. В заказной разработке команда обычно берёт Scrum за основу и добавляет элементы Kanban и XP.
Как выглядит Agile-проект: личный кабинет за шесть спринтов
Допустим, сервисная компания заказывает личный кабинет клиента. Известно главное: клиент видит заявки и оплачивает счета. Остальное, от уведомлений до интеграции с 1С, определится по ходу. Команда работает двухнедельными спринтами, один спринт стоит 400 000 ₽ (условный расчёт).
- Бэклог. Заказчик и команда выписывают желаемое, допустим, 60 задач, и ранжируют их по пользе для бизнеса.
- Три спринта на ядро. В работу идут вход, список заявок и оплата. Через шесть недель и 1,2 млн ₽ готов MVP, который можно показать живым клиентам.
- Обратная связь. Двадцать клиентов тестируют кабинет. Выясняется, что интеграция с 1С нужнее уведомлений, а три запланированных отчёта никто не просит.
- Пересмотр приоритетов. Отчёты уходят из бэклога. На них пришлось бы потратить ещё два спринта, то есть 800 000 ₽, и теперь эти деньги остаются в бюджете.
Экономия здесь не от скорости разработчиков: идею проверили на пользователях раньше, чем потратили весь бюджет.
Когда Agile подходит заказной разработке, а когда выигрывает последовательный план
Гибкий подход оправдан там, где результат нельзя точно описать заранее. Если объём известен до последней страницы, Agile добавляет встречи и не даёт выигрыша.
| Ситуация | Что выбрать | Почему |
|---|---|---|
| SaaS, маркетплейс или приложение, где модель продукта проверяет рынок | Agile, обычно Scrum | Часть функций окажется лишней, часть появится по обратной связи |
| Корпоративный сайт на 15 страниц с утверждённым макетом | Последовательный план и чёткое техническое задание | Объём известен, менять в процессе нечего |
| Запуск к жёсткой дате, например к сезонной распродаже | Гибрид: срок и бюджет фиксированы, порядок задач гибкий | Что не успеет, уйдёт в следующий релиз |
Гибкость не отменяет бюджет: заказчик фиксирует сумму и срок, а набор функций остаётся переменной. Работу спринтами с демо для заказчика применяют в сложной разработке, а типовые проекты по разработке сайтов обходятся и фиксированной сметой. Из чего складывается цена в разных моделях, разобрано в материале о стоимости создания сайта.
Чем Agile не является: прототип, MVP и «работа без ТЗ»
- Agile не равен Scrum. Scrum — один из способов организовать гибкую работу, как Kanban или XP.
- Agile не отменяет документацию. Манифест ценит работающий продукт выше исчерпывающей документации, но не запрещает вести её. ТЗ превращается в живой бэклог.
- Agile не заменяет прототип. Прототип проверяет идею до разработки, а Agile управляет самой разработкой.
- Agile не означает отсутствие плана. План есть, но он короткий и пересматривается после каждого спринта.
Частые вопросы
Что такое Agile простыми словами?
Это подход к разработке, в котором продукт собирают небольшими частями за недели, а не за месяцы. После каждой части заказчик смотрит результат и говорит, что менять. Ошибки в понимании задачи вскрываются рано, пока их исправление недорого.
Чем Agile отличается от Scrum?
Agile — набор ценностей и принципов из манифеста 2001 года. Scrum — конкретный фреймворк с ролями, встречами и спринтами, построенный на этих ценностях. Любая команда на Scrum работает в логике Agile, но не каждая Agile-команда использует Scrum: одни выбирают Kanban, другие собирают свой набор практик.
Когда Agile не подходит?
Когда объём работ известен заранее и не изменится: типовой корпоративный сайт с утверждённым макетом или разовая интеграция по готовому описанию. Не подходит он и заказчику, который не готов участвовать в проекте раз в две недели: без его обратной связи Agile превращается в формальность.
Дороже ли разработка по Agile, чем по ТЗ?
Не обязательно. Стоимость спринта известна заранее, итог зависит от их числа. Экономия возникает, когда лишние функции отсекают по обратной связи, переплата — когда приоритеты меняют без конца. Бюджет можно ограничить: зафиксировать сумму и срок, а набор функций менять внутри рамок.
Кто и когда придумал Agile?
Слово стало общепринятым после встречи 17 разработчиков на курорте Сноуберд в штате Юта в феврале 2001 года. Они подписали Agile Manifesto: четыре ценности и двенадцать принципов. Отдельные практики, например Scrum, появились раньше, в 1990-х, а манифест объединил их общей философией.
Подходит ли Agile для создания сайта?
Для сложных проектов вроде маркетплейсов, личных кабинетов и SaaS да. Для простых сайтов лучше последовательная схема с чётким ТЗ. Если сомневаетесь, обсудите выбор с командой, которая занимается поддержкой и развитием сайтов: на старте важно понять, как будут поступать и приоритизироваться правки.