Привет! Я Олег Зеленый, Scrum-мастер команды «Анализ финансов» и «Цели» внутри направления PFM в Сбере. В этой статье хочу поделиться основными практиками и лайфхаками, которые я вывел за 3 года работы в Сбере. Если вашей команде не хватает прозрачности и структуры рабочего процесса, эти советы могут помочь наладить его или если просто интересно узнать, как работает одна из продуктовых команд в Сбере, тогда тоже welcome.

Сначала давайте немного расскажу, что такое PFM. Personal Financial Management – персональное финансовое управление. Это не core-продукт, а целый набор решений, встроенных в СберБанк Онлайн, среди них: Анализ финансов, Цели, Бюджет, Автонакопления, Всего средств, Календарь выплат. Все сервисы направлены на упрощение пользовательского опыта в управлении финансами, автоматизацию рутины и на безболезненное обучение финансовой грамотности. Если захотите подробнее почитать об этом, то в прошлом году мы уже писали про PFM, модель Дэвида Колба и финансовую грамотность трудоспособного населения России.

Переходя к основной теме, важно отметить, что многие считают Agile карго-культом и не верят, что он будет полезен. Я поделюсь с вами основными поинтами, которые помогли нам освоить многогранный Scrum, благодаря регулярной работе и включённости в том числе. В этой статье мы хотим рассказать о нашем опыте, надеемся, что он будет полезен и вам.

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

1. Продуктовый характер бэклога

Первое, с чего мы начали – гигиена бэклога. Сразу скажу, что мы используем Jira для работы с бэклогом, вы можете использовать что-то другое, главное – принцип. Попробую объяснить на нашем примере. В самом начале наш рабочий бэклог в Jira состоял из Epics и каждая команда вкладывала туда что-то своё: у кого-то это был релиз, у кого-то фича, у кого-то — User Stories (пользовательские истории). Не было единого понимания, как должен выглядеть Epic. А под Epic лежали бесконечным потоком Tasks на конкретного исполнителя — задачи по компетенциям. На самом деле, это плохо, потому что список задач становится бесконечно огромным. Например, в нашей команде 10 человек, спринт длится две недели, задач получается слишком много и без структуры. Бэклог продукта превращается в большое полотно задач. Владелец продукта должен уметь приоритизировать это полотно, но в таком виде приоритизировать нечего, потому что это отдельные задачи конкретных участников команды. Такая модель работы вызывает  путаницу, сложный процесс планирования, какие-то задачи забываются и долго валяются в бэклоге. Кто-то что-то делает, а тебе не всегда понятно, зачем и нужно ли ему заниматься этим в данном спринте. Как же быть с этим?

Чтобы избежать таких проблем или починить их, важно сделать продуктовый характер бэклога. Epics должны содержать пользовательские истории (улучшения для продукта): какая-то новая фича, функция, возможность для развития клиентского опыта. Такие пользовательские истории владелец продукта способен приоритизировать. Тогда у него получается уже не полотно, а конкретный список, которым он может оперировать. А уже внутри пользовательских историй в качестве SubTasks  следует заводить задачи на компетенцию (например, TechTask). Тогда у команды ничего не теряется, появляется возможность видеть, какие конкретно нужно выполнить задачи, чтобы завелась та или иная пользовательская история. Это общий аспект, который будет релевантным не только для большой компании типа Сбера, но и в принципе для любой продуктовой команды.

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

2. Регулярный PBR (Product Backlog Refinement — уточнение бэклога).

Когда у вас уже есть продуктовый бэклог, можно начать его регулярно уточнять. Это значит, что появляется какая-то пользовательская история, но команда её не знает, её надо сделать. Часто команды разбирают, как делать историю, на планировании. В Scrum планирование может длиться вплоть до 8 часов, команды обычно управляются за 2-3 часа. НО бывает такое, что в течение планирования команда не может понять, как делать User Story, и им нужно дополнительное время на подумать, с кем-то посоветоваться, обсудить, спросить. Время на планирование этого не предполагает. Получается, что историю на спринт вы планируете не до конца и появляется высокий риск не выполнить её за спринт, ведь остаётся множество неизвестных.  Для того, чтобы лечить такие боли, и существует PBR. Оно похоже на классическое планирование, но происходит в рамках предыдущего спринта. То есть, ты уточняешь свои задачи на перспективу. Если появляется вопрос «как делать эту пользовательскую историю?», ты можешь без проблем сказать «мы паркуем этот вопрос и к следующему PBR это надо выяснить». К концу спринта появляется пользовательская история, которая соответствует Deffinitoin of Ready (критериям готовности), а это значит, что команда в отношении неё знает достаточно и может с уверенностью сказать, что успеет реализовать за спринт, а риски зафакапить её сильно уменьшатся. Данный лайфхак можно рекомендовать для всех, вне зависимости от формата команды и компании.

Как выглядит PBR на примере:

1. Появляется пользовательская история. На первом PBR владелец продукта рассказывает с точки зрения бизнеса, зачем она нам нужна, какие метрики будет растить? Если дизайнер успел до PBR пообщаться с владельцем продукта, он показывает подготовленные макеты, если нет, то готовит к следующему. Аналитику даём задание к следующему PBR - подготовить архитектуру и план реализации.

2. На второй день PBR у аналитика уже есть план, как реализовывать, у дизайнера есть макеты, всё это обсуждается, и появляется перечень SubTasks. Обсуждаете другие сложные технические вопросы.

3. На третьем PBR у вас появляется полностью готовая пользовательская история, у которой есть относительная оценка в Story Point, на основании которой вы понимаете, что сможете закрыть её за спринт. Все её проговорили, все понимают, что делать и на следующий спринт, на планировании она проходит очень легко. И так по кругу.

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

