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

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

При оценке возможности принять обязательство по реализации набора новых функций некоторые команды предпочитают сначала распределять задачи между конкретными исполнителями, а потом уже оценивать, сможет ли каждый исполнитель справиться с порученной работой. Этот подход работает хорошо, и я, бывало, рекомендовал его использовать (Cohn, 2004). Однако, как оказалось, отказ от распределения задач во время планирования итерации и от индивидуальных оценок, необходимых для принятия обязательств, облегчает команде переход на мышление «мы все работаем над этим вместе».

Если у вас все же возникает необходимость распределить задачи между исполнителями во время планирования итерации, то такое распределение следует считать временным и легко изменяемым в ходе итерации.

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

Я представляю себе итерацию как пустой стакан. Первое, что наливают в стакан, — это неизменные обязательства команды, такие как поддержка и обслуживание других продуктов. Оставшееся в стакане пространство доступно для принятия обязательств по выполнению работы во время итерации. Графически этот образ представлен на рис. 14.4. Понятно, что у команды, чей стакан на 10 % заполнен работой, связанной с поддержкой, будет больше времени на выполнение другой работы, чем у команды, чей стакан изначально наполнен на 90 %.

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

Эффективны оба подхода — и планирование итерации на основе скорости, и планирование итерации на основе обязательств. Я, однако, предпочитаю подход на основе обязательств. Хотя скорость играет критическую роль в планировании релиза, я не считаю, что она должна играть такую же роль при планировании итерации. Для такого заявления есть две причины.

Во-первых, поскольку скорость является показателем для укрупненных оценок (пункты или идеальные дни), она недостаточно точна для планирования работ в коротких итерациях. Мы можем использовать эти укрупненные оценки для определения общего объема работы, которую команда выполняет во время итерации. Их, однако, нельзя таким же образом применять для планирования краткосрочной работы в одной итерации.

Во-вторых, команде необходимо реализовывать 20–30 пользовательских историй за итерацию, чтобы ошибки в пунктах или идеальных днях взаимно уравновешивались. Мало какие команды реализуют столько историй за итерацию.

Чтобы показать, к чему приводят эти проблемы, предположим, что команда имела скорость 30 в каждой из последних пяти итераций. Скорость команды практически стабильна, и, скорее всего, в очередной итерации она вновь выполнит 30 пунктов. Вместе с тем мы знаем, что не все пятипунктовые истории одинаковы. Если взять большой набор пятипунктовых историй, мы наверняка сможем найти, скажем, шесть пятипунктовых историй, которые немного легче, чем пять пунктов. Мы можем промахнуться с некоторыми из них, но, если впервые попробуем это, возможно, все получится — скорость может возрасти с 30 до 40. В то же время можно отобрать только те истории, которые немного сложнее, чем пять пунктов. Мы по-прежнему считаем, что их надо оценивать в пять пунктов, однако они немного сложнее, чем остальные пятипунктовые истории.

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

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

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