Источник

Идея почерпнута из книг по бережливому производству (“производственная система Тойоты”, LEAN), а также лекции Максима Дорофеева о применении принципов бережливого производства в разработке.

Леция на YouTube: Lean + Agile: Если бы программы создавали также, как и автомобили (доклад на SoftwarePeople 2011)

Предлагаемый мною принцип работы не является точной копией того что предложено Максимом. Я внёс корректировки, ужесточил условия по взятию задач.

Одна задача

Принцип работы — в работу берётся только одна задача на всю команду.

Размер команды не более пяти-шести человек. Правило двух пицц.

Фокусировка

В любой момент времени в работе у команды находится ровно одна задача. Не по одной задаче на каждого человека. Только одна задача сразу на всех.

Таким образом достигается максимальная фокусировка команды на задаче.

Если команда берёт в работу по задаче на каждого члена команды, то задачи выполняются параллельно. Любая из параллельно выполняющихся задач может затормозить остальные, тем самым срывая сроки по ним.

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

Максимальная концентрация всей команды на одной задаче уменьшает риски что команда не уложится в дедлайн.

Мы ничего не успеем?

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

Куда девать время?

Вместо отдыха, по желанию, участник команды может заниматься поиском повышения эффективности своей работы.

Например, есть разработчик и его работа заключается в том чтобы генерировать миграции. Если у него нет насущной работы, он может развивать какой-либо собственный инструмент миграций, который позволит делать работу не за час, а за одну минуту.

Решается проблема с вечной нехваткой времени на техдолг и рефакторинг.

Что делать тестировщику пока код не готов? Готовиться к тестированию. Продумывать кейсы, изучать требования. Может быть задокументировать логику работы фичи в базе знаний. Всё это можно делать и без кода, более того, обнаружив важные нюансы тестировщик может сообщить о них разработчику, чтобы тот учёл их в реализации ДО того, как передаст код на тестирование.

Скорость доставки против утилизации

Главная идея всей этой истории отказаться от идеи максимальной утилизации разработчика.

Утилизация — это степень загруженности разработчика, соотношение времени которое он работает к тому времени которое оплачено.

В разработке господствует идея о том, что разработчик должен быть как производственная единица максимально утилизирован. То есть загружен по максимуму. Это неправильно, так как приводит к многочисленным перекосам в процессе разработки.

Утилизация не должна быть главной метрикой эффективности работы.

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

Также можно измерять время цикла: скорость прохождения задачи от попадания в работу до релиза в прод. Так называемый Time To Market, время за которое бизнес получил что просил. Чем меньше TTM, тем эффективнее работает команда.

Преимущества

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

Наша команда становится спецназом, который может всё.