Agile — семейство процессов разработки, а не единственный подход в разработке программного обеспечения, и определяется Agile Manifesto. Agile не включает практик, а определяет ценности и принципы, которыми руководствуются команды.

Agile Manifesto (ценности и принципы, которыми руководствуются команды):

Основные идеи:
• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану.

Принципы, которые разъясняет Agile Manifesto:
• удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
• приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
• частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
• тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
• проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
• рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
• работающее программное обеспечение — лучший измеритель прогресса;
• спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
• постоянное внимание улучшению технического мастерства и удобному дизайну;
• простота — искусство не делать лишней работы;
• лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
• постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Scrum
Методология SCRUM, едва успев появиться, совершила настоящую революцию в мире IT.
Именно SCRUM положил начало таким гигантам как Microsoft, Google, Amazon, Salesforce.com.

SCRUM (SCRibing Unified Methodology) - это набор принципов на которых строится процесс SCRUM-разработки, позволяющий в жестко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающий продукт с новыми бизнес-возможностями, для которых определен наибольший приоритет.

Методология основана на тактике бега на короткие дистанции (спринта).

Задачи для реализации в спринте определяются в начале спринта на совещании для планирования задач (Sprint Planning Meeting) методом Planning Poker (задачи не могут меняться на всем протяжении спринта).
Фиксированная небольшая длительность спринта придает процессу разработки предсказуемость и гибкость.

Спринт - итерация в скраме, в ходе которой создается инкремент бизнес-продукта. Жестко фиксирован по времени.
Длительность одного спринта от 1 до 4 недель.
Чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении.

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

Артефакты SCRUM:
• Диаграмма сгорания задач (Burndown chart) - Диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта.
Данные диаграммы необходимо ежедневно обновлять, чтобы в реальном времени показывать подвижки и издержки в работе над спринтом и проектом, доступные для всех членов SCRUM-команды: скрам-мастера и скрам-владельца продукта.
Диаграмма сгорания работ для спринта — показывает, сколько задач сделано и сколько еще остается сделать в текущем спринте.
• Журнал пожеланий проекта (Project backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items). Журнал пожеланий проекта открыт для редактирования для всех участников скрам-процесса. Project backlog ведется SCRUM Product Owner.
• Журнал пожеланий спринта (Sprint backlog) — содержит функциональность, выбранную владельцем продукта из журнала пожеланий проекта. Все разбито по задачам, каждая из которых оценивается скрам-командой. На Sprint Planning Meeting команда оценивает объем работы, который нужно проделать для завершения спринта методом Planning Poker (задачи не могут меняться на всем протяжении sprint).
• Канбан-доска Канбан-доска должна состоять как минимум из трех колонок: «сделать» (англ. to-do), «в процессе» (in progress), «сделано»(done). При разработке ПО SCRUM канбан-доска обычно включает следующие колонки в соответствии со статусом задач: обсуждается (backlog), согласовано (ready), кодируется (coding), тестируется (testing), подтверждается (approval) и сделано (done). На доску в соответствующий столбец прикрепляются канбан-карточки[26]. Вместо специальных канбан-карточек, которые обычно обозначают потребность или пропускную способность, вместе с доской используются магниты, пластиковые фишки, цветные шайбы или стикеры для представления рабочих элементов и процессов. Каждый из этих объектов представляет собой этап производственного процесса и движется по доске, по мере прогресса. Такое движение соответствует движению SCRUM-процесса производства по Burndown Chart сверху вниз. Часто используется электронная Канбан-доска.
• Цель спринта (Sprint Goal). Это краткое описание бизнес-цели, ради которой выполняется данный спринт. Цель на спринт помогает команде принимать бизнес-обоснованные решения. Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения бизнес-задачи.
• История спринта (Sprint Story). Требуемую бизнес-функциональность, которую добавляют в бэклог, часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам, так и заказчикам.
• Остановка спринта (Abnormal Termination). Остановка спринта может быть произведена раньше срока его планового окончания в исключительных ситуациях. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить скрам мастер или владелец продукта, если исчезает необходимость в реализации цели спринта. После этого начинается новый спринт.
• Задачи истории спринта (Sprint Story Tasks). Добавляются к историям спринта. Выполнение каждой задачи оценивается в часах. Каждая задача не должна превышать 12 часов (зачастую команда настаивает, чтобы максимальная продолжительность задачи равнялась одному рабочему дню).
• Скорость скрам-команды (Velocity). Общее количество очков, набранных скрам-командой за предыдущий спринт. Данная метрика помогает команде понять, сколько историй она может сделать за один спринт.

Совещания (ритуалы SCRUM)
В начале спринта SCRUM Product Owner вносит в Product Backlog новые User Story и удаляет сделанные. Затем проводятся совещания.

