Конвейер непрерывной поставки в SAFe®
Как обеспечить непрерывный процесс определения потребности клиентов, реализации и развертывания решения.
Вольный перевод статьи Continuous Delivery Pipeline — Scaled Agile Framework.
Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения. —Agile-манифест |
Конвейер непрерывной поставки (Continuous Delivery Pipeline, CDP) представляет рабочие процессы, действия и автоматизацию, необходимые для реализации новой функциональности — от появления новой идеи до релиза ценности по требованию для конечного пользователя.
На рисунке 1 изображено, что конвейер включает четыре элемента: Непрерывное изучение (Continuous Exploration, CE), Непрерывную интеграцию (Continuous Integration, CI), Непрерывное развертывание (Continuous Deployment, CD) и Релиз по требованию (Release On Demand, RoD) — каждый из которых описан в отдельной статье.
Конвейер является ключевым элементом компетенции по Agile-поставке продукта. Каждый Agile Release Train (ART) создает и поддерживает или совместно (прим. пер. — с другими ART) использует конвейер с компонентами и технологиями, необходимыми для поставки решений как можно более независимо. Первые три элемента конвейера (CE, CI и CD) применяются вместе, чтобы обеспечить поставку небольших порций новой функциональности, релиз которых затем осуществляется для удовлетворения рыночного спроса.
Создание и обслуживание конвейера непрерывной поставки предоставляет каждому ART возможность поставлять пользователям новую функциональность гораздо чаще, чем в традиционных процессах. Для некоторых «непрерывный» может означать ежедневные выпуски или даже выпуск несколько раз в день. Для других непрерывный может означать еженедельные или ежемесячные выпуски — все, что удовлетворяет требования рынка и соответствует целям предприятия.
Классические практики, как правило, воспринимают релиз как большой монолитный кусок. Однако, реальность такова, что релиз ценности не обязательно должен быть в духе «все или ничего».
Например, спутник — это система, состоящая из самого спутника, наземной станции и веб-фермы, которая передает полученные спутниковые данные конечным пользователям. Некоторые элементы могут выпускаться ежедневно, возможно, функциональность веб-фермы. Другие элементы, такие как аппаратные компоненты самого спутника, могут выпускаться в соответствии с циклом запусков.
Развязка функциональных возможностей веб-фермы от физического запуска спутника устраняет необходимость в монолитном релизе. Такой подход повышает бизнес-гибкость, позволяя поставлять компоненты решения в ответ на частые изменения потребностей рынка.
Содержание статьи
Четыре элемента конвейера непрерывной поставки
Конвейер непрерывной поставки (CDP) в SAFe содержит четыре элемента: непрерывное изучение, непрерывная интеграция, непрерывное развертывание и релиз по требованию. CDP позволяет организациям сопоставить имеющийся конвейер с предлагаемой SAFe структурой, а затем использовать непрерывные улучшения для поставки ценности клиентам.
Петли обратной связи, которые существуют внутри и между элементами, а также вовне между клиентами и предприятием, подпитывают улучшения. Внутренние циклы обратной связи часто сосредоточены на улучшении процессов, в то время как внешние — на улучшениях решения. В совокупности улучшения создают синергетический эффект для того, чтобы предприятие «создавало правильные вещи правильным способом» и часто поставляло ценность на рынок.
Непрерывное изучение — Continuous Exploration
Непрерывное изучение сфокусировано на создании согласованности по тому, что необходимо создать.
В CE дизайн-мышление используется для того, чтобы предприятие понимало потребность клиентов и представляло решение, необходимое для удовлетворения этой потребности.
Непрерывное изучение начинается с идеи или гипотезы о том, что может обеспечить ценность для клиентов и возникает, как правило, в ответ на обратную связь клиентов или исследования рынка.
Затем идеи анализируются и дополнительно исследуются, что приводит к пониманию и конвергенции того, что необходимо в качестве минимально жизнеспособного продукта (Minimum Viable Product, MVP) или минимально поставляемой фичи (Minimum Marketable Feature, MMF). Таким образом обеспечивается пространство решений для изучения того, как существующая архитектура и решения могут или должны быть изменены.
Наконец, конвергенция происходит путем понимания того, какие Возможности и Фичи, если они будут реализованы, могут удовлетворить потребности клиентов и рынка. Последние будут сформулированы и приоритизированы в Бэклоге Программы.
Непрерывная интеграция — Continuous Integration
Непрерывная интеграция сосредоточена на реализации Фич из Бэклога Программы.
В CI применение инструментов дизайн-мышления в пространстве проблем направлено на уточнение функций (например, проектирование карты пользовательской истории), что может мотивировать дальнейшие исследования и использование инструментов пространства решений (таких как отзывы пользователей о прототипе).
После того, как конкретные Фичи стали четко поняты, Agile-команды реализуют их. Выполненная работа помещается в систему управления версиями, собирается и интегрируется в полноценную систему или решение, а также тестируется от начала до конца перед проверкой в предпродуктиве.
Непрерывное развертывание — Continuous Deployment
Непрерывное развертывание сосредоточено на переносе изменений из предпродуктивного окружения в продуктивное.
В этот момент изменения проверяются и контролируются, чтобы убедиться, что они работают должным образом. После переноса фичи становятся доступными в продуктиве, где бизнес определяет подходящее время релиза для клиентов.
Также это позволяет организации реагировать, откатывать или исправлять с упреждением, когда это необходимо.
Релиз по требованию — Release On Demand
Это возможность сделать ценность доступной для клиентов сразу или в поочередном порядке с учетом потребностей рынка и бизнеса.
Это позволяет бизнесу делать релизы, когда рыночные условия оптимальны, и тщательно контролировать величину риска, связанного с каждым релизом. Релиз по требованию также включает в себя критически важные активности конвейера, обеспечивающие стабильность и постоянную ценность Решений в течение длительного времени после релиза.
Хотя конвейер описывается последовательно, однако он не является строго линейным. Скорее, это цикл обучения, который позволяет командам сформулировать одну или несколько гипотез, создать решение для проверки каждой гипотезы и извлечь уроки из этой работы, как показано на рисунке 2.
И хотя каждая Фича проходит через Поток поставки ценности последовательно, команды работают над всеми этапами параллельно. Это означает, что ARTs и Solution Trains, на протяжении каждого PI и каждой итерации внутри PI, непрерывно:
- Изучают то, что может быть ценным для пользователя.
- Интегрируют и демонстрируют ценность.
- Непрерывно развертывают в продуктив.
- Делают релиз всякий раз, когда это нужно бизнесу.
Начните с создания карты текущего процесса
Успешные предприятия уже обладают конвейером поставки, в противном случае они не могли бы осуществлять какие-либо релизы. Но слишком часто конвейер не автоматизирован, содержит значительные задержки и требует человеческого вмешательства, утомительного и подверженного ошибкам. Это, в свою очередь, вынуждает организации откладывать релизы, увеличивая их размер и содержание («Мы выпустим, когда он будет достаточно большим»).
Очевидное противоречие шестому принципу SAFe, который мотивирует к ограничению работы в процессе (WIP) и уменьшению размера партий:
Визуализируйте и ограничивайте незавершенную работу (WIP), уменьшайте размер порций работ, управляйте длиной очередей.
Первый шаг к улучшению потока — применение инструмента Создание Карты Потока Ценности (Value Stream Mapping) для текущего конвейера. На рисунке 3 показан поток через текущий конвейер одного из предприятий, первоначально ориентированный на разработку новых фич. Со временем поток будет охватывать любые изменения в системе, от новых Фич до обслуживания и архитектурных улучшений.
После того, как текущий конвейер визуализирован, необходимо добавить метрики для измерения параметров потока, понимания задержек и выявления возможностей для улучшения (таких как устранение задержек или сокращение количества переделок), как показано на рисунке 4.
Используются четыре основные метрики: Process Time, Lead Time, Delay Time и Percent Complete and Accurate.
Process Time (PT)
Process Time — это фактическое время, необходимое для выполнения работ отдельного шага.
Например, на рисунке 4, шаг Дизайн занимает 4 часа.
Lead Time (LT)
Lead Time — это интервал времени между завершением предыдущего шага и завершением следующего шага.
Другими словами, Lead Time = Задержка после предыдущего шага + Process Time текущего шага.
На рисунке 4 Lead Time от момента появления идеи до определения фичи является переменным. Это обычное явление на первых сессиях сопоставления, ведь процесс пока не имеет четких метрик по некоторым шагам. В таком случае оставшаяся часть процесса может быть улучшена, а на переменной части будет накапливаться статистика для уточнения метрик.
Delay Time
Delay Time — это задержа или иными словами, время, когда работа не производится.
Продолжим с примером на рисунке 4, на котором работа, принятая Менеджером продукта, задерживается на ошеломляющие 696 часов перед развертыванием в тестовую среду.
Понимание и устранение ненужных задержек имеет решающее значение для улучшения потока ценностей.
Percent Complete and Accurate (%C&A)
Percent Complete and Accurate представляет процент результатов, которые могут использоваться на следующем шаге “как есть” без необходимости возврата на предыдущие шаги для исправлений.
Часто задержки связаны с низким качеством в апстриме (предшествующих шагах). Данная метрика позволяет определить шаги, на которых низкое качество результата может приводить к увеличениею Lead Time, что, в свою очередь, приводит к задержкам в поставке ценности.
На рисунке 4 видно, что 20% фич прошедших с шага ”Дизайн” на шаг ”Кодирование” требуют доработки.
Улучшение метрики %C&A — это основа для улучшения потока.
Значение метрики %C&A отдельного шага включается в итоговую метрику Rolled Percent Complete and Accurate, которая представляет собой вероятность того, что рабочий элемент бэклога пройдет через весь поток разработки без доработок.
На примере итоговый %C&A равен 35%, что означает постоянные доработки более чем половины Фич в потоке.
Согласование текущего рабочего процесса с конвейером непрерывной поставки
Как только текущий поток понятен, его можно сопоставить с конвейером непрерывной поставки SAFe. Сопоставление помогает организации принять общую ментальную модель и предоставляет эффективные средства для обсуждения изменений и улучшений.
На рисунке 5 удалены метки «Непрерывный», поскольку на данном этапе процесс вряд ли будет напоминать автоматизированный конвейер.
Определение возможностей для улучшения
Команды ищут возможность повысить эффективность каждого шага, последовательно сокращая Total Lead Time. Это включает в себя определение Process Time, а также качества каждого шага с помощью метрики %C&A. Чем выше это число, тем меньше требуется доработок, и тем быстрее работа движется по системе.
Как показано на рисунке 6, Delay Time (время между шагами) часто является наиболее значительным начальным фактором. Время задержки представляет собой передачу, ожидание и другие непроизводительные затраты времени, не связанные с добавленной стоимостью.
Процесс на рисунке 6 имеет две значительные задержки и значительный объем доработок на первом этапе процесса развертывания. Сокращение задержек, как правило, является самым быстрым и простым способом снижения Total Lead Time. Еще одной приоритетной областью для улучшения является любой шаг с низкими показателями %C&A (большим процентом доработок), поскольку сокращение переделок позволяет ART сосредоточиться на создании ценности (например, для программного решения вместо исправления ошибок команда может сосредоточиться на новых фичах).
Последующие возможности для улучшения сосредоточены на уменьшении размера партии и применении методов DevOps, определенных в каждой из последующих статей, описывающих конвейер непрерывной поставки.
Отслеживание непрерывной поставки
Если рассматривать в целом, непрерывная поставка является обширным процессом. Действительно, это может быть жизненно необходимой способностью каждого ART и Solution Train. Важно, чтобы заинтересованные стороны могли визуализировать и отслеживать текущую работу, даже если значительная ее часть автоматизирована. Им нужна возможность устанавливать ограничения на Незавершенную работу (Work In Proсess, WIP) для повышения пропускной способности, а также выявления и устранения узких мест. Для этого используется , как показано на рисунке 7.
Kanban Программы представляет ряд состояний, каждое из которых кратко изложено ниже:
- Воронка — это начальное состояние для сбора всех новых фич или идей по улучшению существующих.
- Анализ — фичи, которые наилучшим образом соответствуют концепции решения, вытягиваются в этап анализа для дальнейшего изучения. Здесь они уточняются ключевыми атрибутами, включая гипотезу о выгоде для бизнеса и критерии приемки.
- Бэклог программы — после анализа фичи с более высоким приоритетом перемещаются в бэклог, где они ранжируются.
- Реализация – в границах каждого Инкремента программы (PI), топ-фичи из бэклога программы вытягиваются на стадию реализации, где они разрабатываются и интегрируются в систему.
- Проверка в предпродуктиве — фичи, готовые к обзору, вытягиваются в этап проверки в предпродуктиве для интеграции с остальной частью системы и последующего тестирования и проверки.
- Развертывание в продуктив — по мере возможностей фичи развертываются в рабочей среде, где они ожидают релиза.
- Релиз — когда ценность своевременна рыночным возможностям, происходит гипотезы о выгоде для бизнеса и последующий релиз фич.
- Сделано — когда гипотеза доказана, дальнейшая работа над фичей не требуется.
Реализация конвейера непрерывной поставки с помощью DevOps
Построение, обслуживание и оптимизация конвейера непрерывной поставки требует специальных навыков и инструментов по всему потоку поставки ценности. Поскольку этот тип системы поставки требует быстрой поставки сложных Решений с очень короткими циклами обучения и высокой степенью кросс-функционального сотрудничества, методы DevOps идеально подходят для его реализации.
Конвейеры непрерывной поставки лучше всего реализовывать с помощью DevOps.
Два внешних кольца представляют собой конвейер непрерывной поставки, с его четырьмя аспектами и 16 активностями, формирующими замкнутый цикл обучения.
Внутренние кольца представляют домены практик DevOps, которые «питают» CDP. Каждый домен содержит определенные методы и инструменты, которые члены потока поставки ценности используют для прохождения по конвейеру. Подход SAFe CALMR к DevOps, показанный в центре рисунка, представляет собой мышление, которое направляет поведение и принятие решений во всей системе.
Кроме того, SAFe позволяет ART быстро оценивать производительность своих конвейеров поставки и определять конкретные методы DevOps, которые могут быть применены для их оптимизации.
См. всю серию роликов о применении SAFe DevOps на практике.
SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.
Стать пионером трансформации в компании, кратно увеличить объем продаж, вдохновляя своим успехом другие команды, и разрешить себе мечтать о «космосе»: история успешной Agile-трансформации в интервью с Сергеем Нечушкиным, директором департамента малого и среднего бизнеса Абсолют Банка.
В статье рассмотрим Lean Portfolio Management — одну из 7-ми ключевых компетенций, необходимых для достижения Бизнес-гибкости (Business Agility).
Статья с детальным обзором состава и механизма работы портфеля SAFe®. Содержит различные примеры организации портфелей для крупного и малого бизнеса, а также их плюсы и минусы