10.7 Agile

Обзор и мотивация

Agile это мировоззрение поставки программного обеспечения (и ценности) итеративно, инкрементально и в тесном сотрудничестве с теми, кто будет им пользоваться. Кодифицированный в Манифесте гибкой разработки программного обеспечения 2001 года, он лучше всего понимается не как процесс, а как набор ценностей и принципов: приоритет людей и взаимодействий, работающего программного обеспечения, сотрудничества с клиентом и реакции на изменения над тяжёлыми по планам, контрактам и документации умолчаниями, что были прежде. Рамки вроде Scrum, Kanban и экстремального программирования (XP) реализации этого мировоззрения. Они полезные отправные точки, но не само мировоззрение. Эта глава дополняет главу 1.4 (способы работы, широко обозревающую методы), углубляясь именно в Agile.

Agile движется той же силой, что одушевляет конвейеры исследования и поставки (главы 11.1–11.2): требования к программному обеспечению открываются, а не полностью известны заранее, и мир меняется быстрее, чем длинный план может поглотить. Поставка «всё разом» с планированием всего заранее неоднократно производит системы, опаздывающие, превышающие бюджет и, хуже всего, неверные, потому что всё обучение приходит в конце, когда действовать по нему дороже всего. Основная ставка Agile проста: короткие циклы построения реального работающего программного обеспечения и получения реальной обратной связи побеждают длинные циклы спекуляции. При хорошем исполнении он снижает риск непрерывно, а не откладывает его.

Для больших команд, корпораций и государства Agile одновременно мощен и часто искажён. Корпорации принимают его по сотням команд и нередко сводят к ритуалу («теперь у нас ежедневные планёрки»), не меняя того, как принимаются решения или измеряется ценность. Государство приняло Agile намеренно, потому что итеративная, ориентированная на пользователя поставка демонстрируемо снижает риск больших общественных программ: Цифровая служба США и её Digital Services Playbook, Государственная цифровая служба Великобритании и Стандарт услуг и реформы agile-закупок возникли отчасти в ответ на громкие провалы водопада. Приз реален. Как и режим отказа «agile только по названию».

Ключевые принципы

Ценить четыре ценности Манифеста (людей, работающее программное обеспечение, сотрудничество и отзывчивость) выше артефактов процесса.
Часто поставлять работающее программное обеспечение малыми приращениями; работающее программное обеспечение основная мера прогресса.
Приветствовать изменения, даже поздние; адаптивность функция, а не провал.
Строить вокруг мотивированных, наделённых полномочиями, самоорганизующихся команд.
Непрерывно сотрудничать с пользователями и заинтересованными сторонами.
Размышлять и улучшаться по регулярному ритму.
Поддерживать человечный темп и техническое мастерство: скорость без ремесла рушится.

Компромиссы: плюсы и минусы

Решение	Плюсы	Минусы
Agile (адаптивный)	Быстрая обратная связь; поглощает изменения; ранняя непрерывная ценность	Труднее зафиксировать объём/цену заранее; требует вовлечённого клиента и дисциплины
Водопад (предиктивный)	Предсказуемый объём; дружелюбно к контрактам/аудиту	Поздняя обратная связь; риск «всё разом»; плохо подходит неопределённым требованиям
Scrum	Ритм, роли, фокус; широко понятен	Накладные расходы церемоний; трудности с работой, управляемой прерываниями
Kanban	Поток, пределы WIP, гибко; отлично для эксплуатации	Меньше структуры; нужна дисциплина для удержания пределов
Тяжёлое масштабирование (SAFe)	Координирует много команд; знакомо большим организациям	Может вновь ввести командно-административное управление; тяжело на церемонии
Уменьшение / автономия команд	Меньше накладные расходы координации; быстрее команды	Требует низкой связности и сильной платформы/владения

Определяющее напряжение адаптивность против предсказуемости, и классическое неверное прочтение в том, что Agile означает «без плана». Это не так. Он означает планирование непрерывно и обязательства по результатам и ритму, пока объём гнётся. Другая повторяющаяся ловушка воспринимать Agile только как процесс (церемонии) или только как инженерию (XP). Ему нужно и то, и другое.

