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