Случалось ли вам работать над проектом, где участвует более сотни человек, несколько компаний, с учетом 10 часовых поясов, разных менталитетов и языков? Хотим поделиться своим опытом планирования работ в проекте, который управляется по методологии SAFe в условиях вынужденной удаленной работы.
Наша интернациональная команда уже год трудится над масштабным проектом. Мы помогаем крупной софтверной компании внедрить ServiceNOW.
Около года мы управляли проектом с помощью Scrum методологии. Сначала мы разделили проект на направления, каждому направлению — своя команда. Но постепенно все смешалось и мы оказались вот в какой ситуации. В команде 100+ человек — все разбросаны от Китая до Калифорнии, состоит команда из представителей 4х различных компаний. Все работают над одним потоком задач, управлять которым очень сложно, потому что поток огромный.
У нас был один Scrum-мастер, несколько Владельцев продукта (Product Owners), бизнес-консультанты и некоторое количество разработчиков. Scrum-встречи (dailies) мы проводили каждый день для двух стримов — все их вел один и тот же Scrum-мастер, на которого обрушился огромный объем работы.
Agile требует от всей команды самоотдачи, большой ответственности и организованности. Scrum-мастер при этом должен следить не только за картиной целиком, но и за каждой конкретной задачей. Если у разработчика возникли проблемы, требующие помощи коллег – Scrum-мастер должен вовремя вмешаться и помочь, чтобы задача была завершена к концу спринта.
Руководство проекта решило, что нужны изменения. Управление проектом стали переводить на SAFe: Scaled Agile Framework (у ServiceNow есть специальный плагин, который позволяет управлять проектом в этой методологии). Мигрировать решили, потому что охват проекта увеличивался. Иначе никак, ведь мы автоматизировали 4 процесса, но нужно было внедрить 5 новых. Кроме того, в скоуп проекта были добавлены новые бизнес-подразделения, для которых нужно запустить ServiceNow. Как следствие – продуктовых команд больше, прозрачности меньше, да еще эта разница в часовых поясах. Разные часовые пояса – это особый вид головной боли. У Scrum-мастера 6 утра, у другого сотрудника – 2 ночи. Когда проводить Dailies – непонятно.
Вернёмся к SAFe. Почему мы вообще его выбрали? Scaled Agile Framework позволяет применять agile-подходы при работе больших проектных команд (более 50-ти человек). Это удобно. Можно организовать работу нескольких проектных команд, члены которых могут быть разбросаны по всему земному шару. SAFe позволяет работать одновременно нескольким командам в рамках одного проекта над общей большой задачей. В том числе, разным подрядчикам. При этом происходит объединение по направлениям — стримам.
В каждом направлении — свой Владелец продукта, Scrum-мастер, бизнес-консультанты, разработчики, тестировщики. Выглядит сложно, а на деле удобно. Команда большая, направлений много, но все работают для достижения общей цели. Направления сотрудничают друг с другом. В итоге нет какого-то направления, на которое свалился запуск всего продукта. Потоки помогают друг другу и созависимы.
Теперь немного терминологии. Знать её важно, чтобы понять, как мы развивали проект дальше.
Одно из ключевых понятий в SAFe — это PI (Program Increment). Это отрезок времени, в течение которого команда разрабатывает и представляет заказчику готовый к использованию фрагмент программного продукта.
У каждого программного инкремента (PI) существуют цели — PI Objectives. Это такие бизнес- и технические задачи, которые команда обязуется выполнить в течение PI. PI Objectives должны быть правильно сформулированы – от этого многое зависит. Лучше формулируйте их с помощью техники SMART — когда сформулированные цели конкретны, достижимы, измеримы, значимы и ограничены по времени.
Формирование целей – это не задача одного человека. Когда вся команда участвует в формировании и постановке целей, это называется «Планирование программного инкремента» (PI Planning).
Как утверждает методология SAFe, PI Planning – это сердце проекта. “Если вы не делаете PI Planning – вы не делаете SAFe” – заявляют авторы.
Планировать программный инкремент важно по двум причинам. Первая — обозначить временные рамки выполнения задач. Вторая — сплотить членов команды. Каждый участник PI Planning должен ощущать важность мероприятия и чувствовать свою вовлеченность в процесс. Мнение каждого важно — от этого зависит будущее продукта.
Лучший способ организовать PI Planning – собрать всех участников в одной локации. Планирование проходит в течение 2х дней, каждый день делится условно на 2 части:
- общая сессия
- командная работа отдельно для каждого направления разработки (стрима).
На общей сессии вы ставите верхнеуровневые задачи. Показываете основные направления разработки, рассказываете, какие приоритеты согласованы с заказчиком. Потом определяете глобальные планы дальнейшего развития продукта. После этого участники расходятся по своим командам и детально планируют деятельность в рамках своего направления.
У каждой команды существует набор Features (задачи высокого уровня, отвечающие за кусок функционала системы), которые и планируется внедрить в течение предстоящего программного инкремента. Чтобы реализовать Features, для каждой нужно подготовить User Stories. Делать это лучше заранее – до начала планирования PI. Когда User Stories готовы, вся команда производит оценку их сложности с использованием чисел Фибоначчи.
Программный инкремент делится на несколько спринтов, каждый спринт длится обычно две недели. Во время планирования команда приоритизирует Features и определяет, какие из них нужно реализовывать раньше, а какие позднее. На основе приоритизации происходит распределение User Stories по спринтам для всего программного инкремента. То есть мы заранее подробно планируем работу на длительный период (например, квартал).
Нередко встречаются задачи, которые затрагивают несколько стримов. В этом случае кто-то из команды переходит к группе коллег из соседнего направления и обсуждает дальнейший план действий.
В конце второго дня планирования каждая команда представляет на общей сессии свой план работ на квартал, после чего проводится голосование. Каждый участник оценивает по пятибалльной шкале, готов ли он выполнять разработанный план и высказывает свое мнение о процессе планирования. Результаты голосования анализируются, и на их основе принимается решение о необходимости доработки плана.
Это была теория того, как должно быть. Теперь о том, как всё происходило у нас.
Сначала мы планировали собрать почти всех участников в офисе заказчика. Хотели продуктивно поработать, да ещё и в одном часовом поясе. Для сотрудников, что работают удалённо, планировали вести трансляцию встречи. Паззл красиво складывался, но всё пошло не так из-за всеобщей самоизоляции. Реальность перестроилась, и провести живую встречу стало невозможно. Мы озадачились, как организовать виртуальное планирование PI.
Основные сложности и вопросы, которые предстояло решить:
- Как подготовить команду? Большинство участников никогда не участвовали в подобном PI Planning.
- Как вовлечь всех и каждого и не «потерять» людей во время онлайн-планирования? Напомним, что участие каждого члена команды архиважно.
- Что делать с разницей во времени?
- Какие инструменты использовать вместо досок, стикеров, флип-чартов и фломастеров? Спойлер – все сделали силами ServiceNow!
Для того, чтобы оперативно подготовить команду, мы организовали обучающие тренинги. На них всем коллегам рассказывали, что такое планирование PI и зачем оно нужно, объясняли основы, что за чем следует и какие задачи предстоит на планировании решить. Большую часть этих тренинг-сессий проводил Release Train Engineer – ключевая фигура в организации процессов работы команд по SAFe.
Вовлеченность мы регулировали с помощью интерактивов. Например, на общих сессиях устраивали голосования на тему «как вы себя чувствуете после первого дня планирования?» или «какое мороженое вы предпочитаете?».
Во время сессий по направлениям основная работа по вовлечению всех и каждого ложилась на Scrum-мастеров, которым порой приходилось потрудиться, чтобы узнать мнение каждого участника по тому или иному вопросу. Предоставить всю работу активным коллегам было бы проще, но важно дать высказаться каждому.
Следующая сложность — разница во времени. Чтобы преодолеть это, мы организовали посменную работу, а результаты передавали от смены к смене. Например, у нас были коллеги, находящиеся в Китае — с ними мы организовали дополнительные командные сессии. Их PI Planning длился 3 дня. Сессии с Китаем начинались в то время, когда у большинства коллег была ночь, и как только рабочий день китайских коллег заканчивался, они передавали результаты своей работы следующей смене. Так мы наладили рабочий процесс для разных часовых поясов.
Как мы решили проблему с флипчартами, маркерами и вот этим всем? Во время живых встреч всё просто: подошёл к доске и написал что-то так, чтобы все видели. Во время онлайн-встреч так не получится. Проблему решили с помощью ServiceNow, который предоставил все необходимые инструменты прямо в браузере. Например, разные доски: для работы с рисками на уровне всего проекта или для управления зависимостями. В ServiceNow удобный интерфейс для «наполнения» спринтов. В общем, силами ServiceNow, Microsoft Teams и Mentee мы сделали всё — даже онлайн-голосования и опросы.
В остальном мы придерживались классического подхода. Вот как это выглядело.
Сначала провели установочную сессию на общем звонке. На ней обсудили приоритеты всего проекта и высокоуровневые цели по каждому направлению. Длилась сессия 3,5 часа, не считая перерывов.
Затем – отдельный звонок для каждого стрима длительностью 3 часа на котором происходила основная работа. То есть параллельно имели место 7 звонков различных команд. Для проведения таких сессий выделяли 3 ключевых сотрудников:
- Scrum-мастер. Он направлял дискуссию, вовлекал участников в обсуждение, создавал комфорт в работе. Следить за временем и за тем, всё ли обсудили – тоже его задачи.
- SNow-мастер. Вносил необходимые изменения в ServiceNow. Именно его экран мы демонстрировали участникам группы.
- Dependency-мастер. Он отслеживал и разрешал все взаимосвязи между User stories. Если выявлялись зависимости от других направлений, этот человек подключался к звонку нужной команды для решения вопроса.
Во время этих командных сессий ежечасно Release Train Engineer и Scrum-мастера собирались на отдельный короткий 15-ти минутный звонок. На них они «сверяли часы», проверяли как команды работают и успевают ли они выполнять задачи планирования.
Далее, по итогам командных сессий был общий звонок, на котором каждый стрим представил свой план на квартал. На этом же звонке мы обсудили и обработали риски для PI. Итогом сессии было общее голосование – на нём общий план получил 3,77 баллов из 5ти. Это означало, что можно начинать по нему работать. Ура!
В итоге, оказалось, что невозможное возможно. Вся команда не только добилась поставленной цели, но еще и получила колоссальный опыт преодоления любых препятствий.
Для нас это был новый опыт – виртуальное PI планирование и PI планирование вообще.
Не всё прошло гладко. Мы совершали ошибки – расскажем о них, и чему они нас научили:
• Успех мероприятия зависит от предварительной подготовки.
Мы неплохо подготовили людей, но недостаточно подготовили User Stories. Из-за этого уже во время командных сессий пришлось срочно с нуля писать черновики Историй. Случилось это потому, что подготовленные заранее Stories не покрывали планируемые Features. Кроме того, уйму времени мы потратили на оценку сложности User Stories. Было выделено 3 часа на обсуждение рисков, зависимостей и оценку User Stories, но последние отняли больше 2 часов у большинства команд. На риски и зависимости почти ничего не осталось.
В дальнейшем, мы поняли, что при таком авральном добавлении Историй все равно что-то было упущено. Некоторые задачи мы добавляли уже после старта квартала. В идеальном мире после PI Planning дополнительные задачи на разработку возникать не должны (так не бывает)
• Выбор людей, назначенных на роли «мастеров» при командной работе.
У нас было несколько команд и каждая самостоятельно выбирала, кто будет выполнять роли Dependency и Snow-мастера. В итоге в каких-то командах эти роли были назначены людям, являющимся ключевыми фигурами для Направления. Они должны были принимать решения или обсуждать вопросы с коллегами из другой команды. Вместо этого они были вынуждены постоянно демонстрировать экран и вносить изменения в ServiceNow. Мы решили, что SNow-мастером в следующий раз будет кто-то из разработчиков.
• Важно, чтобы в обсуждениях участвовали все.
Несмотря на интерактивы и активную работу скрам-мастеров, все равно остались участники планирования, которые не вступали в обсуждения. Они не проявляли инициативу и отмалчивались. С одной стороны, у любого человека на это могут быть причины: от характера и менталитета до разного уровня квалификации внутри команды. С другой стороны, мы искренне хотим создать комфортную рабочую атмосферу. Такую, когда люди высказываются, не боясь ошибиться и нет давящей иерархии среди сотрудников.
• Посменная передача дел решает проблему разных часовых поясов.
Это стало одним из узких мест для тех команд, которые нуждались в такой передаче. Пересечения в 1 час оказалось недостаточным для того, чтобы процесс планирования в этих командах проходил гладко. Мы решили, что 1-2 ключевых фигуры в следующий раз должны будут работать немного дольше остальных — во второй день планирования, приблизительно с 6ти утра.
• Можно разделять команды на мини-группы.
Уже во время командных сессий мы спонтанно решили разделять команды. Сделали это в нескольких направлениях, чтобы сократить время выполнения активностей. Например, в одном из стримов несколько человек отделились от основной команды и на параллельном звонке провели оценку Историй, пока другая часть команды обсуждала приоритетность Features. Оказалось очень продуктивной идеей.
В итоге, несмотря на все трудности и препятствия PI был спланирован. Вся команда проекта осталась довольна, а следующие три месяца показали прекрасный результат. После написания этой статьи был проведен еще один PI Planning. Он прошел более гладко, и наш заказчик уже озвучил, что следующее планирование мы проведем тоже виртуально. Agile Release Train продолжает движение!
