Демо спринта

В разработке периодически возникает необходимость показать продакту, руководству или стейкхолдерам, что было сделано. Чтобы руководитель остался доволен, а стейкхолдеры воодушевлённо готовили пачки купюр — надо уметь проводить демонстрацию.

За шесть лет регулярных демо я выработал несколько правил, которые помогают к ним готовиться и проводить их без лишнего стресса.

Готовьтесь

Готовьтесь к демонстрации заранее. Расчёт на импровизацию может закончиться заваленной презентацией, забытыми фичами и лишними паузами в попытках вспомнить, что делать дальше.

Напишите сценарий и заранее прогоните его целиком. За час до демонстрации полезно прогнать сценарий ещё раз. Так я не раз обнаруживал, что стенд сломан и его надо срочно чинить.

За 10 минут до демонстрации подготовьте всё, что вам может понадобиться: откройте вкладки, авторизуйтесь, запустите программы. Всё, что зрителю неинтересно и нельзя сделать за несколько секунд, подготовьте заранее.

Разделяйте речь и действия

Сценарий удобно писать в два слоя: речь и действия. Речь — то, что вы говорите аудитории. Действия — то, что вы в этот момент делаете в интерфейсе.

По умолчанию текст сценария — речь. Действия оформляйте так, чтобы их можно было мгновенно отличить от речи. Я использую для этого Markdown-цитаты:

> Нажать кнопку «Загрузить»
> Выбрать файл
> Показать курсором, что появился индикатор загрузки

Вставляйте действие ровно в то место сценария, где его нужно выполнить. Описывайте действия настолько конкретно, чтобы по ним демонстрацию смог провести другой человек. Конкретика особенно полезна во время самого демо: не приходится одновременно вспоминать, что говорить и куда нажимать.

Показывайте

Зрители фильмов заскучают, если сюжет будет рассказан текстом на экране и закадровым голосом. Им нужны меняющиеся кадры. C демо так же: оно должно меняться на глаза у зрителя. Если пять минут ничего не происходит на экране, внимание переключается на что-нибудь другое.

Если результат можно показать — покажите. Если задача сама по себе не имеет визуализацию, придумайте другой способ показать результат: схему, график, слайды, лог выполнения.

Рассказывайте

Не превращайте демо в сухой отчёт — это скучно. Используйте разговорный стиль. Допустимы лёгкие шутки и самоирония, но они не должны превращать демонстрацию в стендап.

Говорите бодро и уверенно. Состояние заразно: если вы говорите нудно, слушателям тоже будет скучно.

Хорошо работает честность: если сразу проговорить проблемы и ограничения, можно избежать части неприятных вопросов позже. Если попутно с выполнением задачи сломали что-то другое — расскажите об этом, всё равно заметят.

Объясняйте

Не перечисляйте выполненные задачи. Для каждой из них стройте рассказ по цепочке проблема → решение → польза.

Используйте термины из мира пользователя и бизнеса, а не разработчика. Если технический термин неизбежен — объясните значение и пользу.

Соблюдайте структуру

Хорошая демонстрация должна идти по понятному маршруту. Зрителю не приходится гадать, почему вы внезапно открыли другой раздел системы и как он связан с тем, что было минуту назад.

Структура не должна быть заметна зрителю как формальный план. Её задача — сделать демонстрацию последовательной: сначала дать контекст, затем провести по изменениям и закончить понятным следующим шагом.

Перед демонстрацией проверьте, что сценарий состоит из нескольких последовательных частей:

1. Предварительные условия

Запишите, какой стенд открыть, под кем авторизоваться и какие данные подготовить заранее. Например: «сотруднику провести ревью и составить ИПР минимум из пяти пунктов». Это служебная часть сценария, зрителям её показывать не нужно.

2. Вступление

В двух–четырёх предложениях поприветствуйте участников и напомните, над чем работали в этой итерации.

3. Разделы по модулям

Начинайте с естественной точки входа пользователя и двигайтесь вглубь системы. Старайтесь выстроить действия так, чтобы каждый следующий клик продолжал предыдущий, а не заставлял прыгать между несвязанными экранами.

4. «Невидимая» работа

Отдельно расскажите про рефакторинг, инфраструктуру и внутренние инструменты, если они были существенной частью работы. Переводите технический результат на язык пользы: «реже сталкиваться с проблемами», «быстрее выпускать изменения», «меньше зависеть от одного человека».

5. Финал

Коротко расскажите, что планируется дальше, и пригласите участников задавать вопросы.