Какая роль аналитика в Agile?

Какая роль аналитика в Agile?

Трансформация роли Business Analyst в Agile

Это критический вопрос, потому что роль BA кардинально изменилась с появлением Agile методологии. 10-15 лет назад я был «стеной требований» между бизнесом и разработкой. Сейчас я интегрирован в команду и работаю иначе. Расскажу, как.

Старый подход (Waterfall) vs Новый подход (Agile)

В Waterfall (2010-е годы):

• BA собирает ВСЕ требования сразу (3-6 месяцев)
• Пишет большой документ SRS на 200+ страниц
• Сдает разработчикам и ждет результата
• Отвечает на вопросы по требованиям
• Проверяет готовый продукт
• Роль: документалист и судья

В Agile (сейчас):

• BA работает с Product Owner и командой в одном спринте
• Пишет небольшие User Stories (1-2 страницы)
• Постоянно взаимодействует с разработчиками
• Помогает уточнять требования во время разработки
• Участвует в демо и планировании
• Роль: фасилитатор и партнер

Ключевые различия в подходе

Роль Аналитика (BA) в Agile

Я вижу роль BA в Agile как 5 основных функций:

1. Product Backlog Refinement (30% времени)

Это САМАЯ ВАЖНАЯ роль BA в Agile. За неделю до спринта:

• Работаю с Product Owner, чтобы определить stories для спринта
• Пишу User Stories в правильном формате
• Добавляю Acceptance Criteria
• Рисую mockups (если нужны)
• Уточняю у stakeholders все вопросы
• Проверяю, что stories готовы к разработке (Definition of Ready)

Пример подготовки:

Before Sprint:
Процесс:
1. Вторник 10:00 - обсуждение с PO (какие stories нужны)
2. Вторник 14:00 - уточнение с бизнесом
3. Среда 10:00 - дизайн и mockups
4. Среда 15:00 - техническое уточнение с lead разработчиком
5. Четверг - финализация stories

Результат:
- 10 stories готовы к спринту
- Разработчики знают, что делать
- Нет неясностей

2. Sprint Collaboration (40% времени)

Во время спринта я работаю с командой:

Daily Standup:

• Слушаю, есть ли вопросы по требованиям
• Быстро отвечаю на уточнения
• Не позволяю разработчикам гадать

Пример диалога:

Девелопер: "При удалении заказа, нужно удалить строки в БД?"
Я: "Нет, помечаем флаг is_deleted=true. Оригинальные данные нужны для audit."
Девелопер: "ОК, понял"

Pair Programming сессии:

• Иногда сидим с разработчиком вдвоем
• Я объясняю бизнес-логику
• Разработчик объясняет технические constraints
• Вместе находим оптимальное решение

QA поддержка:

• QA спрашивает, как проверить функцию
• Я объясняю, как должно работать
• Написали вместе test cases

3. Requirements Clarification (15% времени)

Когда возникают вопросы:

• Разработчик не понимает, как должно работать
• Дизайнер спрашивает о граничных случаях
• QA находит поведение, которое не указано в требованиях

Я:

1. Быстро находу ответ (у себя в голове или у stakeholder)
2. Документирую решение (в Jira comment)
3. Синхронизирую команду

Пример:

QA: "Что показывать, если в фильтре нет результатов?"
Я: "Пусто, с текстом 'Ничего не найдено'. Дизайнер одобрил."
Документ: Добавляю в Acceptance Criteria

4. Демонстрация и Feedback (10% времени)

В конце спринта:

• Демо для stakeholders
• Собираю feedback
• Документирую issues/suggestions
• Приоритизирую для следующих спринтов

5. Retrospective и Improvement (5% времени)

• Участвую в retro
• Предлагаю улучшения процесса
• Помогаю команде стать более эффективной

Как я работаю с Product Owner

Внимание: BA НЕ = Product Owner!

Это разные роли:

Product Owner:

• Определяет, ЧТО нужно делать (видение, roadmap)
• Отвечает за приоритеты
• Принимает финальные решения по требованиям
• Коммуницирует с бизнесом

Business Analyst:

• Определяет, КАК это нужно делать (детали, техническое решение)
• Помогает PO структурировать требования
• Отвечает на вопросы разработчиков
• Создает документацию и mockups

Мое взаимодействие с PO:

