Майк Кон - Agile: оценка и планирование проектов

Естественно, нередко встречаются более крупные задачи. На них, как правило, следует смотреть как на место для размещения одной или нескольких дополнительных задач, которые добавляются по мере формулирования. Если вам необходимо создать 16-часовую задачу во время планирования итерации, создавайте ее. Вместе с тем, как только появится более глубокое понимание этой задачи, дополняйте или заменяйте ее. Это может означать замену первоначальной карточки карточкой с большим или меньшим временем, чем первоначальные 16 часов.

Подход на основе обязательств является альтернативным способом планирования итерации. Этапы планирования итерации на основе обязательств во многом повторяют этапы планирования итерации на основе скорости. В то же время вместо создания плана с использованием вчерашней погоды для определения количества пунктов или идеальных дней, включаемых в текущую итерацию, команде предлагается добавлять в итерацию по одной истории до тех пор, пока она не исчерпает свои возможности по реализации. В целом подход на основе обязательств представлен на рис. 14.3.

Первые этапы — корректировка приоритетов и идентификация цели итерации — точно такие же, как и в подходе на основе скорости. Следующий этап, «Выбор истории для добавления», уже отличается. Владелец продукта и команда по-прежнему выбирают историю с наивысшим приоритетом, которая поддерживает цель итерации. Вместе с тем при планировании итерации на основе обязательств истории выбираются и разбиваются на оцениваемые задачи по одной зараз. Это отличает данный подход от подхода на основе скорости, где выбирается набор историй, оценки которых соответствуют расчетной скорости.

Истории выбираются по одной зараз потому, что после разбивки каждой истории на задачи и оценки этих задач команда решает, сможет ли или не сможет она принять обязательства по реализации этой истории в данной итерации.

В своем исследовании факторов успеха команд Ларсон и Лафасто (Larson and LaFasto, 1989) установили, что единое обязательство, принятое всеми членами команды, является одним из ключевых факторов успеха. Во время совещания по планированию итерации я спрашиваю команду: «Можете ли вы принять обязательство реализовать функции, которые мы обсудили?» Обратите внимание на то, что я не спрашиваю, смогут ли они принять обязательство реализовать задачи, которые мы идентифицировали. Это совершенно другой вопрос и значительно более слабое обязательство, поскольку оно относится к выполнению набора задач, а не к постановке новой функциональности.

Если в ходе итерации появятся новые задачи (а они почти наверняка появятся), то команда, которая приняла обязательство поставить функциональность, описанную пользовательской историей, будет стараться выполнить также и новые задачи. Команда, которая обязалась выполнить только набор идентифицированных задач, может отказаться от выполнения новых. Не исключено, однако, что новые задачи окажутся слишком объемными для выполнения в данной итерации. В этом случае команде необходимо обсудить ситуацию с владельцем продукта и определить, есть ли возможность реализовать цель итерации. Команде для этого, возможно, придется сократить функциональность истории, а то и полностью исключить ее.

Я спрашиваю команду, сможет ли она принять обязательство по реализации после разбивки каждой пользовательской истории на задачи и оценки этих задач. Применительно к первой пользовательской истории такой вопрос может показаться глупым. В команде, планирующей двухнедельную итерацию, может быть семь человек. Может так случиться, что они идентифицировали работу пока всего лишь на 34 часа, а я спрашиваю, смогут ли они принять обязательство по ее выполнению. Их ответ (либо в словесной форме, либо в виде смущения на лицах), без сомнения, будет следующим: «Конечно, мы можем принять обязательство выполнить это. Нас семь, и у нас целых две недели, а здесь работы всего на 34 часа». Вместе с тем чем дальше продвигается обсуждение и чем больше пользовательских историй включаются в итерацию, тем более тщательного обдумывания требует мой вопрос о возможности принятия обязательства. В конечном итоге наступает предел, за которым команда уже не может увеличивать объем обязательств. В таком случае она может исключить историю или заменить ее на более мелкую перед завершением обсуждения.

По моему опыту, для определения, сможет ли команда справиться с набором пользовательских историй, лучше всего просуммировать оценки, данные задачам, и посмотреть, представляет ли полученная сумма разумный объем работы. Надо учитывать, конечно, что некоторым задачам присуща высокая неопределенность, поскольку работа не продумывалась детально, а требования туманны. Так или иначе, суммирование оценок дает определенное представление об общем объеме работы.

Допустим, команда работает с использованием двухнедельных итераций. В каждой итерации ей доступно 560 часов (7 человек × 10 дней × 8 часов в день). Мы знаем, что определенное время тратится на деятельность, не отраженную в карточках с задачами, — ответы на электронные письма, участие в совещаниях и т. д. Также нам известно, что оценки неточны; в конце концов, это оценки , а не гарантированные величины. По этим причинам нельзя ожидать, что эта команда возьмется за выполнение задач объемом 560 часов. На практике большинство команд успешно справляются с работой, когда ее плановый объем (сумма оценок на карточках с задачами) составляет от четырех до шести часов в день. Для нашей команды из семи человек, работающей двухнедельными итерациями, это означает плановый объем работы от 280 до 420 часов. В какой точке этого диапазона команда остановится, зависит от того, насколько хорошо она идентифицирует задачи для данной истории, насколько точно оценивает эти задачи, а также от объема сторонних обязательств членов команды и размера общекорпоративных непроизводительных издержек. После пары итераций большинство команд начинают примерно чувствовать, какой объем работы в часах они должны планировать на итерацию.

Прежде чем принимать обязательство выполнить работу во время итерации, необходимо посмотреть на задачи и понять, обеспечивают ли они подходящее распределение работы в соответствии с квалификацией и опытом членов команды. Не получится ли так, что Java-программист окажется перегруженным, а HTML-программисту будет нечего делать? Не окажутся ли выбранные пользовательские истории легко поддающимися программированию, но требующими много времени или трудно тестируемыми, что приведет к перегрузке тестировщика? Не требуют ли выбранные истории предварительного анализа и дизайна пользовательского интерфейса?