ним как можно больше нюансов до начала планирования. Если вы против Джефа, тогда выберите кого-то другого, но только с условием, что он будет присутствовать на планировании от начала до конца».
• Попробуйте убедить менеджмент найти вам нового product owner’а.
• Отложите начало спринта до того момента, пока у product owner’а не появится свободная минутка для совместного планирования. А пока не берите на себя никаких новых обязательств. Пусть в это время ваша команда займётся любой другой полезной работой.
Почему качество не обсуждается
В предыдущей главе я намеренно не показал на треугольнике четвертую переменную —
Попытаюсь объяснить разницу между
•
•
По правде говоря, у системы с высоким внутренним качеством иногда может быть довольно низкое внешнее. Но наоборот бывает крайне редко. Сложно построить что-то хорошее на прогнившем фундаменте.
Я рассматриваю внешнее качество, как часть общего объема работ. Ведь с точки зрения бизнеса бывает весьма целесообразно как можно быстрее выпустить версию системы с немного корявым и медленным пользовательским интерфейсом, и лишь потом подготовить версию с доработками и исправлениями. Здесь право выбора должно оставаться за product owner'ом, так как именно он отвечает за определение объёма работ. И напротив — внутреннее качество не может быть предметом дискуссии. Команда постоянно должна следить за качеством системы, поэтому оно попросту не обсуждается. Никогда.
(Ну ладно, почти никогда)
Так как же нам различать задачи, связанные с внутренним и внешним качеством?
Представьте, что product owner говорит: «Хорошо ребята, я понимаю, почему вы оценили эту задачу в 6 story point’а, но я уверен, что, если вы чуточку помозгуете, то сможете по-быстрому „залатать“ проблему».
Ага! Он пытается использовать внутреннее качество как переменную! Как я догадался? Да, потому что он хочет, чтобы мы уменьшили оценку задач, не уменьшив при этом объём работ. Слово «заплатка» должно вызывать у вас тревогу.
Почему же мы так жестко стоим на своем?
По моему личному опыту, жертвовать внутренним качеством — это практически всегда очень и очень плохая идея. Сэкономленное время ничтожно мало по сравнению с той ценой, которую вам придётся заплатить как в ближайшем будущем, так и в перспективе. Как только качество вашего кода ухудшится, восстановить его будет очень тяжело.
В этом случае я стараюсь перейти к обсуждению объема задач. «Раз вам так важно получить эту историю как можно раньше, тогда может быть стоит сократить объем задач, чтобы мы могли сделать её побыстрее? Возможно, стоит упростить обработку ошибок и сделать „Улучшенную обработку ошибок“ отдельной историей оставив ее на будущее? Или может понизить приоритет остальных историй, чтобы мы могли сосредоточить все свои усилия на этой?».
Планирование спринта, которое никак не заканчивается
Самая большая сложность при планировании спринта состоит в следующем:
1. Люди не расчитывают, что это займёт так много времени
2. … но так оно и происходит!
В Scrum'е всё ограничено по времени. Мне очень нравится это простое правило, и мы всячески пытаемся его придерживаться.
Так что же мы делаем, когда ограниченное по времени планирование спринта близится к концу, а цель спринта или sprint backlog всё ещё не определены? Просто обрываем планирование? Продлеваем на час? Или, быть может, мы завершаем собрание и продолжаем его на следующий день?
Это случается снова и снова, особенно в новых командах. Как вы обычно решаете эту проблему? Я не знаю. А как решаем её мы? Ну, обычно, я бесцеремонно обрываю встречу. Заканчиваю её. Пусть спринт пострадает. Точнее, я говорю команде и product owner’у: «Итак, встреча заканчивается через 10 минут. Мы, до сих пор, полностью не спланировали спринт. Можем ли мы начать работать с тем, что у нас есть, или назначим ещё одно 4-х часовое планирование спринта на завтра в 8 утра?». Можете догадаться, что они отвечают…:o)
Я несколько раз давал возможность совещанию затянуться, но обычно это, ни к чему не приводило. Главная причина этому — усталость участников встречи. Если команда не выработала подходящий план спринта за 2–8 часов (зависит от конкретно ваших ограничений по времени), они, скорее всего, не управятся с ним и в дополнительное время. Второй вариант, по правде, достаточно хорош: назначить новую встречу на следующий день. За исключением того, что люди обычно нетерпеливы и хотят быстрее начать спринт, а не тратить ещё пару часов на планирование.
Итак, я урезаю продолжительность встречи. Да, спринт от этого страдает. Но с другой стороны, команда получила очень ценный урок, и следующее планирование спринта пройдёт более эффективно. Кроме того, когда вы в следующий раз предложите увеличить продолжительность встречи, люди будут возмущаться гораздо меньше.
Учитесь оставаться в рамках установленного времени, учитесь давать реалистичные оценки. Это касается как продолжительности встреч, так и продолжительности спринта.
Распорядок встречи по планированию спринта
Наличие хотя бы примерного расписания значительно увеличит ваши шансы закончить планирование спринта в отведённое для этого время.
Например, наше расписание выглядит так:
Планирование спринта: с 13:00 до 17:00 (после каждого часа перерыв на 10 минут)
13:00–13:30. product owner разъясняет цель спринта и рассказывает про бизнес- процессы из product backlog'a. Обсуждается время и место проведения демо.
13:30–15:00. Команда проводит оценку времени, которое потребуется на разработку бизнес-процессов и, при необходимости дробит их на более мелкие. В некоторых случаях product owner может изменить приоритет их исполнения. Выясняем все интересующие нас вопросы. Для наиболее важных заполняем поле «Как продемонстрировать».
15:00–16:00. Команда определяет набор user story, которые войдут в следующий спринт. Чтобы проверить насколько это реально, вычисляем производительность команды.
16:00–17:00. Договариваемся о времени и месте проведения ежедневного Scrum'a (если они изменились по сравнению с прошлым спринтом). После чего приступаем к разбиению user story
