Почти всегда получается дешевле сделать меньше, но качественнее, чем больше, но потом в панике латать дыры.
Стоит ли делать приёмочное тестирование частью спринта?
Тут у нас полный «разброд и шатание». Некоторые наши команды включают приёмочное тестирование в спринт, однако, большинство — нет. И вот почему:
Спринт ограничен во времени. Приёмочное тестирование (которое, если брать во внимание моё определение, включает отладку и повторный выпуск продукта), довольно сложно втиснуть в чёткие временные рамки. Что если время уже вышло, а в системе остался критический баг? Что тогда? Собираетесь ждать завершения ещё одного спринта? Или выпустите готовый продукт с этим багом? В большинстве случаев оба вариант неприемлемы. Именно поэтому мы выносим ручное приёмочное тестирование за пределы спринта.
Если две Scrum-команды работают над одним продуктом, тогда ручное приёмочное тестирование необходимо проводить, собрав результаты работы обеих команд. Если обе команды включают в спринт ручное приёмочное тестирование, тогда всё равно нужна команда, которой придётся протестировать финальный релиз, который получается после интеграции результатов работы обеих команд.
Это далеко не идеальное решение, но в большинстве случаев оно нас устраивает.
Соотношение спринтов и фаз приёмочного тестирования
В идеальном Scrum-мире фаза приёмочного тестирования не нужна, так как каждая Scrum-команда после каждого спринта выдаёт новую, готовую к реальному использованию версию системы
Ну, а на самом деле, всё выглядит чуть-чуть по-другому:
После первого спринта выпускается глючная версия 1.0.0. Во время второго спринта начинают поступать сообщения об ошибках, и команда большую часть времени занимается отладкой, а потом выпускает версию с исправлениями 1.0.1 в середине спринта. Потом, в конце второго спринта выходит версия 1.1.0 с новым функционалом, которая, естественно, оказывается ещё более глючной, так как у команды просто не хватило времени довести её до ума из-за того, что приходилось подчищать хвосты, оставшиеся с прошлого спринта. И так по кругу.
Наклонная красная штриховка второго спринта символизирует хаос.
Неприглядная картина, да? А самое грустное в том, что эта проблема остаётся даже при наличии команды приёмочного тестирования. Единственная разница состоит в том, что основная масса сообщений об ошибках поступает от команды тестирования, а не от негодующих пользователей. Но эта разница просто огромна с точки зрения бизнеса, хотя для разработчиков ничего и не меняется. Ну, кроме только того, что тестировщики обычно менее агрессивны, чем конечные пользователи. Обычно.
Простого решения этой проблемы мы так и не нашли. Но наэкспериментировались с разными подходами вдоволь.
Перво-наперво, опять же, необходимо обеспечить наивысшее качество кода, который создаёт Scrum-команда. Стоимость раннего обнаружения и исправления ошибки (в пределах спринта) несравнимо ниже стоимости обнаружения и исправления ошибки после окончания спринта.
Но факт остаётся фактом: как бы мы не уменьшали количество ошибок, они обязательно найдутся и после завершения спринта. Так что же с этим делать?
Подход № 1: «Не начинать новые истории, пока старые не будут готовы к реальному использованию»
Звучит классно, не так ли? Вас тоже греет эта мысль?:)
Несколько раз мы уже было решались на этот подход, и даже рисовали теоретические модели того, как бы могли это сделать. Но каждый раз мы останавливались, когда рассматривали обратную сторону медали. Нам бы пришлось ввести неограниченную по времени итерацию между спринтами, в которую бы мы только тестировали и исправляли ошибки до тех пор, пока у нас на руках не было бы готового к использованию релиза.
Наличие неограниченной во времени итерации между спринтами нам не нравилось в основном из-за того, что она бы нарушила регулярность спринтов. Мы не смогли бы больше заявлять: «Каждые три недели мы начинаем новый спринт». А кроме того она не решает проблему. Даже если мы введём такую итерацию, всё равно время от времени будут появляться ошибки, срочно требующие внимания, и нам надо быть к этому готовыми.