Agile Манифест был опубликован в 2001 году. Он определил ценности и принципы, на основе которых всё множество практик, использовавшихся в разработке программного обеспечения, как новых, так и ранее существовавших, было разделено на две части – Agile практики и не-Agile практики.

Например, юнит-тестирование, покер планирования, ежедневные стендапы стали считаться Agile практиками.

С другой стороны, штрафование сотрудников, подготовка и подписание полного ТЗ проекта, разделение команд по функциональному признаку (отделы архитектуры, разработки, качества) в Agile список не попали.

Причины, по которым ту или иную практику считают Agile или наоборот, не всегда очевидны.

Данная статья – попытка переосмыслить известные мне Agile практики, сформулировать простые и четкие критерии того, какую практику можно считать Agile, а какую нет.

Построю статью следующим образом. Сначала предложу критерии, затем протестирую их на примерах.

Критерии

Практику (а также идею, ценность, принцип, или даже целый фреймворк) будем считать Agile, если она соответствует хотя бы одному критерию (и не противоречит всем остальным). И наоборот, если практика противоречит хотя бы одному критерию, она не будет считаться Agile.

Креативные профессионалы

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

Agile поощряет обучение и профессиональный рост.

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

Эффективные коммуникации

Эффективные – это те коммуникации, которые ведут к принятию правильных решений.

Главный инструмент Agile – живое общение лицом к лицу (face-to-face). При этом задействуются все каналы передачи информации, доступные человеку, причем в обоих направлениях.

Важный фактор успеха – открытый обмен мнениями, исследование альтернатив, конструктивный конфликт, поиск эффективного решения.

Прозрачность, полное раскрытие информации без страха быть наказанным.

Ценность для заказчика/пользователя

Следуя идеям бережливого (lean) производства, Agile фокусируется на деятельности, создающей ценность.

Agile старается исключать/минимизировать всё, что ценности не приносит (eliminate waste).

Обратная связь

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

Важнейший фактор – оперативность обратной связи.

Соответствие ценностей Agile Манифеста предложенным критериям

Agile Value	Критерии
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану

Протестируем известные Agile практики

Регулярный рефакторинг кода

проясняет архитектуру, открывает путь к творчеству, обучению и совершенствованию

облегчает дальнейшее развитие продукта, ускоряет внесение изменений (eliminate waste)

замыкает петлю обратной связи: выявили проблемы – решаем их

Настольный теннис в офисе

позволяет перемежать работу и отдых, снижает стресс, подчеркивает свободу

Конструктивный конфликт

разносторонняя оценка, принятие эффективных решений посредством двусторонней коммуникации

Кросс-функциональные команды

нет потерь времени при передаче задач между командами

разносторонняя оценка, принятие решений, учитывающих все аспекты

Ежедневные стендапы

быстрая обратная связь

прозрачность, взаимопомощь

Информационные радиаторы (канбан-доски, burnup charts)

прозрачность

Бэклог, user stories

наиболее ценные задачи делаем в первую очередь

механизм обратной связи заложен в приемку каждой user story; декомпозиция сторей до небольшого размера повышает оперативность обратной связи

Planning Poker (быстрая коллективная оценка задач)

предварительное обсуждение задач и плана работ, прозрачность

не тратим много времени на раннюю проработку и точную оценку (многие из оцениваемых задач не дойдут до разработки, тратить на них время бессмысленно)

обратная связь владельцу продукта по сложным задачам, требующим декомпозиции

Планирование спринта

обсуждение задач непосредственно перед разработкой

наиболее ценные задачи делаем в первую очередь

обратная связь о том, что может или не может быть сделано прямо сейчас

Открытые рабочие пространства (open space)

оперативный обмен информацией, фоновое восприятие и вычленение релевантной информации

Разработка короткими итерациями (спринтами)

частое планирование и частое подведение итогов

Парное программирование

наиболее оперативная обратная связь – в момент написания кода

Автоматизированное тестирование, юнит-тесты, непрерывная интеграция и поставка (CI/CD)

оперативная обратная связь

Definition of Done

выполнение DoD – важная точка обратной связи

DoD обычно включает поставку ценности клиенту

Не Agile практики

Работа по большому ТЗ, подписанному заказчиком

существенно откладывает или даже блокирует обратную связь

ценность продукта падает, так как не учитываются изменившиеся требования

блокирует открытое общение с заказчиком, создает почву для конфликтов с ним

Поиск виноватого, штрафование сотрудников

демотивирует конкретного человека, подрывает доверие в команде; штраф – сильнейший демотиватор

вместо обмена мнениями о проблеме и способах её решения, идет поиск виноватого

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

Персональное назначение задач (тимлидом / менеджером проекта)

ограничивает творчество, не способствует укреплению команды

отсутствие обсуждения не способствует эффективному принятию решений

создает узкое место в лице того, кто назначает, что приводит к простоям и ожиданиям

способствует отстраненности, не фокусирует команду на целях и ценностях клиента

Логирование времени

демотивирует сотрудников

вместо обсуждения проблемы навязывается процесс

требует дополнительных усилий, не приносящих ценности

может быть полезным в качестве обратной связи для улучшения процесса

Технический долг

рутина (сложность кода, долгое устранение ошибок) блокирует творчество

обслуживание технического долга – это расточительство, оно не приносит ценности, наоборот, отнимает её

Попытки заказчика/менеджера уменьшить оценки трудозатрат, определенные разработчиками

демонстрирует недоверие, демотивирует разработчиков; повышенный стресс приводит к перенапряжению, выгоранию

подавляет открытый обмен информацией, снижает прозрачность, вводит в заблуждение заказчика

авторитарное принятие решений блокирует обратную связь

Заключение

Приведенные критерии – не замена Манифесту. Но они очень помогают мне в повседневной работе. С их помощью (на картинках) я объясняю, что значит быть Agile. С их помощью оцениваю то, с чем сталкиваюсь. Мне бы хотелось узнать, что вы об этом думаете.

Напишите, пожалуйста, в комментариях, всегда ли вам очевидно, является та или иная практика Agile? Как вы разрешаете этот вопрос?

Напишите, какие Agile или не-Agile практики не соответствуют, на ваш взгляд, предложенным критериям. Предложите свои критерии.