Lean №11 - Поставляйте как можно быстрее

Зачем поставлять быстро?

1. Это нравится Заказчику. Чем быстрее покажешь, тем ему приятнее, тем быстрее он сможет использовать продукт.
2. Это снижает риски. Вы можете много закодировать, но пока это не в проде, вы не снимите все риски.
3. Это позволяет принимать решения как можно позже. Вместо того чтобы месяц думать над сложным решением, лучше показать через неделю и снизить уровень неопределенности, чтобы иметь возможность принять более правильное решение.

Что предлагается для этого:

1. Переход с Push системы на Pull. Всегда кажется что чтобы команда работала наиболее эффективно, необходимо микроменеджмент чтобы каждому говорить что ему нужно делать в каждый момент времени. Проблема в том что ИТ системы довольно сложны и комплексны, и четкий план мало вероятен. Лучше работает Pull система, основанная на сигналах и договоренностях. Для этого можно использовать:
1. Короткие итерации.
2. Визуальный контроль. Так как работа само-управляема, необходима визуализация того что происходит для всех. Burn-down chart, список проблем, список возможных рефакторингов, список идей для улучшений, статус сборок, статус тестов. Это все улучшает процесс само-организации. Нужно подумать как это можно улучшить сейчас.
2. Теория очередей. 
1. Необходимо постоянно оценивать время цикла и работать над тем чтобы его снизить. Время от начала грумминга истории до ее закрытия. Время от начала разработки истории с спринте, до ее установки на UAT стенд. 
2. Постоянная скорость прибытия работ. Скидки в ресторанах в дневное рабочее время, дешевый трафик по ночам. Все стараются избежать пиковых нагрузок и распределить их более равномерно. Не нужно выгружать все истории на тестирование в конце спринта - нужно стараться распределить поставку более равномерно. Не важно что вы много кодируете, если не успеваете это тестировать. Не важно много тестировать, если вы не успеваете выгружать это в прод.
3. Малые объемы работ. Чем меньше объем задачи, тем быстрее она пройдет весь процесс, тем меньше для нее будет время цикла. Тем быстрее ее можно будет протестировать и закрыть. Это позволяет распределить процесс тестирования по спринту более равномерно, и не сваливать его в самый конец.
4. Оценивайте объем работы, который ждет чтобы его выполнили. Он будет соотносится с временем цикла. Нужно посмотреть на все наши процессы более обще, со стороны.  
5. Чем больше вариативность времени прибытия работ или времени исполнения работ, тем выше будет время цикла и время ожидания работ. 
6. Чем больше объем работ, тем больше вариативность времени прибытия и исполнения (при чем не линейно). Из этого следует что более эффективно уметь разбивать User story для спринта на примерно одинаковый объем (оценку в points) чтобы сделать процесс более предсказуемым. Тогда время цикла будет меньше, ожиданий будет меньше, визуализация на Burn-down chart лучше.
7. Уменьшение вариативность в начале процесса оказывает больше влияния чем уменьшение вариативности в конце процесса.

Надо измерять и много думать. Можно использовать как одну из тем на ретроспективе.