Scrum и XP: заметки с передовой (Книберг) - страница 52

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

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

• Установить и настроить тестовое окружение.

• Уточнить требования.

• Детально обсудить процесс установки.

• Написать документы по установке (заметки к релизу, readme.txt или что там требуется в вашей компании).

• Пообщаться с подрядчиками (например, с дизайнерами пользовательского интерфейса).

• Улучшить скрипты автоматизированной сборки.

• Последующее разбиение историй на задачи.

• Собрать ключевые вопросы от разработчиков и проследить, чтобы они не остались без ответов.

С другой стороны, что мы делаем в случае, когда мистер Т оказывается «узким местом»? Скажем, сейчас последний день спринта и большая часть функционала уже реализована, а мистер Т не имеет возможности протестировать всё необходимое. Что мы делаем в этом случае? Ну, мы можем сделать всех членов команды помощниками мистера Т. Он решает, что он может сделать самостоятельно, а простые задачи поручает остальным членам команды. Вот, что такое кросс-функциональная команда!

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

Повышайте качество — делайте меньше за спринт!

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