×

Как мы создали свой подход к разработке без привязки к спринтам

Какой процесс разработки выбрать: Scrum, Kanban или же Scrumban? Команды часто задаются этим вопросом в попытках найти наиболее эффективный метод или выбрать хоть какой-нибудь принцип работы. Во многих случаях перевод процессов на одну из методик в «чистом виде» не приносит желаемого результата. Так происходит, потому что каждая команда — это уникальный живой организм, работающий с уникальным продуктом, который находится на своей уникальной стадии развития.

Мы, мобильная продуктовая команда BetterMe, задумались над тем, как сделать нашу разработку не привязанной к искусственным временным рамкам (спринтам), при этом быть эффективными (частые и полезные релизы), разрабатывать и поддерживать несколько продуктов, не раздувая штат.

BetterMe — это достаточно молодой проект украинской продуктовой компании Genesis. Мы создаем мобильные приложения в категории Health and Fitness, ориентируясь на развитые страны. За 8 месяцев существования проекта нашими продуктами воспользовались более 6 млн пользователей, и мы закрепились в ТОП-3 приложений в своей категории на рынке США.

Нам удалось создать свой подход к разработке, используя нужные элементы из Scrum, Kanban и Waterfall. В этой статье я попробую рассказать, как именно.

Структура продуктовой команды

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

  1. В рамках проекта BetterMe разрабатывается 3 продукта. На каждый продукт назначается отдельный Product Manager (PDM), который отвечает за формирование беклога, приоритизацию User stories, рост метрик и в целом за успех продукта.
  2. Facilitator (он же PM), в свою очередь, отвечает за построение и поддержку наших процессов на высоком уровне. Основная цель этой роли — «бесперебойное производство», которого можно достичь посредством поддержки эффективной коммуникации на разных стадиях разработки и контроля качества поступаемого материала инженерам:
    • детально продуманные и прописанные User stories;
    • подготовленный и выверенный дизайн;
    • сформированные аналитические события и др.
  3. Команда инженеров, дизайнеров и тестировщиков перераспределяет свои ресурсы в зависимости от потребностей и целей BetterMe, то есть эти команды не привязаны к конкретному продукту.

Такая структура команды позволяет нам получить необходимую глубину понимания и развития благодаря отдельному Product Manager (PDM) на каждом продукте, не увеличивая при этом команду инженеров до неэффективных размеров.

Приведу пример. Как правило, для эффективной поддержки продукта каждое приложение потребовало бы по 2-3 iOS и Android инженера. Итого, на 3 продукта — по 9 инженеров на каждую мобильную платформу. Наш же подход требует 4-5 инженеров на каждой платформе, потому что команда «плавает» между продуктами в зависимости от заданного приоритета.

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

Процесс планирования и роли

Ранее, когда мы работали по 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) поддерживает эффективность процессов и бесперебойность «производства».

Основной вывод: не бойтесь нарушать правила и адаптируйте свои процессы под вашу реальность в поисках максимальной эффективности.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному0
LinkedIn

Схожі статті




35 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Дякую, що поділились однією із моделей продуктової команди. Експеременти, які приносять позитивні результати, не варто переривати.

Парни-разработчики DOU, сделайте уже увеличение картинок по клику, как на medium.com реализовано

На первый взгляд выглядит привлекательно и вроде даже правильно. Однако сразу же бросаются в глаза два противоречия:
1. На каждый продукт — свой PDM.
2. Команда компактная, то есть PDM-ы конкурируют между собой за команду.

А теперь представим себе ситуацию 1, когда один из продуктов согласно некоторым метрикам становиться более успешным — его PDM рисует «длинный» релиз, с большим кол-вом историй и запрашивает более месяца работы. PDM2 падает в обморок, PDM3 бежит за водой — их продукты останутся без разработки какое-то время. Facilitator бегает между ними всеми и настойчиво просит PDM1 остепенить свои амбиции.

Ситуация 2. Все PDM-ы стараются сообща делать «короткие» релизы, например пробуя A/B на каких-то промежуточных релизах. Поскольку команда компактная, разработчики вынуждены постоянно переключаться между контекстами проектов, на бегу вспоминая все незадокументированные особенности, техн. долг и старые оценки.

