1 ...6 7 8 10 11 12 ...108 В ранние годы гибкой разработки ПО лидеры сообщества нередко не понимали, почему их методы работали. Мы говорили об «экосистемах» {10}и советовали новичкам внедрять все практики – иначе решение не сработает. Некоторые компании опубликовали модели agile-зрелости, где делались попытки оценки усвоения практик. В Scrum-сообществе существует опробованный на практике тест, который часто называют «тестом Nokia» {11}.
Эти основанные на практике оценки направлены на унификацию и отрицают необходимость в адаптации в соответствии с контекстом. Канбан дает рынку разрешение игнорировать эти практические схемы. Он активно поощряет разнообразие.
В 2007 году несколько человек побывали в моем офисе в Corbis, чтобы посмотреть на Канбан в действии. Обычно все посетители, связанные с agile-сообществом разработки ПО, спрашивали об одном и том же: «Дэвид, мы увидели в офисе семь канбан-досок. Они все разные! Каждая команда работает по своему процессу! Как можно справиться с таким разнообразием?» На этот вопрос я обычно отвечал так: «Конечно! Все ситуации разные. Они развивают свой процесс в соответствии с контекстом». Но я знал, что все процессы ведут начало от одних и тех же принципов и что члены команд, осознавая эти базовые принципы, могут адаптировать их под собственные нужды.
Когда с Канбаном познакомилось больше людей, они поняли, что эта система помогает решать проблемы управления изменениями, с которыми они столкнулись в своих организациях. Канбан придает гибкости команде, проекту или компании. Мы пришли к выводу, что Канбан разрешает создать на рынке собственный процесс, оптимизированный для конкретного контекста. Канбан дает разрешение людям думать самостоятельно. Он позволяет быть разными: отличаться от команды, расположившейся в соседнем кабинете, на другом этаже, в другом здании или в конкурирующей фирме. Он дает разрешение отклониться от учебника. Более того, Канбан дает инструменты, которые позволяют объяснить (и оправдать), почему разнообразие – это хорошо и выбрать его – значит поступить правильно.
Чтобы подчеркнуть этот выбор, я разработал дизайн футболки для Общества ограничения незавершенных задач. Я вдохновился постером Шепарда Фэйри для предвыборной кампании Обамы, на который поместил портрет Тайити Оно, создателя канбан-системы в Toyota. Слоган «Да, мы за канбан» призван подчеркнуть, что у вас есть возможность. Вам разрешается попробовать Канбан, модифицировать свои процессы, быть другими. Ваша ситуация уникальна, и вы можете разработать собственное решение для своего процесса, оптимизированное для вашей сферы деятельности и потока создания ценности, рисков, с которыми вы сталкиваетесь, навыков вашей команды и требований ваших клиентов.
• Канбан-системы могут быть использованы в любой ситуации через ограничение наличия элементов работы внутри системы.
• Сады Императорского дворца в Токио используют канбан-систему, чтобы контролировать число посетителей в парке.
• Количество сигнальных карточек «канбан», находящихся в обращении, ограничивает объем незавершенных задач.
• Новая работа втягивается в процесс после возвращения в оборот сигнальной карточки, когда предыдущее задание выполнено.
• В IT-сфере мы, как правило, используем виртуальную канбан-систему, поскольку для ограничения количества незавершенных задач не передаются какие-либо физически существующие карточки.
• Доски со стикерами, часто встречающиеся в гибкой разработке ПО, не являются канбан-системами.
• Канбан-системы создают на рабочем месте положительную напряженность, которая вызывает обсуждение проблем.
• Канбан-метод (или Канбан с большой буквы) использует канбан-систему как катализатор изменений.
• Канбан требует формальных политик процессов.
• Канбан использует инструменты разных областей знаний для анализа проблем и поиска решений.
• Канбан предполагает пошаговое улучшение процессов благодаря постоянному выявлению проблем, влияющих на производительность.
• Современное определение Канбан-метода можно найти в сети на сайте Общества ограничения незавершенных задач (Limited WIP Society, http://limitedwipsociety.ning.com/).
• Канбан дает разрешение на отклонения в разработке ПО, поощряет поиск специфических решений в зависимости от контекста вместо догматического следования определению процесса жизненного цикла разработки ПО или шаблону.
Читать дальше
Конец ознакомительного отрывка
Купить книгу