Основываясь на этом голосовании, мы выбираем 5 улучшений, которые мы попытаемся внедрить в следующем спринте, а на следующей ретроспективе мы проверим, что у нас вышло.
Очень важно не переоценить свои возможности. Выберите всего несколько улучшений для следующего спринта.
Как учиться на чужих ошибках
Информация, которая всплывает в ходе ретроспектив, обычно крайне важна. Для команды настали нелёгкие времена, потому что менеджеры по продажам начали забирать программистов с работы на свои встречи, чтоб те играли роль «технических экспертов»? Это очень важная информация. Возможно, что и у других команд точно такие же проблемы. Может быть, нам стоит провести специальные тренинги по нашему продукту для отдела маркетинга, чтобы они самостоятельно смогли отвечать на все вопросы клиентов?
Возможные способы решения проблем, найденных командой на ретроспективе, могут оказаться полезными не только для неё самой, но и для остальных.
Как же собрать все эти результаты? Мы выбрали достаточно простой способ. Один человек (в этом случае я) принимает участие во всех ретроспективах в роли «связующего звена». Без всяких формальностей.
В качестве альтернативного варианта можно предложить каждой команде составлять отчёт о проведённой ретроспективе. Мы пробовали и этот способ, но поняли, что немногие читают такие отчёты, а ещё меньше тех, кто делают выводы из прочтённого. Поэтому мы остановились на самом простом способе.
Наиболее важные требования для человека, который будет «связующим звеном»:
• Он должен быть хорошим слушателем.
• Если ретроспектива проходит очень вяло, он должен быть готов задать простой, но меткий вопрос, который подтолкнёт людей на дискуссию. Например: «Если бы можно было повернуть время вспять и переделать этот спринт с самого первого дня, чтобы вы сделали по-другому?».
• Он должен быть согласен тратить своё время на посещение всех ретроспектив всех команд.
• Он должен обладать необходимыми полномочиями, которые помогли бы ему взяться за выполнение предложенных командой улучшений, выходящих за пределы возможностей самой команды.
Такой подход работает достаточно хорошо, но это не значит, что нет подходов намного лучше. Как только найдёте что-то новенькое, дайте мне знать.
Изменения. Быть или не быть
Предположим, команда пришла к выводу, что «мы слишком слабо общались внутри команды, поэтому мы постоянно мешали друг другу и переделывали архитектурные решения».
Что нам с этим делать? Организовать ежедневные встречи для обсуждения архитектуры? Внедрить новые средства, чтобы упростить общение? Создать больше страниц в wiki? Может, и да. А может, и нет.
Оказалось, что достаточно всего лишь четко определить проблему, и она часто решается сама собой в следующем спринте. В особенности, если на стене в рабочей комнате повесить записи по ретроспективе спринта (что, к нашему стыду, мы так часто забываем сделать!) Имейте в виду, что каждое изменение имеет свою цену, поэтому перед тем как его внедрять, подумайте, может, стоит ничего не делать вообще и надеяться, что проблема станет меньше или исчезнет совсем.
Пример, приведенный выше («мы так слабо общались внутри команды…») — это классический пример того, что решается лучше всего бездействием.
Если в ответ на каждую жалобу пытаться что-то делать, народ с неохотой будет рассказывать про свои даже самые мелкие проблемы, которые могут быть ужасными.
Типичные проблемы, которые обсуждают на ретроспективах
В этой главе я постараюсь описать стандартные проблемы, которые всплывают в ходе ретроспектив, и возможные пути их решения.
«Нам надо было больше времени потратить на разбиение историй на подзадачи»
О, это классика жанра. Каждый день на Scrum'е можно услышать, как люди произносят избитую до боли фразу: «Я не знаю, что мне сегодня делать». И вам приходится изо дня в день тратить кучу времени для того, чтобы после Scrum'а найти задачи для этих ребят. Мой совет — делайте это заранее.
Стандартные действия: никаких. Возможно, команда сама решит эту проблему на следующем планировании. Если же это повторяется из раза в раз, увеличьте время на планирование спринта.