Хенрик Книберг - Scrum и XP: заметки с передовой
Жёлтые = желательно включить в версию 1.0 (изюм — лук)
Зелёные = могут быть добавлены позже (грейпфрут — персик)
Итак, если к крайнему сроку мы закончим всё: от банана до лука, то нам бояться нечего. Если время будет нас поджимать, то мы ещё успеем выкрутиться, убрав изюм, арахис, пончик и лук. Всё, что ниже лука — бонус.
Оцениваем наиболее важные истории
Чтобы спланировать релиз, product owner’а нужны оценки, как минимум оценки всех включенных в контракт историй. Как и в случае планирования спринта, это — коллективный труд команды и Product owner’а. Команда планирует, а product owner объясняет и отвечает на вопросы.
Оценка считается ценной, если впоследствии она оказалась близкой к реальности. Менее полезной, если отклонение составило, скажем, 30 %. И абсолютно бесполезной, если она не имеет ничего общего с реально потраченным временем.
А вот что я думаю о зависимости ценности оценки от того, кто и как долго её делает.
Резюмируя вышесказанное:
1. Пусть команда проведёт оценку.
2. Не давайте им тратить на это много времени.
3. Убедитесь, что команда понимает, что нужно получить приблизительные оценки, а не контракт, под которым надо ставить подпись.
Обычно product owner собирает всю команду, делает вводный обзор и сообщает, что целью этого совещания является оценка двадцати (например) наиболее значимых историй из product backlog’а. Он проходится по каждой истории и позволяет команде приступить к процессу оценки. Product owner остаётся с командой, чтобы, в случае необходимости, отвечать на вопросы и прояснить объём работ историй. Так же, как и при планировании спринта, колонка «как продемонстрировать» — отличное средство, чтобы избежать недопонимания.
Совещание должно быть строго ограниченным по времени — команды склонны тратить очень много времени на оценку всего нескольких историй.
Если product owner захочет потратить больше времени на оценку, он просто назначит другое совещание позже. Команда должна убедиться в том, что product owner осознаёт, что проведение подобных совещаний отразится на их текущем спринте. То есть, что он понимает, что за все (и за оценку в том числе) нужно платить.
Ниже приведен пример результатов оценки (в story point’а):
Прогнозируем производительность
Хорошо, теперь у нас есть приблизительные оценки для наиболее важных историй. Следующий шаг — прогноз средней производительности команды.
Это значит, что для начала мы должны определить наш фокус-фактор (см. стр. 23 «Как команда принимает решение о том, какие истории включать в спринт?»)
По большому счёту, фокус-фактор показывает: «насколько эффективно команда использует своё время для работы над выбранными историями». Это значение никогда не достигнет 100 %, так как команда всегда тратит время на незапланированные задачи, помощь другим командам, переключение между задачами, проверку электронной почты, ремонт своих поломанных компьютеров, политические дебаты на кухне и т. д.
Предположим, что фокус-фактор нашей команды равен 50 % (это достаточно низкое значение, у моей команды значение колеблется в районе 70 %). Допустим также, что длина нашего спринта будет 3 недели (15 дней), а размер команды — 6 человек.
Таким образом, каждый спринт — это 90 человеко-дней, однако, в лучшем случае мы можем надеяться только на 45 человеко-дней (так как наш фокус-фактор составляет всего 50 %).
Следовательно, прогнозируемая производительность составит 45 story point'ов.
Если у каждой истории оценка будет равна 5 дням (хотя такого и не бывает), тогда эта команда сможет выдавать на-гора примерно по 9 историй за спринт.
Сводим всё в план релиза
Сейчас, когда у нас есть оценки и прогнозируемая производительность, мы можем легко разбить product backlog на спринты:
Каждый спринт состоит из набора историй, количество которых не превышает спрогнозированную производительность 45.
Теперь видно, что, скорее всего, нам потребуется 3 спринта для завершения всей обязательной и желательной функциональности.
3 спринта = 9 календарных недель = 2 календарных месяца. Станет ли это крайним сроком, который мы озвучим клиенту? Это полностью зависит от вида контракта, от того, насколько фиксирован объем работ, и т. д. Обычно мы берём время со значительным запасом, тем самым защищая себя от ошибочных оценок, возможных проблем, неоговоренного функционала и т. д. Значит, в этом случае мы установим срок поставки в 3 месяца, чтобы иметь месяц в резерве.
Очень хорошо, что мы можем демонстрировать клиенту что-нибудь пригодное к использованию каждые 3 недели и позволять ему изменять требования на протяжении всего времени сотрудничества (конечно в зависимости оттого, как выглядит контракт).
Корректируем план релиза
Реальность не подстроится под план, поэтому приходится его корректировать.
По окончании спринта мы смотрим на реальную производительность команды. Если эта производительность существенно отличается от прогнозируемой, мы изменяем прогнозируемую производительность для будущих спринтов и обновляем план релиза. Если это грозит нам срывом срока поставки, product owner может начать переговоры с клиентом или начать искать путь уменьшения объема работ без нарушения контракта. Или, возможно, он и команда смогут увеличить производительность или фокус-фактор путём устранения серьёзных препятствий, которые были обнаружены во время спринта.
Product owner может позвонить клиенту и сказать: «Привет, мы слегка не вписываемся в график, но я полагаю, что мы сможем уложиться в срок, если уберём встроенный Тетрис, разработка которого занимает много времени. Мы можем добавить его в следующем релизе, который будет через три недели после первого релиза».
Пусть это и не самая лучшая новость, но, хотя бы, мы были честны и дали возможность клиенту заранее сделать выбор: или мы поставляем только самую важную функциональность в срок, или же всю полностью, но с задержкой. Обычно, это не очень сложный выбор.:о)
Как мы сочетаем Scrum с XP
То, что Scrum и XP (eXtreme Programming) могут быть эффективно объединены, не вызывает сомнений. Большинство рассуждений в интернете поддерживают это предположение, и я не хочу тратить время на дополнительные обоснования.
Тем не менее, одну вещь я всё-таки должен упомянуть. Scrum решает вопросы управления и организации, тогда как XP специализируется на инженерных практиках. Вот почему эти две технологии хорошо работают вместе, дополняя друг друга.
Тем самым я присоединяюсь к сторонникам мнения, что Scrum и XP могут быть эффективно объединены!
Я собираюсь рассказать про наиболее полезные практики из XP и про то, как мы используем их в нашей повседневной работе. Не все наши команды смогли применить практики XP в полном объеме, но мы провели большое количество экспериментов со многими аспектами комбинации XP/Scrum. Некоторые практики XP напрямую соответствуют практикам Scrum, например, «Whole team», «Sit together», «Stories» и «Planning game». В этих случаях мы просто придерживаемся Scrum.
Парное программирование
Недавно мы начали практиковать его в одной из наших команд. Как ни удивительно, работает довольно-таки хорошо. Большинство других наших команд до сих пор не очень много программирует парно, однако, попробовав эту практику в одной из наших команд для нескольких спринтов, я вдохновился идеей внедрить парное программирование и в других командах.
Вот пока несколько выводов после применения парного программирования:
• Парное программирование действительно улучшает качество кода.
• Парное программирование действительно увеличивает сосредоточенность команды (например, когда напарник говорит: «Слушай, а эта штуковина точно нужна для этого спринта?»)
• Удивительно, но многие разработчики, которые выступают против парного программирования, на самом деле не практиковали его, однако раз попробовав — быстро понимают все преимущества.
• Парное программирование выматывает, так что не стоит заниматься им целый день.
• Частая смена пар даёт хороший результат.
• Парное программирование действительно способствует распространению знаний внутри команды, заметно ускоряя этот процесс.
• Некоторые люди чувствуют себя некомфортно, работая в парах. Не стоит избавляться от хорошего программиста, только потому, что ему не нравится парное программирование.
• Ревью кода — хорошая альтернатива парному программированию.
• У «штурмана» (человека, который не пишет код) должен также быть свой компьютер, но не для разработки, а для выполнения мелких задач, когда это необходимо — просмотра документации, если «водитель» (человек, который пишет код) запнулся и так далее.
