В этой статье я поделюсь своим опытом адаптации стандартов Agile к реалиям своего текущего проекта；перечислю решения, которые продвинули мою команду вперед, призывая мыслить шире и проявлять креативность.

Находясь на позиции бизнес‑аналитика в EPAM Systems, два года назад я присоединился к новому проекту (крупный западный образовательный ресурс).

Команде требовался подходящий рабочий процесс, и мы проанализировали имеющуюся ситуацию:

1. Продуктовый менеджер не является Product Owner и с ним вообще сложно связаться.

2. В архитектуре microservice наш SDK — лишь малая часть основного приложения, без интеграции в которое мы не можем выкатить новую версию.

3. А когда следующий market релиз этого приложения? Кажется, никто не знает.

4. «Требования пока не определены, но нам это нужно очень срочно к началу учебного года.»

5. «Мы все еще придерживаемся мышления стартапа.»

Можно добавлять пункты в список, но основная идея была ясна — каноничные Agile методологии не подходили нашей действительности.

Немного теории

Почему это так? Ниже приведен список аспектов Scrum, Kanban и FDD и факторов, с которыми они никак не бьются:

• Scrum:
  

  • Спринты фиксированной длительности против незапланированных релизов основного приложения.

  • Сapacity спринта против рабочей версии фичи.

  • Стабильная производительность против сезонности бизнеса.

  • Формальные церемонии против необходимости быстрых изменений, приоритизации и внедрения в условиях стартап‑мышления.

• Kanban:
  

  • Ограниченна емкость «работ в процессе» против дедлайнов и гонки за функционалом.

  • Структурированные доски и рабочий процесс с карточками против жестко диктуемых заказчиком, негибких рабочих процессов в Jira.

• FDD:
  

  • Фокус на фиче против поддержки нескольких OKR и необходимости взаимодействия между командами продукта.

Что самое важное?

Чтобы адаптировать наш рабочий процесс к этим сложностям, мы выделили несколько ключевых ценностей:

1. КОГДА дата релиза на маркетплейсы? (Когда конечный пользователь должен увидеть эту функцию, независимо от графиков выпуска и т. д.)

2. ЧТО ожидается к выпуску к этому моменту? (Бизнес‑цели или метрики, которые мы пытаемся поддержать)

3. ЧТО мы можем реально предоставить к этому времени? (Какую версию фичи мы можем спланировать как MVP)

4. ЧТО нам нужно изменить сейчас, чтобы это выполнить? (Объем работы для fixversion, распределение задач между разработчиками, выпустить патч, создание интеграционного snapshot)

В этом месте статьи хочу сослаться на отличное переосмысление от Henrik Kniberg под названием Making sense of MVP. Статья, которая помогла преодолеть бизнес‑аналитическую косность восприятия и взглянуть на процесс с точки зрения пользователя и продукта.

Кунг-Фу начинается здесь...

Шаги, которые мы предприняли в формате рекомендаций:

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

2. Используйте «fixversions» с переменной продолжительностью и объемом вместо спринтов. Это позволит выкатывать функциональные версии фич, а не сырые заготовки.

3. Определяйте состав fixversions с точки зрения пользователя и его ожиданий. Это сильно поможет с приоритетами.

4. Все новые и старые баги распределяйте по 3 «ведрам» (эпикам или лэйблам): срочно поправить, поправить побыстрее и поправить когда‑нибудь. Это очистит вашу доску и избавит от ежедневных мук приоритизации.

5. Планируйте релиз вашей fixversions на основе мощности QA. Это повысит точность планов и предусмотрит bottleneck effect.

6. Сокращайте совещания до необходимого минимума: если команде не особо помогает ретро, то избавьте всех от ретро и других «звонков ради звонков». Лиды разработки, QA и BA вполне в состоянии заниматься планированием, оценкой и feasibility check в то время, как инженеры заняты задачами.

7. Сообщайте обо всем (планы, изменения планов, риски, сомнения). Поддерживайте прозрачную коммуникацию с командой заказчика, и это ощутимо добавит свободы в принятии самостоятельных решений.

Ownership

Красная линия, пересекающая эту тему, — ownership. Хотя это заслуживает более глубокого обсуждения, вкратце: стремитесь заполнить любую пустоту в зонах ответственности, связанных с процессом или продуктом. Создав образ вовлеченного, проактивного и ответственного лидера перед заказчиком, вы получите зеленый свет не только на решения, но и на изменения в процессах.

В результате

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

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

Если вы хотите поделиться своими мыслями, идеями, вопросами или критикой, — заходите в мой Telegram канал @kutuzovvaiti.