Вопросы для обсуждения с командой

В вашем корпоративном или государственном контексте ваши контракты модульные и ориентированные на результат или поставка заперта внутри одного мегаконтракта с фиксированным объёмом? Agile-закупки то место, где гибкость государственного сектора чаще всего преуспевает или проваливается, потому что единый контракт с фиксированной ценой и фиксированным объёмом навязывает водопад, как бы команды поставки ни называли свои совещания. Модульные ориентированные на результат контракты с более короткими приращениями позволяют объёму гнуться до ценного ядра в рамках фиксированного финансирования, а это именно шаблон современных успехов государственного сектора и противоядие прошлым провалам «всё разом». Принесите свидетельства: посмотрите на ваши текущие контракты и спросите, платят ли поставщику за продемонстрированное работающее программное обеспечение или за фиксированный объём, подписанный годы назад. Ответ должен формировать то, как вы структурируете следующую закупку, гораздо сильнее, чем то, какую рамку ваши команды принимают внутри. Нельзя быть адаптивным в поставке, пока ваш контракт предписывает далёкий запуск «всё или ничего».
Встроены ли аудит, доступность и безопасность в каждое приращение через автоматизацию или прикручены как поздний барьер? Соответствие по ходу дела позволяет адаптивной поставке сосуществовать с институциональными ограничениями: встраивайте проверки в приращение через автоматизацию и функции пригодности, а не откладывайте на предвыпускную суету. Поздний барьер соответствия вновь вводит риск «всё разом», который Agile призван был убрать, потому что дорогие проблемы всплывают в конце, когда их труднее всего исправить. Принесите свидетельства: для вашего последнего приращения проверьте, были ли доступность, безопасность и свидетельства аудита проверены автоматически в конвейере или отложены на ручную рецензию перед запуском. Ответ должен вытолкнуть эти свойства в непрерывные автоматические проверки, чтобы надзор удовлетворялся самим актом построения, а не отдельной фазой. Это также то, что держит регулируемую программу честной между аудитами, а не только в недели перед ними.
Как вы узнаете, что ваши команды спринтами влетают в технический долг, и что защищает устойчивый темп под давлением запуска? Agile без инженерной дисциплины вырождается в тёмный scrum, где команды быстро спринтуют в смоляную яму дефектов и несопровождаемого кода, а выгоревшие команды не могут поддерживать качество или отзывчивость. Практики XP (непрерывная интеграция, автоматическое тестирование, рефакторинг, разработка на основе ствола) позволяют команде продолжать дёшево менять программное обеспечение, а это вся предпосылка гибкости, поэтому они не необязательные дополнения, которыми жертвуют, когда маячит дата. Принесите свидетельства: отслеживайте, сокращается или растёт время выполнения, растёт ли доля дефектов и не работает ли команда тихо дольше, чтобы уложиться в каждый спринт. Ответ должен сделать техническое мастерство и человечный темп не подлежащими обсуждению, потому что скорость, купленная ценой ремесла, рушится в течение нескольких итераций. Измеряйте поток и результаты, никогда не скорость как цель, потому что в момент, когда вы делаете сигнал мощности целью продуктивности, он становится ложью.
Прежде чем тянуться к тяжёлой рамке масштабирования, пытались ли вы сократить межкомандные зависимости, создающие потребность в координации с самого начала? Это важнее всего для большой организации, потому что рефлекс, когда много команд должны отгружать вместе, купить рамку вроде SAFe, LeSS или Scrum@Scale, а тяжёлые механизмы масштабирования нередко протаскивают обратно командно-административные, тяжёлые по планам накладные расходы, которые Agile призван убрать. Конкурирующее соображение реально: некоторая координация действительно необходима, а уменьшение в независимые выровненные по потоку команды требует низкой связности, ясного владения и платформы, достаточно зрелой, чтобы команды могли обслуживать себя сами, чего у вас пока может не быть. Принесите на обсуждение свидетельства: картируйте реальные зависимости, заставляющие команды ждать друг друга, и спросите, сколько пережило бы намеренный пересмотр границ команд и владения сервисами. В корпоративных и государственных программах, где оргсхема из десятков команд обычное дело, честный вопрос в том, не добавляете ли вы структуру координации, чтобы компенсировать архитектуру и устройство команд, которые можно было бы упростить, чтобы вообще нуждаться в меньшей координации.
Есть ли у ваших команд подлинный повторяющийся контакт с гражданами или клиентами, для которых они строят, или обратная связь приходит отфильтрованной через посредников? Сотрудничество с клиентом одна из четырёх ценностей Манифеста, а итерации без реального контакта с пользователями тихо оптимизируют не то, что самый дорогой провал, который Agile призван предотвращать. Напряжение в том, что прямой доступ трудно организовать в масштабе, и ему нередко мешают именно те правила закупок, приватности и безопасности, что большие и государственные организации должны соблюдать, поэтому лёгкий путь подставить посредника: бизнес-аналитика, комитет заинтересованных сторон или презентацию исследования прошлого квартала. Принесите свидетельства: для ваших последних нескольких приращений посчитайте, сколько было проверено с реальным пользователем, действительно пользующимся программным обеспечением, а сколько опиралось на чьё-то мнение о том, чего хотят пользователи. Для государственной услуги добавьте, достигло ли ваше тестирование удобства использования людей, затронутых сильнее всего, включая пользователей вспомогательных технологий и людей с низкой цифровой уверенностью, потому что общественная услуга, работающая только для уверенного большинства, провалила обязательство подотчётности, даже если каждая церемония прошла по расписанию.
Финансируются и управляются ли ваши команды вокруг результатов и ритма или вокруг фиксированного объёма, тихо навязывающего водопад за церемониями? Это разница между настоящей гибкостью и поддельным agile, и она решается выше команды, в том, как выпускаются деньги и как сообщается об успехе, а не в том, происходят ли планёрки. Конкурирующее тяготение в том, что функции финансов, портфеля и надзора построены, чтобы утверждать фиксированный объём против фиксированного бюджета за годы вперёд, а просьба финансировать результат с гибким объёмом ощущается как потеря контроля, которой они будут сопротивляться. Принесите свидетельства: проследите, как финансировалась нынешняя инициатива и о чём она отчитывается, и проверьте, измеряют ли команды по доставленным результатам и потоку или по очкам истории и соблюдению объёма, подписанного давно. В корпоративной и государственной среде свяжите это прямо с оболочкой финансирования и соответствия (глава 10.6): если деньги обязаны далёкому запуску «всё или ничего», команды не могут быть адаптивными, как бы верно ни совершали ритуалы, и исправление принадлежит модели управления, а не командам поставки.