Scrum позволяет нам инвестировать до 10% времени от спринта на PBR (в среднем это 1,5 дня). Но лучше выработать баланс: у вас есть Velocity (количество пользовательских историй, которые вы можете закрыть за спринт, оно оценивается относительно оценки в Story point). Если в команде 5 story points в спринт, значит, вам нужно в предыдущем спринте нагрумить минимум 5 story points на спринт. Это можно сделать за одну встречу, а можно и за три встречи не успеть, поэтому важно определить такой темп, при котором вы возобновляете понятный вам бэклог на каждый будущий спринт, а лучше больше, чтобы на новом планировании была возможность выбирать.

*Definition of Ready. Иногда можно столкнуться с такими фразами в команде — «я начал кодировать до того, как у меня появилась аналитика, поэтому теперь нужно много всего переделывать». Порой команды работают с этим следующим образом: давайте напишем аналитику за спринт до, а в следующем спринте сядем по ней писать код.

Но бывает и такое:

1. Фича, по которой написали аналитику, стала неактуальной;

2. Разработчик, сев кодировать, обнаружит, что нельзя сделать так, как написал аналитик. Поэтому вместо того, чтобы расписывать всю аналитику, нужно выделить Definition of ready (критерий готовности). Включить в этот критерий самые важные вехи, которые необходимы до начала реализации User story. Здесь не нужна вся детальная аналитика, ведь она с ненулевой долей вероятности поменяется. Нужен именно минимальный набор, с которым можно работать в начале спринта и который маловероятно будет подвергнут изменениям. А детальные требования вы по ходу спринта проработаете. Инвестировав время в создание качественного DOR, у нас появилась возможность увеличить вовлеченность команды на PBR и опрозрачнить процесс планирования.

3. Undone или неготовая работа.

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

Спринт — это максимум один месяц. А если команды выводят свои фичи в мобильное приложение, то они пользуются общим релизным графиком, вехи и их сроки определены заранее. Для попадания в релиз необходимо выполнить ряд Definition of Ready, в частности, пройти приемо-сдаточные испытания. Команды не всегда успевают закончить все definition of ready в сроки спринта. Как с этим работать? В некоторых фреймворках есть концепция терминов Undone (неготовая работа) и Definition of Done (критерий готовности). Обычно все стремятся определить, что User Story готова, когда она прошла ПСИ, Regress и установлена на пром. Для нас это оказалось неэффективной практикой. При таком раскладе вы действительно никогда не сделаете User Story  за один спринт. Активности, связанные с релизной частью, нужно обозначить как Undone. Undone (неготовая работа) — это то, что вы даже не планируете положить в один спринт. А вот Definition of Done — то, что действительно необходимо закрыть в течение одного спринта. Например, выделить этап тестирования и в течение одного спринта пройти его. Растяжение происходит, но тогда команда концептуально видит, с чем работает. Быстрее в любом случае сделать не получится, но зато появляется прозрачный процесс, что намного ценнее и продуктивно влияет на работу команды.

4. Пересмотрите свои события.

На субъективный авторский взгляд, самый простой для внедрения элемент Scrum в команде — внедрение событий: ретроспективы, дейли, планирование. События, в отличие от остальных практик, встречаются повсеместно. И только после внедрения событий, команды начинают учиться всем остальным практикам. Такой подход не совсем эффективный: лишь после внедрения всей системы элементов, важно пересмотреть свои события в новой парадигме. Тогда, например, в рамках дейли вы будете смотреть, как закрываются пользовательские истории. А на ретроспективах посмотрите, какой из треков у вас сломался, может быть, вам нужно больше уточнять или, наоборот, тратить на это меньше времени. Со всей инфраструктурой практик становится понятнее, что нужно улучшать, следовательно, события этому соответствуют.

5. Масштабирование проблем.

В процессе роста команды количество сложностей в работе тоже множится. Поэтому все чаще люди обращаются к фреймворкам масштабирования (мы, например, выбрали Less). Если на начальном этапе развития команды вы грамотно изучили и применили Scrum, то переход на масштабируемые фреймоврки будет более плавным и менее болезненным. Поэтому рекомендую сначала изучить и попробовать внедрять Scrum хотя бы базово, если хочется применять Less в дальнейшем. Плюс небольшая ремарка-рекомендация: не стоит использовать Scrum для больших доработок с фиксированными требованиями, в частности миграции на целевые системы. Лучше использовать Kanban, PMBOK, Каскад. Scrum в таких задачах будет только мешать.

Важный оффтоп — вопрос эффективности работы. Зачастую под эффективностью понимают утилизацию. Это значит, что человек постоянно чем-то занят, у него нет ни одной свободной минуты, он беспрерывно выполняет свои прямые обязанности: аналитик пишет аналитику, разработчик кодит, тестер тестирует. Но если смотреть на практике, утилизация совершенно не подразумевает эффективность и выполнение целей к концу спринта. Тем не менее без дела никому не хочется сидеть, поэтому в качестве эффективности предлагается рассматривать T-shape: если аналитик написал всю аналитику по фиче, он не бежит описывать следующую фичу, а идёт помогать тестерам, например. Словом, развивает кросс-компетенцию и использует её внутри спринта.

Внедрение и использование этих практик позволилил нашей команде выйти на новый уровень работы. Теперь мы имеем правильную декомпозицию бэклога, сокращенный lead time, у нас появилась возможность ставить эксперимент, разрабатывать более качественные фичи, тем самым увеличивая стоимость продукта. Конечно, это не панацея и у нас осталось много аспектов, над которыми еще предстоит работать, поэтому stay tuned и обязательно делитесь в комментариях лайфхаками ваших команд.