Как настроить работу внутри большой кросс-функциональной команды

Железные из Redmadrobot рассказывают, как отладить работу внутри команды из более семи человек так, чтобы каждый понимал свою зону ответственности, а новый специалист не тратил много времени на погружение в проект.

Как настроить работу внутри большой кросс-функциональной команды

Для этого мы используем спринт-пульс. В статье даём заготовку этого инструмента в Miro, которую можно докрутить под свой проект, и практические советы для организации.

Дисклеймер: данный материал для специалистов, которые работают по Agile, в особенности по Scrum. В тексте присутствуют такие слова, как «блокер», «тайминг», MVP, QA и вот это вот всё. Они могут оскорбить чувства неподготовленных к такому людей.

Предупреждён, значит, вооружен, а теперь к делу. Чем отличается спринт-пульс от спринта:

Спринт — это отрезок времени, за который Scrum-команда создаёт полезную часть продукта, которую можно выпустить в свет.

Спринт-пульс — это инструмент, который помогает минимизировать простои и выстроить работу команды во время спринта с учётом зависимостей внутри.

Мероприятия спринта поменять нельзя, а вот спринт-пульс — это та часть, которую можно настроить под конкретный проект.

Как мы пришли к спринт-пульсу

Чтобы рассказать, как мы пришли к спринт-пульсу, берём в пример историю нашего проекта по созданию мобильного приложения. Но этот инструмент подходит и под другие типы проектов.

Стартовая команда проекта состояла из 6 человек: владелец продукта, менеджер проекта, UX-исследователь, арт-директор и два дизайнера. Одна итерация — одна неделя. Для всего этого подошёл Scrum.

Работа шла так: после проектирования целевых сценариев в wireframes и тестирования их на пользователях, мы должны были создать дизайн-концепцию приложения, а затем приступить к проектированию остальных сценариев и разработке MVP.

Чтобы разработчики могли вовремя стартануть свою часть, их подключили к работе на пару спринтов раньше. Это время нужно было для того, чтобы команда могла продумать архитектуру приложения и настроить непрерывную интеграцию.

В это время появился вопрос — а как, собственно, можно «подружить» создание UI с кодингом? Но так, чтобы сохранился темп работы и постоянный инкремент (прирост продукта). Кроме того, команда разрослась, появились QA и четыре разработчика, пришлось увеличить срок спринта до двух недель.

Мы решили провести встречи с тимлидами по направлениям и с владельцем продукта со стороны клиента.

<i>Железяки штормят возможные варианты взаимодействия​</i>
Железяки штормят возможные варианты взаимодействия​

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

В процессе анализа работы мы поняли, что нам нужно что-то большее, чем мероприятия Scrum, для того чтобы всё работало чётко.

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

Алёна Шестера, Менеджер проектов Redmadrobot
<p><i>Самые первые зарисовки нашего спринт-пульса</i></p>

Самые первые зарисовки нашего спринт-пульса

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

<i>​Первые версии вариантов связей внутри спринта были в физическом варианте — наброски на бумаге, стикеры — всё шло в ход.</i>
​Первые версии вариантов связей внутри спринта были в физическом варианте — наброски на бумаге, стикеры — всё шло в ход.

Последний этап — интегрировать спринт-пульс в сам спринт.

Спринт-пульс со стикеров и бумаги мы пересобрали в Miro. Вообще, можно использовать любую другую программу (хоть на физических носителях, если удобно). Главное, чтобы все участники спринта могли в любое время посмотреть на схему: синхронизироваться по времени, задачам и связью с другими подкомандами.

<i>​Готовый <a href="https://drive.google.com/file/d/1Kx3358PbADe_EdrJu7NcC75chHOIs3Ke/view" rel="nofollow noreferrer noopener" target="_blank">спринт-пульс</a> для нашего проекта</i>
​Готовый спринт-пульс для нашего проекта

Проблемы, которые может решить спринт-пульс

