Categories: Кейсы

Как организовать работу команды: опыт внедрения Scrum в Carrot Quest

Чем сложнее продукт, тем тщательнее нужно организовывать работу разработчиков. Мы используем для этого адаптированную под собственные реалии методику scrum — одного из подходов Agile. Расскажем про особенности внедрения scrum в нашей команде.

Суббота

Мы заканчиваем и начинаем с субботы — планируем спринт на следующую неделю. Рабочая неделя у нас пятидневная, а в субботу собираются самые заряженные члены команды, включая скрам-мастера, дизайнера, product owner. Планирование обычно занимает 2–3 часа: собираем незаконченные или старые задачи в спринт, добавляем новые, расставляем приоритеты.

Спринт в работе

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

Понедельник

В понедельник происходят два события.

Демо

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

Планерка

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

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

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

Расставляя время на спринты, мы не берем за основу 100% доступного времени, так как случаются непредвиденные ситуации. Это тоже надо включать в план, и мы это делаем: добавляем разработчику «Внезапную задачу», которая у скрам-мастера может занимать, например, 12 часов.

Вторник–пятница

Каждый день со вторника по пятницу начинается с 10-минутных стендапов, во время которых каждый рассказывает следующее:

  1. Задачи и успехи за вчерашний день;
  2. План на сегодня;
  3. Сколько времени осталось на спринт и причины, из-за которых он может не успеть.

Эти 10 минут помогают уменьшить риск незавершения спринта, потому что коллега может помочь решить проблему. Кроме того, случается, что в ходе стендапа по инициативе команды (и это важно!) меняются приоритеты заданий в планировании итерации.

Подписывайтесь на рассылку

Получайте кейсы и полезные статьи о маркетинге и росте продукта раз в неделю

Спасибо!

Рыбный четверг

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

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

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

Все сотрудники нашей компании — первые пользователи Carrot Quest. Поэтому самый быстрый способ узнать мнение пользователей сервиса — получить фидбэк от собственной команды.

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

Пятница

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

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

Завершаем ли мы спринты вовремя?

Нет. Мы тратим 3–4 часа в неделю на планирование, синхронизацию и другие процессы в рамках подхода, основанного на agile, и всё равно не завершаем все спринты в отведенное время. Такова жизнь.

Чтобы приблизиться к идеалу, нужно еще много работать:

  • точнее определять трудозатраты на задачу, в будущем попробовать сторипоинты;
  • как можно раньше показывать дизайн разработчикам, чтобы они успели продумать реализацию и задать вопросы;
  • объединить спринты разных команд одной общей целью — это сложно: у каждой команды своя задача и эти задачи часто не пересекаются;
  • анализировать причины, почему факапим спринты, — выделить самые частые и найти возможность их устранить.

Тем не менее методология scrum делает нашу работу предсказуемой. Риски находятся у нас под контролем, если и происходят факапы (без них никуда), то значительно реже, чем раньше.