Что такое Delivery фаза?

Что такое Delivery фаза

Определение

Delivery фаза (фаза разработки) — это период в жизненном цикле проекта, когда требования из Discovery превращаются в готовый продукт. Это фаза между планированием и запуском (launch) продукта.

Основная структура Delivery

Discovery (согласование требований)
    ↓
Delivery (разработка и тестирование) ← мы здесь
    ├─ Разработка (Development)
    ├─ QA и тестирование
    ├─ Интеграция
    └─ Демонстрации (Demo)
    ↓
Launch (запуск продукта)
    ↓
Support (поддержка и улучшения)

Фазы Delivery

1. Архитектурный дизайн (1-2 недели)

Что происходит:

• Технический lead проектирует архитектуру системы
• Определяются технологический стек
• Выбираются инструменты и фреймворки

Роль BA:

• Валидирую, что архитектура поддерживает требования
• Помогаю определить интеграции
• Убеждаюсь, что нет неожиданных сложностей

Артефакты:

• Архитектурные диаграммы
• Выбранные технологии с обоснованием
• C4 Model (System Context, Container, Component, Code)

2. Development (основная работа, 8-16 недель)

Что происходит:

• Разработчики пишут код
• Обычно делится на спринты (2 недели)
• Каждый спринт имеет планирование, разработку, демонстрацию

Роль BA:

• Уточняю требования, когда разработчики натыкаются на вопросы
• Пишу тесты (тестовые сценарии)
• Следю за прогрессом
• Обновляю документацию

Типичный спринт:

Понедельник утро: Sprint Planning (2 часа)
  - Выбираем user stories для спринта
  - Оцениваем сложность (story points)

Вторник-Четверг: Development
  - Daily standup (15 мин) — что сделал, что буду делать, есть ли блокеры
  - Разработка фич
  - Code review
  - Внутреннее тестирование

Пятница: Sprint Review + Retro
  - Демонстрация готовых фич
  - Feedback от Product Owner
  - Retro — что улучшить в процессе

Артефакты:

• Sprint backlog
• Daily standup notes
• Burndown chart (насколько выполнен спринт)

3. QA и тестирование (параллельно с dev)

Что происходит:

• QA инженеры тестируют готовый код
• Поиск багов и несоответствий требованиям
• Регрессионное тестирование
• Нагрузочное тестирование (если критично)

Роль BA:

• Пишу тестовые сценарии (test cases) на основе требований
• Участвую в test review
• Уточняю требования при обнаружении несоответствий

Пример тестового сценария:

Test Case: TC-001 Проверка валидации email при регистрации

Pre-conditions:
- Пользователь на странице регистрации
- Browser: Chrome последний версия

Steps:
1. Введите "invalid-email" в поле Email
2. Нажмите кнопку "Регистрация"
3. Проверьте сообщение об ошибке

Expected Result:
- Красное сообщение: "Пожалуйста, введите корректный email"
- Кнопка регистрации остаётся disabled
- Email не сохраняется в БД

Actual Result:
- [заполняет QA]

Status: PASS / FAIL
Bug ID (если fail): [ссылка на bug]

4. Integration (интеграция компонентов)

Что происходит:

• Различные модули интегрируются
• Проверяется взаимодействие между компонентами
• Интеграция с внешними сервисами (API, платежи, etc)

Примеры:

• Фронтенд подключаешь к бэкенду
• Подключаешь платёжную систему
• Интегрируешь email сервис

Роль BA:

• Участвую в интеграционных встречах
• Документирую API контракты
• Проверяю, что интеграция не добавила новые требования

5. Демонстрации (Demo)

Что происходит:

• Раз в неделю или раз в 2 недели показываем готовые фичи stakeholder'ам
• Собираем feedback
• Уточняем требования, если нужно

Роль BA:

• Подготавливаю сценарии демонстрации
• Объясняю stakeholder'ам, что было сделано
• Собираю feedback и обновляю product backlog

Структура демо:

1. Context (что было сделано и зачем) — 2 мин
2. Live demo (показываю фичи) — 10-15 мин
3. Feedback (слушаю замечания) — 5-10 мин
4. Next steps (что будет дальше) — 2 мин

Длительность Delivery

Зависит от:

• Размера проекта
• Сложности
• Методологии (Waterfall vs Agile)

Примеры:

• Простой проект (5 разработчиков): 2-4 месяца
• Средний проект (20 разработчиков): 4-6 месяцев
• Крупный проект (50+ разработчиков): 6-18 месяцев

Difference: Waterfall vs Agile Delivery

Роль BA в Delivery

Ключевые деятельности:

• Requirements clarification — ежедневные вопросы от разработчиков
• Test case creation — писать тесты на основе требований
• Acceptance criteria — убедиться, что разработчик понимает, когда фича готова
• Risk management — выявить проблемы рано
• Change management — управлять изменениями требований
• Documentation — обновлять спецификации

Типичное распределение времени BA в Delivery:

40% — Уточнение требований (вопросы разработчиков)
25% — Тестирование и написание test case'ов
20% — Встречи и синхронизация (standup, demo, planning)
15% — Документирование и обновление requirements

Метрики Delivery фазы

• Burn-down chart — сколько работы осталось в спринте
• Velocity — сколько story points команда делает за спринт
• Defect rate — количество багов на 100 строк кода
• Test coverage — сколько процентов кода покрыто тестами
• On-time delivery — выполнили ли спринт в срок

Вывод

Delivery фаза — это долгий марафон, где BA как переводчик между требованиями и реальностью. Ошибки в Discovery можно ещё поправить, но в середине Delivery — это становится дорогостоящим. Хороший BA в Delivery фазе:

✅ Отвечает на вопросы быстро ✅ Пишет ясные тестовые сценарии ✅ Ловит проблемы рано ✅ Не меняет требования без причины ✅ Полностью понимает, что разработчик делает