Несколько ситуаций, с которыми нам помогает справляться инструмент. Это именно наш опыт. И конечно же, это не весь список. У каждого пользователя спринт-пульса он может быть свой.

Долгий старт проекта

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

Решение: спринт-пульс — это «стартовый кит», схема работ. Сформировав его до момента, когда командам будут даны задачи, можно быстро и слаженно стартовать.

Блокеры в процессе работы

Во время работы специалисты сфокусированы на выполнении своих задач. Они могут не видеть риски и связи с коллегами.

Без плана внутри спринта команде сложно увидеть всю картину целиком, поэтому появляются блокеры, мешающие следующим в цепочке начать вовремя. Результат такого «снежного кома» — недостижение целей спринта, а иногда провал всего проекта.

Пример: тестирование приложения для банка.

Если не заложить время на тестирование и стабилизацию, то к концу спринта будет кодовая база, но времени на поиск и исправление дефектов не останется. А без этого нельзя назвать разработанный функционал «законченным инкрементом». Отдать такой продукт клиентам банка не получится: он будет работать со сбоями, и это может привести к проблемам для банка. Например, может случиться утечка персональных данных, взлом аккаунтов, кража денежных средств и прочие ужасы.

Решение: на протяжении всей работы команда видит единый спринт-пульс. Каждый знает, кто и что от него ждёт в конкретный день, и выстраивает свою работу исходя из этого. Также спринт-пульс своего рода «контракт» между подкомандами. И если артефакты не были предоставлены в срок, то у специалиста есть право просигнализировать о проблеме, ведь все ключевые сроки зафиксированы в спринт-пульсе.

Погружение нового специалиста в проект

Обычно на онбординг новичка уходит большое количество времени. Чтобы начать работать в полную мощь, ему нужно понять, что вообще происходит и погрузиться в процессы.

Пример: к проекту подключается ещё один дизайнер. Ему рассказывают про проект и задачи, общекомандные и его подкоманды. Затем ему нужно пообщаться с другими дизайнерами и разработчиками. Важно узнать все тонкости, к примеру, когда он может привлечь разработчиков для оценки технической сложности спроектированной им реализации. Это занимает время и отвлекает остальных от задач, а значит, снижает её эффективность.

Решение: подготовленный для проекта спринт-пульс упрощает и ускоряет процесс онбординга. В нём уже наглядно показаны зависимости в команде: кому, в какой момент и что необходимо предоставить.

Как проверить, нужен ли спринт-пульс

Спринт-пульс может ускорить работу, но есть случаи, когда тратить время на его организацию не стоит. Эта табличка — подсказка: если количество «нет» больше, чем «да», то, возможно, вам подойдёт другой инструмент.

<i>Мини-тест на «спринт-пульсность» ситуации</i>
Мини-тест на «спринт-пульсность» ситуации

Как собрать спринт-пульс

Чтобы организовать спринт-пульс для своей команды, нужно ответить на шесть вопросов. Это поможет собрать информацию для выявления зависимостей и блокеров, которые нужно будет разложить на тайминг каждого спринта.

  • Что и кто делает?

Вначале нужно определить направление работы: что делаем, кто делает, какая цель, что считаем за результат и так далее.

  • Какие будут активности?

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

  • Какие контрольные точки спринта?

Определяем контрольные точки в спринте каждой команды. Они обозначают завершение работ над задачей в рамках спринта. Например, закончили разработку новой функциональности → пора проводить регрессионное тестирование.

  • Какие есть связи внутри команды?

Определяем время на производство всех «зависимых» артефактов, нужных для работы других команд (например, макеты дизайнеров для разработчиков). Находим все взаимозависимости. Затем соединяем их и раскладываем на таймлайне спринта.

  • Где могут быть простои?

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

Например, у нас первый день спринта посвящен планированию и оценкам, нежели непосредственной работе, поэтому для нас таким мероприятием стал «чистый день» команды дизайна, в который они могли навести порядок в макетах и актуализировать карту экранов.

