Agile Base Camp 29 Мая в Киве: что я там увидел (Начало. Sprint Demo)

Начну с благодарностей:
Наташе Трениной огромное спасибо за приглашение на конференцию в роли волонтера.
Лиане Шишкиной спасибо - именно от тебя я узнал про команду тренеров Agile.
Спасибо команде волонтеров - с вами было легко и весело.
Спасибо докладчикам: Андрей Бабичев и его "Think different", Артем Сердюк и его "Agile - нечто большее чем просто инструмент? Сказка-быль", Александр Якима и его "Демо итерации: искусство продавать", Николай Алименков и Алексей Солнцев и их "Применение практики Code Review для улучшения качества продукта" и Тимофей Евграшин и его "Подводные камни управления agile проектом - как ответить на вопросы "когда?" и "сколько стоит?"".

Теперь ближе к тому, что меня зацепило. Походу докладов я то и дело выписывал что-то маркером на листочек. Этим и поделюсь. Читать дальше...
Александр Якима поделился своим опытом проведения demo спринтов. Очень интересно слушать человека опытного. Не важно в какой области - главное опытного. А опыта у Александра много - более 200 демо. Казалось бы "чего там?", а не все так просто.

Дальше я привожу мою интерпретацию услышанного, никаких цитат Александра в тексте не будет - всего лишь мой пересказ на тему Demo. Не верьте ни единому моему слову - проверяйте на практике, экспериментируйте. Agile - это эксперимент.

Итак, demo - самая важная часть в разработке. Именно на основании demo у Product Owner'а будет составлено мнение и о команде и о проделанной работе: в код и архитектуру Product Owner не заглянет. А готовиться demo надо с самого первого дня спринта.

Александр призывал перед тем, как угостить кого либо вином из бутылки, испробовать из нее же самому. В demo это можно и стоит сделать со свой командой. Перед тем, как начнется demo разместите где-либо возле компьютера микрофон и запишите все то, о чем будет говорить докладчик на demo. После того, как вся команда уйдет из комнаты, позовите докладчика и дайте ему послушать себя же. Он будет удивлен. И такая обратная связь просто необходима.

Чаще всего Product Owner (особенно в аутсорсинге) человек мыслящий в категориях бизнеса, ему никак не интересно какой фреймворк вы использовали или как проводили рефакторинг. Говорите на его языке. Демонстрируйте интересно - вся команда вместе с Product Owner должны кайфовать от демо. Рассказывайте связно, даже если итерация включала в себя множество мелких несвязных фичей, это все можно слить в одну историю. Держитесь уверенно иначе вам не поверят. Не углубляйтесь в подробности - слушатель не хочет знать как вы сделали 12 мелких улучшений в 5 частях системы, просто скажите, что вы их сделали. Не затягивайте demo - после 45 минут все будут спать. Фасилитируйте demo - иначе слушатели заснут еще раньше.

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

Собирайтесь с командой в одной комнате и пользуйтесь кнопкой mute - так у вас появится шанс при виде баги сказать кому-то в команде "пофиксите кто-то, муть вашу!". Возможно, даже, к концу демонстрации получится показать исправленный вариант - это в глазах слушателя говорит и команде, как о большом профессионале, очень хорошо знающем систему. Вообще начинайте с той фичи, которая сделана лучше всего, а потом покажите плохую - пока demo будет продолжаться исправьте ее.

Если сейчас не можете ответить, возьмите таймаут и ответьте позже - нечего из себя давить непонятно что. Если не уверены стоит ли говорить вообще - не говорите. Все действо проводится ради одной цели - апрува Product Owner'a. Он должен сказать "я принимаю". Если вам кажется, что что-то может помешать получить этот апрув, не делайте! В частности это касается шуток - лучше шутите после получения апрува.

Сделайте demo важным мероприятием для команды. Введите метрику "Кто вытянул демо?" и отмечайте этого человека бурными аплодисментами.

Вообще-то в demo стоит осуществить прыжок выше головы. Тогда оно будет успешным. Если вы боитесь "как бы он не заметил" - Product Owner обязательно заметит. Неуверенность это провал.

После того, как показали demo - дайте на 2-3 дня (или лучше всю следующую итерацию) Product Owner'у поиграться с программой. Если ему что-то не понравилось и это можно пофиксить сразу - сделайте это, он заценит. Это фигуры высшего пилотажа - так вы пополняете счет доверия и в долгосрочной перспективе это окупится с лихвой.

Используйте блокнот - никто не любит повторять дважды, особенно Product Owner. Это самый страшный грех, когда вас просили исправить что-то, а в следующий раз вы показываете тот же глюк. Записывайте все ремарки в блокноте. И исправляйте в первую очередь.

Что касается спринтов, то рекомендации были такими: никогда не переносите окончание итерации потому, что вы не успеваете; и никогда не отменяйте demo по той же причине - итерация должна быть фиксированных размеров. Никаких "мы сделаем демо в следующей итерации". Без demo это уже не agile.

Если demo провалено, то стоит это признать и провести ретроспективу. Сделайте это по горячим следам. Если вы провалились, то из этого надо получить пользу. Никогда не говорите на demo "мы это не сделали потому, что...". Почему вы об этом не сказали сразу посреди спринта? Научитесь доверять своему Product Owner'у. Сообщайте о проблемах по мере поступления - Product Owner любит управлять рисками.

Иногда бывают случаи, когда на demo приходят VIP персоны (инвесторы). Скорее всего они не проект приходят посмотреть, а людей. Предложите предварительно обговорить с Product Owner сценарий demo - он с радостью согласится. Если вам кажется, что пришли смотреть людей - подберите команду, которую не жалко.

Чуть позже я расскажу и о других не менее интересных докладах...