Отсюда вопросы:
1. Как вы решаете проблемы конкуренции продуктов?
2. Каким образом боретесь с затратами на context-switching компактной команды?

Владимир, вопрос хороший! 1й кейс: приоритетность продукта поднимает не его успешность, а потенциальная ценность отдельной функции (истории) для всего проекта BetterMe. Например, если фича Х сделает продукт Б успешней чем лидирующий продукт А, то конечно мы дадим высокий приоритет такой задаче. Итого, не важна успешность продукта, важен прирост, который может дать новая история для всего нашего бизнеса

Касательно 2го кейса, да существует в производстве такое понятие как switching cost, но наш подход не твердит, что вся команда должна переключаться на продукт А или Б, или В. может быть расстановка где 1 человек на А, 2 человека на Б и 1 на В. Любые комбинации возможны. Главное все обсудить и запланировать.

Доброго времени суток Михаил.

Понравилось описание вашего процесса, понятно и развернуто, спасибо!

Интересно было бы почитать, как именно выглядел у вас Scrum (вижу описание текущего процесса, но не понятно как он выглядел при Scrum), какие минусы вы видели в «чистом» подходе и как приняли решение от него уйти.
Из того что понял — не устраивала фиксированная длина итераций, так как вы привязывали релизы к спринтам или наоборот.
Критиковать не буду, так как не могу знать всех причин и специфики работы с вашей командой и продуктом, но не совсем понимаю, какие изменения вы внесли в Scrum для достижения результата описанного в «Итоге».

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

Если я правильно понимаю, преимущество пришло по наследству из Scrum?

Мы поддерживаем гибкую разработку, сохраняя при этом глубину понимания продукта благодаря отдельному PDM на каждом продукте.

Если я правильно понимаю, также взяли роль из Scrum, но там роль имела наименование Product Owner.

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

Вы не пробовали менять длину спринта, и осязать продукт по итогам каждого демо спринта?

PDM во многом берет на себя роль PM для лучшего понимания продукта и подводных камней каждой фичи.

Есть ли у вас тут какие то отличия от Scrum?

Facilitator (PM) поддерживает эффективность процессов и бесперебойность «производства».

В его ответственность входит что либо, что не входит в роль Scrum Master?

И еще пара вопросов, если вас не затруднит:
У вас был выделенный Scrum Master во время Scrum?
Вы тестируете только весь релиз, не тестируя каждую фичу отдельно?

Ранее, когда мы работали по Scrum, мы не ощущали привязки спринтов к реальной ценности, которую команда должна нести бизнесу и пользователям.

Вы пробовали как то решать эту проблему в рамках Scrum?

Более того, выпуск версии приложения не всегда совпадал с рамками спринта, что приводило к смещению или следующего спринта, или релиза.

Не подумайте что это критика, мне правда интересно, у нас скажем, по необходимости берется в спринт таска «Релиз x.x», которая может быть выполнена в середине спринта, и не обязательно ждать демо, чтобы провести релиз на прод.
Не возникает ли у вас «плавание» темпа разработки?
Сколько в среднем занимает разработка одного релиза?
У вас проводились ретроспективы во времена Scrum? Какие вопросы на них поднимали?
Какой опыт имели ваши менеджеры до текущего проекта (agile/watefall/etc)?

Исходя из статьи у них проблема была скорее всего не с использованием Scrum подхода, а с непониманием грамотной приоритизации невыполненых работ по всем текущим проектам в компании. Автор отметил, что они не хотели раздувать штат сотрудников для изоляции кроссфункциональных команд по каждому из Scrum проектов. Основная проблема состояла скорее всего в премещениях разработчиков между проектами, что в итоге теряло понимание ценности и достижения целей по окончанию каждого спринта, а также непопадание в сроки. Как результат, я вижу что они решили объеденить три комманды в одну и решать задачи по ходу их поступления и уровням приоритетов от каждого из PDMs. Это нормальный подход, который позволяет доносить понимание ценностей по каждому из проектов всем членам одной большой dev team. Такой подход практикуется в Канбане, главное чтоб работа с рисками и приоритетами велась адекватно используя тотже WSJF и модель KANO.