Алёна Шестера, менеджер проектов Redmadrobot
  • Когда командам нужно синхронизироваться?

Здесь нужно понять, на каких контрольных точках будет синхронизироваться команда. Все эти моменты фиксируем: какой результат, в каком объеме и к какому сроку должен быть готов. Мы синхронизируемся на встречах, звонках или в Slack.

Как только дизайнеры завершили проектирование сценария в ваерах, мы собирались всей командой на синк. На нем мы презентовали наработки и собирали обратную связь по техническим ограничениям. В результате дизайнеры выдавали максимально реализуемые результаты.

Алёна Шестера, менеджер проектов Redmadrobot

Важно понимать, что на протяжении какого-то времени спринт-пульс будет «притираться» к реальностям проекта. Но даже несмотря на это, стартовать получится всё равно быстрее, чем без него.

Чтобы собрать спринт-пульс для своей команды, можно использовать вот такой шаблон. Мы указали основные моменты, дальше вы можете адаптировать всё под свой проект.

​Инструмент можно <a href="https://miro.com/app/board/o9J_kvXjB4A=/" rel="nofollow noreferrer noopener" target="_blank">разглядеть</a> поближе и <a href="https://drive.google.com/open?id=1YeIag1x5VUgKrjzCrGKbXi7Bp1z4ciFO" rel="nofollow noreferrer noopener" target="_blank">скачать</a> бэкап-файл для Miro
​Инструмент можно разглядеть поближе и скачать бэкап-файл для Miro

Итог

Эффективный процесс получается настроить, когда каждый специалист понимает, что, когда и зачем он делает. Для этого команду нужно синхронизировать, и спринт-пульс хорошо справляется с этой задачей.

Это дополнительный и необязательный инструмент для SCRUM-команд, но он точно полезный. Особенно, если команда кросс-функциональная и в ней больше семи человек. Спринт-пульс поможет двигаться в тайминге спринта, а вовремя завершенные спринты в свою очередь гарантируют готовый продукт к сроку.

4242
24 комментария

Изобретена диаграмма Ганта?

8
Ответить

В чём-то механика схожа, только Гантт собирается под конкретные работы, а здесь скорее обозначается ритм взаимодействия, который в каждом спринте заполняется разными работами. 

3
Ответить

Ну, грубо говоря :) В целом да, идея та же, только горизонт планирования меньше и задачки совсем атомарные

Ответить

Спринт-пульс - это самопридуманный термин или где-то подсмотрели? На самом деле сама механика выглядит как адаптация метода критичной цепи (из "водопадной" разработки) на гибкие методологии. Использовал такую штуку в паре своих проектов (у меня правда был гибрид скрама и канбана, а не скрам - команде так было удобнее), но ни про какие "спринт-пульсы" не слышал.

4
Ответить

Да, этот термин у нас в Роботах зародился давным-давно (даже делали первый подход к написанию полноценной статьи по этому инструменту, ее можно тут почитать https://habr.com/ru/company/redmadrobot/blog/289916/), но до конца докрутили этот инструмент недавно, теперь делимся опытом)

Ответить

Диаграмма Ганта с критической цепью, вот что это, а не спринт пульс. Меня впринципе раздражают адепты скрама (не гибких методологий вообще, а именно этого срама), а когда они пытаются собрать из уже известных инкрементных, итерационных и каскадных методологий какого то непонятного монстра, при этом массово переименовывая уже известные термины и подходы, пытаясь их "диджилитизировать" как говорят в скрамтеке, от этого у меня прям подгорает. Але, если бы у вас была хотя бы мельчайшая крупица академических знаний, вы бы в жизни не опубликовали эту чушь. Все это было пройдено и в waterfall и в xp и rup и в куче других методологий, но срамоводы впереди планеты всей - они открывают "новые" подходы. 

4
Ответить

С языка снял. Я бы лучше не сказал

Ответить