49 / 94
Scrum и XP: заметки с передовой
49
•
Пусть ваше демо будет бизнес-ориентированным, забудьте про технические детали.
Сфокусируйтесь на том "что мы сделали", а не на том "как мы это делали".
•
Если это возможно, дайте аудитории самой попробовать поиграть с продуктом.
•
Не нужно показывать кучу исправлений мелких багов и элементарных фич. Вы можете упомянуть
о них, но демонстрировать их не стоит, потому что это заберёт у вас много времени и снизит
внимание к более важным историям.
Что делать с "недемонстрируемыми" вещами
Член команды:
"Я не собираюсь демонстрировать эту задачу, потому что её невозможно
продемонстрировать. Я говорю про историю 'Улучшить масштабируемость системы так, чтобы она могла
обслуживать одновременно 10 000 пользователей'. Я, по-любому, не смогу пригласить на демо 10 000
пользователей".
ScrumMaster:
"Так, ты закончил с этой задачей?"
Член команды:
"Ну, конечно".
ScrumMaster:
"А как ты узнал, что оно потянет?"
Член команды:
"Я сконфигурировал нашу систему в среде, предназначенной для тестирования
производительности, и нагрузил систему одновременными запросами с восьми серверов сразу”.
ScrumMaster:
"Так у тебя есть данные, которые подтверждают, что система может обслужить 10 000
пользователей?"
Член команды:
"Да. Хоть тестовые сервера и слабенькие, однако, в ходе тестирирования они всё равно
справились с 50 000 одновременных запросов".
ScrumMaster:
"Так, а откуда у тебя эта цифра?"
Член команды
(расстроенный)
:
"Ну, хорошо, у меня есть отчёт! Ты можешь сам глянуть на него, там
описано как всё это дело было сконфигурировано и сколько запросов было отослано!"
ScrumMaster:
"О, отлично. Это и есть твоё "демо". Просто покажи этот отчёт аудитории и вкратце
пробегись по нему. Всё же лучше, чем ничего, правда?"
Член команды:
"А что, этого достаточно? Правда он выглядит как-то корявенько, надо бы его немножко
шлифануть".
ScrumMaster:
“Хорошо, только не трать на это слишком много времени. Он не обязан быть красивым,
главное – информативным”.