пример того, что решается лучше всего бездействием.
Если в ответ на каждую жалобу пытаться что-то делать, народ с неохотой будет рассказывать про свои даже самые мелкие проблемы, которые могут быть ужасными.
Типичные проблемы, которые обсуждают на ретроспективах
В этой главе я постараюсь описать стандартные проблемы, которые всплывают в ходе ретроспектив, и возможные пути их решения.
«Нам надо было больше времени потратить на разбиение историй на подзадачи»
О, это классика жанра. Каждый день на Scrum'е можно услышать, как люди произносят избитую до боли фразу: «Я не знаю, что мне сегодня делать». И вам приходится изо дня в день тратить кучу времени для того, чтобы после Scrum'а найти задачи для этих ребят. Мой совет — делайте это заранее.
Стандартные действия: никаких. Возможно, команда сама решит эту проблему на следующем планировании. Если же это повторяется из раза в раз, увеличьте время на планирование спринта.
«Очень часто беспокоят извне»
Стандартные действия:
• Попросите команду уменьшить фокус-фактор на следующий спринт, чтобы у них был более реалистичный план.
• Попросите команду более подробно записывать случаи вмешательства (кто и как долго). Потом будет легче решить проблему.
• Попросите команду переводить все внешние запросы на ScrumMaster'а или Product owner’а.
• Попросите команду выбрать одного человека в качестве «голкипера» и перенаправлять на него все вопросы, которые могут отвлечь команду от работы. Это позволит остальной части команды
• сконцентрироваться на своих задачах. В это роли может выступать, как ScrumMaster, так и любой член команды, которого нужно будет периодически менять.
«Мы взяли огромный кусок работы, а закончили только половину»
Стандартные действия: никаких. Скорее всего, в следующий раз команда не станет браться за нереальный объём работ. Или, по крайней мере, поскромнее оценит свои возможности.
«У нас в офисе бардак и очень шумно»
Стандартные действия:
• Попробуйте создать более благоприятную атмосферу или перевезите команду на другое место. Куда угодно. Можете снять комнату в отеле (см. стр. 43 «Как мы обустроили комнату команды»).
• Если это возможно, попросите команду уменьшить фокус-фактор на следующий спринт с чётким описанием причины: шум и бардак в офисе. Может быть, это заставит Product owner’а начать пинать вышестоящий менеджмент насчёт вашей проблемы.
Слава Богу, мне никогда не приходилось перевозить команду в другое место. Но если придётся — я это сделаю.:o)
Отдых между спринтами
В реальной жизни невозможно постоянно бежать как спринтер. Между забегами вам в любом случае нужен отдых. Если вы бежите с постоянной максимальной скоростью, то, по сути, вы просто бежите трусцой.
То же самое наблюдается в Scrum’е, да и в разработке программного обеспечения в целом. Спринты очень изматывают. Как у разработчика, у вас никогда нет времени, чтобы расслабиться, каждый день вы должны стоять на этом проклятом Scrum-митинге и рассказывать всем, чего вы добились вчера. Мало кто может похвастаться: «Я потратил большую часть дня, положив ноги на стол, просматривая блоги и попивая капучино».
Помимо собственно отдыха, есть ещё одна причина для паузы между спринтами. После демо и ретроспективы, как команда, так и product owner будут переполнены информацией и всевозможными идеями, которые им следовало бы обмозговать. Если же они немедленно займутся планированием следующего спринта, то есть риск, что они не смогут упорядочить всю полученную информацию или сделать надлежащие выводы. К тому же у Product owner’а не хватит времени для корректировки его приоритетов после проведённого демо и т. д.
Плохо:
Перед началом нового спринта (если быть точным, после ретроспективы спринта и перед планированием следующего спринта) мы стараемся добавлять небольшой промежуток свободного времени. Увы, у нас это не всегда получается.
Как минимум, мы стараемся добиться того, чтобы ретроспектива спринта и следующее планирование спринта не проходили в один и тот же день. Перед началом нового спринта каждый должен хорошенько выспаться, не думая при этом о спринтах.
Лучше:
Еще лучше:
Один из вариантов для этого — «инженерные дни» (или как бы вы их не называли). Это дни, когда разработчикам разрешается делать по сути все, что они хотят. (ОК, я признаю, в этом виноват Google). Например, читать о последних средствах разработки и API, готовиться к сертификации, обсуждать компьютерные занудства с коллегами, заниматься своим личным проектом.
Лучше некуда?
Наша цель — инженерный день между каждым спринтом. Так между спринтами появляется реальная возможность отдохнуть, а команда разработки получает хороший шанс поддерживать актуальность своих
