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