Сопровождение других продуктов и обязательство

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

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

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