Комментарии 6
чем быстрее она окажется в проде, тем выше эффективность команды.
Это не так, если брать определение эффективности из статьи. То есть подход one-piece-flow дает оптимизацию времени, но при этом не обеспечивает оптимизацию пропускной способности.
Клевая статья, спасибо!
А что вы делаете с исследовательскими задачами? Когда задачу без прототипа не оценить, когда надо побегать по отделам и договориться про совместное решение и тому подобное?
Цель исследования — сформировать список дальнейших понятных действий. Такие задачи попадаются редко, но действительно бывают. Обычно делем так: берём её в спринт, оцениваем всегда в одинаковое число SP. Если в процессе исследования понимаем, что за эти же SP можно начать что-то реализовывать, то тут же и делаем. Если нет — заводим прилинкованные к этому тикету новые, а с ними уже работаем, как обычно.
По этому фильтру работа началась приблизительно в июне, то есть мы с 19 дней на задачу ускорились до 9 дней. Результат ещё круче, чем в Поиске!
Обратите внимание на зелёную линию. Это количество задач, которые попали на график. Мы стали чуть больше декомпозировать и, как следствие, выполнять больше задач.
Задачи стали мельче, поэтому они стали выполняться быстрее. Ловкость рук и отличный график.
Всё так. Изначальная цель доставлять быстрее новые фичи пользователям выполнена. Иногда даже специально отказывались от больших и долгих эпиков в пользу небольших задач, которые приносят такой же эффект по ключевым метрикам команды.
Но да, важно следить за тем, чтобы команда не начала дробить задачи ради дробления. Каждая задача — полноценная фича, заметное улучшение приложения. Ну и опять же, команда в курсе, что эти графики — не цель, а инструмент, так что уже на этом этапе можно отмести мотивацию дробить впустую.
Ускоряем Cycle Time и растим счастье в команде