Кстати, обычно практики приходящие в софтверный инжиниринг из реальной инженерии (строительство, машиностроение, …), отличаются тяжеловесностью, обилием сложных правил и ограничений, содержат строгую специализацию по ролям – ведь в реальном мире все это действительно оправдано, и отклонение от СНИПов и прочих строительных ГОСТов, нарушение последовательности строительных операций, и т.п. – почти гарантированно приводят к проблемам, а зачастую и к катастрофам с человеческими жертвами. В софтверной же индустрии, используемый при построении информационных систем и других сложных программ «материал» – операционные системы, библиотеки, фреймворки – не менее сложен, чем сталь или бетон, но при этом более гибок, – например, для информационной системы можно (хотя и сложно), без последствий для пользователя, полностью или частично заменить фундамент – сменить используемые библиотеки или даже архитектуру. Поэтому «классическое управление проектами», с диаграммами Ганта и безликими человеческими ресурсами плохо работает в разработке ПО, где для эффективной работы в первую очередь надо сосредоточиться на удобстве командной работы, учитывая психологию разработчика (по отдельности и в группе), минимизируя ручные операции, исключая ненужную работу, т.е. всеми возможными способами повышая мотивацию участников и исключая «узкие места» процесса. Собственно успех Agile-практик показывает, что мораль Крыловской басни «...а вы друзья, как ни садитесь...» к софверной разработке не очень применима, а вот применим скорее сюжет фантастического рассказа «Побег» (из сборника «Лавка сновидений» Ильи Варшавского), где удалось радикально поднять производительность уборки хлопка у заключенных, просто убедив их, что они свободны, и собирают «белые цветы радости».
Этим и объясняется успех Scrum-а для измученных
Так вот, пришедший из автомобилестроения Kanban несет в себе дух Lean-практик, избавляющихся от любых ненужных ритуалов, и содержит в себе всего 3 правила! Сравните с 9 правилами Scrum или более, чем 120 правилами RUP. Неудивительно, что зал нашей компании был полон ПиЭмами, интересующимися – решит ли Kanban их проблемы со Scrum? Можно отказаться от итераций, планирования и жесткого time-boxing-а, не потеряв при этом управляемость и прозрачность процесса?! А, может, как часто бывает, «истина где-то посередине» – и оптимальным будет именно сочетание Scrum и Kanban?
Далее мы представляем видеозапись обсуждения в четырех частях (где-то по часу каждая). Да, обсуждение было настолько захватывающем, что народ не расходился практически до закрытия метро.
Правда мы должны предупредить читателя, что перед тем как смотреть видео, лучше выполнить домашнее задание и прочитать-пролистать вводные материалы по Kanban (собственно это заранее и проделали все собравшиеся):
- http://www.crisp.se/...an-vs-Scrum.pdf
- http://availagility....ow-and-cadence/
- http://en.wikipedia....are_development
В целом, содержание видео следующее. Первая часть – вербализация проблем Scrum, которых собравшиеся надеялись решить через Kanban. Была исписана целая
Кратко ключевые слова из этих проблем, ставшие «меню» этой встречи:
- «Support Team». Техподдержка, багфиксинг, доработки.
- «Сильно распределенная разработка». Разработчики в разных местах, их трудно синхронизовать.
- «Сверхкроссфункциональные микрокоманды». Пара парней на все руки (см. сериал «IT Crowd»).
- «Безудержный заказчик или нестабильный backlog»/«Несинхронизованный deployment»/«Хаотически меняющиеся приоритеты». Постоянные внезапные форс-мажорные заказы «фич» вне бэклога в текущую итерацию.
- «Мутные красные бумажки», «Стек-вместо-очереди», «Research-and-Development».
- «Scrum-шизофрения: Два product-ownera на одну команду».
- «Случай-в-Питере» — Разработка «Софт-плюс-Железо», сложность синхронизации разных команд с разными технологиями.
- «Растянутый Workflow задачи» — долгая многоитерационная постановка, или тестирование на стороне заказчика.
- «Технологическая цепочка».
- «Существенно разномощные задачи» — «фрагментация корзины бэклога».
- «Проектная аритмия» (сбивается ритм демо, планирований, ретроспектив) — разный ритм участников разработки (включая заказчика).
- «Проблема счастливой семейной жизни» — waste времени на ретроспективы.
- «Дефицит Product Ownerов» — они могут стать критическим ресурсом.
- «Расслабляющая команда», «Деградация через самоорганизованное командой уменьшение Scope».
- «Трудно форсировать Аврал».
Ну и далее два часа горячего обсуждения, когда проверяли, сможет ли Kanban вылечить диагнозы, записанные Доктором Agile на доске при, так сказать, коллективном дифференциальном диагнозе. Тоже местами было более чем живо, где например услышишь о уставе боя танковых колонн.
Отчет и качественное видео по ссылке.
