Все статьи
Про купе и паровоз
Дата: 24.02.2021
История Kaspersky про самостоятельное внедрение Scaled Agile Framework® (SAFe®) и что из этого получилось.
Доклад на конференции Enterprise Agile Russia 30 ноября 2020 года.
Ольга Захарова (модератор конференции): Дорогие друзья, я рада вас приветствовать на нашей конференции Enterprise Agile Russia 2020. Также рада приветствовать наших следующих спикеров, Александра Колесникова и Антона Киселева, компания Kaspersky. Название их доклада хорошо иллюстрирует нашу картинку, заставку на конференции — про купе и паровоз. Доклад будет про самостоятельный опыт внедрения SAFe в компании в условиях достаточно жестких ограничений по срокам, по бюджету. И как я поняла, без централизованной поддержки такого внедрения. Конечно, мы ждем от ребят lessons learned, что делать, что не делать для тех, кто только задумывается о том, чтобы начинать трансформацию в своей компании.
Александр Колесников: Мы хотели бы рассказать о попытке внедрения SAFe в компании, которая называется «Про купе и паровоз». С вами кандидаты наук, Антон Киселев и Александр Колесников. И вот наш опыт. В первую очередь хотелось бы рассказать о проекте, в котором происходило внедрение. Этот проект в области информационной безопасности. В нем более 100 человек в командах разного профиля, десяток внутренних заказчиков, несколько сотен тысяч клиентов, несколько внутренних подрядчиков и несколько десятков миллионов защищаемых хостов.
Проект действительно является ключевым для компании, и у нас не было права на ошибку. И все-таки мы попробовали. Кратко, что же мы делали. На экране SAFe версии 4.6, потому что на тот момент, когда мы его пробовали в нашей компании, актуальной версией была версия 4.6. Что же у нас было перед тем, как начать? У нас была команда разработки, была работа по итерациям, была каким-то образом построена работа по бэклогам. Был в каком-то виде построен DevOps.
Но нам этого, естественно, не хватало, нам было необходимо двигаться дальше. Мы решили привнести в свою работу Essential SAFe, добавить те части, которые мы могли добавить на своем уровне, а именно выровнять работу между заказчиками, архитекторами, внедрить институт RTE, построить что-то похожее на PI Planning, улучшить Delivery Pipeline и усовершенствовать существующие Agile-команды. И естественно, построить работу с бэклогом.
DevOps — это мышление, культура и набор инженерных практик, способствующих интеграции, автоматизации и тесному взаимодействию между всеми специалистами для эффективной разработки и эксплуатации решения.
Essential SAFe (Базовый SAFe) предоставляет минимальный набор элементов, необходимых Agile Release Train (ART) для поставки решений, и является самой простой отправной точкой для внедрения.
Release Train Engineer (RTE) или «машинист поезда» — это лидер-слуга и коуч в Agile Release Train (ART), который проводит мероприятия и помогает в реализации процессов, а также поддерживает команды в поставке ценности.
PI-планирование — это регулярно повторяющееся мероприятие всего ART, которое согласовывает команды и заинтересованных лиц вокруг общей миссии и концепции.
Конвейер Непрерывной Поставки (Continuous Delivery Pipeline, CDP) представляет собой процессы, активности и автоматизацию, которые необходимы для формирования новой функциональности от идеи до выпуска ценности по запросу.
Agile-команда — это кросс-функциональная группа размером 10 и менее человек, которая обладает всеми необходимыми навыками для определения, создания, тестирования и внедрения ценности своим клиентам.
Зачем? Нам это было необходимо для того, чтобы повысить эффективность работы и снизить оверхеды. Рынок развивается, конкуренты бегут быстро. Мы должны бежать еще быстрее. Нам необходимо уменьшить время на коммуникации, так как вся работа должна происходить внутри одной команды. Коммуникация на 100 человек – это все-таки достаточно сложная вещь. А еще есть заказчики, а еще есть подрядчики.
Нам безусловно необходимо сократить цикл разработки за счет фокусного подхода с привлечением всех необходимых участников и заинтересованных лиц. Когда у вас много заказчиков, вас тянут в разные стороны. Мы же должны концентрироваться, чтобы двигаться вперед.
Где? Делали мы это в рамках проекта. Не в рамках программы, не в рамках компании. Мы использовали не PI Planning, а только элементы из него. Для того, чтобы быть честными, мы это назвали квартальным планированием. Отсюда пошла игра слов: ку-пэ, QP, Quarter Planning. О том, кто принимал в этом участие, расскажет мой коллега, Антон Киселев. Антон, тебе слово.
Антон Киселев: Александр, спасибо! Коллеги, добрый вечер!
Итак, кто? В состав команды обязательно входили dev lead, аналитик, архитектор, разработчик и тестировщик. Опционально по мере необходимости, туда могли быть добавлены test lead, автоматизатор, Product Owner или Scrum-мастер.
Командные роли, которые у нас присутствовали. Это обязательно была роль Scrum-мастера, ее мог выполнять dev lead, роль аналитика, архитектора, Product Owner. Роль Product Owner мог выполнять как Product Manager, аналитик или архитектор. Product Manager на всех не хватает. Их ресурсы были весьма ограничены. Поэтому в какой-то момент подключался аналитик и мог выполнять эту роль. Архитектор мог выполнять роль Product Owner по технические изменениям и техническому долгу. И по классике, разработчики и тестировщики, которые также могли быть как автоматизаторами, так и ручниками.
Собственно, из этого формировалась так называемая Feature Team.
Теперь немного подробнее расскажу о том, как из большой команды мы сформировали Feature Team. На рисунке схематично показано, из чего состоял отдел тестирования. До нашего эксперимента он состоял из четырех групп. Здесь показано, что продукт состоял в данном случае для примера из 16 компонент или 16 функциональных областей. Каждая группа тестирования внутри была из полностью кросс-функциональных тестировщиков, которые знали, понимали, были экспертами во всех вверенных им функциональных областях или технических частях. Что нельзя было сказать на тот момент о команде разработки. Там точно так же были группы разработчиков, но внутри каждой группы разработчиков были эксперты, которые были погружены и разбирались в одной или нескольких фичах или функциональных областях.
При этом, так как это был эксперимент, и был в рамках конкретной версии продукта, у нас были другие версии продукта на поддержке, для которых точно так же нужно было продолжать выполнять определенные операционные обязанности, такие как регресс, поддержка и так далее. Поэтому из каждой группы тестировщиков мы в каждую группу разработчиков добавили по одному-двум тестировщикам, тем самым мы покрыли тестированием каждую группу разработчиков, с одной стороны. С другой стороны, обеспечили так называемую обратную совместимость — это тогда, когда тестировщики возвращались при регрессионных тестированиях в свою группу, делились знаниями и оставались все той же кросс-функциональной группой.
Владелец Продукта (Product Owner, PO) — член Agile-команды, основная ответственность которого в максимизации ценности, поставляемой командой, что он обеспечивает соответствием Бэклога Команды потребностям клиентов и заинтересованных лиц.
Скрам-мастер (Scrum Master) — это лидер и коуч Agile-команды, который помогает в реализации командных процессов, мероприятий и поставке ценности.
Как уже сказал Александр, у нас было купе. Это планирование на шесть итераций. Четыре итерации – это разработка и две итерации мы брали в начале эксперимента на стабилизацию. Итерация по классике две недели. Два дня на планирование. А чуть позже мы уменьшили время планирования до одного дня. Остальные дни разработка. Также присутствовал Daily Scrum, демо и ретроспектива в день планирования. Чуть подробнее про квартальное планирование. Это достаточно большой ивент на два полных дня, планирование работ на три месяца. Были приглашены, помимо Feature Team, представители заказчиков, подрядчиков, которые также могли вызываться ситуативно.
Естественно, мы предупреждали их об этом заранее. Представители программ и так далее. На выходе мы имели следующие артефакты. Прежде всего? Приоритизированный бэклог, зависимости, HLE-оценки (прим. ред. — High Level Estimate), capacity, критерии успеха и цели, закоммиченный скоуп, план по итерациям, и что немаловажно, запросы на зависимые команды. Про инфраструктурной поддержку и далее уже расскажет Александр.
Итерации — это стандартный временной отрезок фиксированной длительности, в течение которого Agile-команды и ART по отдельности и совместно обеспечивают прирост потребительской ценности, работая над достижением PI-целей.
Планирование Итерации — это мероприятие Скрам в SAFe, во время которого все члены команды определяют перечень элементов Бэклога Команды, который они могут взяться реализовать во время предстоящей Итерации. Итоговый план работ команда описывает в виде обязательных целей итерации.
Ретроспектива Итерации — это регулярное мероприятие, на котором члены команды обсуждают результаты итерации, анализируют свои практики и определяют пути улучшения.
Александр Колесников: Антон, спасибо!
Безусловно, работа по новому принципу потребовала перестройки работы нашей инфраструктуры. Мы очень активно работали над совершенствованием нашего Delivery Pipeline. Мы развивали и Continuous Integration, и Continuous Deployment. Немного поработали в направлении Continuous Exploration. Это выражалось в активной работе с Product Manager. Мы сильно усовершенствовали наши процедуры выкладки и таргетирования релиза. Таргетирование – это распределение релиза по разным странам, так как он у нас на множество стран по всему миру.
Таймлайн, как уже сказал, Антон, схема 4+2. Вот даты реального релиза, как это было запланировано. Эти даты в итоге превратились вот в такой вот календарь событий. Первый квартал прошел по схеме 4+2: 4 итерации разработки, 2 итерации стабилизации. Второй квартал прошел по схеме 3+3, десятую итерацию мы изменили с итерации разработки в итерацию стабилизации. По сути, это аналог итерации Innovation and Planning.
Как это выглядело в реальности? Выглядело это вот таким образом. Две доски, две простыни, на которых намечены тикеты. Эти тикеты соединены ниточками с пластилином. На тикетах написано работа. Естественно, все это имеет идентичное отображение в электронной системе. Но для наглядности оно висело на самом видном месте.
Что было на самом деле, как у нас получилось на самом деле? Ожидаемо первый квартал был неуспешен. Мы не закрыли ни одного требования. Мы учились допиливать процессы. Мы учились работать по-другому. Мы улучшали нашу инфраструктуру. Во втором квартале мы закрыли все требования плюс те требования, которые не закрыли в первом квартале, перешли на схему 3+3 и в конце добавили классическую стабилизацию, как это принято в нашей компании.
Что получилось? Выпустили в срок, провели два PI-планирования. Мы приблизились к состоянию PI-планирования. Мы поддержали 4 программы параллельно, делали это в два раза быстрее, чем раньше. Справа вы видите сокращение Lead Time и Work Time по фичам почти в 2 раза. Самое главное, релиз проходил более спокойно.
Если вы внимательно следите за выступлениями наших коллег из ScrumTrek, то может быть, вы замечали фразу: релиз был выпущен впервые вовремя за 12 лет. Это фраза про наш продукт. У нас не было сдвижки ни на один день.
Что не получилось? Мы бросились в этот омут сразу же. Мы не потратили время не предварительную подготовку. В итоге мы столкнулись со следующими препятствиями:
- Операционная готовность работать на уровне SAFe на уровне одного проекта невозможна без привлечения всего остального R&D, без привлечения представителей сейлз и маркетинг, потому что мы не можем построить полную цепочку создания ценностей.
- Готовность инфраструктуры. Инфраструктура обычно не готова. Это нормально. Нужно время, нужны усилия на то, чтобы ее подготовить, на то, чтобы ее перестроить. Пришлось тратить значительное количество усилий и в этом направлении.
- Естественно, готовность майндсета. Некоторые не понимали, что происходит. Пришлось тратить большое количество усилий на то, чтобы объяснить, что мы делаем, для чего мы делаем. После того, как люди увидели, куда мы идем, они к нам присоединились.
Что надо было сделать? Надо было сделать следующее. После того как мы выпустили этот релиз, мы пошли поучились на RTE. Это надо было сделать в самую первую очередь. Коллеги, на этом у нас все. Спасибо за внимание!
Непрерывное Изучение (Continuous Exploration, CE) — это часть Конвейера Непрерывной Поставки, процесс управления инновациями и обеспечения согласованности работ путем постоянного изучения потребностей рынка и пользователей, а также определения Концепции, Дорожной Карты и Фич Решения.
Непрерывная Интеграция (Continuous Integration, CI) — это часть Конвейера Непрерывной Поставки, процесс разработки, тестирования, интеграции и проверки, после которого они готовы к развертыванию и релизу.
Непрерывное Развертывание (Continuous Deployment, CD) — это часть Конвейера Непрерывной Поставки, которая автоматизирует развертывание новой функциональности из промежуточного окружения в промышленное, где она будет готовы к релизу.
Итерация Инноваций и Планирования (Innovation and Planning Iteration, IP-итерация) — это уникальная, специальная итерация, которая проводится в каждом Интервале Планирования (Planning Interval, PI). Она обеспечивает определенный буфер для достижения PI-целей и время для инноваций, непрерывного обучения, PI-планирования и мероприятия Инспекции и Адаптации (Inspect and Adapt, I&A).
Вопрос-ответ
Ольга Захарова: Коллеги, большое спасибо вам за доклад. Советуете ли вы другим компаниям, кто сейчас находится на распутье, принятии решений, выбирать такой путь, делать эксперимент только на одном проекте.
Антон Киселев: На мой взгляд, это крайне интересный и полезный эксперимент по ряду причин, одна из которых, на наш взгляд, более тесная работа с бизнесом и с подрядчиками, и с коллегами или с подразделениями, у которых есть зависимости. Это первое. Во-вторых, как уже Александр показывал, даже при минимальной подготовке при желании можно достичь очень хороших и значимых результатов.
Александр Колесников: Если вы решаете пробовать SAFe, как, впрочем, любую другую методологию, новую для вашей компании, вы должны в первую очередь говорить, что это эксперимент, мы пробуем. Потому что если вы не будете говорить, что это эксперимент, то вы встретите дополнительное сопротивление на своем пути.
Ольга Захарова: Коллеги, а что дальше? Эксперимент закончен, признан успешным. Что дальше происходит в компании, поделитесь.
Антон Киселев: На данный момент мы находимся на стадии извлечения уроков. Я надеюсь, пойдем на следующий рывок.
Видео и слайды выступления
