Как я искал, что тормозит поставку команды

Итак, локальная оптимизация привела нас в парадоксальную ситуацию: программисты стали делать больше, а поставка команды снизилась. Чаще всего это случается, когда изменения не учитывают бутылочное горлышко системы. Но мы не сразу поняли, в чём проблема.

В предыдущем посте я рассказал о том, что такое бутылочные горлышки и как производительность моей команды ухудшилась из-за увеличения скорости разработки. В конечном счёте нам пришлось откатить изменения и снизить количество задач, производимых программистами. Бутылочным горлышком оказался ресурс тестировщиков, а не скорость написания кода.

⭐️ С чего начать поиск бутылочных горлышек

Я забежал вперёд и раскрыл спойлер — что оказалось бутылочным горлышком в нашем случае. Но ведь это не вся история. Нам пришлось потратить время и усилия на поиск узкого места.

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

Для начала я пошёл и покопался, что может указывать на бутылочное горлышко в системе. В книге «Цель» Голдратт приводит следующий признак: перед бутылочным горлышком всегда скапливается работа. Выглядеть это может по-разному: какой-то этап процесса оказывается переполнен задачами или же задачи на нём выполняются очень долго. Так или иначе, при визуализации процесса на той же канбан-доске бутылочное горлышко обычно легко увидеть.

⭐️ Действительно ли это бутылочное горлышко?

В нашем случае всё оказалось просто до боли: на этапе Ready for QA было огромное количество задач, которое в основном увеличивалось. В среднем там висело по 10 задач с периодическими увеличениями до 15.

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

➡️ Посмотрели на некотором периоде времени (несколько недель), как у нас меняется состояние колонки Ready for QA и cycle time для этого статуса. Мы увидели, что cycle time самый большой на всём жизненном цикле задачи, а задач в Ready for QA приходит больше, чем уходит.

➡️ Провели ретроспективы, посвящённые трудностям в поставке за последние несколько недель. Тестировщики жаловались на нагрузку, программисты жаловались, что задачи висят в тестировании и их не получается смержить, из-за чего приходится править конфликты.

➡️ На дейликах часто звучали фразы вида: «Протестируйте, пожалуйста, эту задачу в приоритете, она мне нужна для следующей задачи».Как видите, сразу несколько признаков указывали на то, что бутылочным горлышком является тестирование. Поэтому наша локальная оптимизация скорости разработки сделала всей системе только хуже — тестирование просто не могло переварить увеличившийся поток задач.

⭐️ Главная ошибка при поиске бутылочных горлышек

На мой взгляд, главная ошибка — принимать первую же гипотезу как истину и бросаться её чинить.

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

В некоторых процессах бывают статусы с долгим cycle time, но это не делает их бутылочным горлышком. Например, одна из моих команд работала по Scrum, и самый долгий cycle time был у статуса Ready for release. Делает ли это частоту релизов бутылочным горлышком команды? Конечно, нет. Поэтому важно внимательно и всесторонне изучить свои гипотезы, прежде чем что-либо менять.

Итак, нам удалось найти и провалидировать бутылочное горлышко команды. Теперь мы были готовы к тому, чтобы ускорять поставку. Об этом — в следующем посте.

// Сталкивались ли вы с бутылочными горлышками в разработке? Делитесь в комментариях, интересен чужой опыт. А также ставьте 💛**, если тема заходит.