Scrum и XP: заметки с передовой

наставником Джо. Или будьте сами им. Если Джо действительно важен для команды, такой будет цена достижения цели. У нас были похожие ситуации, и этот подход более-менее срабатывал.

Как мы проводим демо

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

Почему мы настаиваем на том, чтобы каждый спринт заканчивался демонстрацией

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

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

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

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

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

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

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

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

Памятка по подготовке и проведению демо

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

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

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

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

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

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

Что делать с «недемонстрируемыми» вещами

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

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

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

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

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

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

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

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

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

Как мы проводим ретроспективы

Почему мы настаиваем на том, чтобы все команды проводили ретроспективы

Наиболее важная вещь в отношении ретроспектив — это их проведение.

По некоторым причинам команды не проявляют должного интереса к проведению ретроспектив. Без