Когда я внедрял такой подход, некоторые команды хотели учесть, помимо прочего, время отпусков, время отсутствия работников по болезни и другие перерывы в работе. Не стоит заморачиваться — это вряд ли сделает расчет более точным. Такие события — одна из причин, по которым никто не строит планы с расчетом на 100 %-ную доступность команды.
Как уделить проекту больше времени
Сколько бы часов в день члены команды ни уделяли проекту, вы вряд ли откажетесь от возможности увеличить это число. Лучший, на мой взгляд, способ добиться этого придумал Франческо Чирилло из XPLabs. Он учит команды работать с высокой концентрацией 30-минутными интервалами (Cirillo, 2005). Каждый 30-минутный интервал состоит из двух частей: 25 минут интенсивной работы, а затем пятиминутный перерыв. Эти 30-минутные интервалы называют pomodori, что в переводе с итальянского означает «помидоры». Такое название связано с использованием таймеров в виде помидоров, подающих сигнал, когда истекают 25 минут.
Чирилло представил свой метод Пьергьюлиано Босси, который документально подтвердил его успешность при работе со многими командами (Bossi, 2003; Bossi and Cirillo, 2001). Эти команды обычно планировали выполнить работу на 10 помидоров (пять часов) в день. Если вы тратите свое время менее продуктивно, чем хотелось бы, можете попробовать этот подход.
Развертывание историй и выбор того, что подходит
Следующий этап — развертывание историй в задачи, их оценка и повторение этого процесса до тех пор, пока не удастся заполнить расчетное количество доступных часов (в нашем случае 240 часов). Вовсе не обязательно развертывать истории в порядке приоритета. Что нам действительно требуется, так это довольно случайный набор историй. Не старайтесь, например, развернуть все одно- и двухпунктовые истории и ни одной трех- и пятипунктовой истории. Аналогичным образом не старайтесь развернуть только истории, которые связаны в основном с пользовательским интерфейсом или базой данных. Попытайтесь подобрать представительный набор историй.
Продолжайте отбирать истории и разбивать их на задачи до тех пор, пока выбранные задачи не превысят возможности членов команды. В случае команды SwimStats, например, следует соблюдать осторожность и рассчитывать на то, что программист и аналитик также являются опытными администраторами баз данных. Отбирайте истории до тех пор, пока команда с одним набором специальностей не сможет справиться с дополнительной работой. Подсчитайте количество пунктов или идеальных дней для выбранной работы, и это будет вероятная скорость команды.
Предположим, мы собрали запланированную команду (или создали ее аналог, если проект начнется лишь через год) и развернули некоторые истории, как показано в табл. 16.2. Если мы видим, что команда SwimStats в составе четырех человек может справиться с этим, но дополнительная работа будет ей не по силам, то останавливаемся. Эта работа объемом 221 час довольно хорошо подходит для доступных 240 часов. Наша точечная оценка скорости при этом будет равна 25.
Создание диапазона на основе найденной скорости
Используйте любой подход, который вам нравится, для преобразования точечной оценки скорости в диапазон. Как и прежде, я предпочитаю умножение на 60 % и 160 %. Для команды SwimStats наши расчетные 25 пунктов на итерацию дают диапазон от 15 до 40.
Возможный вариант для некоторых команд
Некоторым командам, особенно тем, в которых много членов с неполной занятостью, не следует закладывать одинаковое количество доступных часов для всех. В такие команды могут входить члены, которые могут уделять проекту намного меньшую часть своего времени. В этих случаях полезно создавать нечто вроде табл. 16.3.
В команде SwimStats, как видно из табл. 16.3, Юрий и Саша полностью заняты в проекте. SwimStats — единственный проект Сергея, однако он выполняет другие управленческие и корпоративные функции, которые отнимают у него определенное время. Карина делит свое время между SwimStats и другим проектом. У нее очень мало обязанностей, кроме этих двух проектов, поэтому она может уделять им почти шесть часов в день. Вместе с тем ей приходится многократно переключаться с одного проекта на другой в течение дня, и такая многозадачность сказывается на ее производительности, поэтому в таблице показано, что она уделяет проекту SwimStats только два продуктивных часа в день.
Не забывайте, зачем это делается
Помните, что причиной, по которой мы прогнозируем скорость, является невозможность или нецелесообразность выполнения итерации при отсутствии исторических данных у конкретной команды. Такое может случиться, если команда пока что не сформирована, а вам нужно составить план проекта, который начнется лишь через несколько месяцев.
Если, например, вы работаете в условиях, когда стратегическое планирование и бюджетирование приходится осуществлять задолго до начала проекта, то прогнозирование скорости может оказаться наилучшим подходом.
Какой подход следует использовать
Принятие решения о том, какой подход использовать, нередко проще, чем может показаться при виде разнообразия вариантов. Обстоятельства чаще всего направляют вас и ограничивают возможности. Ниже приведены рекомендации по применению методов оценки скорости в порядке убывания их желательности.
• Если у вас есть возможность выполнить одну или несколько итераций, прежде чем давать оценку скорости, то обязательно пользуйтесь ею. Никакая оценка не может сравниться с фактическими результатами, и наблюдение реальной скорости команды всегда будет наилучшим выбором.
• Используйте фактическую скорость команды в сходном проекте.
• Оценивайте скорость по тому объему работы, с которым вы можете справиться.
Независимо от подхода, который вы используете, при первой же возможности переходите на фактические, наблюдаемые значения скорости. Допустим, вы оцениваете скорость по объему работы, которая подходит для итерации, поскольку проект начнется не раньше чем через шесть месяцев и организации необходимо лишь примерно понять, сколько времени потребуется на этот проект. Как только начинается реализация проекта и у вас появляется возможность измерить фактическую скорость, переходите при обсуждении проекта и вероятного диапазона сроков его завершения на фактические данные.
Резюме
Существует три способа оценки скорости. Во-первых, можно использовать исторические средние показатели при их наличии. Вместе с тем, прежде чем применять исторические средние показатели, необходимо понять, не изменились ли существенно команда, характер проекта, технология и т. п. Во-вторых, можно отложить оценку скорости до тех пор, пока не будут выполнены несколько итераций. Это обычно наилучший вариант. В-третьих, можно спрогнозировать скорость путем разбивки нескольких историй на задачи и определения объема работ, подходящего для итерации. Этот процесс очень похож на планирование итерации.
