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

Ясное дело, в Интернете полно статей о том, кто и как этот скрам у себя взращивал, что получилось, а что нет. Я не претендую на уникальность и всего не читал, ибо писателей таких статей гораздо больше, чем у меня свободного времени. Однако хочу рассказать, как мы в команде Android-разработки выстроили (и еще строим) процесс, практически не тратя время на встречи и обсуждения. Получилось так именно потому, что моё время (я PO) и время команды сильно ограничено, и я стремлюсь сделать всё, чтобы не заниматься процессами ради процессов и при этом сохранять производительность и прозрачность на высоком уровне.

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

Я — продуктовый менеджер Android-команды в компании Wrike. Кроме этого мне выпала почётная роль скрам-мастра.

Мы — satellite app, а большая часть наших клиентов выполняет работу в офисе и использует web-версию продукта. Ключевых релизов у нас около 3-х в квартал, но приходится уделять много времени на поддержку улучшений из web-версии. Из-за активного развития веба мы релизимся раз в две недели. Функция приложения — не терять связь с командой и следить за рабочими процессами. Настраивать окружение можно только в web-версии. Стратегия развития продукта — увеличить аудиторию и её активность на мобильных устройствах. Наша команда состоит из пяти Android-разработчиков, двух QA, одного UX-дизайнера, одного продуктового менеджера. Все ребята очень скиловые.

Теперь, когда у читателя сложилось некоторое представление о команде, я перейду к сути статьи — процессам. Сегодня речь пойдёт про такие элементы скрама, как: PBR, Retro, Planning, Daily. Моя основная цель как скрам-мастера — использовать ценность этих встреч и одновременно тратить на них минимум времени. Кроме того, что это просто логично с точки зрения оптимизации ресурсов, у нас есть еще одно ограничение: наша команда должна поддерживать изменения двадцати продуктовых команд. Мы не поддерживаем все изменения, но те, что затрагивают существующий функционал, требуют нашего участия. В статье я расскажу подробнее о том, сколько времени мы выделяем на каждый из этих четырёх ритуалов и какие плоды приносят такие временные рамки.

PBR

Подсмотрел в интернете такое определение: «PBR (Product Backlog Refinement) — это процесс добавления деталей, оценок и порядка к элементам в списке невыполненных работ». По своему опыту знаю, что на таком событии часто присутствует вся команда, чтобы увидеть задачу заранее, подсветить неочевидные моменты. Но такая встреча требует много времени, а у нашей команды его нет, потому что изменений с web-версии прилетает много. Поэтому мы изменили формат встречи.

Как показала практика, есть список задач, которые могут быть очень сложными или нехарактерными, на первый взгляд, для продукта. Перед исследованием таких задач я собираю всех желающих и рассказываю суть происходящего — это у нас называется Forum. Происходит такое крайне редко, однако порядочно сплачивает команду и подогревает интерес к задаче, вызывает привыкание причастность к продукту. И растёт эта причастность именно из-за своей нерегулярности. Такое собрание становится чем-то особенным, нерутинным и потому значимым.

Разбор работы происходит следующим образом: каждая задача (story) планируется на одного человека (давайте назовём его «чемпион»), и он проводит исследование того, что конкретно нужно по ней сделать. Добавляет описание, уточняет у UX-дизайнера, как должны работать какие-то моменты, если этого не хватает в доке, советуется с бэкендом и пишет подробный план. На самом деле получается нечто вроде Spike’а.

Такой подход себя хорошо зарекомендовал по следующим причинам:

• Продолжительное время работы над задачей позволяет глубже понять её суть. Глубокое понимание задачи ведёт к тому, что чемпион может найти ошибки, допущенные во время проектирования. И я сейчас не только про код, но и про саму идею. Своего рода проверка решения на органичность.
• Для себя я отметил, что растёт мотивация команды (графиков роста счастья нет, простите) и желание довести задачу до продакшена.
• Если мотивация чемпиона высокая, и он разобрался в сути задачи, то у него рождаются предложения, которые позволяют сократить стоимость разработки, наполняется бэклог технических задач, появляются предложения по UX. Последние могут сэкономить много времени программиста.

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