Взгляд по секторам

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

Малый бизнес. Без agile-коуча и при ограниченном бюджете воспринимайте Agile как горстку привычек, а не программу трансформации, которую вы комплектуете: короткий недельный цикл, видимая доска с пределами работы в процессе и одно конкретное улучшение каждую неделю, которое вы действительно завершаете. Опирайтесь на Kanban, которому нужно мало церемоний и который подходит работе, управляемой прерываниями, и принимайте практики, встроенные в уже покупаемые инструменты, а не поднимайте тяжёлый процесс. Судите усилия по тому, отгружаете ли вы полезное программное обеспечение клиентам чаще, а не по тому, насколько близко подражаете Scrum.

Крупная организация. Проблема координация многих команд без возвращения командно-административного управления. Предпочитайте уменьшение, то есть сокращение межкомандных зависимостей через проектирование выровненных по потоку команд и прочную платформу, прежде чем принимать тяжёлую рамку масштабирования. Финансируйте и управляйте вокруг результатов (OKR) и ритма, а не фиксированного годового объёма и очков истории, сделайте инженерные практики в стиле XP не подлежащими обсуждению по командам и управляйте поставкой как портфелем с метриками потока и мерами результатов, чтобы группы улучшались по свидетельствам, а не ритуалу.

Государственный сектор. Правила закупок, прозрачность и публичная подотчётность определяют каждый выбор. Структурируйте модульные ориентированные на результат контракты с более короткими приращениями вместо одного мегаконтракта с фиксированным объёмом, поскольку agile-закупки то место, где гибкость государственного сектора чаще всего преуспевает или проваливается. Встраивайте аудит, доступность и безопасность в каждое приращение через автоматизацию, чтобы надзор удовлетворялся самим актом построения, публикуйте прогресс и свидетельства общественной ценности надзорным органам и боритесь за подлинный доступ к гражданам (включая пользователей вспомогательных технологий) в каждой итерации, потому что это ограничение, которое чаще всего выторговывают.

