Что такое Agile?

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

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

Что такое Agile: краткая история

Механический перевод слова не раскрывает понятие полностью. Agile и flexible нередко переводят одним словом «гибкий», но оттенки различаются. Гибкость может описывать физическое свойство, тогда как agile также подразумевает подвижность мышления, быструю реакцию и способность менять направление.

В совокупности эти значения дают более полное представление. Исходная статья ссылается на материал Д. Блинова 2021 года об истории Agile-манифеста. Сам манифест определяет ценности и принципы разработки программного обеспечения.

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

Agile-манифест: четыре ценности и двенадцать принципов

Манифест 2001 года описывает приоритеты разработки и сотрудничества с заказчиком. Четыре ценности придают большее значение:

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

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

Двенадцать принципов

1. Считать удовлетворение заказчика полезными поставками главным приоритетом.
2. Быть готовыми к изменению требований, в том числе на поздних этапах.
3. Часто поставлять работающие части продукта.
4. Обеспечивать сотрудничество представителей бизнеса и разработчиков на протяжении проекта.
5. Создавать мотивированным профессионалам нужные условия, поддерживать их и доверять их работе.
6. Использовать прямое общение для общего понимания.
7. Оценивать прогресс прежде всего по работающему продукту.
8. Поддерживать устойчивый темп для заказчиков, разработчиков и пользователей.
9. Постоянно уделять внимание техническому качеству и хорошему проектированию.
10. Стремиться к простоте и сокращать ненужную работу.
11. Позволять эффективным самоорганизующимся командам вырабатывать требования, архитектуру и решения.
12. Регулярно искать способы повысить эффективность команды и корректировать работу.

Эти принципы поддерживают итеративный подход: выполнение работы сопровождается анализом результата и уточнением следующих шагов. Полезной аналогией служит цикл PDCA:

1. План: спланировать работу.
2. Do: выполнить её.
3. Check: проверить результат.
4. Act: внести необходимые изменения и начать следующий цикл.

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

Философия Agile и управление

В обсуждениях часто спрашивают, является ли Agile методологией или философией. Полезно различать общую философию и конкретные методы её применения. Ниже рассматриваются Scrum, Kanban, Extreme Programming (XP), DSDM и Feature Driven Development (FDD).

Scrum

Название связано с регби и согласованной командной работой. Исходная статья рассказывает об исследованиях Хиротаки Такэути и Икудзиро Нонаки, а затем о применении Scrum Джеффом Сазерлендом в разработке программ в 1990-х годах. В ней также упоминаются книга Сазерленда и использование подхода крупными организациями.

Работу помогают организовать несколько понятий:

• Product Backlog: упорядоченная работа, необходимая для продукта.
• Sprint Backlog: работа, выбранная и запланированная на спринт.
• Sprint Goal: общая цель спринта.
• Burndown chart: возможный способ показать оставшийся объём работы; это вспомогательный приём, а не весь метод.

Ответственность и рабочие договорённости должны быть понятны. Product Owner отвечает за ценность продукта и порядок бэклога и обладает полномочиями принимать соответствующие продуктовые решения. Разработчики создают инкремент. Scrum Master помогает команде и организации эффективно применять Scrum и устранять препятствия.

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

Kanban

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

На доске задачи могут проходить следующие стадии:

• Запланировано.
• В разработке.
• На тестировании.
• Готово.

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

Extreme Programming (XP)

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

Исходный материал ссылается на работы Кента Бека о разработке через тестирование. Среди рассматриваемых практик:

• Единые стандарты кода для всей команды.
• Написание теста до реализации в цикле разработки через тестирование.
• Внимательное общение разработчиков и заказчиков для устранения вопросов и недопонимания.
• Планирование следующего шага после анализа предыдущего и корректировка текущего плана при необходимости.

Эти практики помогают работать с меняющимися требованиями и сосредоточиться на полезном для заказчика результате.

DSDM

DSDM расшифровывается как Dynamic Systems Development Method. Подход рассматривает подготовку, сам проект и работу после поставки, начиная с бизнес-целей и доступных ресурсов. В статье приводится историческое изложение девяти идей:

1. Активно вовлекать заказчиков и пользователей.
2. Давать команде право принимать уместные решения без постоянных дополнительных согласований.
3. Вовремя поставлять решение, пригодное для своей цели, вместо бесконечного совершенствования.
4. Быстро решать критические функциональные проблемы и поставлять полезные возможности.
5. Использовать обратную связь заказчика для улучшения результата.
6. По возможности сохранять обратимость изменений.
7. Определять основные требования до начала детальной работы.
8. Включать тестирование во весь процесс разработки.
9. Поддерживать тесное сотрудничество участников.

Эти идеи пересекаются с другими описанными подходами. Для дополнительного знакомства исходная статья рекомендует книгу Дженнифер Стэплтон о DSDM. Историческое изложение следует отличать от формулировок и структуры более поздних версий фреймворка.

Feature Driven Development (FDD)

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

1. Разработать общую модель и определить задачи продукта.
2. Составить список функций на основе этих потребностей.
3. Планировать работу по функциям.
4. Проектировать по функциям.
5. Реализовывать по функциям.

FDD явно выделяет моделирование системы. Это различие в акцентах, а не основание отрицать пользу других подходов.

Преимущества Agile

Главное преимущество — способность реагировать на изменения. Цифровые продукты работают в меняющейся среде, а частая обратная связь помогает адаптироваться. Небольшим командам с понятными полномочиями и тесным общением зачастую проще это организовать.

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

Ограничения и трудности внедрения

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

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

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

Идеи Agile обсуждаются и за пределами IT: в инженерии, оборудовании и потребительских товарах. Исходная статья приводит коляску Britax B-Agile как иллюстрацию адаптивности, однако название или конструкция изделия сами по себе не доказывают применение конкретного метода разработки. Общий вывод — выбирать практики под задачу, поддерживать обратную связь и оценивать пользу результата.