Как ускорить поставку без дополнительных людей

Итак, моей команде потребовалось ускорить поставку. Увеличив производительность разработки, мы чуть не довели своих QA до выгорания. Поэтому мы сделали шаг назад и начали анализировать весь процесс поставки, чтобы найти затык.

Предыдущий пост закончился на том, что мы нашли “бутылочное горлышко” своего процесса поставки. Им оказалось тестирование — команда не могла поставлять больше, чем QA в состоянии переварить. Мы тщательно проверили эту гипотезу и убедились, что она верна.

Конечно же, первым делом я запросил дополнительных тестировщиков в команду. Начальство ответило в стиле ДимАнатолича: “Денег нет, но вы там держитесь. И поставку ускорьте.” Что поделать — пришлось выкручиваться.

⭐️ Выкручиваемся как можем

Первым делом я вернулся к книге “Цель” Голдратта, которая и дала мне понимание бутылочных горлышек. Вопрос был следующий: как ускоряться без дополнительных ресурсов? И я нашёл ответ — строить систему вокруг бутылочного горлышка, подчинить ему весь производственный процесс. Для этого можно сделать следующие вещи:

➡️ Перестать перегружать бутылочное горлышко работой (всё равно больше не сделает). ➡️ Ускорить прохождение работы через бутылочное горлышко (повысить КПД). ➡️ Убрать лишнюю работу с бутылочного горлышка (вдруг оно делает что-то бесполезное). ➡️ Увеличить ресурсы бутылочного горлышка (то, с чего я пытался начать).

В нашем случае подчинение поставки бутылочному горлышку значило, что тестирование становится центральным компонентом системы. И вся система должна быть построена вокруг него. Увеличение ресурсов нам было недоступно (по крайней мере сейчас), поэтому мы стали применять остальные пункты выше.

⭐️ Первые шаги

Первым делом мы перестали перегружать тестировщиков фичами. К счастью, мне даже не пришлось продавать это стейкхолдерам — их интересовала только конечная поставка по результатам спринта, а её объём определялся ресурсом тестирования. Ребята выдохнули, и мы стали думать над фундаментальным вопросом: как нам ускорить тестирование за счёт более свободных ресурсов разработки?

У нас уже была автоматизация, но самих тестов было не слишком много. У тестировщиков постоянно не хватало на них времени. Параллельно мы примерно прикинули, сколько задач возвращается из тестирования на доработку, и поняли, что повышение качества входа может сильно нас ускорить.

Поэтому мы решили вложиться одновременно в автоматизацию и улучшение требований. Список идей выглядел примерно так:

➡️ Изменили DoR: задача считается готовой к разработке, только если в ней описаны тест-кейсы. Для описания тест-кейсов подключается тестирование. ➡️ Изменили DoD: задача считается выполненной, только если разработчик написал автотесты, покрывающие описанные в требованиях кейсы. ➡️ Завели задачи на написание автотестов. Эти задачи выполнялись как техдолг.

Эти перемены учитывали все заинтересованные стороны. Гипотетический путь выглядел примерно так:

➡️ Описанные тест-кейсы упрощали работу программиста, которому не приходилось придумывать их на ходу. ➡️ Написание автотестов снижало количество багов на входе в тестирование. ➡️ Поскольку автотесты сохраняются, количество багов в целом должно уменьшаться. ➡️ Ресурс тестировщиков тратится на написание тест-кейсов, но это окупается за счёт ускорения тестирования. ➡️ Написание автотестов программистами постепенно повысит общее покрытие приложения и дополнительно снизит количество багов.

⭐️ Что получилось в итоге

Гипотезы сработали отлично. Пару спринтов мы привыкали, но обратная связь от ребят была потрясающей. Программисты радовались, что задачи реже возвращаются на доработку, тестировщики радовались, что в задачах меньше багов и растёт покрытие тестами, я радовался ускорению поставки. При этом спокойны были и стейкхолдеры: все при деле, фичи делаются — всё прекрасно.

Мы добились ускорения поставки на 30%, и этот показатель продолжал расти. Бонусом мы получили постепенное снижение багов на проде практически до нуля. Но впереди были новые челленджи, о которых я расскажу в следующем посте :)

// Ставь 💛 в поддержку своих тестировщиков!