Примеры

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

Крупная организация. 60-командная трансформация телекома сначала «делает Scrum», но не видит улучшения. Команды по-прежнему получают фиксированный годовой объём и отчитываются о скорости. Перезапуск переориентируется на принципы: квартальные OKR заменяют предписания функций, команды реорганизуются для сокращения межкомандных зависимостей (уменьшение), а практики XP (CI, TDD, разработка на основе ствола) становятся не подлежащими обсуждению. Время выполнения падает, дефекты снижаются, и, что важно, бизнес начинает измерять результаты, а не очки истории, связывая поставку Agile с конвейером исследования (глава 11.1).

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

Бизнес-обоснование: мотивы, ROI и TCO

Отдача от Agile приходит от снижения риска и более быстрой реализации ценности. Поставляя работающее программное обеспечение рано и часто, команды непрерывно превращают неопределённость в свидетельства, ловя провалы «не то» и «не заработает», пока они дёшевы, а не при далёком дорогом запуске. Исследования, стоящие за современной поставкой (выводы DORA, DevOps Research and Assessment, в главе 11.2), показывают, что практики, которые продвигает Agile (малые партии, частые выпуски, быстрая обратная связь, техническое мастерство), коррелируют с лучшей поставкой и стабильностью и организационной эффективностью. Ранние приращения также раньше начинают возвращать ценность, улучшая сроки и общий размер ROI по сравнению с выпуском «всё разом», не возвращающим ничего до конца.

По совокупной стоимости владения Agile снижает цену изменения на протяжении жизни системы при условии, что инженерная дисциплина реальна. Его главный риск поддельный agile: церемония без принципа или ремесла, добавляющая накладные расходы совещаний, не давая никакой выгоды, и способная быть хуже честного водопада. Так что бизнес-обоснование условно. ROI высок, когда вы принимаете Agile как мировоззрение плюс инженерию, и примерно нулевой (или отрицательный), когда принимаете его как ритуал. Обосновывайте перед руководством, формулируя Agile как непрерывное снижение риска и измерение результатов, а не «идти быстрее», и настаивая, что вложение включает технические практики, а не только новые совещания.

Антипаттерны и ловушки

Поддельный / карго-культовый agile: церемонии выполняются, а решения, финансирование и мировоззрение остаются водопадом.
Скорость как продуктивность: превращение оценки мощности в цель, что портит её (закон Гудхарта).
Тёмный scrum: спринт без технического мастерства в несопровождаемый, изобилующий дефектами код.
Ретроспективы без изменений: размышление, не производящее завершённых действий.
Фиксированный объём и дата и цена: называние этого agile, пока качество тихо поглощает давление.
Отсутствующий клиент: нет реальной обратной связи пользователей, так что итерации оптимизируют не то.
Поклонение рамке: «SAFe/Scrum так говорит», перевешивающее принципы и суждение команды.
Масштабирование до уменьшения: добавление тяжёлых рамок координации вместо сокращения зависимостей.

Модель зрелости