Планирование спринта (Sprint Planning Meeting)
Происходит в начале новой итерации Спринта.
• Из бэклога проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда;
• На основе выбранных задач создается бэклог спринта. Каждая задача оценивается в идеальных человеко-часах;
• Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;
• Обсуждается и определяется, каким образом будет реализован этот объем работ;
• Продолжительность митинга ограничена сверху 8 часами в зависимости от продолжительности спринта, опыта команды и т. п.
• (первая часть совещания) Участвуют скрам-мастер, владелец продукта и скрам команда: выбирают задачи из бэклога продукта;
• (вторая часть совещания) Участвует только скрам-команда: обсуждают технические детали реализации, наполняют бэклог спринта.

Покер планирования (Planning Poker)
Покер планирования (Planning Poker, а также англ. Scrum poker) — техника оценки, основанная на достижении договоренности, главным образом используемая для оценки сложности предстоящей работы или относительного объема решаемых задач при разработке программного обеспечения.

Planning Poker проводится на Sprint Planning Meeting.
Для проведения покера планирования необходимо подготовить список обсуждаемых функций и несколько колод пронумерованных карт. Колода карт содержит карты 0, ?, 1, 2, 3, 5, 8, 13, 20, 40, 100, «?», «Чашка кофе». Знак вопроса означает, что «игрок» не понял до конца смысл обсуждаемого или не обладает достаточной информацией, чтобы оценить ее. Чашка кофе, в свою очередь, означает «Я устал, давайте передохнем».

Каждому участнику обсуждения выдается по одной колоде карт. Все колоды идентичны друг другу.

Участники выбирают по одной карте и кладут их рубашкой вверх, показывая таким образом, что выбор сделан. Числовые достоинства карт могут использоваться по-разному: они могут означать количество дней, наиболее подходящие дни или относительные единицы сложности (англ. story points). Каждый участник называет свою карту и переворачивает ее.

Ежедневное стоячее SCRUM-совещание (Daily SCRUM)
• начинается в одно и то же время в одном месте;
• все могут наблюдать, но только «свиньи» говорят;
• в митинге участвуют SCRUM Master, SCRUM Product Owner и SCRUM Team;
• длится ровно 15 минут;
• все участники во время Daily SCRUM стоят (митинг в формате Daily Standup).

SCRUM-мастер задает каждому члену SCRUM-команды 3 вопроса:
• Что я сделал с момента прошлой встречи для того, чтобы помочь Команде Разработки достигнуть Цели Спринта?
• Что я сделаю сегодня для того, чтобы помочь Команде Разработки достичь Цели Спринта?
• Вижу ли я препятствия для себя или Команды Разработки, которые могли бы затруднить достижение Цели Спринта? (Над решением этих проблем методом фасилитации работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.)

Agile
В основе идеи Agile лежал отказ от долгосрочного планирования в пользу динамичного формирования задач и возможности вносить изменения в любой момент, как только того потребует рынок в лице конечных потребителей или заказчиков продукта. Идея «гибкого» менеджмента на рубеже 20-21 веков стала настолько актуальной и востребованной, что пришло время оформить её в виде свода ценностей и принципов.

Scrum
Ориентирование на актуальные потребности меняющегося рынка предполагает логичное решение в виде создания канала (-ов) получения обратной связи от потребителя или заказчика. Для полноты информации желательно настраивать такой канал, по которому будут приходить не абстрактные рассуждения, а отклики на практическое использование продукта. Чем чаще отклики будут приходить, тем тоньше и точнее получится настройка конечного продукта.

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

1) Вся работа над проектом разделяется на короткие этапы – итерации (в Scrum, например, такие этапы называются «спринтами»). За время одной итерации нужно успеть выпустить продукт, который можно тестировать и получать отклики от потребителей (технический модуль, приложение, локальную услугу – например, востребованность кофемашины в булочной и т. д.).

2) Любые замечания или требования рынка фиксируются и входят в список требований на следующую итерацию. То есть, план составляется по ходу создания продукта. Подобные этапы цикличны и возобновляются до тех пор, пока не исчерпается список требований.

3) Чтобы было удобно фиксировать требования рынка они, как правило, приводятся к единому формату (в Scrum – это «пользовательские истории») и размещаются на информационных площадках (досках).

4) Чем эффективнее и достовернее каналы связи с потребителями, тем выше вероятность получения исчерпывающей информации. Множественные эксперименты дают более злободневные данные о продукте и о клиенте. Причём, каждая значимая поправка добавляет полезность, а, значит, и ценность конечному продукту. (За поддержание такой связи с заказчиком и создание ценности в Scrum отвечает специальный «персонаж» – т. н. «Владелец проекта»). А ориентированность на клиента – это ключевая ценность философии Agile.

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

К отдельным agile-подходам относятся scrum и kanban.

Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.

Scrum-подход делит рабочий процесс на равные спринты – обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце – обсуждаются результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.

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

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

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