align="center">Ситуационное поведение и канбан
В реализациях Канбана мы ожидаем увидеть появление новых привычек и осознания некоторых правил, список которых постоянно растет. Некоторые из них (или даже все) есть в большинстве последних реализаций. Так, все они присутствовали в Corbis за 2007 год. Мы полагаем, что этот список будет расти, когда мы больше узнаем о влиянии Канбана на организации.
• Процессы уникальны для каждого проекта или потока создания ценности.
• Разделенные каденции (или разработка, не привязанная к единому итерационному циклу).
• Рабочее расписание определяется стоимостью задержки.
• Оптимизация поставки ценности с помощью классов обслуживания.
• Управление рисками основывается на емкости производственной системы.
• Терпимость к экспериментам в процессе.
• Управление на основании количественных показателей
• Вирусное распространение (Канбана) по организации.
• Слияние небольших команд для создания единых трудовых центров.
Канбан как разрешение действовать
Канбан – это не методология жизненного цикла разработки ПО и не подход к управлению проектами. Он требует наличия каких-то процессов, чтобы можно было применить Канбан для их постепенного изменения.
Этот эволюционный подход, поддерживающий постепенные изменения, до сих пор оспаривается в сообществе специалистов по гибкой разработке ПО. Дело в том, что в его рамках команды не должны брать на вооружение определенный метод или шаблон процесса. Индустрия сервисов и инструментов разработала несколько методик, определенных в двух популярных методах гибкой разработки. В рамках же Канбана сотрудники и их команды могут создавать собственные производственные процессы, способные покрывать ожидания заказчика от этих самых процессов и требующие выработки нового набора инструментов. И действительно, Канбан породил целую волну возникновения революционных инструментов, готовых сместить уже используемые в гибком управлении проектами и заменить их более наглядными и программируемыми, легко подгоняемыми под конкретные рабочие задачи.
В ранние годы гибкой разработки ПО лидеры сообщества нередко не понимали, почему их методы работали. Мы говорили об «экосистемах»{10} и советовали новичкам внедрять все практики – иначе решение не сработает. Некоторые компании опубликовали модели agile-зрелости, где делались попытки оценки усвоения практик. В Scrum-сообществе существует опробованный на практике тест, который часто называют «тестом Nokia»{11}.
Эти основанные на практике оценки направлены на унификацию и отрицают необходимость в адаптации в соответствии с контекстом. Канбан дает рынку разрешение игнорировать эти практические схемы. Он активно поощряет разнообразие.
В 2007 году несколько человек побывали
Highsmith, Jim.
Тест Nokia Test приписывается Басу Водде, а здесь описан вариант Джеффа Сазерленда, который принял его на вооружение и внес существенные изменения: http://jeffsutherland.com/scrum/2008/08/nokia-test-where-did-it-come-from.html.
