В настоящее время мы используем Канбан для управления настройками и расширениями в нашем приложении.
Наше приложение представляет собой корпоративное приложение, которое легко настраивается, однако правильная настройка инструмента довольно сложна. Разработка нашего инструмента велась несколько лет (около 15), и код достаточно сложный. Кроме того, требования и спецификации клиентов очень изменчивы. Они часто существенно меняются перед окончанием проекта. Поэтому нам нужен гибкий (agile) процесс, чтобы адаптировать эти изменения в проекте.
Наша текущая доска Канбан подсчитывается со следующими статусами/столбцами: * Указание * Указание-утверждение * Отклонено * Готово к разработке/конф. * В процессе (разработка/конф.) * Тестирование * UAT * Выполнено.
С моей точки зрения, наша текущая проблема с внедрением Канбана заключается в том, что мы не включаем важную информацию, которая должна запрашиваться поэтапно перед перемещением из одного столбца в другой. Например, Спецификация программного обеспечения, Критерии приемки, План тестирования, Примечания к выпуску... Я вижу, что включение этих элементов может увеличить сложность процесса Канбан, и это заставляет меня задаться вопросом, является ли Канбан правильным решением, которое нам нужно.
С другой стороны, я чувствую, что наша реализация Канбана не дает той гибкости, которую мы хотим. Требования часто меняются до завершения проекта.
Канбан звучит как правильное решение для вас. Я просто не уверен, что то, что вы описываете, является Канбаном в обычном понимании.
Наличие доски задач с этапами работы не делает ее Канбан. Я слышал, как вы говорите, что требования могут меняться с момента, когда вы начинаете, до момента, когда вы заканчиваете. Это говорит мне о том, что время вашего цикла, от начала до конца, велико. Обычно это означает, что ваши «Истории» слишком велики. Это часто означает, что ваши истории недостаточно четко определены и разложены.
Если вы работаете над программным проектом, то цикл одной «истории» обычно не должен превышать недели. Если вы выходите за пределы недели, то, вероятно, вы имеете дело с большой сложностью, и шансы не сделать все правильно и вовремя значительно возрастают.
«История» довольно критична. Я бы порекомендовал книгу Джеффа Паттона «Сопоставление пользовательских историй» в качестве ключевого ресурса. Вам нужно свести свои пользовательские истории к небольшим, ценным частям рабочего продукта.
Это ответ довольно высокого уровня, поскольку я делаю несколько предположений о том, что происходит, основываясь на вашем описании. Найдите способ сократить время цикла, и я думаю, вы увидите, что все остальное улучшится. Лучший способ сократить время цикла — разбить ваши истории на более мелкие части.
Майкл