Демонстрация спринта — очень важная часть Scrum’а, которую многие все же недооценивают. «Ой, а нам что, обязательно делать демо? Мы все равно ничего интересного не покажем!» «У нас нет времени на подготовку разных &%$# демо!» «У меня куча работы, не хватало еще смотреть чужие демо!»

Хорошо выполненное демо оказывает огромное воздействие, даже если оно не показалось захватывающим.

• Положительная оценка работы воодушевляет команду.

• Все остальные узнают, чем занимается ваша команда.

• На демо заинтересованные стороны обмениваются жизненно важными отзывами.

• Демо проходит в дружеской атмосфере, поэтому разные команды могут свободно общаться между собой и обсуждать насущные вопросы. Это ценный опыт.

• Проведение демо заставляет команду действительно доделывать задачи и выпускать их (даже если это всего лишь на тестовый сервер). Без демо мы постоянно оказывались с кучей на 99 % сделанной работы. Проводя демо, мы можем получить меньше сделанных задач, но они будут действительно закончены, что (в нашем случае) намного лучше, чем куча функционала, который «типа» сделан и будет болтаться под ногами в следующем спринте.

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

Это очень неприятно. Но это действует, как горькая пилюля. В следующем спринте команда действительно постарается все доделать! Они будут думать «ладно, может, в следующем спринте стоит показать всего две вещи вместо пяти, но, черт возьми, в этот раз они будут РАБОТАТЬ!». Команда знает, что демо придется проводить не смотря ни на что, и благодаря этому шансы увидеть там что-то пристойное значительно возрастают. Я несколько раз был этому свидетелем.

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

• Не тратьте много времени на подготовку демо, особенно на создание эффектной презентации. Выкиньте всё ненужное и сконцентрируйтесь на демонстрации только реально работающего кода.

• Следите, чтобы демо проходило в быстром темпе. Сконцентрируйтесь на создании не столько красивого, сколько динамичного демо.

• Пусть ваше демо будет бизнес-ориентированным, забудьте про технические детали. Сфокусируйтесь на том «что мы сделали», а не на том «как мы это делали».

• Если это возможно, дайте аудитории самой попробовать поиграть с продуктом.

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

Член команды: «Я не собираюсь демонстрировать эту задачу, потому что её невозможно продемонстрировать. Я говорю про историю 'Улучшить масштабируемость системы так, чтобы она могла обслуживать одновременно 10 000 пользователей'. Я, по-любому, не смогу пригласить на демо 10 000 пользователей».

ScrumMaster: «Так, ты закончил с этой задачей?»

Член команды: «Ну, конечно».

ScrumMaster: «А как ты узнал, что оно потянет?»

Член команды: «Я сконфигурировал нашу систему в среде, предназначенной для тестирования производительности, и нагрузил систему одновременными запросами с восьми серверов сразу». ScrumMaster: «Так у тебя есть данные, которые подтверждают, что система может обслужить 10 000 пользователей?»

Член команды: «Да. Хоть тестовые сервера и слабенькие, однако, в ходе тестирирования они всё равно справились с 50 000 одновременных запросов». ScrumMaster: «Так, а откуда у тебя эта цифра?»

Член команды (расстроенный): «Ну, хорошо, у меня есть отчёт! Ты можешь сам глянуть на него, там описано как всё это дело было сконфигурировано и сколько запросов было отослано!» ScrumMaster: «О, отлично. Это и есть твоё „демо“. Просто покажи этот отчёт аудитории и вкратце пробегись по нему. Всё же лучше, чем ничего, правда?»

Член команды: «А что, этого достаточно? Правда он выглядит как-то корявенько, надо бы его немножко шлифануть».

ScrumMaster: «Хорошо, только не трать на это слишком много времени. Он не обязан быть красивым, главное — информативным».