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

«У нас в офисе бардак и очень шумно»

Стандартные действия:

• Попробуйте создать более благоприятную атмосферу или перевезите команду на другое место. Куда угодно. Можете снять комнату в отеле (см. стр. 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 (банан — груша)

Жёлтые = желательно включить в версию 1.0 (изюм — лук)

Зелёные = могут быть добавлены позже (грейпфрут — персик)

Итак, если к крайнему сроку мы закончим всё: от банана до лука, то нам бояться нечего. Если время будет нас поджимать, то мы ещё успеем выкрутиться, убрав изюм, арахис, пончик и лук. Всё, что ниже лука — бонус.

Оцениваем наиболее важные истории

Чтобы спланировать релиз, product owner’а нужны оценки, как минимум оценки всех включенных в контракт историй. Как и в случае планирования спринта, это — коллективный труд команды и Product owner’а. Команда планирует, а product owner объясняет и отвечает на вопросы.

Оценка считается ценной, если впоследствии она оказалась близкой к реальности. Менее полезной, если отклонение составило, скажем, 30 %. И абсолютно бесполезной, если она не имеет ничего общего с реально потраченным временем.

А вот что я думаю о зависимости ценности оценки от того, кто и как долго её делает.

Резюмируя вышесказанное:

1. Пусть команда проведёт оценку.

2. Не давайте им тратить на это много времени.

3. Убедитесь, что команда понимает, что нужно получить приблизительные оценки, а не контракт, под которым надо ставить подпись.

Обычно product owner собирает всю команду, делает вводный обзор и сообщает, что целью этого совещания является оценка двадцати (например) наиболее значимых историй из product backlog’а. Он проходится по каждой истории и позволяет команде приступить к процессу оценки. Product owner остаётся с командой, чтобы, в случае необходимости, отвечать на вопросы и прояснить объём работ историй. Так же, как и при планировании спринта, колонка «как продемонстрировать» — отличное средство, чтобы избежать недопонимания.