Опять же это мои догадки, но я бы на их месте посмотрел бы на тотже SAFe. Если я не ошибаюсь с его пощью можно установить баланс между текущими проектами в организации без потерь связанными с дедлайнами по каждому спринту. И опять же, если отбросить метрики по velocity, то можно было бы спокойно делать итерации по двум проектам с меньшим весом, а на проект с высшим приоритетом переводить больше ресурсов с другихкомманд, сохраняя баланс и снижение рисков технического долга по другим проектам.

Молодцы, что не останавливаетесь и эволюционируете. Вот читаю и понимаю, что это чистой воды протоканбан. Правильно ли я понимаю, что у вас один беклог на 3 продукта и одна кросфункциональная комманда? Не могли бы вы подробней расписать как вы приоритезируете фичи по важности поставки по всем 3 проектам сразу и как продак менеджеры договариваются между собой? Баланс разработки между продуктами уж очень напоминает ССРМ, что тоже перекочевал в канбан с теории ограничений. Михаил, всетаки у вас вновь изобрести колесо не получилось, одно из основных принципов канбана это использовать то, что уже есть и работает в организации сейчас. Так что впред и не останавливайтесь на начатом. Скоро накопите статистику и поймете, что оценка по скраму вам будет не нужна и вовсе, а будете ориентироваться на показания метрик где будете знать сколько понадобится на чендж реквест, а сколько на резработку челендж функционала. Но помните, что вытягивание будет работать только если грамотно выставлять WIP лимиты по незавершенной работе.

А, и вот ещё, а где на схеме Chief Product Owner и кто ещё туда не попал? :)

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

И насколько указанные «продукты» независимы друг от друга по бизнесу, функционалу и технически? Может, по факту у Вас один продукт с несколькими компонентами?

Вы в самом начале понимания процессов. Поищите и почитайте каких нибуть основ ... Будьте смелее :-)

Добрый вечер, Миша. А подскажите, как вы боретесь при этом с багами?) Например, релиз вы планируете выпустить через три недели, и вот, в начале третьей недели, когда почти все уже сделано и идет комплексное тестирование и тут вылазит куча багов, и в сроки релиза не укладываетесь, что делаете в таких случаях?)

Миша, здравствуйте. Мы стараемся итерационно подавать функционал в тестирование, то есть, не «сваливаем» весь релиз в тестирование одним махом. Очень много баг отлавливаются в течении, скажем, этих 3 недель. Кроме того, в процесс планирования стараемся подключать тестировщиков для более точной оценки и учета возможных багов.

Здравствуй, Миша!
— спринт каждого продукта в своё время и своей длительности?
— или на 1 спринтрелиз планируются задачи на разработку по всем 3 продуктам и в конце одновременно 3 релиза?

Денис, спасибо за вопрос. Спринтов, как таковых, нет. Разработка идет параллельно 2-3х продуктов; а может разрабатываться и 1н продукт, если он сейчас самый приоритетный и требует фокусировки усилий.

На каждый продукт назначается отдельный Product Manager

А как они между собой делят инженерный ресурс?
Кто устанавливает приоритеты по продуктам?
Ну и кто выгребает если ничего не успевают по всем продуктам?)
А вообще этот подход уже описан в литературе. Хорошо что хоть у вас он работает, так как служить 3м господам проблематично)

Тарас, вопрос хороший. Тут просто важен навык приоритезации. Поверьте, в рамках 3х продуктов всегда можно найти самые приоритетные вещи, которые при Х усилий должны принести 2Х результата; наоборот, такой подход позволяет/заставляет отсекать лишнее, а его очень много, как правило. Согласно нашему подходу, за расстановку приоритетов между продуктами отвечает CPO.

Если 3 беклога имеют сквозную приоритизацию и общий набор исполнителей, не будет ли справедливо считать их одним?

Работают же как то копмании обслуживающие группу клиентов.

как то

Вы очень правильно охарактеризовали их работу)

Молодцы, что начали пользоваться своими мозгами. Главное чтобы для вас работало. А то так складывается впечатление что у некоторых менеджеров скрам бук вместо головы.

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

Мне кажется, цель фиксированного спринта — не только и не столько фиксированный темп разработки, сколько снижение рисков с одной стороны и гибкость с другой. Гибкость не размера спринта, а содержания работ. Даже если продукт внутренний, как в вашем случае, таким же неравномерным становится и фидбек после релизов. Кстати, при такой схеме должно обостряться желание передвинуть релиз на пару дней, если что-то не успели, не так ли?

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