Уровень 1, Начальный. Водопад или стихийная поставка; выпуски «всё разом»; работа реактивна и тяжела на планы, без итеративной обратной связи и общего понимания, зачем Agile мог бы помочь.
Уровень 2, Развитие. Несколько команд принимают церемонии Agile (планёрки, спринты, ретроспективы), но практика непоследовательна по организации: мировоззрение и инженерная дисциплина отстают от ритуалов, скорость воспринимается как выпуск, а объём всё ещё фиксируется заранее.
Уровень 3, Стандартизация. Ценности и принципы действительно направляют работу по организации, документированы и ожидаются от каждой команды: техническое мастерство в стиле XP (CI, автоматическое тестирование, рефакторинг, разработка на основе ствола) стандартная практика, команды самоорганизуются, клиенты вовлечены в каждой итерации, а ретроспективы производят конкретные завершённые изменения.
Уровень 4, Управление. Поставка измеряется и контролируется относительно базовых значений: команды отслеживают время выполнения, частоту развёртываний, долю неудачных изменений и долю ускользнувших дефектов (метрики потока и стабильности в стиле DORA) рядом с мерами результатов, привязанными к ключевым результатам, и сравнивают каждую с известным базовым значением. Действия ретроспектив отслеживаются до завершения, сигналы устойчивого темпа вроде переработок и выгорания мониторятся, а скорость никогда не используется как цель продуктивности. Решения «пускать или нет» опираются на эти свидетельства, а не мнение.
Уровень 5, Оркестрация. Адаптивная поставка интегрирована с бизнес-планированием и планированием рисков по организации: результаты (OKR) двигают финансирование и ритм, проектирование команд с низкими зависимостями (уменьшение) минимизирует накладные расходы координации, а гибридное управление удовлетворяет надзор, не замедляя поставку. Непрерывное улучшение культурное, а не церемониальное, и организация рутинно пересматривает объём, пересобирает команды и перебалансирует портфель по мере сдвигов свидетельств и картины рисков.

Идеи для обсуждения

Оцените вашу команду по двенадцати принципам Agile: где вы agile в церемонии, но не в сути?
Используется ли скорость в вашей команде как прогноз или как цель и что это сделало с поведением?
Каких технических практик XP не хватает и как их отсутствие проявляется в дефектах или медленных изменениях?
Прежде чем принимать рамку масштабирования, могли бы вы вместо этого сократить межкомандные зависимости?
Что конкретно блокирует реальный доступ к пользователям в каждой итерации в вашем контексте и как это можно убрать?
Какое последнее конкретное изменение действительно произвела ретроспектива?

Главные выводы

Agile это мировоззрение ценностей и принципов, а не набор церемоний; рамки отправные точки, а не цель.
Поставляйте работающее программное обеспечение часто, приветствуйте изменения и наделяйте полномочиями самоорганизующиеся команды.
Техническое мастерство (практики XP) не подлежит обсуждению. Гибкость без него становится быстрым распадом.
Масштабируйте осторожно; предпочитайте уменьшение. Сокращайте зависимости, прежде чем добавлять рамки координации.
В корпорации/государстве сочетайте адаптивную поставку с гибридным управлением и agile-закупками и боритесь за реальный доступ к пользователям.
ROI это непрерывное снижение риска и более ранняя ценность, но только когда Agile реален, а не ритуален. См. главы 1.4, 11.1, 11.2, 10.6 и 11.3.

Источники и дополнительное чтение

Kent Beck et al., Manifesto for Agile Software Development and its twelve principles (agilemanifesto.org, 2001).
Ken Schwaber and Jeff Sutherland, The Scrum Guide.
Kent Beck, Extreme Programming Explained: Embrace Change.
David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business.
Mike Cohn, User Stories Applied and Succeeding with Agile.
Jeff Patton, User Story Mapping.
Stephen Denning, The Age of Agile.
Matthew Skelton and Manuel Pais, Team Topologies (team design and descaling).
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (evidence for agile/DevOps practices).
U.S. Digital Service, Digital Services Playbook; UK Government, Government Service Standard.

10.7 Agile

Обзор и мотивация

Ключевые принципы

Рекомендации

Опирайтесь на ценности и принципы, а не церемонии

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

Настаивайте на техническом мастерстве

Масштабируйте осторожно и предпочитайте уменьшение

Сделайте гибкость реальной в корпорации и государстве

Улучшайтесь непрерывно и всерьёз