Как выпустить с Kanban? [закрытый]
4 ответа
Когда мы внедряли Канбан на моей последней работе, выпуски выпускались одним из трех способов:
- Выпускать каждые две недели по расписанию.
- Если в корзине «готово» на доске оказывается достаточно стикеров, чтобы их можно было выпустить вне цикла, сообщите об этом бизнес-подразделению, которое мы выпускаем, чтобы мы могли предотвратить слишком большую рассинхронизацию.
- Бизнес-подразделению требуется выпуск вне цикла для определенной функции или набора функций, которые необходимы немедленно.
Это действительно было довольно открыто.
Канбан говорит о том, как управлять потоком работы и ограничивать незавершенную работу, он ничего не говорит о частоте релизов как таковых. Однако он довольно требователен, поскольку требует, чтобы рабочая интегрированная версия продукта сохранялась постоянно, а новые функции добавлялись, как только они считаются законченными (выполненными, последний столбец на доске).
Концепция, которая часто используется, заключается в том, что существует "каденция" - регулярный интервал, когда этот "готовый продукт" берется и фактически развертывается в живую систему/отгружается.
Однако я думаю, что здесь также может помочь одна концепция, которая очень четко прописана в Scrum. В Scrum четко сказано, что Scrum призывает к "отгружаемому приращению продукта" (подтверждающему определение DONE) в конце каждого спринта. Вопрос о том, отправлять ли его или развертывать, выходит за рамки процесса разработки, потому что в конечном итоге это бизнес-решение. То же самое, я думаю, относится и к Kanban, готовый, интегрированный продукт доступен в любое время, а использовать ли его на самом деле - это бизнес-решение, которое выходит за рамки процесса разработки и управления им.
Нет единого определения. Обычно в канбан мы добавляем MMF (минимальные рыночные функции), что по определению означает, что каждая функция должна повышать ценность для клиента, поэтому вы должны иметь возможность выпускать каждую функцию независимо.
Это не означает, что вы должны выпускать каждую функцию отдельно, поэтому вы найдете целый ряд подходов (Дэвид упоминает некоторые из них). Я считаю обычным случаем, когда команда Kanban выпускает релизы чаще, чем если бы они следовали одному из ограниченных по времени подходов.
Демонстрации в Kanban не являются обязательными, но если клиент желает их использовать, вы можете демонстрировать функции по мере развертывания, даже если вы выпускаете каждую функцию независимо. Теоретически каждая функция должна добавлять ценность, поэтому этот подход должен работать хорошо.
Мы ставим демонстрацию как условие перевода функции из "Тестирования" в "Готовность к выпуску". Таким образом, это происходит от функции к функции, а не от спринта к спринту, и характер функции определяет характер демонстрации. Чем больше бизнес вовлечен в процесс разработки, тем меньше это становится проблемой.