Если релизы раз 5-7 дней, у вас большие организационные потери. Все равно нужно что-то как-то планировать, выкладывать и так далее, времени на саму разработку приходится мало. Если же релиз раз в две недели (близко к размеру спринта), то я вообще не вижу смысла. Каждый раз надо определять его размеры отдельно, это тоже потери и усложнение.

Все ИМХО, конечно.

Давайте посмотрим, что получается в сухом остатке.
У нас 3 продукта, 1 продакт овнер и одна команда. То есть, одна команда работает над несколькими продуктами. Для разнообразия. И для уменьшения количества неэффективных инженеров.
Спринты убрали, потому что начали планировать релизы. И потому что спринты — искусственные временные рамки. В отличие от релизов. Которые естественные.
Команда сама перераспределяет свои ресурсы. Исходя из целей BetterMe.
Один беклог на три продукта.
И елка зажглась! Потому что тестирование релиза — это хорошо, refinement — это хорошо, хорошие user stories — это хорошо, оценка инженерами функционала — это хорошо, и, наконец, аналитика — это тоже хорошо. А фиксированная длина спринта — плохо.
Я правильно уловил суть?

Сейчас еще и выяснится, что релиз-бейзд спринты теперь для удобства длиной полгода, и елка воспылает! )

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

Не буду с вами спорить, так как у вас свои реалии и опыт. В том то и дело, что этот подход прошел тестирование, учитывая «обязательства по срокам к стейкхолдерам\кастомерам». Мы не аутсорс и команда отвечает за результаты перед самими собой, поэтому в эффективности заинтересован каждый.

А что будет, если фича, отобранная в очередной релиз затянется? Например, вместо 3-х недель она делается уже три месяца и до сих пор нормально не рабтает?

Вы будете месяцами откладывать релиз давно сделанных вещей только из-за этого?

P.S.
Что-то поведение вашей команды между релизами уж больно напоминает старый знакомый waterfall :)

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

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

Какие еще важные преимущества Вы видите у данного подхода? Вводили ли вы дополнительно какие-либо ограничения «комфорта», чтобы

поддержать тонус и разнообразие в разработке

кроме матричной структуры?

Денис, спасибо за обратную связь. Из ряда преимуществ данного подхода есть еще тот факт, что он заставляет хорошо приоритезировать задачи/направления, учитывая ограниченность ресурсов и заинтересованность каждого из продакт менеджеров.

Хочу отметить, что когда у вас сильная команда, то от вас не требуется постоянный «пушинг», оценка, контроль. Очень важно жестко отбирать команду на ранней стадии; это перекроет большой ряд вопросов.

Спасибо за ответ, конечно, обычно сам по себе «пушинг» — это скорее попытки скрыть ошибки менеджмента, ну а взаимный контроль никогда не вредил, чтобы вся команда понимала, что и зачем мы делаем, правильно? Оценка — это часть очень важной обратной связи, чтобы мы понимали, что движемся туда, корректировали свои действия при необходимости.

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

Интересно, были ли у вас проблемы, связанные с постоянной недостаточностью ресурсов и видите ли вы риски в бутиковом пути развития?

Денис, недавно пришли к тому, что если релиз требует длительного периода реализации, то необходимо проводить: 1) периодическую коректировку плана, учитывая реалии; 2) регулярное демо, где команда говорит на сколько идет в ногу с планом. Адаптация плана — это нормально. + это позволяет «выкидывать» лишнее, если наблюдаем сильное отклонение от плановой оценки сроков.

Извините, я не понял ваш вопрос про бутиковый путь развития.

Учитывая нашу реальность, мы вывели ключевой принцип: планируем не фиксированные по времени спринты, а релизы (версии приложений, которые включают в себя набор User stories).

это называется здравый смысл:)

Такий підхід не дає відповіді на питання щодо продуктивності команди. Виглядає так, що або команді нав’язують певний темп і тоді росте технічний борг, що якось раптом потім усе завалить, або команда на розслабоні працює — рано чи пізно це набридне інвесторам.
На мою думку краще все ж мати спрінти й міряти продуктивність команди традиційним способом.

Підписатись на коментарі