70 / 94
Scrum и XP: заметки с передовой
70
Простого решения этой проблемы мы так и не нашли. Но наэкспериментировались с разными подходами
вдоволь.
Перво-наперво, опять же, необходимо обеспечить наивысшее качество кода, который создаёт Scrum-
команда. Стоимость раннего обнаружения и исправления ошибки (в пределах спринта) несравнимо ниже
стоимости обнаружения и исправления ошибки после окончания спринта.
Но факт остаётся фактом: как бы мы не уменьшали количество ошибок, они обязательно найдутся и после
завершения спринта. Так что же с этим делать?
Подход №1: "Не начинать новые истории, пока старые не будут готовы к реальному
использованию"
Звучит классно, не так ли? Вас тоже греет эта мысль? :)
Несколько раз мы уже было решались на этот подход, и даже рисовали теоретические модели того, как
бы могли это сделать. Но каждый раз мы останавливались, когда рассматривали обратную сторону медали.
Нам бы пришлось ввести неограниченную по времени итерацию между спринтами, в которую бы мы только
тестировали и исправляли ошибки до тех пор, пока у нас на руках не было бы готового к использованию
релиза.
Спринт №
1
Время
Спринт №
2
Релиз
Спринт №
3
Релиз
Наличие неограниченной во времени итерации между спринтами нам не нравилось в основном из-за
того, что она бы нарушила регулярность спринтов. Мы не смогли бы больше заявлять: "Каждые три недели
мы начинаем новый спринт". А кроме того она не решает проблему. Даже если мы введём такую итерацию,
всё равно время от времени будут появляться ошибки, срочно требующие внимания, и нам надо быть к этому
готовыми.
Подход №2: "Начинать реализовывать новые истории, но наивысшим приоритетом ставить
доведение старых до ума"
Мы предпочитаем этот подход. По крайней мере, до сих пор так и было.
По сути, он состоит в следующем: когда мы заканчиваем спринт, мы переходим к следующему, но
учитываем, что в следующем спринте нам потребуется время на исправление багов прошлого спринта. Если
следующий спринт оказывается перегружен работой над исправлением дефектов прошлого, то мы пытаемся
понять причину такого количества дефектов и выработать способ поднять качество. И мы выбираем длину
спринта достаточной, чтобы успеть справиться с приличным объёмом работы по исправлению багов
прошлого спринта.
Постепенно, за несколько месяцев, количество работы по устранению дефектов прошлых спринтов
уменьшилось. Кроме того, мы смогли добиться, чтобы на устранение дефекта требовалось отвлекать меньше
людей, то есть, нет нужды беспокоить всю команду по поводу каждого бага. Теперь хаос в наших спринтах
снизился до приемлемого уровня.