ПО: "Хочу добавить search на сайте"
Я: "ОК, давайте уточним требования:
  - Что искать? (товары, статьи, комментарии?)
  - По каким полям? (название, описание?)
  - Как быстро должна быть поиск? (instant vs по Enter?)
  - Что показать в результатах? (список с превью?)
  - Есть ли budget на performance?

  Я предлагаю MVP версию:
  - Поиск только по названиям товаров
  - Поиск по Enter
  - Результаты 10 товаров на странице
  - Время ответа < 1 сек

ПО: "Perfect, это то, что нам нужно для v1"
Я: "В следующих версиях можно добавить полнотекстовый поиск, фильтры, и т.д."

Как я работаю с разработчиками

Я НЕ:

• Не даю команде команды (это делает Scrum Master)
• Не проверяю код (это делает tech lead и code review)
• Не управляю людьми

Я:

• Объясняю, почему нужна эта функция (context)
• Помогаю разобраться в сложных требованиях
• Отвечаю на вопросы быстро
• Предлагаю альтернативные решения
• Учусь из их feedback

Пример диалога:

Девелопер: "Этот фильтр медленный, нам нужен индекс в БД"
Я: "Сколько это добавит времени?"
Девелопер: "1 день плюс 1 день на тесты"
Я: "ОК, это стоит того. Давайте включим в story.
И спасибо, что предложил оптимизацию!"

Типичный день BA в Agile

9:00 - Daily Standup (15 мин)
  Я слушаю, есть ли блокирующие вопросы

9:30 - Уточнение требований (30 мин)
  QA: "Как тестировать X?"
  Девелопер: "Что если user сделает Y?"

10:30 - Refinement session (60 мин)
  Работаю с PO над следующими stories
  Пишу Acceptance Criteria
  Рисую mockups

12:00 - Обед

13:00 - Pair session с разработчиком (60 мин)
  Обсуждаем архитектуру для новой фичи
  Я объясняю бизнес логику
  Он предлагает технические constraints

14:30 - Stakeholder meeting (30 мин)
  Уточняю требования с бизнесом
  Собираю feedback

15:15 - Documentation (30 мин)
  Обновляю Confluence
  Документирую решения

16:00 - Preparation для следующего дня
  Готовлю материалы
  Отвечаю на вопросы по email

17:00 - Уход

Ключевые скилы BA в Agile

Hard Skills:

• User Stories написание
• Mockups (Figma, Sketch)
• SQL для простых аналитических запросов
• Понимание API и интеграций

Soft Skills (ВАЖНЕЕ!):

• Коммуникация (объясняю сложное просто)
• Active listening (слушаю, не перебиваю)
• Flexibility (требования меняются, адаптируюсь)
• Empathy (понимаю боли пользователей и разработчиков)
• Problem solving (помогаю найти решение)

Типичные ошибки BA в Agile

❌ Пишу слишком подробные требования

• Agile это не Waterfall
• "Работающее ПО важнее полной документации"

❌ Избегаю разработчиков

• BA ДОЛЖЕН работать с командой каждый день
• Написал requirements и ушел = плохой BA

❌ Не участвую в демо

• Демо это не просто "показ разработчика"
• Я должен проверить, что сделано правильно

❌ Беру слишком много на себя

• Не я принимаю решения, это PO
• Я помогаю, не управляю

❌ Не учусь у разработчиков

• Они знают много о технических constraints
• Хороший BA учится каждый день

Эволюция за 10+ лет

2010: BA = документалист (200 страниц SRS) 2013: BA = аналитик (анализирую требования) 2016: BA = фасилитатор (помогаю команде разобраться) 2020: BA = партнер (работаю вместе с командой) 2025: BA = интегрированный член спринта (часть scrum team)

Итог: Роль BA в Agile

✅ Подготавливаю stories перед спринтом (Definition of Ready) ✅ Работаю с командой во время спринта (ежедневно) ✅ Отвечаю на вопросы быстро и ясно ✅ Собираю feedback в конце спринта ✅ Помогаю улучшить процесс в retro ✅ Партнер, а не судья — я в одной команде с разработчиками

Главное изменение: Я перестал быть "стеной между бизнесом и разработкой" и стал мостом, который помогает им понять друг друга.

В Agile успех зависит не от объема документации, а от качества коммуникации и взаимопонимания в команде. Моя роль — обеспечить это взаимопонимание.