1. «На месте разберёмся» — обычно конца такой задачи не видно до момента, когда она почти завершена.
2. «Давайте перестрахуемся и заложим побольше времени» — тут я приверженец поговорки: «Работа делается столько времени, сколько на неё выделяется». От себя добавлю, что при таком подходе она не будет закончена вовремя.
3. «Разведка боем» — дойдя до заранее определённой точки, мы решаем, как будем действовать дальше.

В случае, если задачи нетривиальные, исследование часто идёт параллельно с разработкой. Обычный code discovery занимает не более дня и позволяет построить вполне точный план разработки. Я бы сказал, что из всех задач исследованию подлежат примерно 10%, остальные можно брать в работу и без этого процесса. Наш рецепт производительности — это сильные разработчики и правило, что 20% ресурсов выделяется на технические задачи. Команда лучше знает, как и куда стоит направить усилия, чтобы держать код в здоровом состоянии. Для меня это именно тот инструмент, который позволяет двигаться быстро с продуктовыми задачами, держать разработчиков довольными, планировать чётко и успевать в сроки. Это развивает инженерную культуру и поддерживает мотивацию ребят в команде.

Retro

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

Позвольте мне привести пример задачи (проблемы), что встала перед нами на Retro — забываем добавлять аналитику. Может показаться, что она касается скорее PM’a, чем разработчиков, но, как я сказал, ребята в команде мотивированы и хотят делать свою работу хорошо. Из-за ограниченного ресурса аналитики вести этот процесс идеально не удаётся, потому прямо на retro мы выстроили конкретный процесс и разделили обязанности между членами команды так, что каждый вносит свою пользу на определённом этапе. Также важное замечание: если за час мы не успели придумать, как решить проблему, мы соглашаемся попробовать предложенные идеи и корректировать их по ходу.

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

Planning

Моя любимая часть скрама. Нравится она мне по двум причинам:

1. это весело;
2. это практически не требует моего участия.

Процесс выглядит так: есть список задач, который я определяю на спринт. Каждый участник команды совместно с другими решает, в какой момент и что лучше начать делать, какими будут acceptance criteria для задачи. Члены команды сами выставляют зависимости между UX, DEV и QA. А весело это именно потому, что ребята сами договариваются, планируют приоритетные задачи в комфортном для них порядке. Они обсуждают, шутят, они действуют как команда, они сплочены в этот момент. В зависимости от своих планов/настроения они понимают, чем и когда хотят заниматься, и от этого выставляются сроки и зависимости. Получается что-то вроде Workload — планирование отталкивается не от задач, а от людей.


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

Daily

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

Итог

Spike на 1 день + редкие встречи в формате Forum для введения в курс дела ребят по необычным задачам дают хорошее понимание о том, какая работа нам предстоит. Планирование занимает всего час и проходит в свободной форме, все люди прекрасно договариваются о том, что им нужно делать. Retro проходит всегда в одном формате, но очень продуктивно, и мелочи в процессах обтачиваются регулярно. А открытость продакт-менеджера в дейли формирует в команде равноправие и доверие.

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

И эти показатели в нашей команде довольно высоки:

• Качество: 2-3 бага после релиза (а релизы у нас крупные);
• Скорость: наша команда в пять разработчиков, два QA и одного UX поддерживает изменения, которые создают двадцать web-команд;
• Удовлетворённость: за пять лет моей работы в Wrike из компании ушел один разработчик и один QA.

Icing on the cake

Немного математики. За двухнедельный спринт получается:

• 10 Daily по 15 минут;
• ± 2 Forum’а по часу;
• Planning 1 час;
• Retro 1 час.

Итого: 4ч 30мин ± 2 часа из 80 часов в двухнедельном спринте.

Ясное дело, что это число стоит умножить на количество людей в команде, чтобы понять, во сколько человеко-часов вам обходятся скрам ивенты. Мой показатель — 5.6% ±2.5% при размере команды в 9 человек. Чем больше будет команда, тем выше будет расти это значение. Но давайте не забывать, что скрам-команда имеет рекомендуемые размеры, а значит и показатель времени, которое тратится на командные события, тоже имеет разумный предел.

В общем-то, пока всё. Будет идеально, если поделитесь цифрами: сколько времени занимают скрам ивенты у вас. Ну и чтобы сделать статью более ценной, давайте обсудим пользу и вред, который, по вашему мнению, могут принести такие оптимизации.