Как настроить работу внутри большой кросс-функциональной команды
Железные из Redmadrobot рассказывают, как отладить работу внутри команды из более семи человек так, чтобы каждый понимал свою зону ответственности, а новый специалист не тратил много времени на погружение в проект.
Для этого мы используем спринт-пульс. В статье даём заготовку этого инструмента в Miro, которую можно докрутить под свой проект, и практические советы для организации.
Предупреждён, значит, вооружен, а теперь к делу. Чем отличается спринт-пульс от спринта:
Спринт — это отрезок времени, за который Scrum-команда создаёт полезную часть продукта, которую можно выпустить в свет.
Спринт-пульс — это инструмент, который помогает минимизировать простои и выстроить работу команды во время спринта с учётом зависимостей внутри.
Мероприятия спринта поменять нельзя, а вот спринт-пульс — это та часть, которую можно настроить под конкретный проект.
Как мы пришли к спринт-пульсу
Чтобы рассказать, как мы пришли к спринт-пульсу, берём в пример историю нашего проекта по созданию мобильного приложения. Но этот инструмент подходит и под другие типы проектов.
Стартовая команда проекта состояла из 6 человек: владелец продукта, менеджер проекта, UX-исследователь, арт-директор и два дизайнера. Одна итерация — одна неделя. Для всего этого подошёл Scrum.
Работа шла так: после проектирования целевых сценариев в wireframes и тестирования их на пользователях, мы должны были создать дизайн-концепцию приложения, а затем приступить к проектированию остальных сценариев и разработке MVP.
Чтобы разработчики могли вовремя стартануть свою часть, их подключили к работе на пару спринтов раньше. Это время нужно было для того, чтобы команда могла продумать архитектуру приложения и настроить непрерывную интеграцию.
В это время появился вопрос — а как, собственно, можно «подружить» создание UI с кодингом? Но так, чтобы сохранился темп работы и постоянный инкремент (прирост продукта). Кроме того, команда разрослась, появились QA и четыре разработчика, пришлось увеличить срок спринта до двух недель.
Мы решили провести встречи с тимлидами по направлениям и с владельцем продукта со стороны клиента.
После этого зафиксировали этапы работы и узнали, что необходимо каждой подкоманде, чтобы стартовать свою часть. Например, функциональные требования от аналитика — это основа работы разработчиков. Если тут случится задержка, то и весь проект «съедет» по сроку.
В процессе анализа работы мы поняли, что нам нужно что-то большее, чем мероприятия Scrum, для того чтобы всё работало чётко.
Собрав информацию, мы нашли и зафиксировали зависимости внутри команды: что после чего идёт и в какой промежуток времени должно быть сделано — всё это и стало спринт-пульсом.
Последний этап — интегрировать спринт-пульс в сам спринт.
Спринт-пульс со стикеров и бумаги мы пересобрали в Miro. Вообще, можно использовать любую другую программу (хоть на физических носителях, если удобно). Главное, чтобы все участники спринта могли в любое время посмотреть на схему: синхронизироваться по времени, задачам и связью с другими подкомандами.
Проблемы, которые может решить спринт-пульс
Несколько ситуаций, с которыми нам помогает справляться инструмент. Это именно наш опыт. И конечно же, это не весь список. У каждого пользователя спринт-пульса он может быть свой.
Долгий старт проекта
По правилам Scrum, команда сама должна выстроить работу внутри спринта, опираясь на его мероприятия. Но проблема номер раз — у членов команды разный уровень способностей в коммуникациях и организованности. Два — чтобы наладить коммуникацию и процессы, специалистам нужно провести серию встреч, потратив на это время.
Решение: спринт-пульс — это «стартовый кит», схема работ. Сформировав его до момента, когда командам будут даны задачи, можно быстро и слаженно стартовать.
Блокеры в процессе работы
Во время работы специалисты сфокусированы на выполнении своих задач. Они могут не видеть риски и связи с коллегами.
Без плана внутри спринта команде сложно увидеть всю картину целиком, поэтому появляются блокеры, мешающие следующим в цепочке начать вовремя. Результат такого «снежного кома» — недостижение целей спринта, а иногда провал всего проекта.
Пример: тестирование приложения для банка.
Если не заложить время на тестирование и стабилизацию, то к концу спринта будет кодовая база, но времени на поиск и исправление дефектов не останется. А без этого нельзя назвать разработанный функционал «законченным инкрементом». Отдать такой продукт клиентам банка не получится: он будет работать со сбоями, и это может привести к проблемам для банка. Например, может случиться утечка персональных данных, взлом аккаунтов, кража денежных средств и прочие ужасы.
Решение: на протяжении всей работы команда видит единый спринт-пульс. Каждый знает, кто и что от него ждёт в конкретный день, и выстраивает свою работу исходя из этого. Также спринт-пульс своего рода «контракт» между подкомандами. И если артефакты не были предоставлены в срок, то у специалиста есть право просигнализировать о проблеме, ведь все ключевые сроки зафиксированы в спринт-пульсе.
Погружение нового специалиста в проект
Обычно на онбординг новичка уходит большое количество времени. Чтобы начать работать в полную мощь, ему нужно понять, что вообще происходит и погрузиться в процессы.
Пример: к проекту подключается ещё один дизайнер. Ему рассказывают про проект и задачи, общекомандные и его подкоманды. Затем ему нужно пообщаться с другими дизайнерами и разработчиками. Важно узнать все тонкости, к примеру, когда он может привлечь разработчиков для оценки технической сложности спроектированной им реализации. Это занимает время и отвлекает остальных от задач, а значит, снижает её эффективность.
Решение: подготовленный для проекта спринт-пульс упрощает и ускоряет процесс онбординга. В нём уже наглядно показаны зависимости в команде: кому, в какой момент и что необходимо предоставить.
Как проверить, нужен ли спринт-пульс
Спринт-пульс может ускорить работу, но есть случаи, когда тратить время на его организацию не стоит. Эта табличка — подсказка: если количество «нет» больше, чем «да», то, возможно, вам подойдёт другой инструмент.
Как собрать спринт-пульс
Чтобы организовать спринт-пульс для своей команды, нужно ответить на шесть вопросов. Это поможет собрать информацию для выявления зависимостей и блокеров, которые нужно будет разложить на тайминг каждого спринта.
- Что и кто делает?
Вначале нужно определить направление работы: что делаем, кто делает, какая цель, что считаем за результат и так далее.
- Какие будут активности?
Находим все активности, которые затрагивают каждую из команд. Например, QA: ревью требований, написание тест-кейсов, тестирование, верификация исправленных дефектов и прочее. Прописываем их этапы от начала и до конца спринта.
- Какие контрольные точки спринта?
Определяем контрольные точки в спринте каждой команды. Они обозначают завершение работ над задачей в рамках спринта. Например, закончили разработку новой функциональности → пора проводить регрессионное тестирование.
- Какие есть связи внутри команды?
Определяем время на производство всех «зависимых» артефактов, нужных для работы других команд (например, макеты дизайнеров для разработчиков). Находим все взаимозависимости. Затем соединяем их и раскладываем на таймлайне спринта.
- Где могут быть простои?
Выявляем простои — моменты, которые могут сказаться на скорости и достижении целей спринта. Также находим задачи, которыми можно занять подкоманды во время вынужденных простоев. Но не просто, чтобы специалисты что-то делали, эти задачи должны помочь другой команде работать эффективнее в будущем.
- Когда командам нужно синхронизироваться?
Здесь нужно понять, на каких контрольных точках будет синхронизироваться команда. Все эти моменты фиксируем: какой результат, в каком объеме и к какому сроку должен быть готов. Мы синхронизируемся на встречах, звонках или в Slack.
Важно понимать, что на протяжении какого-то времени спринт-пульс будет «притираться» к реальностям проекта. Но даже несмотря на это, стартовать получится всё равно быстрее, чем без него.
Чтобы собрать спринт-пульс для своей команды, можно использовать вот такой шаблон. Мы указали основные моменты, дальше вы можете адаптировать всё под свой проект.
Итог
Эффективный процесс получается настроить, когда каждый специалист понимает, что, когда и зачем он делает. Для этого команду нужно синхронизировать, и спринт-пульс хорошо справляется с этой задачей.
Это дополнительный и необязательный инструмент для SCRUM-команд, но он точно полезный. Особенно, если команда кросс-функциональная и в ней больше семи человек. Спринт-пульс поможет двигаться в тайминге спринта, а вовремя завершенные спринты в свою очередь гарантируют готовый продукт к сроку.
#проект #управлениепроектами #команда #управлениекомандой #agile #scrum #спринт #инструменты #приложение #redmadrobot
Изобретена диаграмма Ганта?
В чём-то механика схожа, только Гантт собирается под конкретные работы, а здесь скорее обозначается ритм взаимодействия, который в каждом спринте заполняется разными работами.
Извините, обозначается что? Ритм? Очень сенсорно, ага...
Ну, грубо говоря :) В целом да, идея та же, только горизонт планирования меньше и задачки совсем атомарные
Спринт-пульс - это самопридуманный термин или где-то подсмотрели? На самом деле сама механика выглядит как адаптация метода критичной цепи (из "водопадной" разработки) на гибкие методологии. Использовал такую штуку в паре своих проектов (у меня правда был гибрид скрама и канбана, а не скрам - команде так было удобнее), но ни про какие "спринт-пульсы" не слышал.
Да, этот термин у нас в Роботах зародился давным-давно (даже делали первый подход к написанию полноценной статьи по этому инструменту, ее можно тут почитать https://habr.com/ru/company/redmadrobot/blog/289916/), но до конца докрутили этот инструмент недавно, теперь делимся опытом)
Диаграмма Ганта с критической цепью, вот что это, а не спринт пульс. Меня впринципе раздражают адепты скрама (не гибких методологий вообще, а именно этого срама), а когда они пытаются собрать из уже известных инкрементных, итерационных и каскадных методологий какого то непонятного монстра, при этом массово переименовывая уже известные термины и подходы, пытаясь их "диджилитизировать" как говорят в скрамтеке, от этого у меня прям подгорает. Але, если бы у вас была хотя бы мельчайшая крупица академических знаний, вы бы в жизни не опубликовали эту чушь. Все это было пройдено и в waterfall и в xp и rup и в куче других методологий, но срамоводы впереди планеты всей - они открывают "новые" подходы.
С языка снял. Я бы лучше не сказал
Спасибо за статью=)
Мы старались) Если интересно, то будем больше про наши PM-хаки.
Интересно.
Отличный материал, спасибо!
Пожалуйста.
Правда ли что скрам - прямой путь к выгоранию? Какая у вас текучка?
Звучит, скорее, как утверждение🤔
Вообще, тема применения скрама философская и немного выходит за рамки темы статьи, но, мне кажется, важны два фактора успешности скрама:
1. его грамотное применение и
2. внимание к команде
Любая работа ведет к выгоранию, просто с разной скоростью
В любом случае скрам делает процесс работы прозрачнее для команды, чем вне его
Текучка может быть не из за методологии управления проектами, а банально из-за уровня зарплаты не пропорционального нагрузке. Например, аналитику 60, а разработчику 150
Вот засранцы, такая разница
Идея, скорее, адаптирована под скрам. Главный фокус тут в выстраивании оптимальной последовательности активностей, которые носят повторяющийся характер, и их зависимости, выраженные в конкретном, но, опять же, повторяющемся моменте времени в спринте
Комментарий недоступен
Как же грустно, похоже, работать в таких галерах
Мы просто оптимизировали процесс, чтобы работать было проще. А галер у нас нет — можно прийти и убедиться, мы не скрываемся)
"Чтобы разработчики могли вовремя стартануть свою часть, их подключили к работе на пару спринтов раньше. Это время нужно было для того, чтобы команда могла продумать архитектуру приложения и настроить непрерывную интеграцию."
А у проектирование у вас тоже происходит за пару спринтов или уже во время спринта?
Всё это туфта на фоне отлаженного водопада. Встречается оно конечно редко, но увидев однажды забываешь про всратые скрамы навсегда