Демонстрация работы: show & tell

Show & tell (Sprint Review / Demo) — регулярная встреча, на которой команда демонстрирует stakeholders готовую работу за спринт и собирает обратную связь.

Зачем нужно

Демо — самый прямой путь от разработчика к пользователю/бизнесу. Оно создаёт прозрачность, проверяет, что построили то, что нужно, и мотивирует команду видеть результаты своей работы. Для разработчика умение демонстрировать и объяснять — критический навык для карьерного роста.

Где используется

Scrum Sprint Review — официальное событие в конце спринта
RS School — финальное демо командного проекта
Собеседования — "расскажи о проекте, который ты делал"
Внутренние демо — show & tell внутри команды

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

1. Контекст (1–2 мин)
   "В этом спринте мы работали над системой авторизации.
    Цель была: пользователи могут регистрироваться и входить."

2. Демонстрация (основная часть)
   Показывай живой продукт, а не слайды
   Пройди типичный сценарий пользователя:
   - Регистрация → Подтверждение email → Вход → Профиль

3. Акцент на ценности, не на коде
   ПЛОХО: "Мы сделали JWT middleware с refresh token logic"
   ХОРОШО: "Теперь пользователи остаются авторизованными 30 дней"

4. Edge cases и ограничения
   "Сейчас не реализовано: OAuth (следующий спринт)"

5. Вопросы и обратная связь
   "Что думаете? Что изменить или добавить?"

Подготовка к демо

За день до демо:
□ Деплой на staging или prod
□ Подготовить сценарий (что показываешь и в каком порядке)
□ Проверить, что всё работает на реальных данных
□ Подготовить fallback (скриншоты/видео если демо упадёт)

Перед демо:
□ Закрыть лишние вкладки, почту, уведомления
□ Увеличить шрифт / zoom в браузере (читаемо на экране)
□ Проверить звук и видео (remote)
□ Открыть нужные вкладки заранее

Техника рассказа про проект

Структура STAR (для собеседований и демо):
Situation  — контекст, в чём была проблема
Task       — что требовалось сделать
Action     — что именно ты сделал (конкретно)
Result     — что получилось, метрики если есть

Пример:
S: "Команда RS School, проект трекер задач"
T: "Нужно было сделать авторизацию за неделю"
A: "Реализовал JWT, refresh tokens, защищённые роуты"
R: "Все 5 сценариев прошли тесты, деплой на Vercel"

Частые ошибки

Ошибка	Проблема	Решение
Показывать код вместо продукта	Stakeholders не понимают код	Только live-демо UI/API, код — по запросу
Готовить демо на "сырых" данных	Падает, выглядит непрофессионально	Подготовить seed-данные заранее
Говорить только о проблемах	Создаёт тревогу, нет ощущения прогресса	Сначала что сделано, потом что нет
Очень длинное демо (45+ мин)	Аудитория теряет внимание	Цель: 15–20 минут максимум