Привет, Хабр! Сегодня мы расскажем о том, как разные команды в JetBrains “готовят” Agile и работают с Agile досками.
За продуктами JetBrains стоит множество команд: продуктовые, команды маркетинга, технической документации, дизайна и многие другие. Каждая команда придерживается собственного процесса, в зависимости от целей, ресурсов и особенности самой команды. На примере нашей компании и продукта YouTrack, мы расскажем о том, насколько гибкие бывают процессы, как найти подходящий для своей команды, и как настроить свою Agile доску.
Начнем с описания целей, которые ставит перед собой команда, внедряя тот или иной процесс. В нашем случае, цели можно сформулировать так:
Наша команда практикует методологию Scrum c некоторыми дополнениями. Спринты длятся две недели. Начинаем работу над спринтом с планирования, а по истечении двух недель проводим демо и ретроспективу. Планирование состоит из двух частей: общей, где присутствует вся команда, включая маркетологов, технических писателей и инженеров тех. поддержки, и технической. В рамках общей части мы обсуждаем истории, которые собираемся взять на спринт, а в технической части программисты разбивают их на подзадачи. Каждый день мы проводим стендап, на котором каждый член команды в течение минуты рассказывает, над чем работает, и поднимает вопрос для обсуждения, после чего мы смотрим на состояние задач на доске и обсуждаем возникшие вопросы.
Колонки на доске разбиты по состоянию задач: open, in progress/to be discussed и fixed. Если задача находится в прогрессе более чем три дня, мы разбиваем ее на подзадачи. Мы ввели это правило, чтобы разработчик не “зависал” на задаче и двигался дальше. Ежедневно мы получаем запросы в тех. поддержку. Чтобы мониторить прогресс по тем, которые требуют внимания разработчиков, на доске есть отдельный swimlane для запросов от пользователей.
Планирование задач мы ведем в бэклоге. В YouTrack бэклог — это сохраненный поиск, который можно открыть прямо на доске и приоритизировать задачи вручную. Благодаря тому, что вся команда активно вовлечена в процесс и следит за состоянием задач на доске, нам удается их правильно приоритезировать, оперативно решать проблемы пользователей, чинить важные баги и разрабатывать новую функциональность. Переход на цикл постоянных релизов позволил нам получать фидбэк от внутренних и внешних пользователей на самом раннем этапе (в рамках экспериментальной функциональности) и вносить нужные изменения на этапе разработки, а не после релиза.
Речь идет о команде дизайна, которая обеспечивает визуальное представление всех наших продуктов на рынке, начиная с сайта, маркетинговых материалов, и заканчивая печатными материалами. UI/UX дизайнеры входят в продуктовые команды и являются частью их процессов.
В основном дизайнеры получают задания от коллег (PMM) из продуктовых команд, которым нужен дизайн чего-то, желательно вчера. При таком процессе важно отслеживать поступление новых задач и равномерно распределять их внутри команды.
Цели:
Спринты на доске соответствуют сезонам: зима, весна, лето, осень. Все новые созданные задачи автоматически попадают на доску на текущий спринт. Задачи объединяются в свимлэйны по членам команды. Назначать исполнителя на задачу может только руководитель команды. Это правило реализуется при помощи custom workflow. Таким образом, новая задача сначала попадает в свимлейн uncategorized, а “переплывает” в свимлейн определенного дизайнера, как только его назначили исполнителем.
Каждый дизайнер работает в рамках своего свимлэйна, а руководитель, окинув взглядом доску, оценивает загруженность каждого сотрудника и равномерно распределяет задачи. Благодаря такому процессу задачи не задерживаются в состоянии open и завершаются в срок, а каждый заказчик может легко отследить место своей задачи в очереди дизайнера.
Маркетологи в JetBrains взаимодействуют с множеством коллег из разных команд. Чтобы следить за исполнением своих задач, необходимо держать около 20 проектов на доске: маркетинг, дизайн, локализация, веб, аналитика, интернет-маркетинг и так далее.
Цели:
Маркетинговая доска представляет собой набор задач из 20 проектов, объединенных в свимлейны по разным активностям. Например, релиз продукта, рекламная кампания, исследование, серия блог постов или видео, и т. д. В качестве колонок мы используем значения поля Состояние из разных проектов. Поскольку набор состояний может отличаться от проекта к проекту, добавить на доску нужно все значения, которые важно отслеживать, а затем объединить несколько состояний в одну колонку. Таким образом у нас на доске 5 колонок. Свимлейны мы определяем по типу задачи. Каждая задача типа Epic или Feature образует свимлейн. Задачи, которые не относятся к крупной активности, попадают в нижнюю часть доски (uncategorized cards).
Когда коллеги из других проектов начинают работать над нашей задачей, они меняют ее состояние, задача перемещается по доске и мы следим за ее прогрессом. Если необходима обратная связь или задача выполнена и ждет проверки с нашей стороны, ее переводят в состояние in review. Таким образом работа над задачами становится более продуктивной и мы лишний раз не “дергаем” коллег. Для нас же ключевым моментом является визуализация наших активностей: в каждый момент времени наглядно видно, что сделано, а что осталось для завершения каждой активности. Например, глядя на свимлейн с рекламной кампанией, я сразу могу сказать, что нам не хватает только баннеров для запуска.
Эти команды придерживаются методологии Kanban. Их процессы очень похожи между собой, потому что во многом их задачи пересекаются и работают над ними одни и те же сотрудники.
Цели:
Команды работают с Kanban доской без спринтов. Однако задачи объединены в свимлейны по приоритету задач (general и priority). Колонки отражают этапы разработки. Планирование задач ведется в бэклоге, а их приоритет обсуждается на ежедневных стендапах. В каждой колонке заданы ограничения на WIP (количество задач в колонке). Это помогает команде контролировать нагрузку на каждом этапе и визуализировать проблемы с нагрузкой на каждом шаге. Если количество задач превышает допустимое значение, команда не начинает работу над новыми задачами, пока не справится с текущей нагрузкой.
Чтобы автоматизировать процесс, команды используют набор custom workflow. Например, если разработчик перетащил задачу из бэклога на доску, он автоматически назначается исполнителем задачи. Если задача переходит в колонку QA, то она автоматически назначается на QA-инженера.
Цели:
Андрею, как и остальным нашим PMM, необходимо следить за задачами во многих проектах, чтобы координировать различные активности для продвижения IntelliJ IDEA.
Задачи на доске объединены в свимлейны по проектам. Колонок на доске нет, точнее все состояния задачи объединены в одну колонку. Настроить доску таким образом можно, выбрав шаблон “Персональная доска”.
Андрей также использует расширение для Chrome “YouTrack Tweaks”, которое позволяет добавлять на карточку поля и раскрашивать их в разные цвета. Расширение также позволяет использовать доску в режиме Darcula. Карточки не перемещаются по доске, а просто присутствуют на ней до тех пор, пока задача не выполнена. Выполненные задачи просто пропадают с доски. Такой процесс позволяет сконцентрировать на открытых задачах и отслеживать прогресс по своим задачам в разных проектах.
Итак, каких же правил нужно придерживаться, чтобы наладить процесс в своей команде? Что общего между всеми этими примерами?
И помните: продукт, который вы выбираете для управления задачами, должен быть гибким настолько, чтобы подстроиться под ваш процесс.
Если тема вас заинтересовала, то вы можете прочитать всю серию статей или посмотреть видео с подробной инструкцией по настройке досок в нашем блоге.
Ваша команда YouTrack JetBrains
The Drive to Develop
За продуктами JetBrains стоит множество команд: продуктовые, команды маркетинга, технической документации, дизайна и многие другие. Каждая команда придерживается собственного процесса, в зависимости от целей, ресурсов и особенности самой команды. На примере нашей компании и продукта YouTrack, мы расскажем о том, насколько гибкие бывают процессы, как найти подходящий для своей команды, и как настроить свою Agile доску.
Как “готовит” Scrum Команда YouTrack
Начнем с описания целей, которые ставит перед собой команда, внедряя тот или иной процесс. В нашем случае, цели можно сформулировать так:
- Перейти на цикл постоянных релизов: мажорный релиз каждые 2-3 месяца.
- Ускорить процесс разработки.
- Улучшить качество кода (в рамках постоянных релизов).
- Вовлечь в процесс всех участников команды.
Наша команда практикует методологию Scrum c некоторыми дополнениями. Спринты длятся две недели. Начинаем работу над спринтом с планирования, а по истечении двух недель проводим демо и ретроспективу. Планирование состоит из двух частей: общей, где присутствует вся команда, включая маркетологов, технических писателей и инженеров тех. поддержки, и технической. В рамках общей части мы обсуждаем истории, которые собираемся взять на спринт, а в технической части программисты разбивают их на подзадачи. Каждый день мы проводим стендап, на котором каждый член команды в течение минуты рассказывает, над чем работает, и поднимает вопрос для обсуждения, после чего мы смотрим на состояние задач на доске и обсуждаем возникшие вопросы.
Колонки на доске разбиты по состоянию задач: open, in progress/to be discussed и fixed. Если задача находится в прогрессе более чем три дня, мы разбиваем ее на подзадачи. Мы ввели это правило, чтобы разработчик не “зависал” на задаче и двигался дальше. Ежедневно мы получаем запросы в тех. поддержку. Чтобы мониторить прогресс по тем, которые требуют внимания разработчиков, на доске есть отдельный swimlane для запросов от пользователей.
Планирование задач мы ведем в бэклоге. В YouTrack бэклог — это сохраненный поиск, который можно открыть прямо на доске и приоритизировать задачи вручную. Благодаря тому, что вся команда активно вовлечена в процесс и следит за состоянием задач на доске, нам удается их правильно приоритезировать, оперативно решать проблемы пользователей, чинить важные баги и разрабатывать новую функциональность. Переход на цикл постоянных релизов позволил нам получать фидбэк от внутренних и внешних пользователей на самом раннем этапе (в рамках экспериментальной функциональности) и вносить нужные изменения на этапе разработки, а не после релиза.
Как команда дизайна создает материалы для 23 продуктов
Речь идет о команде дизайна, которая обеспечивает визуальное представление всех наших продуктов на рынке, начиная с сайта, маркетинговых материалов, и заканчивая печатными материалами. UI/UX дизайнеры входят в продуктовые команды и являются частью их процессов.
В основном дизайнеры получают задания от коллег (PMM) из продуктовых команд, которым нужен дизайн чего-то, желательно вчера. При таком процессе важно отслеживать поступление новых задач и равномерно распределять их внутри команды.
Цели:
- Взаимодействовать со всеми продуктовыми командами.
- Равномерно распределять задачи.
- Следить за поступлением новых задач.
- Приоритезировать задачи в зависимости от срока исполнения.
Спринты на доске соответствуют сезонам: зима, весна, лето, осень. Все новые созданные задачи автоматически попадают на доску на текущий спринт. Задачи объединяются в свимлэйны по членам команды. Назначать исполнителя на задачу может только руководитель команды. Это правило реализуется при помощи custom workflow. Таким образом, новая задача сначала попадает в свимлейн uncategorized, а “переплывает” в свимлейн определенного дизайнера, как только его назначили исполнителем.
Каждый дизайнер работает в рамках своего свимлэйна, а руководитель, окинув взглядом доску, оценивает загруженность каждого сотрудника и равномерно распределяет задачи. Благодаря такому процессу задачи не задерживаются в состоянии open и завершаются в срок, а каждый заказчик может легко отследить место своей задачи в очереди дизайнера.
Как работают продуктовые менеджеры по маркетингу YouTrack и Hub
Маркетологи в JetBrains взаимодействуют с множеством коллег из разных команд. Чтобы следить за исполнением своих задач, необходимо держать около 20 проектов на доске: маркетинг, дизайн, локализация, веб, аналитика, интернет-маркетинг и так далее.
Цели:
- Следить за своими задачами в разных проектах.
- Вовремя давать обратную связь исполнителям.
- Приоритезировать задачи в зависимости от дедлайна.
Маркетинговая доска представляет собой набор задач из 20 проектов, объединенных в свимлейны по разным активностям. Например, релиз продукта, рекламная кампания, исследование, серия блог постов или видео, и т. д. В качестве колонок мы используем значения поля Состояние из разных проектов. Поскольку набор состояний может отличаться от проекта к проекту, добавить на доску нужно все значения, которые важно отслеживать, а затем объединить несколько состояний в одну колонку. Таким образом у нас на доске 5 колонок. Свимлейны мы определяем по типу задачи. Каждая задача типа Epic или Feature образует свимлейн. Задачи, которые не относятся к крупной активности, попадают в нижнюю часть доски (uncategorized cards).
Когда коллеги из других проектов начинают работать над нашей задачей, они меняют ее состояние, задача перемещается по доске и мы следим за ее прогрессом. Если необходима обратная связь или задача выполнена и ждет проверки с нашей стороны, ее переводят в состояние in review. Таким образом работа над задачами становится более продуктивной и мы лишний раз не “дергаем” коллег. Для нас же ключевым моментом является визуализация наших активностей: в каждый момент времени наглядно видно, что сделано, а что осталось для завершения каждой активности. Например, глядя на свимлейн с рекламной кампанией, я сразу могу сказать, что нам не хватает только баннеров для запуска.
Как готовят Kanban Команды CLion и AppCode
Эти команды придерживаются методологии Kanban. Их процессы очень похожи между собой, потому что во многом их задачи пересекаются и работают над ними одни и те же сотрудники.
Цели:
- Планировать задачи в условия частых релизов (3 раза в год).
- Вовлечь в процесс всех членов команды.
- Управлять нагрузкой на команду на всех стадиях разработки.
- Визуально приоритезировать задачи.
Команды работают с Kanban доской без спринтов. Однако задачи объединены в свимлейны по приоритету задач (general и priority). Колонки отражают этапы разработки. Планирование задач ведется в бэклоге, а их приоритет обсуждается на ежедневных стендапах. В каждой колонке заданы ограничения на WIP (количество задач в колонке). Это помогает команде контролировать нагрузку на каждом этапе и визуализировать проблемы с нагрузкой на каждом шаге. Если количество задач превышает допустимое значение, команда не начинает работу над новыми задачами, пока не справится с текущей нагрузкой.
Чтобы автоматизировать процесс, команды используют набор custom workflow. Например, если разработчик перетащил задачу из бэклога на доску, он автоматически назначается исполнителем задачи. Если задача переходит в колонку QA, то она автоматически назначается на QA-инженера.
Персональная доска продуктового менеджера по маркетингу IntelliJ IDEA
Цели:
- Взаимодействовать с различными командами.
- Следить за своими маркетинговыми активностями.
- Управлять собственными задачами.
Андрею, как и остальным нашим PMM, необходимо следить за задачами во многих проектах, чтобы координировать различные активности для продвижения IntelliJ IDEA.
Задачи на доске объединены в свимлейны по проектам. Колонок на доске нет, точнее все состояния задачи объединены в одну колонку. Настроить доску таким образом можно, выбрав шаблон “Персональная доска”.
Андрей также использует расширение для Chrome “YouTrack Tweaks”, которое позволяет добавлять на карточку поля и раскрашивать их в разные цвета. Расширение также позволяет использовать доску в режиме Darcula. Карточки не перемещаются по доске, а просто присутствуют на ней до тех пор, пока задача не выполнена. Выполненные задачи просто пропадают с доски. Такой процесс позволяет сконцентрировать на открытых задачах и отслеживать прогресс по своим задачам в разных проектах.
Итак, каких же правил нужно придерживаться, чтобы наладить процесс в своей команде? Что общего между всеми этими примерами?
- Agile — это игра, а мы все любим играть. В этой игре важно установить правила и обязательно их соблюдать.
- Agile вовлекает каждого члена команды, дает возможность влиять на принятие решений и совершенствовать процесс. Участие в принятии решений накладывает ответственность за решение, в той или иной степени. Это заставляет серьезнее относиться к своей работе и работе команды в целом.
- Каждый участник Agile команды способен самоорганизовываться.
- Agile процесс очень динамичен, его нельзя зафиксировать, и необходимо постоянно улучшать.
И помните: продукт, который вы выбираете для управления задачами, должен быть гибким настолько, чтобы подстроиться под ваш процесс.
Если тема вас заинтересовала, то вы можете прочитать всю серию статей или посмотреть видео с подробной инструкцией по настройке досок в нашем блоге.
Ваша команда YouTrack JetBrains
The Drive to Develop
Поделиться с друзьями