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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По некоторым причинам команды не проявляют должного интереса к проведению ретроспектив. Без небольшого давления со стороны многие команды часто пропускают ретроспективу и сразу переходят к следующему спринту. Может быть, это особенность шведского менталитета, в чём я не уверен.

Хотя при этом все вроде соглашаются, что ретроспективы крайне полезны. Я бы даже сказал, что ретроспектива является вторым по значимости мероприятием в Scrum'e (первое — это планирование спринта), потому что это самый подходящий момент для начала улучшений!

Конечно, чтобы возникла хорошая идея, вам не нужна ретроспектива, она может прийти к вам в голову, когда вы дома в душевой кабинке! Но поддержит ли команда вашу идею? Может быть, но вероятность значительно выше, если идея рождается внутри команды, то есть, во время ретроспективы, когда каждый может сделать свой вклад в обсуждение идеи.

Без ретроспектив вы обнаружите, что команда наступает на одни и те же грабли снова и снова.

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

Хотя основной формат немного варьируется, но в основном мы делаем так:

• Выделяем 1–3 часа, в зависимости от того насколько долгая ожидается дискуссия.

• Участвуют: product owner, вся команда и я собственной персоной.

• Располагаемся либо в отдельной комнате с уютным мягким уголком, либо на террасе, либо в каком-то другом похожем месте, поскольку нам нравится вести дискуссию в спокойной и непринуждённой атмосфере.

• Зачастую мы стараемся не проводить ретроспективы в рабочей комнате, так как это рассеивает внимание участников.

• Выбираем кого-то в качестве секретаря.

• ScrumMaster показывает sprint backlog и при участии команды подводит итоги спринта. Важные события, выводы и т. д.

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

• Мы сравниваем прогнозируемую и реальную производительность. Если имеются существенные расхождения, то пытаемся проанализировать и понять, почему так получилось.

• Когда время подходит к концу, ScrumMaster пытается обобщить все конкретные предложения по поводу того, что мы можем улучшить в следующем спринте.

Вот вам пример доски с нашей последней ретроспективы: