Как мы создали свой подход к разработке без привязки к спринтам
Какой процесс разработки выбрать: Scrum, Kanban или же Scrumban? Команды часто задаются этим вопросом в попытках найти наиболее эффективный метод или выбрать хоть какой-нибудь принцип работы. Во многих случаях перевод процессов на одну из методик в «чистом виде» не приносит желаемого результата. Так происходит, потому что каждая команда — это уникальный живой организм, работающий с уникальным продуктом, который находится на своей уникальной стадии развития.
Мы, мобильная продуктовая команда BetterMe, задумались над тем, как сделать нашу разработку не привязанной к искусственным временным рамкам (спринтам), при этом быть эффективными (частые и полезные релизы), разрабатывать и поддерживать несколько продуктов, не раздувая штат.
BetterMe — это достаточно молодой проект украинской продуктовой компании Genesis. Мы создаем мобильные приложения в категории Health and Fitness, ориентируясь на развитые страны. За 8 месяцев существования проекта нашими продуктами воспользовались более 6 млн пользователей, и мы закрепились в ТОП-3 приложений в своей категории на рынке США.
Нам удалось создать свой подход к разработке, используя нужные элементы из Scrum, Kanban и Waterfall. В этой статье я попробую рассказать, как именно.
Структура продуктовой команды
Для лучшего понимания нашей методики разработки, опишу сначала подход к формированию структуры команды и наших продуктов:
- В рамках проекта BetterMe разрабатывается 3 продукта. На каждый продукт назначается отдельный Product Manager (PDM), который отвечает за формирование беклога, приоритизацию User stories, рост метрик и в целом за успех продукта.
- Facilitator (он же PM), в свою очередь, отвечает за построение и поддержку наших процессов на высоком уровне. Основная цель этой роли — «бесперебойное производство», которого можно достичь посредством поддержки эффективной коммуникации на разных стадиях разработки и контроля качества поступаемого материала инженерам:
- детально продуманные и прописанные User stories;
- подготовленный и выверенный дизайн;
- сформированные аналитические события и др.
- Команда инженеров, дизайнеров и тестировщиков перераспределяет свои ресурсы в зависимости от потребностей и целей BetterMe, то есть эти команды не привязаны к конкретному продукту.
Такая структура команды позволяет нам получить необходимую глубину понимания и развития благодаря отдельному Product Manager (PDM) на каждом продукте, не увеличивая при этом команду инженеров до неэффективных размеров.
Приведу пример. Как правило, для эффективной поддержки продукта каждое приложение потребовало бы по
Преимущество такого подхода заключается не только в том, что мы сохраняем компактные команды, но и в том, что он дает возможность поддержать тонус и разнообразие в разработке. Более того, такая структура подталкивает нас разрабатывать унифицированные каркасы продуктов, модули, которые легко поддерживать и масштабировать. Например, создав сервис работы с платными подписками и покупками, мы можем повторно использовать его на других приложениях.
Процесс планирования и роли
Ранее, когда мы работали по Scrum, мы не ощущали привязки спринтов к реальной ценности, которую команда должна нести бизнесу и пользователям. Более того, выпуск версии приложения не всегда совпадал с рамками спринта, что приводило к смещению или следующего спринта, или релиза. Еще важно отметить, что в отличие от веб-разработки, выпускать в мир каждую готовую фичу — не лучший вариант, поскольку существует ряд препятствий:
- необходимость проводить тестирование всей версии релиза в комплексе, а не отдельной фичи;
- процесс выкатки билда в Store и проверки его со стороны App Store или Google Play команд тоже занимает время;
- процесс обновления пользователей на новую версию проходит постепенно, а не моментально;
- слишком частые апдейты могут привести к жалобам со стороны пользователей.
Учитывая нашу реальность, мы вывели ключевой принцип: планируем не фиксированные по времени спринты, а релизы (версии приложений, которые включают в себя набор User stories). То есть длительность итерации зависит от времени, необходимого для реализации следующей версии приложения, которая и является основным продуктом разработки. Кроме того, релиз можно «пощупать» как целостный продукт и измерить его влияние на метрики.
Перейдем к деталям.
Длительность итерации в разработке определяется не каким-то установленным периодом времени (например, спринт = 1 неделя), а исходит из времени, необходимого на реализацию скоупа User stories и задач, которые запланированы к разработке для конкретной версии приложения (в Jira им присваивается соответствующая версия).
Процесс планирования релиза имеет несколько этапов:
1. Выбор фич-кандидатов для релиза
Product Manager определяет перечень фич, которые необходимо реализовать в следующей версии приложения, исходя из приоритизированного User Story Map. Кстати, для построения User Story Map используем удобнейший инструмент RealtimeBoard, а каждая карточка User Story — это ссылка на конкретный User Story в Jira (cм. ниже).
2. Формирование первичного релиз-беклога
PDM формирует в Jira беклог из user stories, отобранных из User Story Map для следующей версии приложения; описывает user stories, определяет в них приемочные критерии (acceptance criteria). UI/UX team, исходя из описания User stories, создает мокапы для покрытия acceptance criteria и согласовывает их с PDM. Кстати, для подготовки дизайн-ресурсов мы используем Zeplin, что значительно уменьшает головную боль инженеров и дизайнера. Кроме того, в Zeplin мы сразу разделяем дизайн экранов по версиям приложения, что тоже позволяет быстро ориентироваться в наборе задач, которые попадут в релиз (cм. ниже).
3. Разбор user stories из первичного релиз-беклога
Facilitator организовывает встречу под названием «груминг», на которой происходит разбор пользовательских историй, выбранных PDM для релиза. На груминге присутствуют PDM, UI/UX, PM, команда разработки (состав команды разработки варьируется в зависимости от user stories) и QA команда.
Эта встреча — одна из самых важных в процессе, так как у команды есть возможность подвергнуть критике некоторые решения Product manager, задать уточняющие вопросы и обнаружить проблемы на ранней стадии. Груминг значительно улучшает качество задач, которые поступают в разработку. Это повышает эффективность команды и минимизирует лишние телодвижения и коррективы, когда задачи уже в прогрессе.
Основные цели груминга:
- Корректировка User stories на ранней стадии;
- Обнаружение подводных камней, так как задачу рассматривают с разных углов (development, QA, аналитика);
- У команды есть полное понимание, что мы делаем дальше, и ориентация в том, как мы это делаем.
4. Доработка user stories из релиз-беклога
PDM и UI/UX, при необходимости, по результатам груминга вносят правки в описание user stories и дизайн в соответствии с договоренностями, достигнутыми командой на груминге.
5. Формирование набора аналитических событий (events)
Аналитика играет для нас важнейшую роль, поэтому этап подготовки аналитических событий, подхода к анализу релиза «встроен» в наш процесс разработки. Этот шаг можно пройти и до груминга, если пользовательская история требует особого аналитического подхода.
6. Оценка user stories инженерами
После финализации пользовательских историй Facilitator организовывает встречу, на которой происходит оценка и декомпозиция историй на технические задачи. При этом команда придерживается следующего правила: срок реализации одной подзадачи не должен превышать 8 часов.
По итогам оценки команда разработки озвучивает менеджеру продукта плановый срок реализации выбранных user stories. PDM на основании этой информации и приоритетов принимает решение о том, стоит ли включать все user stories в плановый релиз, и утверждает финальный релиз-беклог.
Итог
Подведу итог, выделив основные принципы, которые мы заложили в наш процесс разработки мобильных приложений:
- Мы не раздуваем команды для поддержания максимальной эффективности и разнообразия разработки. Кроме того, такой подход мотивирует нас разрабатывать унифицированные компоненты.
- Мы поддерживаем гибкую разработку, сохраняя при этом глубину понимания продукта благодаря отдельному PDM на каждом продукте.
- Мы «живем» релизами, а не спринтами, что позволяет осязать продукт нашей работы и быть более гибкими.
- PDM во многом берет на себя роль PM для лучшего понимания продукта и подводных камней каждой фичи.
- Процессные встречи (груминги, планнинги и т. д.) не имеют жесткой календарной привязки, то есть они организовываются в нужный момент.
- Facilitator (PM) поддерживает эффективность процессов и бесперебойность «производства».
Основной вывод: не бойтесь нарушать правила и адаптируйте свои процессы под вашу реальность в поисках максимальной эффективности.
