68 / 94
Scrum и XP: заметки с передовой
68
С другой стороны, что мы делаем в случае, когда мистер Т оказывается "узким местом"? Скажем, сейчас
последний день спринта и большая часть функционала уже реализована, а мистер Т не имеет возможности
протестировать всё необходимое. Что мы делаем в этом случае? Ну, мы можем сделать всех членов команды
помощниками мистера Т. Он решает, что он может сделать самостоятельно, а простые задачи поручает
остальным членам команды. Вот, что такое кросс-функциональная команда!
Итак, мистер Т
действительно
играет особую роль в команде, но он, кроме того, может выполнять
работу других членов команды, так же, как и другие члены команды могут делать его работу.
Повышайте качество – делайте меньше за спринт!
Это решается щё на планировании спринта. Проще говоря, не пытайтесь сделать как можно больше
историй за спринт. Если у вас существуют проблемы с качеством или вам приходится тратить слишком много
времени на приёмочное тестирование, просто делайте меньше за спринт! Это автоматически приведёт к
повышению качества, уменьшит продолжительность приёмочного тестирования и количество багов, которые
вылезут у конечного пользователя. В конце концов, это должно поднять производительность всей команды,
ведь она сможет сконцентрироваться на новых задачах, вместо того, чтобы постоянно тратить время на
исправление старого кода, который постоянно ломается.
Почти всегда получается дешевле сделать меньше, но качественнее, чем больше, но потом в панике
латать дыры.
Стоит ли делать приёмочное тестирование частью спринта?
Ту у нас полный «разброд и шатание». Некоторые наши команды включают приёмочное тестирование в
спринт, однако, большинство – нет. И вот почему:
•
Спринт ограничен во времени. Приёмочное тестирование (которое, если брать во внимание моё
определение, включает отладку и повторный выпуск продукта), довольно сложно втиснуть в
чёткие временные рамки. Что если время уже вышло, а в системе остался критический баг? Что
тогда? Собираетесь ждать завершения ещё одного спринта? Или выпустите готовый продукт с
этим багом? В большинстве случаев оба вариант неприемлемы. Именно поэтому мы выносим
ручное приёмочное тестирование за пределы спринта.
•
Если две Scrum-команды работают над одним продуктом, тогда ручное приёмочное тестирование
необходимо проводить, собрав результаты работы обеих команд. Если обе команды включают в
спринт ручное приёмочное тестирование, тогда всё равно нужна команда, которой придётся
протестировать финальный релиз, который получается после интеграции результатов работы
обеих команд.
Scrum
команда
A
T
релиз
1.0.0
Scrum
команда
B
T
Команда
тестировщиков
Это далеко не идеальное решение, но в большинстве случаев оно нас устраивает.