Agile появился в далеком 2001 году, но еще десять лет назад на собеседовании в российскую IT-компанию редко можно было услышать «Вы работаете по agile или waterfall?». Сторонники подхода собирались на узкопрофильных конференциях, а agile внедряли только самые передовые компании.
Сейчас по Agile работают полностью или частично большинство разработчиков. Метод ценят за создание среды, в которой есть место здоровому стрессу, поддержке и мягким дедлайнам. Подход поддерживает креативные идеи и делает итоговый продукт более конкурентоспособным. Заказчики уважают agile за то, что он ставит их желания на первое место.
В этом тексте подробно расскажем, как планировать процессы в системе, которая основана на отказе от планирования. Опишем цикл разработки по agile и покажем его этапы.
Что такое Agile
В российском IT-сленге в ходу термины «аджайл», «агиле», но чаще используют именно латинское написание.
Agile — это подход к разработке продукта, основанный на гибкости и постоянном общении между всеми участниками процесса.
Его создали 17 разработчиков, бывших сторонниками разных подходов. Они назвали себя Agile Alliance.
Они вывели 12 принципов и 4 ценности разработки, которые легли в основу Agile-философии.
Более детально мы рассказываем об Agile в материале «Agile: что это за метод, кому подходит и как его применять».
Базовые принципы Agile
Их 12, и они описывают общие подходы к разработке. Принципы делают центром внимания реальные потребности, а не бюрократию и выполнение пунктов «для галочки». Чтобы поспевать за меняющимися условиями рынка и создать конкурентоспособный продукт, заказчика наделяют правом менять техническое задание в любой момент разработки, даже на последних этапах. В результате в Agile сроки пляшут чечетку, зато готовый продукт максимально похож на то, что хочет заказчик.
Важная деталь — во всех Agile-методиках заказчик и разработчики сотрудничают друг с другом. Обычно роль посредника играет продакт- или проджект-менеджер на стороне команды разработки. Это человек, который трудится над продуктом вместе со всеми каждый день и обеспечивает быструю связь между командой программистов и своим руководством.
Также сторонники Agile выступают за простоту. Команда отказывается от лишней работы и работает в минимальном составе.
Более подробно принципы разобраны в материале «Agile-манифест: ключевые положения, принципы, история и развитие».
Методологии Agile
Сам по себе Agile методологией не является, его принято считать стилем подхода или даже философией разработки. В рамках него есть несколько методологий со своими правилами. Все они предполагают разбивку проекта на этапы, после каждого из которых заказчик или его представитель может вмешаться в процесс, предложить правки, поменять ТЗ или задать вопрос.
Самые популярные методологии — Scrum и Kanban, на них мы подробнее остановимся ниже. Они просты для изучения, а ещё они подходят не только для IT-разработки, но и для других проектов. Например, для выпуска книг и периодики или для организации крупных мероприятий.
К практикам Agile также относят:
- Extreme Programming (XP) — это методология разработки программного обеспечения, которая фокусируется на качестве кода и коммуникации. Вместо код ревью здесь парное программирование, когда один разработчик пишет код, а другой отсматривает его в реальном времени.
- DevOps — это методологический подход, объединяющий разработку и эксплуатацию, К нему прибегают, когда хотят ускорить поставку и повысить качество программного обеспечения. Пока команда занята улучшением, предыдущая версия уже на тестировании у заказчика, а пред-предыдущая — доступна пользователям!
- LeSS (Large-Scale Scrum) — это расширение методологии Scrum, разработанное для поддержки крупномасштабных проектов. Оно позволяет нескольким командам работать вместе над одним продуктом.
- Lean — это методология, основанная на принципах бережливого производства. Она уменьшает потери и увеличивает ценность продукта для пользователя. В первую очередь направлена на определение ценности, устранение потерь и непрерывное улучшение процессов.
- DSDM (Dynamic Systems Development Method) — метод, целью которого является сдать проект в срок и при этом уложиться в бюджет, придерживаясь Agile-принципов.
Всего насчитывается 19 методологий в рамках Agile. Их объединяет заявленная философией гибкость, открытость и желание помочь клиенту с наименьшими потерями.
Методика Kanban
Своё название получила от канбан-доски — меловой или магнитной поверхности, на которой разными цветами визуализируют проект. По расцветке каждый специалист знает свою роль на этом этапе работы, отмечает статусы и задачи.
Смысл подхода в прозрачности всех процессов и наглядности. Именно они обеспечивают необходимую в Agile гибкость.
Подробный обзор методологии читайте в нашей статье «Kanban: что это, как работает, и причем тут Agile».
Методика Scrum
Гибкость в Scrum достигается благодаря постоянному общению. Руководитель команды зовется скрам-мастером, и его задача — устраивать ежедневные встречи, собирать обратную связь от заказчика и доносить её до разработчиков.
Особенность Scrum в делении проекта на короткие одинаковые по продолжительности периоды. Например, по месяцу. После каждого из них заказчику на тест отдаётся новая версия проекта.
Из каких этапов состоит гибкий цикл разработки Agile
В каждой методологии цикл разработки свой, но есть и общие этапы. Agile основан на циклах: короткий подход, тест, обратная связь, заново.
Покажем этапы на примере разработки приложения, чтобы было нагляднее.
- Обсуждение и планирование проекта в целом. На этом этапе решают, какие функции нужны в первую очередь. Допустим, вы хотите приложение, которое считает шаги и строит маршруты по нужному количеству шагов до цели.
- Разработка функции №1. Для нас это счет шагов. Разработчики сделали его и отдали нам на тестирование.
- Разработка функции №2. Проектирование маршрутов по числу шагов. Разработчики делают первый вариант карты и отдают на тест.
- Доработка. Вы протестировали функционал №1 и решили, что неплохо бы еще добавить цели по шагам и уведомления, когда они достигнуты. Отправили пожелания по функции №1 разработчикам.
- Демо-версия. Вы получаете приложения со всеми функциями и решаете, что доработать или изменить.
- Релиз. Вы решаете, что продукт готов к выпуску. Правки из пункта 4 можно внедрить уже после запуска и добавить после обновления.
- Следующая итерация. Начинается новый цикл.
Таким образом готовый продукт создается в кратчайшие сроки, одновременно с этим дорабатывается и тестируется. В некоторых методологиях набор этапов может отличаться. В скраме он дополняется постоянными обсуждениями и тестами, в канбане — пометками на доске по всем процессам, чтобы заказчик мог подключиться в любой момент и внести коррективы.
Для сравнения, в не-Agile схеме разработка такого же приложения с подсчётом шагов и маршрутами выглядела бы так:
- Заказчик пишет полное техническое задание, описывающее весь функционал приложения: экраны, кнопки, все способности программы. ТЗ должно быть исчерпывающим — заранее отвечать на все вопросы и описывать, как должен выглядеть финальный продукт.
- Когда ТЗ готово, его передают разработчикам на реализацию.
- Команда программирует, тестирует и разрабатывает дизайн. Заказчику сдают готовый продукт. Замечания и пожелания, если они не были изначально указаны в ТЗ, не берутся в расчет.
- Подписывается акт приёма-передачи. Все дальнейшие доработки оформляются дополнительными соглашениями или новыми заказами и отрабатываются также последовательно.
Такой метод разработки вполне можно использовать, если создаётся что-то простое, в чём вы уверены заранее. Например, типовую утилиту для внутреннего пользования. Это будет дешевле и быстрее. Зато Agile может обеспечить более актуальный результат, потому что позволяет реагировать на изменения рынка.
Подойдёт ли вам Agile
Чтобы понять, нужен ли вам Agile-подход, ответьте на утверждения ниже «да» или «нет». Если вы согласны с большинством пунктов, значит, лучше выбрать традиционную поэтапную разработку.
- У вас строгое ТЗ с жесткими сроками.
Agile предполагает гибкость, поэтому и сроки тоже должны быть гибкими. - Вы точно знаете, что хотите получить на выходе и не поменяете свои желания.
Даже если сейчас вам так кажется, это не значит, что за время разработки ничего не изменится. Поэтому хорошо подумайте, прежде чем ответить на этот вопрос. - Вы работаете в зарегулированной сфере.
В целом это не помеха, но Agile-разработка отводит бюрократию на второй план, а для государственной сферы порядок документации и отчёты важны. - Проект нужно будет много раз повторять с неизменным результатом.
Если нужно построить пять одинаковых зданий, с Agile получится пять уникальных. - Вам хочется отправить ТЗ разработчикам и забыть о проекте до сдачи.
Работая по Agile, будьте готовы к постоянному участию заказчика в проекте. - У вас нет времени на постоянные совещания, летучки и согласования.
В Agile их действительно много, поэтому стоит выделить для этого отдельного человека или быть готовым найти время на обсуждения.
Финальное решение за вами. Не воспринимайте Agile как волшебную таблетку и учитывайте при планировании все особенности.
Что в итоге
Гибкие методологии управления проектами захватили мир IT и продолжают экспансию за его пределами. Упрощение, внимание к клиенту и его желаниям, мягкие дедлайны и постоянные обсуждения, подход «от клиента», а не «от продукта» помогают командам получать конкурентоспособный качественный результат. Однако следует помнить, что Agile — это не только про гибкость, но и про повышенный ценник и меняющиеся дедлайны, потому что продукт будет постоянно дорабатываться и улучшаться. Часто это означает постоянное продление договора с разработчиками и в определенный момент начинает напоминать подписку с автопродлением на IT-компанию и ее услуги.
Лучше всего Agile работает в небольших мотивированных командах профессионалов, где каждый болеет за проект и ничего не делает для галочки.
