В этой статье я поделюсь своим опытом адаптации стандартов Agile к реалиям своего текущего проекта；перечислю решения, которые продвинули мою команду вперед, призывая мыслить шире и проявлять креативность.
Находясь на позиции бизнес‑аналитика в EPAM Systems, два года назад я присоединился к новому проекту (крупный западный образовательный ресурс).
Команде требовался подходящий рабочий процесс, и мы проанализировали имеющуюся ситуацию:
-
Продуктовый менеджер не является Product Owner и с ним вообще сложно связаться.
-
В архитектуре microservice наш SDK — лишь малая часть основного приложения, без интеграции в которое мы не можем выкатить новую версию.
-
А когда следующий market релиз этого приложения? Кажется, никто не знает.
-
«Требования пока не определены, но нам это нужно очень срочно к началу учебного года.»
-
«Мы все еще придерживаемся стартапа.»
Можно добавлять пункты в список, но основная идея была ясна — каноничные Agile методологии не подходили нашей действительности.
Немного теории
Почему это так? Ниже приведен список аспектов Scrum, Kanban и FDD и факторов, с которыми они никак не бьются:
-
Scrum:
-
Спринты фиксированной длительности против незапланированных релизов основного приложения.
-
Сapacity спринта против рабочей версии фичи.
-
Стабильная производительность против сезонности бизнеса.
-
Формальные церемонии против необходимости быстрых изменений, приоритизации и внедрения в условиях стартап‑мышления.
-
-
Kanban:
-
Ограниченна емкость «работ в процессе» против дедлайнов и гонки за функционалом.
-
Структурированные доски и рабочий процесс с карточками против жестко диктуемых заказчиком, негибких рабочих процессов в Jira.
-
-
FDD:
-
Фокус на фиче против поддержки нескольких OKR и необходимости взаимодействия между командами продукта.
-
Что самое важное?
Чтобы адаптировать наш рабочий процесс к этим сложностям, мы выделили несколько ключевых ценностей:
-
КОГДА дата релиза на маркетплейсы? (Когда конечный пользователь должен увидеть эту функцию, независимо от графиков выпуска и т. д.)
-
ЧТО ожидается к выпуску к этому моменту? (Бизнес‑цели или метрики, которые мы пытаемся поддержать)
-
ЧТО мы можем реально предоставить к этому времени? (Какую версию фичи мы можем спланировать как MVP)
-
ЧТО нам нужно изменить сейчас, чтобы это выполнить? (Объем работы для fixversion, распределение задач между разработчиками, выпустить патч, создание интеграционного snapshot)
В этом месте статьи хочу сослаться на отличное переосмысление от Henrik Kniberg под названием Making sense of MVP. Статья, которая помогла преодолеть бизнес‑аналитическую косность восприятия и взглянуть на процесс с точки зрения пользователя и продукта.
Кунг-Фу начинается здесь...
Шаги, которые мы предприняли в формате рекомендаций:
-
Используйте имеющуюся статусную модель JIRA под свои нужды с помощью лэйблов, компонентов и других атрибутов. Доска должна быть читаема и понятна для каждого члена команды.
-
Используйте «fixversions» с переменной продолжительностью и объемом вместо спринтов. Это позволит выкатывать функциональные версии фич, а не сырые заготовки.
-
Определяйте состав fixversions с точки зрения пользователя и его ожиданий. Это сильно поможет с приоритетами.
-
Все новые и старые баги распределяйте по 3 «ведрам» (эпикам или лэйблам): срочно поправить, поправить побыстрее и поправить когда‑нибудь. Это очистит вашу доску и избавит от ежедневных мук приоритизации.
-
Планируйте релиз вашей fixversions на основе мощности QA. Это повысит точность планов и предусмотрит bottleneck effect.
-
Сокращайте совещания до необходимого минимума: если команде не особо помогает ретро, то избавьте всех от ретро и других «звонков ради звонков». Лиды разработки, QA и BA вполне в состоянии заниматься планированием, оценкой и feasibility check в то время, как инженеры заняты задачами.
-
Сообщайте обо всем (планы, изменения планов, риски, сомнения). Поддерживайте прозрачную коммуникацию с командой заказчика, и это ощутимо добавит свободы в принятии самостоятельных решений.
Ownership
Красная линия, пересекающая эту тему, — ownership. Хотя это заслуживает более глубокого обсуждения, вкратце: стремитесь заполнить любую пустоту в зонах ответственности, связанных с процессом или продуктом. Создав образ вовлеченного, проактивного и ответственного лидера перед заказчиком, вы получите зеленый свет не только на решения, но и на изменения в процессах.
В результате
Нам удалось построить процесс, которые не соответствует стандартам клиента, но работает эффективнее, чем они. Все стороны довольны: команда не бегает по сомнительным звонкам и не релизит версии ради версий, в то время как заказчик получает прозрачные планы и ожидания.
Этот опыт вдохновил меня продолжать эксперименты с различными методологиями, превращая их в мозаику из разнообразных элементов. Этот творческий процесс напоминает мне о детстве и увлеченности конструктором.
Если вы хотите поделиться своими мыслями, идеями, вопросами или критикой, — заходите в мой Telegram канал @kutuzovvaiti.
Автор: AIKutuzov
