Вы когда-нибудь работали над проектом, в котором участвовало более ста человек, несколько компаний, учитывая 10 часовых поясов, разные менталитеты и языки? Хотим поделиться опытом планирования работы над проектом, управляемым по методологии SAFe, в условиях вынужденной удаленной работы.
Наша международная команда уже год работает над масштабным проектом.
Мы помогаем крупной компании-разработчику программного обеспечения внедрить ServiceNOW. Мы руководили проектом по методологии Scrum около года.
Сначала мы разделили проект на направления, в каждом направлении была своя команда.
Но постепенно все смешалось и мы оказались в такой ситуации.
В команде 100+ человек — все разбросаны от Китая до Калифорнии, команда состоит из представителей 4 разных компаний.
Все работают над одним потоком задач, справиться с которым очень сложно, потому что поток огромный.
У нас был один Scrum Master, несколько владельцев продуктов, бизнес-консультантов и несколько разработчиков.
Скрам-митинги (ежедневные) мы проводили каждый день по два потока — все их вел один и тот же Скрам-мастер, на которого был возложен огромный объем работы.
Agile требует самоотдачи, большой ответственности и организованности от всей команды.
При этом Scrum-мастер должен следить не только за всей картиной, но и за каждой конкретной задачей.
Если у разработчика возникают проблемы, требующие помощи коллег, Scrum Master должен вовремя вмешаться и помочь, чтобы задача была выполнена к концу спринта.
Руководство проекта решило, что необходимы изменения.
Управление проектом стало передаваться в SAFe: Масштабируемая гибкая платформа (У ServiceNow есть специальный плагин, позволяющий управлять проектом по этой методологии).
Они решили мигрировать, потому что масштабы проекта увеличивались.
Другого пути нет, потому что мы автоматизировали 4 процесса, а нужно было внедрить 5 новых.
Кроме того, в объем проекта были добавлены новые бизнес-подразделения, для которых необходимо запустить ServiceNow. В результате продуктовых команд становится больше, прозрачности меньше, да ещё и разница в часовых поясах.
Разные часовые пояса — это особая головная боль.
У Скрам-мастера — 6 утра, у другого сотрудника — 2 часа ночи.
Неясно, когда проводить ежедневные задания.
Вернемся к SAFe. Почему мы вообще выбрали его? Масштабируемая гибкая платформа позволяет использовать гибкие подходы при работе с большими проектными командами (более 50 человек).
Это удобно.
Возможна организация работы нескольких проектных команд, участники которых могут быть разбросаны по всему земному шару.
SAFe позволяет нескольким командам одновременно работать в рамках одного проекта над общей большой задачей.
В том числе различных подрядчиков.
При этом происходит объединение по направлениям – потокам.
В каждом направлении есть свой Product Owner, Scrum Master, бизнес-консультанты, разработчики, тестировщики.
Выглядит сложно, но на самом деле удобно.
Команда большая, направлений много, но все работают на достижение общей цели.
Направления сотрудничают между собой.
В результате не существует конкретного направления, на которое пришелся бы запуск всего продукта.
Потоки помогают друг другу и взаимозависимы.
Теперь немного терминологии.
Зная это важно понимать, как мы развивали проект дальше.
Одним из ключевых понятий SAFe является PI (инкремент программы).
Это период времени, в течение которого команда разрабатывает и представляет заказчику готовый к использованию фрагмент программного продукта.
У каждого приращения программного обеспечения (PI) есть цели — PI Objectives. Это бизнес- и технические задачи, которые команда обязуется выполнить в ходе PI. PI Objectives необходимо правильно сформулировать – от этого зависит многое.
Их лучше формулировать по методике SMART – когда сформулированные цели конкретны, достижимы, измеримы, значимы и ограничены во времени.
Постановка целей – это не задача одного человека.
Когда вся команда участвует в формировании и постановке целей, это называется «Планирование приращения программы» (PI Planning).
Как гласит методология SAFe, PI Planning — это сердце проекта.
«Если вы не занимаетесь PI Planning, вы не занимаетесь SAFe» — говорят авторы .
Планирование приращений программного обеспечения важно по двум причинам.
Первый – установить сроки выполнения задач.
Второе – объединить членов команды.
Каждый участник PI Planning должен чувствовать важность события и чувствовать себя вовлеченным в процесс.
Мнение каждого важно — от него зависит будущее продукта.
Лучший способ организовать PI Planning — собрать всех участников в одном месте.
Планирование происходит в течение 2 дней, каждый день делится на 2 части:
- общая сессия
- командная работа отдельно по каждому направлению разработки (потоку).
Покажите основные направления развития, расскажите, какие приоритеты согласованы с заказчиком.
Затем вы определяете глобальные планы дальнейшего развития продукта.
После этого участники расходятся по своим командам и детально планируют деятельность на своей территории.
У каждой команды есть набор Feature (высокоуровневые задачи, отвечающие за часть функциональности системы), которые планируется реализовать в ходе предстоящего инкремента программного обеспечения.
Чтобы реализовать функции, вам необходимо подготовить пользовательские истории для каждой.
Лучше это сделать заранее – до начала ПИ-планирования.
Когда пользовательские истории готовы, вся команда оценивает их сложность с помощью чисел Фибоначчи.
Инкремент программного обеспечения делится на несколько спринтов, каждый из которых обычно длится две недели.
Во время планирования команда расставляет приоритеты для функций и определяет, какие из них необходимо реализовать раньше, а какие позже.
В зависимости от приоритетов пользовательские истории распределяются по спринтам для всего прироста программного обеспечения.
То есть мы заранее Детально планируем работу на длительный период (например, четверть).
Нередко можно встретить задачи, затрагивающие несколько потоков.
В этом случае кто-то из команды выходит к группе коллег соседнего направления и обсуждает дальнейший план действий.
По окончании второго дня планирования каждая команда представляет на общем собрании свой план работы на квартал, после чего проводится голосование.
Каждый участник оценивает по пятибалльной шкале, готов ли он реализовать разработанный план и высказывает свое мнение о процессе планирования.
Результаты голосования анализируются, и на их основе принимается решение о необходимости доработки плана.
Это была теория того, как должно быть.
Теперь о том, как все происходило у нас.
Сначала мы планировали собрать практически всех участников в офисе заказчика.
Мы хотели работать продуктивно, да ещё в одном часовом поясе.
Для сотрудников, которые работают удаленно, мы запланировали трансляцию встречи.
Пазл складывался прекрасно, но из-за всеобщей самоизоляции все пошло не так.
Реальность изменилась и провести живую встречу стало невозможно.
Мы озадачились, как организовать виртуальное ПИ-планирование.
Основные трудности и вопросы, которые пришлось решить:
- Как подготовить команду? Большинство участников никогда раньше не участвовали в PI Planning таким образом.
- Как вовлечь всех и не «потерять» людей при онлайн-планировании? Напомним, участие каждого члена команды крайне важно.
- Что делать с разницей во времени?
- Какие инструменты следует использовать вместо досок, стикеров, флипчартов и маркеров? Спойлер — все сделал ServiceNow!
На них всем коллегам рассказали, что такое ПИ-планирование и зачем оно нужно, объяснили основы, что за чем следует и какие задачи нужно решить при планировании.
Большую часть этих обучающих занятий проводил инженер Release Train, ключевая фигура в организации рабочих процессов команд SAFe. Мы регулировали взаимодействие с помощью интерактивных взаимодействий.
Например, на общих занятиях проводили опросы на тему «как вы себя чувствуете после первого дня планированияЭ» или «какое мороженое ты предпочитаешьЭ» 
Во время фокус-сессий основная работа по вовлечению всех участников ложилась на скрам-мастеров, которым порой приходилось изрядно потрудиться, чтобы узнать мнение каждого участника по тому или иному вопросу.
Было бы проще оставить всю работу активным коллегам, но важно дать каждому право голоса.
Следующая трудность — разница во времени.
Чтобы преодолеть это, мы организовали посменную работу и передавали результаты из смены в смену.
Например, у нас были коллеги, находящиеся в Китае — мы организовывали с ними дополнительные командные занятия.
Их PI-планирование длилось 3 дня.
Сессии с Китаем начинались в то время, когда большинство коллег находились в ночное время, и как только рабочий день китайских коллег заканчивался, они передавали результаты своей работы следующей смене.
Так мы наладили рабочий процесс для разных часовых поясов.
Как мы решили проблему с флипчартами, маркерами и всем этим? Во время живых встреч все просто: выйдите к доске и напишите что-нибудь, чтобы все видели.
Это не будет работать во время онлайн-встреч.
Проблему решили с помощью ServiceNow, который предоставил все необходимые инструменты прямо в браузере.
Например, разные доски: для работы с рисками на уровне всего проекта или для управления зависимостями.
ServiceNow имеет удобный интерфейс для «наполнения» спринтов.
В общем, мы делали всё с помощью ServiceNow, Microsoft Teams и Mentee — даже онлайн-голосование и опросы.
В остальном мы придерживались классического подхода.
Вот как это выглядело.
Сначала мы провели вводное заседание по общему призыву.
Были обсуждены приоритеты всего проекта и цели высокого уровня по каждому направлению.
Сеанс длился 3,5 часа, не считая перерывов.
Далее — отдельный звонок на каждый поток длительностью 3 часа, на котором проходила основная работа.
То есть параллельно произошло 7 звонков от разных команд. Для проведения таких занятий были выделены 3 ключевых сотрудника:
- Скрам-мастер.
Он руководил дискуссией, вовлекал участников в дискуссию, создавал комфорт в работе.
Следить за временем и все ли обговорено – тоже его задача.
- Снежный хозяин.
Внесены необходимые изменения в ServiceNow. Именно его экран мы показали участникам группы.
- Мастер зависимостей.
Он отслеживал и разрешал все связи между историями пользователей.
Если выявлялись зависимости от других направлений, этого человека подключали к вызову необходимой команды для решения вопроса.
На них «сверяли часы», проверяли, как работают команды и успевают ли они выполнить плановые задачи.
Далее по итогам командных сессий состоялся общий призыв, где каждый поток представил свой план на квартал.
Во время того же разговора мы обсудили и проработали риски для PI. Итогом заседания стало общее голосование – в нем генплан получил 3,77 балла из 5. Это означало, что мы могли приступить к работе над ним.
Ура! 
В итоге оказалось, что невозможное возможно.
Вся команда не только добилась своей цели, но и приобрела колоссальный опыт преодоления любых препятствий.
Для нас это был новый опыт – виртуальное PI-планирование и PI-планирование в целом.
Не все прошло гладко.
Мы совершали ошибки — расскажем о них и о том, чему они нас научили: • Успех мероприятия зависит от предварительной подготовки.
Мы хорошо подготовили людей, но недостаточно подготовили пользовательские истории.
Из-за этого уже во время командных сессий нам приходилось срочно писать черновики Stories с нуля.
Это произошло потому, что подготовленные заранее Истории не охватывали запланированные Фичи.
Кроме того, мы потратили много времени на оценку сложности пользовательских историй.
На обсуждение рисков, зависимостей и оценку пользовательских историй было выделено 3 часа, но последнее у большинства команд заняло более 2 часов.
От рисков и зависимостей почти ничего не осталось.
Позже мы поняли, что при таком экстренном добавлении Историй чего-то всё равно не хватает. Мы добавили некоторые задания после начала квартала.
В идеальном мире после PI Planning не должно возникнуть дополнительных задач разработки (такого не бывает) • Выбор людей, назначаемых на «главные» роли в командной работе.
У нас было несколько команд, и каждая самостоятельно выбирала, кто будет исполнять роли Зависимости и Снежного Хозяина.
В результате в некоторых командах эти роли были закреплены за людьми, которые были ключевыми фигурами для Дирекции.
Им приходилось принимать решения или обсуждать проблемы с коллегами из другой команды.
Вместо этого они были вынуждены постоянно делиться экраном и вносить изменения в ServiceNow. Мы решили, что в следующий раз одним из разработчиков будет мастер SNow. • Важно, чтобы в обсуждениях участвовали все.
Несмотря на взаимодействие и активную работу Скрам-мастеров, все же находились участники планирования, которые не вступали в дискуссии.
Они не проявили инициативы и промолчали.
С одной стороны, причины для этого могут быть у любого человека: от характера и менталитета до разного уровня квалификации внутри команды.
С другой стороны, мы искренне хотим создать комфортную рабочую атмосферу.
Тот, когда люди высказываются, не боясь ошибиться, и среди сотрудников нет репрессивной иерархии.
• Назначение смен решает проблему разных часовых поясов.
Это стало одним из узких мест для тех команд, которым был необходим такой трансфер.
Пересечение в 1 час было недостаточным для обеспечения бесперебойного процесса планирования для этих команд. Мы решили, что 1-2 ключевым фигурам в следующий раз придется работать чуть дольше остальных – на второй день планирования, примерно с 6 утра.
• Вы можете разделить команды на мини-группы.
Уже во время командных занятий мы спонтанно решили разделить команды.
Мы сделали это по нескольким направлениям, чтобы сократить время выполнения мероприятий.
Например, в одном из потоков несколько человек оторвались от основной команды и на параллельном звонке оценивали Stories, а другая часть команды обсуждала приоритет Фич.
Это оказалась очень продуктивная идея.
В итоге, несмотря на все трудности и препятствия, ПИ было запланировано.
Вся команда проекта осталась довольна, и следующие три месяца показали отличные результаты.
С момента написания этой статьи было проведено еще одно PI Planning. Все прошло более гладко, и наш заказчик уже сообщил, что следующее планирование мы также проведем виртуально.
Поезд Agile Release продолжает двигаться! Теги: #Удаленная работа #agile #безопасно #ITSM #ServiceNow
-
Денвер 3 Альфа
19 Oct, 24 -
Факторизация Чисел
19 Oct, 24 -
Прокси Или Как Это Работает
19 Oct, 24
