Как выстроить процессы в команде? Почему одни практики эффективнее других? Какую методологию выбрать и можно ли совмещать Kanban и Scrum?
На эти вопросы мы попросили ответить Владислава Ганьжина, менеджера команды «Отели» сервиса для планирования путешествий OneTwoTrip. В рамках годовой программы «Продакт-менеджер» Владислав провел вебинар о гибких методологиях и рассказал об опыте команды OneTwoTrip. Делимся важными идеями.
Зачем нужны гибкие методологии?
Расскажу на примере особенностей работы нашей команды.
Разработка сложных систем. Бронирование отелей — это невероятная логика внутри. У нас есть разные поставщики, разные флоу по оплате, есть ситуации, когда надо изменить бронирование.
Конечный результат неизвестен. Мы разрабатываем продукт, который постоянно развивается. Все быстро меняется, а мы подстраиваемся под требования, которые есть на рынке.
Быстро меняется контекст. Как рынок, так и конкретные технологии.
Высокие требования. Выигрывает тот, кто решает проблемы пользователей.
Ограниченные ресурсы. Мы развиваемся итерационно, шаг за шагом. Ограничения есть в рамках бюджета, численности команды и так далее.
Для эффективной работы при таких вводных существуют различные методологии, фреймворки и философии. Самые популярные из них — Kanban и Scrum. Выбор методологии — это спорная тема, но мне хочется акцентировать внимание на том, как практики обеих методологий могут использоваться в любых командах и продуктах.
Выбор методологии — это решение команды или руководства?
Сильно зависит от команды: если в ней пять тысяч человек, жесткая структура, большие процессы и иногда даже собственная методология, то там особо не поспоришь. В таких командах часто есть отдельные Agile-коучи, и коммуницировать надо с ними.
Но если говорить об опыте OneTwoTrip, то у нас сейчас переходный этап, поэтому мы свободны в принятии решений. В процессе разработки мы выбираем то, что нам кажется наиболее верным.
Как встраивать Kanban в Scrum?
Сначала нужно хорошо погрузиться в методологию Scrum и определить, на что она делает упор. Ее философия состоит в том, чтобы донести ценности до пользователя и разработки. Последняя в течение 2–3 недель (в зависимости от спринта) уже покажет что-то пользователю и позволит получить фидбэк. Такими итерациями нужно идти к большой цели, которую держит в фокусе продакт-менеджер. Оцените, какие лично у вас есть точки роста в процессе, и дальше изучите практики в Kanban.
Kanban, как мне кажется, больше фокусируется не на том, ЧТО мы сделаем за две недели, а КАК БЫСТРО. И здесь уже не так важно итерационное движение к цели, оно более плавное.
Если вы хотите переходить на другую методологию или совместить обе, нужно понимать, зачем вам это и какие проблемы в процессе вы решаете. Я знаю, что некоторые команды используют гибридный Scrumban для перехода с одной методологии на другую.
Как это работает на практике?
Начнем с того, что в Kanban и Scrum есть практики Daily (дейлик). Kanban Meeting позволяет выявить проблемы в постановке тех задач, что максимально близки к завершению. Daily Scrum — это инспекция прогресса в достижении Sprint Goal (цели спринта). События Daily Scrum улучшают коммуникацию, выявляют препятствия и способствуют быстрому принятию решений.
По большому счету, дейлики — это созвон команды, на котором мы сверяемся с планом и выясняем, нужно ли прямо сейчас решать какие-то проблемы.
Почему важно проводить дейлики? Сейчас многие команды работают удаленно, но потребность в коммуникации никуда не ушла. Это поддерживает мотивацию, создает эмоциональную связь и ощущение причастности. Супер, если есть возможность проводить такие встречи не только онлайн.
Это также дает возможность оперативно решать вопросы после основной части. Важно оговориться, что дейлики иногда затягиваются. Если возникают какие-то вопросы, то их желательно решать не всем вместе, а выносить на обсуждение локальными группами.
Что делать, если в компании на дейлик выделяют целый час?
Продакт-менеджер может влиять на команду и коммуникацию. Если часовые созвоны кажутся вам неэффективными и излишними, предложите решения. У дейлика достаточно понятные цели: это общее обсуждение, как мы идем по плану, то есть вопросы, которые мы решаем именно сейчас. Если это большие проекты, которые вы только планируете, и по ним много вопросов, выносите их на отдельную встречу с лидами.
Ну и просто поторапливайте команду. Поставьте встречу на 20 минут и предупредите участников, когда пройдет половина созвона. Все начнут говорить чуть быстрее, а на втором дейлике уже будут в фокусе. Со временем встречи станут эффективнее.
Ты много говоришь про фокус на большой цели, а как выглядит планирование?
Эта практика также есть в обеих методологиях. Каденции в Kanban помогают приоритизировать элементы из общего объема работ, а Sprint Planning в Scrum определяет список задач на конкретный период.
Планирование — это отличная возможность, чтобы проговорить, какую задачу мы берем и в какую итерацию. Компания OneTwoTrip значительно выросла, процессы меняются, поэтому веб-релизы идут быстрее, чем мобильные. А нам в команде «Отели» важно смотреть, когда и какие релизы идут в приложении. На этом звонке мы в том числе передаем команде, что в конкретный релиз нужно выкатить именно эту задачу. Почему важно это транслировать и доносить общий контекст? Некоторые фичи могут быть привязаны к маркетинговым акциям, поэтому у них есть четкий дедлайн.
Но все-таки важно смотреть на процессы с точки зрения продуктивности. Если вам кажется, что эффективно идти одним образом, а методология рекомендует другим, то надо выбирать то, что работает именно для вас.
Что значит двигаться итерационно?
В Scrum итерации существуют в виде спринтов. В Kanban напрямую этого нет, но есть планирование, где мы вносим задачи, и ретро, где мы обсуждаем их.
Итерации нужны, потому что всегда что-то идет не так, а итерационное движение помогает гибко управлять разработкой. Например, мы получили обратную связь о том, что в проекте есть проблемы, тогда в следующей итерации мы можем это исправить. А еще декомпозиция сложных проектов помогает легче идти по квартальному плану и отслеживать прогресс.
Как измерять эффективность?
Наша команда измеряет количество задач, которые мы выполняем за определенный промежуток времени, количество релизов, Lead Time (когда задача попала в to-do и потом — в продакшн) и количество созданных и закрытых багов.
На все эти вещи тоже хорошо смотреть итерационно. Например, если с каждой итерацией становится меньше выполненных задач, важно выяснить, что пошло не так, и исправить это.
Раз в месяц мы собираемся с большой командой «Отели» и стейкхолдерами на системное демо, чтобы синхронизироваться и отследить, насколько хорошо мы идем по плану.
И, конечно, ретро, где мы обсуждаем, что прошло хорошо во время спринта, с какими проблемами столкнулись и как они были решены. Формат может быть разный: доска, Miro, опрос и т. д. Но важно разбирать конкретные задачи проекта, потому что это помогает приземлиться.
