Не забывайте об ограничении системы

Не забывайте об ограничении системы

Допустим приемочное тестирование - это ваше самое узкое место. Например, у вас слишком мало тестировщиков или фаза приемочного тестирования забирает много времени из-за ужасного качества кода.

Допустим, команда, которая выполняет приемочное тестирование, успевает проверить 3 фичи в неделю (не подумайте, мы не используем «фичи в неделю» как метрику; я взял это для примера). Также допустим, что ваши разработчики могут сделать 6 новых фич в неделю.

Для менеджера или Product owner’а (даже для самой команды) будет искушением запланировать разработку 6-ти новых фич в неделю.

Только не это! Витать в облаках долго не получится, а когда упадёте - будет больно.

Лучше при планировании рассчитывать на 3 фичи в неделю, а оставшееся время направить на устранение узкого места. Например:

• Заставить разработчиков потестировать (приготовьтесь к «благодарности» за это…).

• Внедрить новые инструменты и скрипты, которые упростят тестирование.

• Добавить больше автоматизации.

• Сделать длиннее спринт и включить приемочное тестирование в спринт.

• Выделить несколько «тестовых спринтов», где вся команда будет работать над приемочным тестированием.

• Нанять больше тестировщиков (даже если это означает уволить некоторых разработчиков).

Мы пробовали все эти решения (кроме последнего). С точки зрения долгосрочной перспективы лучшими являются пункты 2 и 3, а именно: более эффективные инструменты, скрипты и автоматизация тестирования.

А для выявления узких мест лучше всего подходят ретроспективы.