- PVSM.RU - https://www.pvsm.ru -
Чистый скрам — как единорог на музыкальном фестивале: вроде бы он существует, все о нём говорят, только вот показать тебе его никто не может. Так же сложилось и у нас в команде, об этом и поговорим. А если конкретнее — о том, как мы сократили время на встречи и не потеряли пользу от них.
Ясное дело, в Интернете полно статей о том, кто и как этот скрам у себя взращивал, что получилось, а что нет. Я не претендую на уникальность и всего не читал, ибо писателей таких статей гораздо больше, чем у меня свободного времени. Однако хочу рассказать, как мы в команде Android-разработки выстроили (и еще строим) процесс, практически не тратя время на встречи и обсуждения. Получилось так именно потому, что моё время (я PO) и время команды сильно ограничено, и я стремлюсь сделать всё, чтобы не заниматься процессами ради процессов и при этом сохранять производительность и прозрачность на высоком уровне.
Дам небольшое представление о себе, чтобы у читателя начал складываться портрет человека, от чьего лица идет повествование.
Я — продуктовый менеджер Android-команды в компании Wrike. Кроме этого мне выпала почётная роль скрам-мастра.
Мы — satellite app, а большая часть наших клиентов выполняет работу в офисе и использует web-версию продукта. Ключевых релизов у нас около 3-х в квартал, но приходится уделять много времени на поддержку улучшений из web-версии. Из-за активного развития веба мы релизимся раз в две недели. Функция приложения — не терять связь с командой и следить за рабочими процессами. Настраивать окружение можно только в web-версии. Стратегия развития продукта — увеличить аудиторию и её активность на мобильных устройствах. Наша команда состоит из пяти Android-разработчиков, двух QA, одного UX-дизайнера, одного продуктового менеджера. Все ребята очень скиловые.
Теперь, когда у читателя сложилось некоторое представление о команде, я перейду к сути статьи — процессам. Сегодня речь пойдёт про такие элементы скрама, как: PBR, Retro, Planning, Daily. Моя основная цель как скрам-мастера — использовать ценность этих встреч и одновременно тратить на них минимум времени. Кроме того, что это просто логично с точки зрения оптимизации ресурсов, у нас есть еще одно ограничение: наша команда должна поддерживать изменения двадцати продуктовых команд. Мы не поддерживаем все изменения, но те, что затрагивают существующий функционал, требуют нашего участия. В статье я расскажу подробнее о том, сколько времени мы выделяем на каждый из этих четырёх ритуалов и какие плоды приносят такие временные рамки.
Подсмотрел в интернете такое определение [1]: «PBR (Product Backlog Refinement) — это процесс добавления деталей, оценок и порядка к элементам в списке невыполненных работ». По своему опыту знаю, что на таком событии часто присутствует вся команда, чтобы увидеть задачу заранее, подсветить неочевидные моменты. Но такая встреча требует много времени, а у нашей команды его нет, потому что изменений с web-версии прилетает много. Поэтому мы изменили формат встречи.
Как показала практика, есть список задач, которые могут быть очень сложными или нехарактерными, на первый взгляд, для продукта. Перед исследованием таких задач я собираю всех желающих и рассказываю суть происходящего — это у нас называется Forum. Происходит такое крайне редко, однако порядочно сплачивает команду и подогревает интерес к задаче, вызывает привыкание причастность к продукту. И растёт эта причастность именно из-за своей нерегулярности. Такое собрание становится чем-то особенным, нерутинным и потому значимым.
Разбор работы происходит следующим образом: каждая задача (story) планируется на одного человека (давайте назовём его «чемпион»), и он проводит исследование того, что конкретно нужно по ней сделать. Добавляет описание, уточняет у UX-дизайнера, как должны работать какие-то моменты, если этого не хватает в доке, советуется с бэкендом и пишет подробный план. На самом деле получается нечто вроде Spike’а [2].
Такой подход себя хорошо зарекомендовал по следующим причинам:
Отдельное внимание хочу уделить времени, которое тратится на такие исследования. Сложные задачи требуют глубинного погружения, особенно в случае с legacy. Тут, на мой взгляд, есть 3 основные стратегии:
В случае, если задачи нетривиальные, исследование часто идёт параллельно с разработкой. Обычный code discovery занимает не более дня и позволяет построить вполне точный план разработки. Я бы сказал, что из всех задач исследованию подлежат примерно 10%, остальные можно брать в работу и без этого процесса. Наш рецепт производительности — это сильные разработчики и правило, что 20% ресурсов выделяется на технические задачи. Команда лучше знает, как и куда стоит направить усилия, чтобы держать код в здоровом состоянии. Для меня это именно тот инструмент, который позволяет двигаться быстро с продуктовыми задачами, держать разработчиков довольными, планировать чётко и успевать в сроки. Это развивает инженерную культуру и поддерживает мотивацию ребят в команде.
Тут я хвастаться не буду, просто скажу, что в команде есть правило: вместе с проблемой предлагай решение. Ребята в команде ответственные, хотят работать хорошо и не отвлекаться на неприятные мелочи, поэтому они заинтересованы, чтобы процессы были понятные и надёжные.
Позвольте мне привести пример задачи (проблемы), что встала перед нами на Retro — забываем добавлять аналитику. Может показаться, что она касается скорее PM’a, чем разработчиков, но, как я сказал, ребята в команде мотивированы и хотят делать свою работу хорошо. Из-за ограниченного ресурса аналитики вести этот процесс идеально не удаётся, потому прямо на retro мы выстроили конкретный процесс и разделили обязанности между членами команды так, что каждый вносит свою пользу на определённом этапе. Также важное замечание: если за час мы не успели придумать, как решить проблему, мы соглашаемся попробовать предложенные идеи и корректировать их по ходу.
Но случаи бывают и пограничными, когда профессиональные цели несколько расходятся, и между членами команды могут появляться шероховатости, иначе говоря, инженеры больше сфокусированы на технической части, PM на продукте, а дизайнер на удобстве и графике. Но поскольку наша главная общая цель — создать хороший продукт, то мы не стесняемся обсуждать моменты на стыке интересов членов команды. И тут стоит сказать, что у нас принято быть открытым и честным. Если же в команде кто-то стесняется высказать свою точку зрения, то высока вероятность, что в команде существует неравноправие или есть скрытые конфликты. Лишь равноправие в системе позволяет быть открытым. Если интересно, как нам это удалось, дайте знать в комментариях, а пока поехали дальше.
Моя любимая часть скрама. Нравится она мне по двум причинам:
Процесс выглядит так: есть список задач, который я определяю на спринт. Каждый участник команды совместно с другими решает, в какой момент и что лучше начать делать, какими будут acceptance criteria для задачи. Члены команды сами выставляют зависимости между UX, DEV и QA. А весело это именно потому, что ребята сами договариваются, планируют приоритетные задачи в комфортном для них порядке. Они обсуждают, шутят, они действуют как команда, они сплочены в этот момент. В зависимости от своих планов/настроения они понимают, чем и когда хотят заниматься, и от этого выставляются сроки и зависимости. Получается что-то вроде Workload — планирование отталкивается не от задач, а от людей.
На первый взгляд может показаться кашей, однако из-за того, что команда сама планирует, она хорошо разбирается в происходящем и оперативно вносит изменения
В первую очередь, это про синхронизацию, но хочу отдельно подчеркнуть мою роль как продакт-менеджера в этом событии. Я уже говорил о том, что в команде важно равноправие. Климат должен быть такой, чтобы ребята чувствовали себя командой, а не индивидуальными контрибьюторами. Потому, будучи продакт-менеджером, я рассказываю новости компании, а также чем я занимался, что узнал и что меня ждёт. Перед командой секретов у меня нет, хотя крайне редко возникают исключения: некоторые вещи нас просят придержать до официального анонса. Но такие анонсы — это прям что-то из ряда вон выходящее.
Spike на 1 день + редкие встречи в формате Forum для введения в курс дела ребят по необычным задачам дают хорошее понимание о том, какая работа нам предстоит. Планирование занимает всего час и проходит в свободной форме, все люди прекрасно договариваются о том, что им нужно делать. Retro проходит всегда в одном формате, но очень продуктивно, и мелочи в процессах обтачиваются регулярно. А открытость продакт-менеджера в дейли формирует в команде равноправие и доверие.
Для меня, в конечном счёте, лишь три показателя имеют смысл: уровень удовлетворённости команды, чтобы ребята не выгорели, качество продукта и скорость исполнения задач.
И эти показатели в нашей команде довольно высоки:
Немного математики. За двухнедельный спринт получается:
Итого: 4ч 30мин ± 2 часа из 80 часов в двухнедельном спринте.
Ясное дело, что это число стоит умножить на количество людей в команде, чтобы понять, во сколько человеко-часов вам обходятся скрам ивенты. Мой показатель — 5.6% ±2.5% при размере команды в 9 человек. Чем больше будет команда, тем выше будет расти это значение. Но давайте не забывать, что скрам-команда имеет рекомендуемые размеры, а значит и показатель времени, которое тратится на командные события, тоже имеет разумный предел.
В общем-то, пока всё. Будет идеально, если поделитесь цифрами: сколько времени занимают скрам ивенты у вас. Ну и чтобы сделать статью более ценной, давайте обсудим пользу и вред, который, по вашему мнению, могут принести такие оптимизации.
Автор: Евгений Рубилов
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/scrum/348793
Ссылки в тексте:
[1] определение: https://www.scrum.org/resources/blog/scrum-trenches-product-backlog-refinement-scrum-team-responsibility
[2] Spike’а: https://www.visual-paradigm.com/scrum/what-is-scrum-spike/
[3] Источник: https://habr.com/ru/post/491332/?utm_source=habrahabr&utm_medium=rss&utm_campaign=491332
Нажмите здесь для печати.