Хенрик Книберг - Scrum и XP: заметки с передовой
Изменения. Быть или не быть
Предположим, команда пришла к выводу, что «мы слишком слабо общались внутри команды, поэтому мы постоянно мешали друг другу и переделывали архитектурные решения».
Что нам с этим делать? Организовать ежедневные встречи для обсуждения архитектуры? Внедрить новые средства, чтобы упростить общение? Создать больше страниц в wiki? Может, и да. А может, и нет.
Оказалось, что достаточно всего лишь четко определить проблему, и она часто решается сама собой в следующем спринте. В особенности, если на стене в рабочей комнате повесить записи по ретроспективе спринта (что, к нашему стыду, мы так часто забываем сделать!) Имейте в виду, что каждое изменение имеет свою цену, поэтому перед тем как его внедрять, подумайте, может, стоит ничего не делать вообще и надеяться, что проблема станет меньше или исчезнет совсем.
Пример, приведенный выше («мы так слабо общались внутри команды…») — это классический пример того, что решается лучше всего бездействием.
Если в ответ на каждую жалобу пытаться что-то делать, народ с неохотой будет рассказывать про свои даже самые мелкие проблемы, которые могут быть ужасными.
Типичные проблемы, которые обсуждают на ретроспективах
В этой главе я постараюсь описать стандартные проблемы, которые всплывают в ходе ретроспектив, и возможные пути их решения.
«Нам надо было больше времени потратить на разбиение историй на подзадачи»
О, это классика жанра. Каждый день на Scrum'е можно услышать, как люди произносят избитую до боли фразу: «Я не знаю, что мне сегодня делать». И вам приходится изо дня в день тратить кучу времени для того, чтобы после Scrum'а найти задачи для этих ребят. Мой совет — делайте это заранее.
Стандартные действия: никаких. Возможно, команда сама решит эту проблему на следующем планировании. Если же это повторяется из раза в раз, увеличьте время на планирование спринта.
«Очень часто беспокоят извне»
Стандартные действия:
• Попросите команду уменьшить фокус-фактор на следующий спринт, чтобы у них был более реалистичный план.
• Попросите команду более подробно записывать случаи вмешательства (кто и как долго). Потом будет легче решить проблему.
• Попросите команду переводить все внешние запросы на ScrumMaster'а или Product owner’а.
• Попросите команду выбрать одного человека в качестве «голкипера» и перенаправлять на него все вопросы, которые могут отвлечь команду от работы. Это позволит остальной части команды
• сконцентрироваться на своих задачах. В это роли может выступать, как ScrumMaster, так и любой член команды, которого нужно будет периодически менять.
«Мы взяли огромный кусок работы, а закончили только половину»
Стандартные действия: никаких. Скорее всего, в следующий раз команда не станет браться за нереальный объём работ. Или, по крайней мере, поскромнее оценит свои возможности.
«У нас в офисе бардак и очень шумно»
Стандартные действия:
• Попробуйте создать более благоприятную атмосферу или перевезите команду на другое место. Куда угодно. Можете снять комнату в отеле (см. стр. 43 «Как мы обустроили комнату команды»).
• Если это возможно, попросите команду уменьшить фокус-фактор на следующий спринт с чётким описанием причины: шум и бардак в офисе. Может быть, это заставит Product owner’а начать пинать вышестоящий менеджмент насчёт вашей проблемы.
Слава Богу, мне никогда не приходилось перевозить команду в другое место. Но если придётся — я это сделаю.:o)
Отдых между спринтами
В реальной жизни невозможно постоянно бежать как спринтер. Между забегами вам в любом случае нужен отдых. Если вы бежите с постоянной максимальной скоростью, то, по сути, вы просто бежите трусцой.
То же самое наблюдается в Scrum’е, да и в разработке программного обеспечения в целом. Спринты очень изматывают. Как у разработчика, у вас никогда нет времени, чтобы расслабиться, каждый день вы должны стоять на этом проклятом Scrum-митинге и рассказывать всем, чего вы добились вчера. Мало кто может похвастаться: «Я потратил большую часть дня, положив ноги на стол, просматривая блоги и попивая капучино».
Помимо собственно отдыха, есть ещё одна причина для паузы между спринтами. После демо и ретроспективы, как команда, так и product owner будут переполнены информацией и всевозможными идеями, которые им следовало бы обмозговать. Если же они немедленно займутся планированием следующего спринта, то есть риск, что они не смогут упорядочить всю полученную информацию или сделать надлежащие выводы. К тому же у Product owner’а не хватит времени для корректировки его приоритетов после проведённого демо и т. д.
Плохо:
Перед началом нового спринта (если быть точным, после ретроспективы спринта и перед планированием следующего спринта) мы стараемся добавлять небольшой промежуток свободного времени. Увы, у нас это не всегда получается.
Как минимум, мы стараемся добиться того, чтобы ретроспектива спринта и следующее планирование спринта не проходили в один и тот же день. Перед началом нового спринта каждый должен хорошенько выспаться, не думая при этом о спринтах.
Лучше:
Еще лучше:
Один из вариантов для этого — «инженерные дни» (или как бы вы их не называли). Это дни, когда разработчикам разрешается делать по сути все, что они хотят. (ОК, я признаю, в этом виноват Google). Например, читать о последних средствах разработки и API, готовиться к сертификации, обсуждать компьютерные занудства с коллегами, заниматься своим личным проектом.
Лучше некуда?
Наша цель — инженерный день между каждым спринтом. Так между спринтами появляется реальная возможность отдохнуть, а команда разработки получает хороший шанс поддерживать актуальность своих знаний. К тому же, это достаточно весомое преимущество работы в компании.
Сейчас у нас один инженерный день между спринтами. Если конкретно, то это первая пятница каждого месяца. Почему же не между спринтами? Ну, потому что я считал важным, чтобы вся компания брала инженерный день в одно и то же время. Иначе люди не воспринимают его серьезно. И так как мы (пока что) не согласовывали спринты между всеми продуктами, я был вынужден выбрать инженерный день, независимый от спринтов.
Когда-нибудь мы можем попробовать согласовать спринты между продуктами (то есть одна и та же дата для начала спринта и одновременное окончание спринтов для всех продуктов и команд). В этом случае, мы точно поместим инженерный день между спринтами.
Как мы планируем релизы и составляем контракты с фиксированной стоимостью
Иногда нужно планировать дальше, чем на один спринт вперед. Это типичная ситуация для контрактов с фиксированной стоимостью, когда нам приходится планировать наперед, или же есть риск подписаться под нереальной датой поставки.
Как правило, планирование релиза для нас — это попытка ответить на вопрос: «когда, в самом худшем случае, мы сможем поставить версию 1.0».
Если вы действительно хотите разобраться, как планировать релиз, советую пропустить эту главу и купить книгу Майка Кона «Agile Estimating and Planning». Эх, прочитать бы мне эту книгу раньше… (она попалась мне уже после того, как мы на собственном опыте поняли, что к чему…). Мой способ планирования простой, как угол дома, но может послужить вам хорошей отправной точкой.
Определяем свою приёмочную шкалу
В дополнении к обычному product backlog, product owner определяет приёмочную шкалу, которая представляет собой ни что иное, как простое разбиение всех историй product backlog’а на группы в зависимости от их уровня важности в контексте контрактных обязательств.
Вот пример диапазонов из нашей приёмочной шкалы:
• Все элементы с важностью >= 100 обязаны быть включены в версию 1.0, иначе нас оштрафуют по полной программе.
• Все элементы с важность 50–99 должны быть включены в версию 1.0, но в случае чего мы можем выкатить эту функциональность в следующем дополнительном релизе.
• Элементы с важностью 25–49 необходимы, но могут быть сделаны в последующем релизе версии
• 1.1.
• Важность элементов < 25 весьма спорна, так как возможно, что они вообще никогда не пригодятся.
Вот пример product backlog’а, раскрашенного в соответствии с вышеописанными правилами:
Красные = обязательно должны быть добавлены в версию 1.0 (банан — груша)
