Agile
Agile-коуч
Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
Enterprise Agile Russia
HR
Kanban
KPI
LeSS
Nexus
OKR
OKR Russia
OKR-инструменты
PMI
Project management
SAFe
Scrum
Scrum in Hardware
Scrum-мастер
Spotify
XM
Архитектура
Бюджетирование
Владелец продукта
Игра
Инженерия
Конфликты
Менеджмент
Обучение
Продуктовый менеджмент
Самоорганизация
Тренинг
Фасилитация
Финансы
Холакратия
Применить

Про купе и паровоз

24 фев 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-команды.  И естественно, построить работу с бэклогом.

Зачем? Нам это было необходимо для того, чтобы повысить эффективность работы и снизить оверхеды. Рынок развивается, конкуренты бегут быстро. Мы должны бежать еще быстрее. Нам необходимо уменьшить время на коммуникации, так как вся работа должна происходить внутри одной команды. Коммуникация на 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 функциональных областей. Каждая группа тестирования внутри была из полностью кросс-функциональных тестировщиков, которые знали, понимали, были экспертами во всех вверенных им функциональных областях или технических частях. Что нельзя было сказать на тот момент о команде разработки. Там точно так же были группы разработчиков, но внутри каждой группы разработчиков были эксперты, которые были погружены и разбирались в одной или нескольких фичах или функциональных областях.

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

Как уже сказал Александр, у нас было купе. Это планирование на шесть итераций. Четыре итерации – это разработка и две итерации мы брали в начале эксперимента на стабилизацию. Итерация по классике две недели. Два дня на планирование. А чуть позже мы уменьшили время планирования до одного дня. Остальные дни разработка. Также присутствовал Daily Scrum, демо и ретроспектива в день планирования. Чуть подробнее про квартальное планирование. Это достаточно большой ивент на два полных дня, планирование работ на три месяца. Были приглашены, помимо Feature Team, представители заказчиков, подрядчиков, которые также могли вызываться ситуативно.

Естественно, мы предупреждали их об этом заранее. Представители программ и так далее. На выходе мы имели следующие артефакты. Прежде всего? Приоритизированный бэклог, зависимости, HLE-оценки (прим. ред. — High Level Estimate), capacity, критерии успеха и цели, закоммиченный скоуп, план по итерациям, и что немаловажно, запросы на зависимые команды. Про инфраструктурной поддержку и далее уже расскажет Александр.

Александр Колесников: Антон, спасибо!

Безусловно, работа по новому принципу потребовала перестройки работы нашей инфраструктуры. Мы очень активно работали над совершенствованием нашего 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. Это надо было сделать в самую первую очередь. Коллеги, на этом у нас все. Спасибо за внимание!

Вопрос-ответ

Ольга Захарова: Коллеги, большое спасибо вам за доклад. Советуете ли вы другим компаниям, кто сейчас находится на распутье, принятии решений, выбирать такой путь, делать эксперимент только на одном проекте.

Антон Киселев: На мой взгляд, это крайне интересный и полезный эксперимент по ряду причин, одна из которых, на наш взгляд, более тесная работа с бизнесом и с подрядчиками, и с коллегами или с подразделениями, у которых есть зависимости. Это первое. Во-вторых, как уже Александр показывал, даже при минимальной подготовке при желании можно достичь очень хороших и значимых результатов.

Александр Колесников: Если вы решаете пробовать SAFe, как, впрочем, любую другую методологию, новую для вашей компании, вы должны в первую очередь говорить, что это эксперимент, мы пробуем. Потому что если вы не будете говорить, что это эксперимент, то вы встретите дополнительное сопротивление на своем пути.

Ольга Захарова: Коллеги, а что дальше? Эксперимент закончен, признан успешным. Что дальше происходит в компании, поделитесь.

Антон Киселев: На данный момент мы находимся на стадии извлечения уроков. Я надеюсь, пойдем на следующий рывок.

Видео выступления

Слайды доклада

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile Inc.

Другие статьи
3 апр 2021, Александр Троицкий
Relentless Improvements или долгий путь стратегических и тактических изменений

История Технологического Центра Дойче Банка про 3 года трансформации в сторону выстраивания команд вокруг цепочек создания ценности.

2 апр 2021, Андрей Гирин
Эволюция Потребности или в прошлом квартале было по-другому

История Ак Барс Банка про эволюцию процесса управления бэклогом портфеля на протяжении года.

20 мар 2021, Сергей Рогачев
OKR в России

Ожидания и реальные результаты от применения нового подхода к целеполаганию OKR (Objectives and Key Results) в различных отраслях на примерах реальных российских компаний.