Спринт-пульс — это дополнительный инструмент, который может использовать Scrum-команда для организации процесса внутри спринта. Он помогает настроить работу в команде и экономит время на погружение новых специалистов. Как его применять, рассказывает железный project-manager Алёна Шестера. Бонусом, в конце статьи, вы найдёте шаблон для первой сборки.
Когда-то мы уже немного рассказывали об этом инструменте. С момента написания предыдущей статьи, он много раз нас выручал, поэтому мы решили раскрыть тему подробнее.
Названия похожи, но суть разная:
Мероприятия спринта неизменны, а спринт-пульс — это часть, которую можно настроить под конкретный проект.
Артефакт — объект, созданный в процессе работы над проектом (например, протокол, макет, бэклог и прочее).
Инкремент — прирост продукта (например, появление новых фич или их обновление).
Блокер — ситуация, которая мешает работе и блокирует её.
Вехи — значимые этапы проекта.
Главной задачей нашего проекта, которую мы взяли для примера, было создание мобильного приложения с нуля. Работа разделилась на несколько этапов. Первым производственным этапом было создание дизайна сервиса. А в качестве первого существенного артефакта — создание макетов экранов (wireframes) для высокоприоритетных сценариев приложения. Эти сценарии входили в MVP продукта.
Стартовая команда состояла из 6 человек: product-owner со стороны заказчика, project-manager, ux-исследователь, арт-директор и два дизайнера. Каждую итерацию нужно было предоставлять новые макеты — это показатель того, что проект идёт в нужном темпе. Одна итерация — одна неделя. Scrum отлично подошёл для этой задачи. Согласовав дни начала и конца спринта, а также дни и состав участников мероприятий спринта, мы начали работу.
Следующей ключевой задачей была разработка дизайн-концепции. После этого нас ожидала разработка, поэтому в параллель этой задаче, мы подключили аналитика, архитектора, разработчиков и тестировщика, чтобы подготовить все необходимое для полноценного старта: продумать и заложить архитектуру приложения, настроить CI (непрерывную интеграцию), и главное, договориться о взаимодействии внутри объединенной команды.
В этот момент мы поняли, что нам необходимо найти решение, которое «подружило» бы проектирование и разработку, а также сохранило темп работы и систематическое получение инкремента.
В процессе анализа предстоящей работы мы поняли, что нам нужно что-то большее, чем мероприятия Scrum, чтобы эффективно стартовать. Мы столкнулись с большим количеством активностей: анализ и составление первичных бизнес-требований, проектирование сценария, подготовка макетов, составление функциональных требований, проектирование API, разработка и тестирование. Из-за этого (при планировании спринта) была велика вероятность упустить что, кому и когда может понадобиться в процессе работы, внутри самого спринта.
Кроме того, используя только стандартные инструменты Scrum, можно столкнуться с проблемой долгого планирования из спринта в спринт. Каждый раз нам пришлось бы договариваться с подкомандами, когда и что можно увидеть и оценить.
Также с помощью инструментов Scrum не получится эффективно распределить время специалистов. В условиях большого проекта это привело бы к блокерам: артефакт для старта работ следующего этапа не был бы готов. К примеру: чтобы разработчики серверной части смогли приступить к созданию API, им нужно понимать, какой функционал предполагают спроектировать дизайнеры. Если не распределить время специалистов оптимально, то есть риск, что работа не будет сделана в срок.
Мы стремились выстроить «поток» внутри спринта. Главная задача — сделать процесс работы понятным каждому члену подкоманды и минимизировать простои. Все должны понимать свою зону ответственности и моменты, когда и что нужно предоставить.
Параллельно с разработкой мы стали собирать спринт-пульс. Начали со встреч с ведущими специалистами по каждому направлению и с product-owner со стороны заказчика. Зафиксировали основные этапы работы и определили, что необходимо каждой подкоманде, чтобы стартовать свою часть процесса. Например, функциональные требования от аналитика — это основа работы разработчиков. Если тут случится задержка, то и весь проект «съедет» по сроку.
Дополнительно проговорили с заказчиком важные моменты, которые могли влиять на спринт-пульс. Один из таких моментов — параметр time-to-market (время вывода на рынок) в 1 месяц и получение инкремента (прирост функциональности) раз в 2 недели.
Собрав информацию, мы нашли и зафиксировали зависимости: что и после чего идёт, а также — в какой промежуток времени должно быть сделано. Всё это и стало рабочим процессом.
Самые первые зарисовки
Во время сбора спринт-пульса, важно минимизировать моменты, где могут быть простои. Например, в нашем случае стоило заложить больше времени аналитика на описание методов API. Так как на основе этой информации, готовят требования для команды front-end разработчиков, нужно было быть готовыми к увеличению срока.
Первые версии вариантов связей внутри спринта были в физическом варианте: наброски на бумаге, стикеры — всё шло в ход!
Последний этап — интегрировать спринт-пульс в сам спринт.
Размышления, как разбить инструмент на спринты
У нас получилось собрать оптимальный для себя вариант спринт-пульса: он учитывал все зависимости и контрольные точки для предоставления результата другой команде.
Спринт-пульс со стикеров и листов бумаги мы пересобрали в Miro. Можно использовать любую другую программу (и на физических носителях, если удобно). Главное, чтобы все участники спринта могли в любое время посмотреть на схему — синхронизироваться по времени, задачам и связям с другими подкомандами.
Спринт-пульс для нашего проекта
Чтобы сделать спринт-пульс для своей команды, нужно ответить на 6 вопросов. Это поможет собрать информацию, из которой можно выявить зависимости и блокеры. Затем их нужно разложить на тайминг каждого спринта.
1) Что и кто делает?
В начале нужно определить направление работы: что делаем, кто делает, какая цель, что считаем за результат и т.д.
2) Какие будут активности?
Находим все активности, которые затрагивают каждую из подкоманд. Прописываем их этапы от начала и до конца спринта.
3) Какие вехи спринта?
Определяем вехи (контрольные точки) в спринте каждой подкоманды. Они обозначают завершение работ над задачей в рамках спринта.
4) Какие есть связи внутри команды?
Определяем время на производство всех «зависимых» артефактов, нужных для работы других команд (например, макеты дизайнеров для разработчиков). Находим все взаимозависимости. Затем соединяем их и раскладываем на таймлайне спринта.
5) Где могут быть простои?
Выявляем простои — моменты, которые могут сказаться на скорости и достижении целей спринта. Также находим задачи, которыми можно занять подкоманды во время вынужденных простоев. Но не просто, чтобы специалисты что-то делали — эти задачи должны помочь другой команде работать эффективнее в будущем.
Например, у нас первый день спринта посвящен планированию и оценкам, поэтому для нас таким мероприятием стал «чистый день» команды дизайна, в который они могли навести порядок в макетах и актуализировать карту экранов.
6) Когда командам нужно синхронизироваться?
Здесь нужно понять, на каких контрольных точках будет синхронизироваться команда. Все эти моменты фиксируем: какой результат, в каком объеме и к какому сроку должен быть готов. Обозначить это нужно для всех подкоманд.
Для того, чтобы дизайнеры могли выдавать реализуемый результат для разработчиков, при завершении проектирования сценария в wireframes, мы собирались всей командой для презентации наработок и сбора обратной связи по техническим ограничениям.
Важно понимать, что на протяжении какого-то времени спринт-пульс будет «притираться» к реальностям проекта. Но, даже несмотря на это, стартовать получится всё равно быстрее, чем без него.
Чтобы собрать спринт-пульс для своей команды, можно использовать вот такой шаблон. Основные моменты тут указаны, но что-то можно и нужно адаптировать под свой проект.
Разглядеть поближе и скачать можно здесь
Есть случаи, когда спринт-пульс — лишнее, но иногда он будет просто незаменим.
Эта табличка — подсказка: если количество «да» больше, чем «нет», то, возможно, вам стоит использовать этот инструмент.
Мини-тест на «спринт-пульсность» ситуации
Тут несколько ситуаций, с которыми нам помогает справляться инструмент. Это именно наш опыт и, конечно же, это не весь список. У каждого пользователя спринт-пульса он может быть свой.
По правилам Scrum, команда сама должна выстроить работу внутри спринта, опираясь на его мероприятия. Но первая проблема — члены команды обладают разным уровнем коммуникации и организованности. Вторая — чтобы наладить коммуникацию и процессы, командам нужно провести серию встреч и потратить на это много времени.
Решение: спринт-пульс — стартовый кит, который ускорит работу. Сформировав его до начала производства (до момента, когда командам будут даны задачи), можно быстро и слаженно стартовать.
Во время работы специалисты сфокусированы на выполнении своих задач. Они могут не осознавать риски и связи с другими специалистами. Без фиксированного плана внутри спринта, команде сложно увидеть всю картину целиком. Как следствие, появляются блокеры: следующие специалисты в цепочке не могут приступить к работе. Результат такого «снежного кома» — недостижение целей спринта, а в крайних случаях — провал проекта.
Пример: яркий пример — тестирование мобильного приложения для банка. Если в него не заложить время на тестирование и стабилизацию, то к концу спринта будет кодовая база, но времени на поиск дефектов не останется. А без этого нельзя назвать разработанный код «законченным инкрементом». Отдать такой продукт клиентам банка не получится: помимо того, что он будет работать со сбоями, это может привести к проблемам для банка. Например, может случиться утечка персональных данных, взлом аккаунтов, кража денежных средств и прочее.
Решение: на протяжении всей работы команда видит единый спринт-пульс. Каждый знает, кто и что от него ждёт в конкретный день спринта, и выстраивает свою работу, исходя из этих зависимостей. Помимо этого, спринт-пульс — своего рода «контракт» между подкомандами. И если артефакты не были предоставлены в срок, то у специалиста есть полное право эскалировать проблему, ведь все ключевые сроки зафиксированы в спринт-пульсе.
Обычно на онбординг специалиста уходит достаточно большое количество времени. Чтобы начать работать в полную мощь, ему нужно понять, что происходит и погрузиться в процессы.
Пример: к проекту подключается ещё один дизайнер. Ему рассказывают про проект и задачи: общекомандные, а также задачи непосредственно его подкоманды. Затем ему нужно пообщаться с другими дизайнерами и разработчиками. Важно узнать все тонкости, к примеру, когда он может привлечь разработчиков для оценки технической сложности спроектированной им реализации. Это занимает время и отвлекает команду от задач, что в целом снижает её эффективность.
Решение: Подготовленный для проекта спринт-пульс существенно упрощает и ускоряет процесс погружения специалиста. В нём уже наглядно показаны зависимости в команде — кому, в какой момент и что необходимо предоставить. С его помощью можно быстрее и эффективнее встраивать в проект новых специалистов.
Эффективный процесс получается настроить, если каждый сотрудник понимает что, когда и зачем он делает. Для этого команду нужно синхронизировать и спринт-пульс хорошо справляется с этой задачей. Это только дополнительный инструмент для scrum-команд, но точно полезный. Он позволяет быстро наладить производственный процесс и обозначить зону ответственности для каждого. Спринт-пульс поможет двигаться в тайминге спринта, а вовремя завершенные спринты, в свою очередь, гарантируют готовый продукт к сроку.
Когда-то мы уже немного рассказывали об этом инструменте. С момента написания предыдущей статьи, он много раз нас выручал, поэтому мы решили раскрыть тему подробнее.
Спринт-пульс и спринт: в чём разница
Названия похожи, но суть разная:
- Спринт — это отрезок времени, за который Scrum-команда создаёт часть продукта, которую можно показать заказчику и которая будет ему полезна. Спринт состоит из пяти мероприятий: планирование, ежедневный Scrum, разработка, демо спринта и ретроспектива.
- Спринт-пульс — это инструмент, который помогает выстроить эффективную работу внутри команды во время спринта.
Мероприятия спринта неизменны, а спринт-пульс — это часть, которую можно настроить под конкретный проект.
Термины
Артефакт — объект, созданный в процессе работы над проектом (например, протокол, макет, бэклог и прочее).
Инкремент — прирост продукта (например, появление новых фич или их обновление).
Блокер — ситуация, которая мешает работе и блокирует её.
Вехи — значимые этапы проекта.
Спринт-пульс в действии
Главной задачей нашего проекта, которую мы взяли для примера, было создание мобильного приложения с нуля. Работа разделилась на несколько этапов. Первым производственным этапом было создание дизайна сервиса. А в качестве первого существенного артефакта — создание макетов экранов (wireframes) для высокоприоритетных сценариев приложения. Эти сценарии входили в MVP продукта.
Стартовая команда состояла из 6 человек: product-owner со стороны заказчика, project-manager, ux-исследователь, арт-директор и два дизайнера. Каждую итерацию нужно было предоставлять новые макеты — это показатель того, что проект идёт в нужном темпе. Одна итерация — одна неделя. Scrum отлично подошёл для этой задачи. Согласовав дни начала и конца спринта, а также дни и состав участников мероприятий спринта, мы начали работу.
Следующей ключевой задачей была разработка дизайн-концепции. После этого нас ожидала разработка, поэтому в параллель этой задаче, мы подключили аналитика, архитектора, разработчиков и тестировщика, чтобы подготовить все необходимое для полноценного старта: продумать и заложить архитектуру приложения, настроить CI (непрерывную интеграцию), и главное, договориться о взаимодействии внутри объединенной команды.
В этот момент мы поняли, что нам необходимо найти решение, которое «подружило» бы проектирование и разработку, а также сохранило темп работы и систематическое получение инкремента.
В процессе анализа предстоящей работы мы поняли, что нам нужно что-то большее, чем мероприятия Scrum, чтобы эффективно стартовать. Мы столкнулись с большим количеством активностей: анализ и составление первичных бизнес-требований, проектирование сценария, подготовка макетов, составление функциональных требований, проектирование API, разработка и тестирование. Из-за этого (при планировании спринта) была велика вероятность упустить что, кому и когда может понадобиться в процессе работы, внутри самого спринта.
Кроме того, используя только стандартные инструменты Scrum, можно столкнуться с проблемой долгого планирования из спринта в спринт. Каждый раз нам пришлось бы договариваться с подкомандами, когда и что можно увидеть и оценить.
Также с помощью инструментов Scrum не получится эффективно распределить время специалистов. В условиях большого проекта это привело бы к блокерам: артефакт для старта работ следующего этапа не был бы готов. К примеру: чтобы разработчики серверной части смогли приступить к созданию API, им нужно понимать, какой функционал предполагают спроектировать дизайнеры. Если не распределить время специалистов оптимально, то есть риск, что работа не будет сделана в срок.
Мы стремились выстроить «поток» внутри спринта. Главная задача — сделать процесс работы понятным каждому члену подкоманды и минимизировать простои. Все должны понимать свою зону ответственности и моменты, когда и что нужно предоставить.
Параллельно с разработкой мы стали собирать спринт-пульс. Начали со встреч с ведущими специалистами по каждому направлению и с product-owner со стороны заказчика. Зафиксировали основные этапы работы и определили, что необходимо каждой подкоманде, чтобы стартовать свою часть процесса. Например, функциональные требования от аналитика — это основа работы разработчиков. Если тут случится задержка, то и весь проект «съедет» по сроку.
Дополнительно проговорили с заказчиком важные моменты, которые могли влиять на спринт-пульс. Один из таких моментов — параметр time-to-market (время вывода на рынок) в 1 месяц и получение инкремента (прирост функциональности) раз в 2 недели.
Собрав информацию, мы нашли и зафиксировали зависимости: что и после чего идёт, а также — в какой промежуток времени должно быть сделано. Всё это и стало рабочим процессом.
Самые первые зарисовки
Во время сбора спринт-пульса, важно минимизировать моменты, где могут быть простои. Например, в нашем случае стоило заложить больше времени аналитика на описание методов API. Так как на основе этой информации, готовят требования для команды front-end разработчиков, нужно было быть готовыми к увеличению срока.
Первые версии вариантов связей внутри спринта были в физическом варианте: наброски на бумаге, стикеры — всё шло в ход!
Последний этап — интегрировать спринт-пульс в сам спринт.
Размышления, как разбить инструмент на спринты
У нас получилось собрать оптимальный для себя вариант спринт-пульса: он учитывал все зависимости и контрольные точки для предоставления результата другой команде.
Спринт-пульс со стикеров и листов бумаги мы пересобрали в Miro. Можно использовать любую другую программу (и на физических носителях, если удобно). Главное, чтобы все участники спринта могли в любое время посмотреть на схему — синхронизироваться по времени, задачам и связям с другими подкомандами.
Спринт-пульс для нашего проекта
Как собрать спринт-пульс
Чтобы сделать спринт-пульс для своей команды, нужно ответить на 6 вопросов. Это поможет собрать информацию, из которой можно выявить зависимости и блокеры. Затем их нужно разложить на тайминг каждого спринта.
1) Что и кто делает?
В начале нужно определить направление работы: что делаем, кто делает, какая цель, что считаем за результат и т.д.
2) Какие будут активности?
Находим все активности, которые затрагивают каждую из подкоманд. Прописываем их этапы от начала и до конца спринта.
3) Какие вехи спринта?
Определяем вехи (контрольные точки) в спринте каждой подкоманды. Они обозначают завершение работ над задачей в рамках спринта.
4) Какие есть связи внутри команды?
Определяем время на производство всех «зависимых» артефактов, нужных для работы других команд (например, макеты дизайнеров для разработчиков). Находим все взаимозависимости. Затем соединяем их и раскладываем на таймлайне спринта.
5) Где могут быть простои?
Выявляем простои — моменты, которые могут сказаться на скорости и достижении целей спринта. Также находим задачи, которыми можно занять подкоманды во время вынужденных простоев. Но не просто, чтобы специалисты что-то делали — эти задачи должны помочь другой команде работать эффективнее в будущем.
Например, у нас первый день спринта посвящен планированию и оценкам, поэтому для нас таким мероприятием стал «чистый день» команды дизайна, в который они могли навести порядок в макетах и актуализировать карту экранов.
6) Когда командам нужно синхронизироваться?
Здесь нужно понять, на каких контрольных точках будет синхронизироваться команда. Все эти моменты фиксируем: какой результат, в каком объеме и к какому сроку должен быть готов. Обозначить это нужно для всех подкоманд.
Для того, чтобы дизайнеры могли выдавать реализуемый результат для разработчиков, при завершении проектирования сценария в wireframes, мы собирались всей командой для презентации наработок и сбора обратной связи по техническим ограничениям.
Важно понимать, что на протяжении какого-то времени спринт-пульс будет «притираться» к реальностям проекта. Но, даже несмотря на это, стартовать получится всё равно быстрее, чем без него.
Чтобы собрать спринт-пульс для своей команды, можно использовать вот такой шаблон. Основные моменты тут указаны, но что-то можно и нужно адаптировать под свой проект.
Разглядеть поближе и скачать можно здесь
Когда спринт-пульс нужен, а когда нет
Есть случаи, когда спринт-пульс — лишнее, но иногда он будет просто незаменим.
Эта табличка — подсказка: если количество «да» больше, чем «нет», то, возможно, вам стоит использовать этот инструмент.
Мини-тест на «спринт-пульсность» ситуации
Проблемы, которые может решить спринт-пульс
Тут несколько ситуаций, с которыми нам помогает справляться инструмент. Это именно наш опыт и, конечно же, это не весь список. У каждого пользователя спринт-пульса он может быть свой.
Долгий старт проекта
По правилам Scrum, команда сама должна выстроить работу внутри спринта, опираясь на его мероприятия. Но первая проблема — члены команды обладают разным уровнем коммуникации и организованности. Вторая — чтобы наладить коммуникацию и процессы, командам нужно провести серию встреч и потратить на это много времени.
Решение: спринт-пульс — стартовый кит, который ускорит работу. Сформировав его до начала производства (до момента, когда командам будут даны задачи), можно быстро и слаженно стартовать.
Блокеры в процессе работы
Во время работы специалисты сфокусированы на выполнении своих задач. Они могут не осознавать риски и связи с другими специалистами. Без фиксированного плана внутри спринта, команде сложно увидеть всю картину целиком. Как следствие, появляются блокеры: следующие специалисты в цепочке не могут приступить к работе. Результат такого «снежного кома» — недостижение целей спринта, а в крайних случаях — провал проекта.
Пример: яркий пример — тестирование мобильного приложения для банка. Если в него не заложить время на тестирование и стабилизацию, то к концу спринта будет кодовая база, но времени на поиск дефектов не останется. А без этого нельзя назвать разработанный код «законченным инкрементом». Отдать такой продукт клиентам банка не получится: помимо того, что он будет работать со сбоями, это может привести к проблемам для банка. Например, может случиться утечка персональных данных, взлом аккаунтов, кража денежных средств и прочее.
Решение: на протяжении всей работы команда видит единый спринт-пульс. Каждый знает, кто и что от него ждёт в конкретный день спринта, и выстраивает свою работу, исходя из этих зависимостей. Помимо этого, спринт-пульс — своего рода «контракт» между подкомандами. И если артефакты не были предоставлены в срок, то у специалиста есть полное право эскалировать проблему, ведь все ключевые сроки зафиксированы в спринт-пульсе.
Погружение нового специалиста в проект
Обычно на онбординг специалиста уходит достаточно большое количество времени. Чтобы начать работать в полную мощь, ему нужно понять, что происходит и погрузиться в процессы.
Пример: к проекту подключается ещё один дизайнер. Ему рассказывают про проект и задачи: общекомандные, а также задачи непосредственно его подкоманды. Затем ему нужно пообщаться с другими дизайнерами и разработчиками. Важно узнать все тонкости, к примеру, когда он может привлечь разработчиков для оценки технической сложности спроектированной им реализации. Это занимает время и отвлекает команду от задач, что в целом снижает её эффективность.
Решение: Подготовленный для проекта спринт-пульс существенно упрощает и ускоряет процесс погружения специалиста. В нём уже наглядно показаны зависимости в команде — кому, в какой момент и что необходимо предоставить. С его помощью можно быстрее и эффективнее встраивать в проект новых специалистов.
Вывод
Эффективный процесс получается настроить, если каждый сотрудник понимает что, когда и зачем он делает. Для этого команду нужно синхронизировать и спринт-пульс хорошо справляется с этой задачей. Это только дополнительный инструмент для scrum-команд, но точно полезный. Он позволяет быстро наладить производственный процесс и обозначить зону ответственности для каждого. Спринт-пульс поможет двигаться в тайминге спринта, а вовремя завершенные спринты, в свою очередь, гарантируют готовый продукт к сроку.
