Dual-Track Agile: Discovery и Delivery параллельно

Dual-Track Agile — подход, при котором Discovery (что строить) и Delivery (как строить) идут параллельно. Это решает проблему «сначала исследуем полгода, потом строим полгода».

Проблема последовательного подхода

Waterfall: Discovery (3 мес) → Design (2 мес) → Development (4 мес) → Launch

Проблемы: - Долго до первого результата - Discovery устаревает к моменту launch - Нет feedback loop

Dual-Track решение

``` Discovery Track: [Исследуем Sprint N+1] [Исследуем Sprint N+2] Delivery Track: [Строим Sprint N] [Строим Sprint N+1] ```

Discovery опережает Delivery на 1-2 спринта.

Структура команды

Product Trio: - Product Manager — владеет Discovery и Delivery - Designer — участвует в Discovery, создаёт дизайн для Delivery - Tech Lead — оценивает feasibility в Discovery, ведёт разработку в Delivery

Разработчики: - Основное время в Delivery - Участвуют в Discovery: технические spike'и, оценки

Артефакты Discovery Track

1. Opportunity Solution Tree - Outcome (цель) - Opportunities (возможности) - Solutions (решения) - Experiments (эксперименты)

2. Validated Backlog - Идеи, прошедшие валидацию - Ready для Delivery

3. Experiment Results - Что проверяли - Что узнали - Что дальше

Как организовать Discovery

Continuous Discovery: - Минимум 1 интервью в неделю - Регулярные usability-тесты - A/B-эксперименты на проде

Типы Discovery-активностей

| Активность | Время | Частота | |------------|-------|----------| | User interview | 1 час | 2-3/неделю | | Usability test | 30 мин | 2-3/неделю | | Prototype testing | 1 день | По необходимости | | Data analysis | 2-4 часа | Еженедельно |

Координация Discovery и Delivery

Ритуалы

1. Weekly Discovery Sync (30 мин) - Что узнали на этой неделе? - Какие гипотезы проверяем? - Что готово для Delivery?

2. Sprint Planning включает: - Review Discovery результатов - Выбор validated идей для спринта

3. Sprint Review включает: - Demo Delivery результатов - Share Discovery инсайтов

Когда Discovery готов для Delivery

Definition of Ready из Discovery: - [ ] Проблема валидирована (данные + интервью) - [ ] Решение протестировано (прототип/smoke test) - [ ] Feasibility подтверждена (tech lead) - [ ] User Stories написаны - [ ] Design готов (если нужен)

Типичные проблемы и решения

1. Discovery отстаёт от Delivery

Симптом: команда ждёт работу или берёт невалидированные идеи.

Решение: - Увеличить capacity на Discovery - Параллелить несколько Discovery streams - Иметь буфер валидированных идей

2. Discovery опережает слишком сильно

Симптом: инсайты устаревают до реализации.

Решение: - Быстрее переносить в Delivery - Меньше исследовать вперёд - Re-validate перед началом работы

3. Команда не верит в Discovery

Симптом: «Давайте просто построим и посмотрим».

Решение: - Показывайте ROI Discovery (сэкономленное время) - Вовлекайте разработчиков в интервью - Celebrate wins от Discovery

Метрики Dual-Track

Discovery: - Количество интервью в неделю - Time-to-validate (от идеи до валидации) - Hit rate (% валидированных гипотез)

Delivery: - Velocity - Lead time - Quality (bugs)

Интегрированные: - Time-to-market (от идеи до прода) - Success rate (% фичей, достигших целевых метрик)

Визуализация ключевых концепций

flowchart TD
    subgraph Методологии["Agile методологии"]
        SCRUM["Scrum"]
        KANBAN["Kanban"]
        SAFE["SAFe"]
    end...