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