Истории выбираются по одной зараз потому, что после разбивки каждой истории на задачи и оценки этих задач команда решает, сможет ли или не сможет она принять обязательства по реализации этой истории в данной итерации.
Запрос на принятие обязательств
В своем исследовании факторов успеха команд Ларсон и Лафасто (Larson and LaFasto, 1989) установили, что единое обязательство, принятое всеми членами команды, является одним из ключевых факторов успеха. Во время совещания по планированию итерации я спрашиваю команду: «Можете ли вы принять обязательство реализовать функции, которые мы обсудили?» Обратите внимание на то, что я не спрашиваю, смогут ли они принять обязательство реализовать задачи, которые мы идентифицировали. Это совершенно другой вопрос и значительно более слабое обязательство, поскольку оно относится к выполнению набора задач, а не к постановке новой функциональности.
Если в ходе итерации появятся новые задачи (а они почти наверняка появятся), то команда, которая приняла обязательство поставить функциональность, описанную пользовательской историей, будет стараться выполнить также и новые задачи. Команда, которая обязалась выполнить только набор идентифицированных задач, может отказаться от выполнения новых. Не исключено, однако, что новые задачи окажутся слишком объемными для выполнения в данной итерации. В этом случае команде необходимо обсудить ситуацию с владельцем продукта и определить, есть ли возможность реализовать цель итерации. Команде для этого, возможно, придется сократить функциональность истории, а то и полностью исключить ее.
Я спрашиваю команду, сможет ли она принять обязательство по реализации после разбивки каждой пользовательской истории на задачи и оценки этих задач. Применительно к первой пользовательской истории такой вопрос может показаться глупым. В команде, планирующей двухнедельную итерацию, может быть семь человек. Может так случиться, что они идентифицировали работу пока всего лишь на 34 часа, а я спрашиваю, смогут ли они принять обязательство по ее выполнению. Их ответ (либо в словесной форме, либо в виде смущения на лицах), без сомнения, будет следующим: «Конечно, мы можем принять обязательство выполнить это. Нас семь, и у нас целых две недели, а здесь работы всего на 34 часа». Вместе с тем чем дальше продвигается обсуждение и чем больше пользовательских историй включаются в итерацию, тем более тщательного обдумывания требует мой вопрос о возможности принятия обязательства. В конечном итоге наступает предел, за которым команда уже не может увеличивать объем обязательств. В таком случае она может исключить историю или заменить ее на более мелкую перед завершением обсуждения.
Суммирование оценок
По моему опыту, для определения, сможет ли команда справиться с набором пользовательских историй, лучше всего просуммировать оценки, данные задачам, и посмотреть, представляет ли полученная сумма разумный объем работы. Надо учитывать, конечно, что некоторым задачам присуща высокая неопределенность, поскольку работа не продумывалась детально, а требования туманны. Так или иначе, суммирование оценок дает определенное представление об общем объеме работы.
Допустим, команда работает с использованием двухнедельных итераций. В каждой итерации ей доступно 560 часов (7 человек × 10 дней × 8 часов в день). Мы знаем, что определенное время тратится на деятельность, не отраженную в карточках с задачами, — ответы на электронные письма, участие в совещаниях и т. д. Также нам известно, что оценки неточны; в конце концов, это оценки, а не гарантированные величины. По этим причинам нельзя ожидать, что эта команда возьмется за выполнение задач объемом 560 часов. На практике большинство команд успешно справляются с работой, когда ее плановый объем (сумма оценок на карточках с задачами) составляет от четырех до шести часов в день. Для нашей команды из семи человек, работающей двухнедельными итерациями, это означает плановый объем работы от 280 до 420 часов. В какой точке этого диапазона команда остановится, зависит от того, насколько хорошо она идентифицирует задачи для данной истории, насколько точно оценивает эти задачи, а также от объема сторонних обязательств членов команды и размера общекорпоративных непроизводительных издержек. После пары итераций большинство команд начинают примерно чувствовать, какой объем работы в часах они должны планировать на итерацию.
Прежде чем принимать обязательство выполнить работу во время итерации, необходимо посмотреть на задачи и понять, обеспечивают ли они подходящее распределение работы в соответствии с квалификацией и опытом членов команды. Не получится ли так, что Java-программист окажется перегруженным, а HTML-программисту будет нечего делать? Не окажутся ли выбранные пользовательские истории легко поддающимися программированию, но требующими много времени или трудно тестируемыми, что приведет к перегрузке тестировщика? Не требуют ли выбранные истории предварительного анализа и дизайна пользовательского интерфейса?
Команда в ситуации вроде этой должна сначала попытаться найти подходы к более рациональному распределению работы. Может ли HTML-программист в этом примере помочь тестировщику? Может ли кто-нибудь другой, кроме дизайнера пользовательского интерфейса, выполнить эту работу? Если нет, то можно ли удалить из этой итерации истории, которые требуют дизайна пользовательского интерфейса, и можно ли вместо них взять истории, в которых это не требуется? Главное, чтобы все в команде отвечали за что-нибудь в пределах своих умений независимо от специализации.
Индивидуальные обязательства
При оценке возможности принять обязательство по реализации набора новых функций некоторые команды предпочитают сначала распределять задачи между конкретными исполнителями, а потом уже оценивать, сможет ли каждый исполнитель справиться с порученной работой. Этот подход работает хорошо, и я, бывало, рекомендовал его использовать (Cohn, 2004). Однако, как оказалось, отказ от распределения задач во время планирования итерации и от индивидуальных оценок, необходимых для принятия обязательств, облегчает команде переход на мышление «мы все работаем над этим вместе».
Если у вас все же возникает необходимость распределить задачи между исполнителями во время планирования итерации, то такое распределение следует считать временным и легко изменяемым в ходе итерации.
Сопровождение других продуктов и обязательство
В дополнение к реализации проекта многие команды также отвечают за поддержку и обслуживание другой системы. Это может быть предыдущая версия продукта, над которым ведется работа, или не связанная с ним система. Когда команда принимает обязательство реализовать набор историй во время итерации, ей необходимо учитывать необходимость обслуживания и поддержки. Я не имею в виду общие задачи по устранению ошибок, которые можно приоритизировать заранее. Они должны проходить процесс приоритизации в ходе планирования итерации. Под обслуживанием и поддержкой я понимаю непредсказуемые, но неизбежные элементы жизни многих команд — поддержку веб-сайта или базы данных, прием обращений за поддержкой от ключевых клиентов, оперативную техническую поддержку и т. д.
