Оценка команды с разными методами

Единая методология оценки: Story Points + QA Hours

Проблема реальна: Dev оценивают поинтами (относительная сложность), QA оценивают часами (абсолютное время). Нужна система, которая объединяет оба подхода.

1. Объяснение команде: Story Points for Everyone

Главная идея: Story Point = относительная сложность, НЕ часы.

Шкала:

• 1 point = простой (Dev: 1 час, QA: 30 мин)
• 3 points = средний (Dev: 2-3 часа, QA: 1-2 часа)
• 5 points = сложный (Dev: 4-8 часов, QA: 4-6 часов)
• 8 points = очень сложный (Dev: 1-2 дня, QA: 1 день)
• 13+ points = слишком сложный, нужно сплитить

Для QA: "Ты оцениваешь не только тестирование, но и:

1. Понимание требований (+15-30 мин)
2. Планирование тестов (+15-30 мин)
3. Manual execution (+X часов)
4. Баг-репорты (+30 мин за баги)
5. Регрессия (+10-20% от total)"

2. Подход: Hybrid Estimation

На Planning meeting:

Dev говорит: "5 points"
QA говорит: "6 часов"
PM говорит: "Total estimate = 5 + (6/4) = 6.5 points ≈ 8 points"

Conversion formula:

• 1 Story Point Dev = 4-5 часов work
• QA hours / 4 = QA points equivalent
• Total points = Dev points + QA points

В Jira:

• Field 1: Dev Story Points (обязательно)
• Field 2: QA Hours (обязательно для QA)
• Field 3: Risk Level (Low/Medium/High)
• Calculated: Total Points = Dev + QA/4

3. Учёт специфики QA

Проблема 1: QA недооценивает

Решение: Чек-лист для оценки

☐ Понимание требований: +15-30 мин
☐ Планирование тестов: +15-30 мин
☐ Manual testing: +X часов
☐ Bug reporting: +30 мин
☐ Regression: +10-20% от total

Проблема 2: QA приносит surprises

Решение: Early QA involvement

• QA читает feature на Planning (не потом)
• QA видит код в WIP (среда/четверг, не пятница)
• QA пишет acceptance criteria вместе с Product

Проблема 3: QA не может предсказать баги

Решение: Risk-based estimation

Base time × Risk multiplier
- Low risk (новая simple feature): base × 1.0
- Medium risk (integration): base × 1.25
- High risk (legacy code, external APIs): base × 1.5

Пример: Интеграция с OAuth
Base: 3 часа × 1.5 (high risk) = 4.5 часов

4. Definition of Done для единства

✅ DEVELOPMENT:
☐ Code written
☐ Unit tests > 80%
☐ Code reviewed
☐ Merged to main

✅ QUALITY:
☐ Test cases written
☐ Manual testing done
☐ Bugs found < threshold
☐ Regression passed

✅ DEPLOYMENT:
☐ Staged
☐ Production checklist
☐ Ready to ship

Важно: Это не "когда Dev готов". Это "когда ВСЕ готовы".

5. Planning Meeting: New Structure (2 hours)

00:00-00:10: Requirements review
- PO читает story
- Dev спрашивает: "Какие форматы? Размеры?"
- QA спрашивает: "Что если ошибка? Edge cases?"

00:10-00:30: Dev estimation
- Dev говорит points
- Tech Lead validates

00:30-00:50: QA estimation
- QA говорит часы (с разбором)
- QA говорит risks

00:50-01:00: Validation
- PM: "Total estimate = 6.5 points. Ок?"
- Если QA > 10 часов: может быть, feature слишком сложна?

01:00-02:00: Repeat for all stories

6. Метрики для мониторинга

Неделю 1-2: Калибровка

• Что Dev оценил в 5 points, сколько часов было реально?
• Что QA оценил в 6 часов, сколько было реально?

Неделю 3+: Стабилизация

• Accuracy > 80%
• Surprises < 20%

7. Главный разговор с командой

"Мы используем разные метрики: Dev в points, QA в часах. Это создаёт confusion.

Вот новая система: оба даёте оценки, потом мы их объединяем в один total estimate.

Почему это работает:

1. Honesty — видна реальная работа (не только код)
2. Planning — спринты более реалистичные
3. No surprises — обе стороны на одной странице

Первые 2 спринта — калибровка. Потом будет ясно.

Вопросы?"