Неправильный подход: «Клепать новые истории»
Если перефразировать, то это значит: «реализовывать новые истории, вместо того, чтобы довести старые до ума». Казалось бы — да кому такое может прийти в голову? А, тем не менее, мы частенько допускали эту ошибку в начале и, я уверен, что и многие другие компании тоже. Эта неадекватность связана со стрессом. На самом деле многие менеджеры не понимают, что когда кодирование закончено, то, мы, как правило, всё ещё далеки от релиза, готового к использованию. Поэтому менеджер (или product owner) просит команду наращивать функционал продукта, в то время как груз почти-готового-к-выпуску кода становится всё тяжелее и тяжелее, замедляя весь процесс.
Не забывайте об ограничении системы
Допустим приемочное тестирование — это ваше самое узкое место. Например, у вас слишком мало тестировщиков или фаза приемочного тестирования забирает много времени из-за ужасного качества кода.
Допустим, команда, которая выполняет приемочное тестирование, успевает проверить 3 фичи в неделю (не подумайте, мы не используем «фичи в неделю» как метрику; я взял это для примера). Также допустим, что ваши разработчики могут сделать 6 новых фич в неделю.
Для менеджера или Product owner’а (даже для самой команды) будет искушением запланировать разработку 6-ти новых фич в неделю.
Только не это! Витать в облаках долго не получится, а когда упадёте — будет больно.
Лучше при планировании рассчитывать на 3 фичи в неделю, а оставшееся время направить на устранение узкого места. Например:
• Заставить разработчиков потестировать (приготовьтесь к «благодарности» за это…).
• Внедрить новые инструменты и скрипты, которые упростят тестирование.
• Добавить больше автоматизации.
• Сделать длиннее спринт и включить приемочное тестирование в спринт.
• Выделить несколько «тестовых спринтов», где вся команда будет работать над приемочным тестированием.
• Нанять больше тестировщиков (даже если это означает уволить некоторых разработчиков).
Мы пробовали все эти решения (кроме последнего). С точки зрения долгосрочной перспективы лучшими являются пункты 2 и 3, а именно: более эффективные инструменты, скрипты и автоматизация тестирования.
А для выявления узких мест лучше всего подходят ретроспективы.
У вас, наверное, сложилось впечатление, что у нас есть тестеры во всех Scrum-командах, и что мы обзавелись ещё одной огромной командой тестеров, которые после каждого спринта проводят приёмочное тестирование всех готовых продуктов.
Ну … это не так совсем.
У нас всего несколько раз