Эмерджентное поведение с Канбаном
Чем сильнее вы сожмете кулак, Таркин, тем больше звездных систем ускользнет сквозь ваши пальцы.Принцесса Лея
Вспомним пример с медицинским центром, приведенный выше. Если бы вы попросили команду, которой руководит менеджер с командно-административным стилем управления, помочь персоналу улучшить процессы, то что бы произошло? Первым делом оценили бы, сколько времени врач тратит на каждого пациента. Это потребовало бы вовлечения врачей, медсестер и сотрудников клиники, но позволило бы руководителям проекта взять под контроль систему, создать подробное описание всех ресурсов (процедурных комнат, врачей и медсестер) и на микроуровне управлять каждым аспектом практики.
Такой способ успокоил бы всех, но, к сожалению, он неэффективен. Врачи учились лечить, а не оценивать. Руководители проекта могли бы придумать идеальное расписание, но более вероятно, что они создадут нереальное расписание, потому что врачи дадут им скудные данные. Именно поэтому Канбан смотрит на всю систему в совокупности. Вместо попыток заниматься микроменеджментом любой небольшой деятельности команда использует системы мышления Канбан, чтобы понять, измерить и постепенно совершенствовать систему в целом. Принимается тот факт, что отдельные элементы работы могут меняться, но система в целом действует предсказуемо, когда потери, неравномерность и излишек (муда, мура и мури) снижаются.
Когда команда использует Канбан, чтобы постепенно улучшить процесс сборки программного обеспечения, зачастую начинает меняться и вся компания. Рассмотрим пример компании, пытающейся сократить время выполнения задачи. До попытки команды использовать Канбан менеджеры и пользователи ругали ее за отсутствие немедленной реакции на запросы пользователей. В ответ команда создала планы проекта, которые «доказали», что ничего не произошло. Это привело к конфликту и негативным эмоциям.
Канбан помог решить основную проблему. Команда использовала метод пяти «почему», чтобы найти причину удлинения времени выполнения задач, и ввела WIP-лимиты для исправления ошибки.
Но как это решило проблему? Давайте вернемся к первым двум канбан-практикам, о которых говорилось в этой главе, – совместному улучшению, экспериментальному развитию и реализации петли обратной связи. Они помогают понять, что происходит. Во-первых, в буквальном смысле изменилось восприятие процессов не только всеми членами команды, но и руководителем. Визуализация рабочего процесса при помощи канбан-доски выявила раздробленное видение. Менеджеры смогли понять, что работы скапливались, и это убедило их в необходимости введения WIP-лимитов, а также уменьшения управляющих воздействий на команду. Вот пример того, как лимитирование незавершенных работ меняет поведение.
Рассмотрим ситуацию, когда команда постоянно получает запросы от разных менеджеров и ей приходится соблюдать баланс чужих интересов. Каждый руководитель считает свою просьбу самой важной. Если команда работает по запросу одного менеджера, то другой чувствует себя оскорбленным. Все испытывают большое давление, потому что столкнулись с неразрешимой проблемой.
Если эта команда использует Канбан для визуализации рабочего процесса, то все запросы менеджеров по написанию функций будут в итоге находиться в качестве рабочих элементов в первом столбце. Если запросов больше, чем команда способна выполнить, то стикеры накопятся в столбце и каждый сможет это увидеть. Теперь разработчикам понятно, что делать, – нужно получить согласие всех менеджеров на введение WIP-лимита в этом столбце.
Допустим, они договорились и ввели лимит на выполнение незавершенных работ. Менеджеры продолжат добавлять новые функции до тех пор, пока этот WIP-лимит не будет исчерпан. Но как только первый менеджер достигает лимита, он больше не может просто так добавить новый стикер на доску, для этого придется удалить какой-то другой. Если он не хочет удалять один из своих стикеров, нужно будет договариваться с другими менеджерами.
Повторимся: когда менеджер уперся в WIP-лимит, он не обвинил команду. Он признал это как ограничение системы и занялся поиском решения с коллегами-менеджерами. Перед нами важная часть системного мышления. Когда все, кто имеет дело с системой, осознают это, они работают в ее рамках, чтобы решать свои проблемы. И так как все понимают, как работает система, потери и неравномерная нагрузка больше не являются проблемой только одной команды. Это общая проблема, в том числе и для менеджеров.
Так новое поведение проявляется и вне команды. Вместо того чтобы просто обвинять разработчиков за неравномерную нагрузку, в чем необязательно они виноваты, всех начинают волновать стикеры в первом столбце, потому что именно ими будет заниматься команда. Можно организовывать встречи для определения приоритетов, устраивать «торги» между собой или искать любые другие пути, чтобы решить, какие задачи выполнять в первую очередь. Но, главное, команде больше не нужно брать на себя вину, потому что она не должна работать на пределе возможностей.
Другими словами, до внедрения Канбана разработчикам приходилось иметь дело с руководителями, считающими, что команда может выполнить неограниченное количество задач. И они всегда были разочарованы, когда результаты работы не соответствовали обещаниям. С введением WIP-лимита менеджеры с магическим мышлением перестали так думать. Они пересмотрели свое поведение не из желания что-то изменить, а потому что работали в системе, которая побуждала их действовать по-другому. В результате у команды появился временной запас, необходимый для отдыха и качественной работы. Все силы, которые раньше тратились на сепаратные переговоры с менеджерами по удовлетворению их запросов, теперь полностью отдаются работе. Это гораздо более эффективный способ управления командой.
Ключевые моменты
Одна из важных целей, которую ставит перед собой канбан-команда, – максимизация потока или скорости, с которой рабочие элементы перемещаются по системе.Канбан-практика измерения и управления потоком подразумевает измерение потока и корректировку процесса для его максимизации.Кумулятивная диаграмма потока (CFD) показывает лимит на выполнение незавершенных работ (WIP-лимит), число рабочих элементов, добавляемых ежедневно (скорость поступления), общее количество рабочих элементов в рабочем процессе (список) и среднее время нахождения рабочих элементов в системе (время на выполнение заказа).Когда скорость поступления и список со временем не меняются, система стабильна, канбан-команды устанавливают WIP-лимит для ее стабилизации.Когда система стабильна, к ней можно применять закон Литтла, который означает, что среднее время на выполнение заказа всегда равно долгосрочной скорости поступления, поделенной на долгосрочный список.Если ваша команда может стабилизировать рабочий процесс при помощи WIP-лимитов, то вы сумеете уменьшить время выполнения заказа для пользователей при условии, что они не будут добавлять новые рабочие элементы, сокращающие скорость поступления.Канбан-команды часто прибегают к процессу явной стратегии, добавляя определение понятия «сделано» или дополнительный критерий внизу каждого столбца на канбан-доске.Когда канбан-команды постепенно совершенствуют систему, добавляя WIP-лимиты, управляя потоком и используя явную стратегию, они тем самым улучшают управление остальной компанией.
Часто задаваемые вопросы
Вы говорите о WIP-лимитах и явной стратегии как об инструментах, способных изменить работу команды. Но этот аргумент кажется надуманным. Или это все-таки правда?
Удивительно, но это правда. Чтобы понять почему, вернемся к истокам Lean и Канбана.
WIP-лимиты – простой, но эффективный инструмент для сглаживания потока, и его эффективность известна уже давно. Канбан базируется на сигнальной системе для создания вытягивающей производственной системы, которая возникла в компании Toyota в 1950-е годы (как и многие идеи и инструменты Lean). Название «канбан» происходит от японского слова, которое означает «сигнальная карточка» (буквально «вывеска» или «рекламный щит»); для обозначения сигнальной карточки принято писать слово «канбан» с маленькой буквы. На станции сборочной линии завода-изготовителя использовалось определенное количество канбан-карточек, на которых печатался номер каждой детали или ее название, требующейся на сборочной линии.
По мере окончания комплектующих на этапе сборочной линии канбан-карточка вставлялась в пустой слот на тележке для деталей; это сигнализировало, что их количество надо увеличить. Так выглядел цикл пополнения сборочной линии, а производственная команда использовала только необходимые в данный момент комплектующие, что позволило всей компании уменьшить общее количество деталей, которые необходимо хранить на складе. Ограничение количества канбан для каждой детали позволило команде установить WIP-лимиты.
Программистам иногда трудно понять, как систему с использованием канбан-карточек можно применить к разработке программного обеспечения. Им не нравится сравнивать себя с персоналом сборочного конвейера – и это справедливо, потому что разработка скорее похожа на то, что делают автомобильные инженеры и конструкторы, а не рабочие. Но в Канбане не принято относиться к людям как к винтикам механизма. Канбан и конвейер объединяет лишь то, что они используют канбан-карточки на контейнерах с запчастями или стикеры на доске, чтобы сигнализировать: еще не все готово.
Иногда легче понять это при помощи примера, не имеющего ничего общего ни с конвейером, ни с программным обеспечением. Каждое лето на большой выставочной площадке в Сент-Поле проводится ярмарка, которую посещает более миллиона жителей штата. На территории выставочного комплекса располагается множество поставщиков продуктов питания. Один из самых популярных – стенд компании – производителя кукурузы гриль. Другие известные поставщики имеют длинные очереди у своих стендов – например, не менее двух десятков людей выстраиваются, чтобы купить жареные оливки на палочке. Но там, где посетителям предлагают кукурузу гриль, как правило, огромное количество людей обслуживается практически без очередей. Как они этого добились?
В отличие от поставщика жареных оливок, который имеет два одинаковых по назначению окна с длинными очередями, на стенде кукурузы гриль созданы два отдельных окна. В первом вы платите деньги и получаете чек, а во втором отдаете чек в обмен на початок кукурузы.
Поначалу участникам ярмарки это казалось излишеством: зачем отдавать деньги одному человеку, брать у него чек, а затем передавать его кому-то другому? Но теперь все вынуждены согласиться с необходимостью этого дополнительного этапа: чек – это канбан-карточка, и поставщик кукурузы гриль создает WIP-лимит и вытягивающую систему.
Люди, готовящие кукурузу во втором окне, знают, сколько чеков выбито, и будут отправлять в первое окно только нужное количество чеков, поэтому очередь ожидающих небольшая. Это позволяет регулировать количество готовящейся кукурузы. Поэтому в периоды замедления спроса они не держат кукурузу на гриле так долго, что она превращается в уголь, а в пиковые моменты увеличивают объемы, чтобы свести очередь к минимуму. Это также означает, что они могут нанять дополнительных людей для трудоемких действий и жарить кукурузу, не отвлекаясь на денежные расчеты. В тех редких случаях, когда количество людей, желающих купить кукурузу, превышает возможности людей внутри киоска, образуется очередь в первом окне. Те, кто готовит кукурузу, защищены от хаоса, связанного с покупателями, пытающимися всучить им деньги. Они могут полностью сконцентрироваться на процессе жарки, что позволяет очереди двигаться быстрее или не появляться вовсе.
Благодаря тому, что их работа течет плавно, процесс приготовления может стать ритмичным и позволяет сотрудникам чувствовать себя более комфортно и хорошо выполнять свою работу.
Регулирование WIP-лимита предоставляет поставщику кукурузы гриль свободу действий. Увеличение чеков приводит к росту количества жарящейся кукурузы в периоды с пиковой нагрузкой (например, после окончания больших шоу на ближайших трибунах). Они могут быстро и плавно нарастить производство, а затем так же плавно его уменьшить после спада спроса. Знают ли продавцы кукурузы, что они применяют закон Литтла? Ограничивая число прибывающих в систему людей, они могут уменьшить время обработки заказа, чтобы клиенты, заплатившие за кукурузу, не ожидали ее. (Вы можете представить, как выглядит кумулятивная диаграмма потока?)
Этот пример помогает проиллюстрировать разницу между выталкивающими и вытягивающими системами. Производители жареных оливок используют выталкивающую систему – длинную очередь. Люди «проталкивают» ее, потому что она привлекает покупателей и создает спрос. Поставщики оливок не имеют контроля над спросом, они могут продавать оливки только следующему человеку из очереди. Продавцы кукурузы гриль «втягивают» очередь, потому что выдают чеки заплатившему клиенту. Они используют их для притягивания людей к своему стенду и могут ограничить количество покупателей, если оно достигает лимита. Так они устанавливают WIP-лимит, позволяющий им уравновешивать производственные возможности и спрос. Регулирование WIP-лимита дает возможность мгновенно приспосабливаться к меняющейся ситуации.
У меня нет обилия деталей для сборки автомобиля или кукурузы, которую нужно обжарить на гриле. Я создаю программное обеспечение, поэтому постоянно решаю различные проблемы. Какое отношение ко мне имеют эти примеры?
Канбан имеет к вам самое прямое отношение, потому что это система, позволяющая мгновенно реагировать на изменения в проекте. Вводя лимит на выполнение незавершенных работ и контролируя размер очереди, вы уменьшаете вариабельность. Выделяя источники задержек и применяя такие методы, как кластеризация блокеров (или анализ коренных причин блокировок и усовершенствования, направленные на снижение вероятности и влияния блокеров), мы сокращаем вариабельность. Атака на ее источники, негативно влияющие на экономический результат системы, является одной из основных техник Канбана.
Командам разработчиков нужно этим заниматься – и много. Можно утверждать, что разработчики гораздо чаще имеют дело с изменчивостью, чем производители автомобилей или поставщики кукурузы. Программное обеспечение отличается от любого другого инжинирингового продукта тем, что оно изменчиво. Так как ПО не является физическим объектом, программисты имеют гораздо больше возможностей, чем другие инженеры, изменять его и на более поздних этапах проекта. Но каждое изменение несет риск. И если ваш проект бросало из стороны в сторону вследствие изменившихся требований, то появляются неравномерности (мура), потому что эти изменения могут стать очень разрушительными.
Так что же вы можете сделать, чтобы убедиться, что эти неравномерности не сорвут проект?
Большинство водопадных команд мыслят традиционно, считая, что работа выполняется через процесс управления изменениями. Изменения контролируются, замедляются, и, если возможно, их избегают. Изменения в плане должны быть предложены, рассмотрены командой, проанализированы с точки зрения их влияния на проект, а затем согласованы со всеми сторонами, прежде чем они будут реализованы. Это эффективный способ защиты проекта от изменчивости, уменьшающий его риски, – но при этом он гарантирует, что ваша команда создает именно запланированное изначально независимо от того, на самом ли деле это ценно для пользователей.
Мир традиционного управления проектами выглядит не таким мрачным, как это может показаться. В и мы видели, что команда имеет больше возможностей для разработки легко изменяемого программного обеспечения, если ей предоставить спокойную обстановку, в которой удается работать разумное количество часов, и такую эмоциональную атмосферу, чтобы было проще сосредоточиться на решении проблем. Хорошие руководители проектов признают это. Поэтому они будут добавлять временной запас в график работы, так же как в ХР-командах. А управление процессами изменений означает, что они не имеют ХР-возможности добавлять задачи с низким приоритетом, которые команда может сместить на более поздние итерации, потому что это потребует изменения плана, а значит, его рассмотрения и утверждения. Вместо этого они будут добавлять буферы, или дополнительные задачи, не имеющие реальной значимости, просто заполняющие график, часто используя формулы для определения того, сколько еще можно втиснуть таких «пустых» задач. Теперь они могут следовать первоначальному плану и дать команде достаточно времени для работы – и в то же время избавляются от дополнительной изменчивости, поэтому проект завершается вовремя.
Другими словами, когда команда испытывает трудности с традиционным проектным управлением, в ответ она обычно добавляет в график работ «пустые» задачи – независимо от того, что является причиной проблемы.
Канбан-команды не создают буферы и «пустые» задачи в графике, потому что это скрывает изменчивость от тех, кто старается создавать правильные решения. Ценности бережливого мышления в том, что они позволяют видеть картину целиком и препятствуют сокрытию информации. Кроме того, бережливое мышление говорит нам, что, когда есть потери, вызванные неравномерностью, мы должны найти причину проблемы и устранить ее. Вместо того чтобы скрывать потери за «пустыми» элементами, канбан-команды показывают их, визуализируя рабочий процесс, вводя WIP-лимиты и другие стратегии, чтобы их исправить. Они делают изменчивость и ее основные причины явными.
Что делать, если мой руководитель не согласен с введением лимитов на выполнение незавершенных работ?
Тогда вы будете иметь проблемы с внедрением Канбана. Когда вы читаете о том, как действует Канбан, кажется, что создание очередей и ограничение потока поможет существенно улучшить работу команды. Но все начинается с введения WIP-лимитов, которые нужны, чтобы ваше руководство согласилось не добавлять дополнительную работу, когда команда достигает WIP-лимита.
Это может стать ахиллесовой пятой при попытке совершенствования, особенно когда руководитель убежден, что мышление приравнивается к действию. Допустим, вы потратили несколько недель или даже месяцев, помогая команде разобраться с Канбаном, работая вместе над визуализацией рабочего процесса, создавая канбан-доску и проводя тщательные измерения для определения WIP-лимита. Теперь вы вместе с другими менеджерами с гордостью приносите свое предложение. Ваш руководитель понимает, что это заслуживает внимания. Он говорит: «Мне нравится канбан-доска, я думаю, что эти измерения замечательны, и полностью вас поддерживаю. Но мне нужно сделать всего одно небольшое изменение. Стереть этот номер в верхней части столбца на доске».
Ему кажется, что это абсолютно несущественно – стереть один маленький номер. Но WIP-лимит – это ноу-хау Канбана. Без него команда не имеет возможности ограничить поток и Канбан не работает.
На интуитивном уровне не всегда понятно, что сокращение работы всего на один шаг позволяет ускорить весь проект. И даже если вы визуализируете рабочий процесс, проводите измерения и выявляете потери, вызванные неравномерной работой, перегрузками и необоснованной или невозможной работой, это может оказаться недостаточно убедительным для руководителя. Когда это не так, он будет ориентироваться на WIP-лимит и видеть в нем компромисс. Может быть, он чувствует, что, удалив его, команда сможет оптимизировать свою работу и предотвратить неполную занятость. Или он считает, что WIP-лимит дает команде временной запас, и боится, что она будет злоупотреблять им, замедляя темпы работы и устраивая себе отпуск. Либо эта идея просто кажется ему неудачной. А возможно, он чересчур рационален и совершенно лишен магического мышления, поэтому считает так: поставка по готовности приведет к тому, что функция будет переходить из одного релиза в другой и пользователи, увидев это, одуреют и начнут настаивать на увольнении разработчиков и выгонять людей. Но независимо от того, что он думает, удаление WIP-лимита выбивает опору из-под всех действий в стиле Канбана.
Так что же делать, если вы не можете получить согласия руководителей на введение WIP-лимита?
Это отличная возможность, чтобы попробовать Scrum, в котором есть предсказуемые временные ограничения и заранее оговоренный объем, а также руководство со стороны специально выделенного для этого владельца продукта.
Причина, по которой Scrum эффективен, когда менеджеры сталкиваются с ограничениями, в том, что бэклог находится внутри проекта. Scrum-команды полагаются на владельца продукта, имеющего полномочия принимать решения, какие рабочие задачи следует добавлять в бэклог и включать в каждый спринт, и вводят его в состав команды. Теперь команда контролирует объем, а руководители и пользователи могут работать с владельцем продукта, чтобы вносить любые изменения, в том числе и в объем работы. Это дает гораздо больше гибкости, чем традиционный процесс управления изменениями, но все равно ограничивает изменчивость, которой подвержена компания. Команда даже использует доску для визуализации рабочего процесса – но это доска задач, а не канбан-доска, потому что содержит задачи, а не рабочие элементы и в ней нет WIP-лимитов или других явных стратегий.
В то же время Канбан имеет очереди и буфера – внешние объекты по отношению к проекту.
Соглашаясь с WIP-лимитом, клиенты (руководители, пользователи, владельцы продукта и т. д.) решают, что помещать в очередь. Они должны согласовывать WIP-лимиты и не защищаться от изменчивости, но взамен получают гораздо больше контроля над тем, какие функции создаются и в каком порядке. Используя производственные термины, мы называем это поставкой «точно в срок», потому что команда сама решает, какая задача выполняется следующей, основываясь на рабочих элементах, ожидающих на различных этапах рабочего процесса (стикеры в столбцах на канбан-доске), и эти решения могут приниматься очень поздно – даже за минуту до начала работы над рабочим элементом.
Если попытка освоить Канбан заканчивается внедрением Scrum – это очень хороший результат. Как только команда заработает последовательно внутри стабильной системы, вы поможете ей узнать, что такое процесс усовершенствования. Обнаружив, что команда получает результат «лучше-чем-ничего», считайте это шагом в правильном направлении. Теперь вы можете продолжать двигаться вперед. Использование Канбана улучшает работу команды, создающей программное обеспечение, и является прекрасным способом для прогресса.
Считается, что Канбан – это не система управления проектами, но, когда вы перемещаете рабочие элементы по канбан-доске, это похоже на управление. Вы уверены, что это не система управления проектами?
Да, это вовсе не система управления проектами и не методология создания программного обеспечения. Канбан – это метод улучшения процесса.
Прежде чем вы сможете улучшить процесс, вы должны понимать это. Канбан-доска – прекрасный инструмент, помогающий создавать ПО, потому что это очень эффективный способ визуализации рабочего процесса.
Это также очень эффективный способ исправлять серьезные ошибки, которые часто встречаются в процессе улучшения: команда не всегда начинает работу, действительно хорошо понимая, как сегодня нужно разрабатывать программное обеспечение. Процесс усовершенствования начинается с того, что группа менеджеров и руководитель проекта собираются вместе и создают схемы или описания текущего процесса. Обычно они понимают, что для процесса усовершенствования необходима точка отсчета, поэтому занимаются рассылкой опросов, интервьюируют команды разработчиков и ищут другие способы, чтобы собрать информацию. Затем они объединяют все полученные сведения в документированный процесс и используют его в качестве отправной точки для совершенствования.
Проблема в том, что сбор такой информации – очень сложное дело. Он редко дает реальное представление о том, как на самом деле команды собирают создавать ПО. Представьте, что вы член команды, которого комитет старших руководителей спросил, как работает ваш проект. Вы будете указывать на неудачи? Или постараетесь нарисовать радужную картину? Даже если вы стремитесь быть максимально правдивым, вам не избежать обычной слабости, свойственной любому человеку: хорошо помнить успехи и забывать о проблемах.
Вот где лучше всего работает Канбан. Вначале команда визуализирует рабочий процесс на канбан-доске. Но не останавливается на достигнутом – по мере развития проекта она обновляет рабочие элементы на доске. Все члены команды понимают, что делают это не для управления проектом, а чтобы создать точную картину системы, которую используют для производства программного обеспечения. Это действительно реальная картина, потому что команда постоянно обновляет ее. И это очень полезно: когда программисты хотят выяснить, над какой пользовательской историей или функцией работать дальше, они четко видят, как работа протекает через систему. Но канбан-доску не используют для того, чтобы выяснить, какие задания следует выполнять. На ней присутствует информация об уровне рабочих элементов, но не задач. Если система включает доску задач, диаграмму Ганта или какой-то другой способ управления проектом, то они по-прежнему будут его применять.
Из-за того, что Канбан имеет такой эффективный способ визуализации рабочего процесса (канбан-доска) и измерения потока через систему (при помощи CFD), команда способна достичь наиболее эффективного улучшения. Но это не единственная причина, по которой команды, использующие Канбан, добиваются успеха в процессе совершенствования. Канбан позволяет получить отличные результаты, когда команда внедряет бережливое мышление. Как мы видели в примере со Scrum и XP, самый эффективный способ помочь команде принять бережливое мышление – использовать канбан-практики. Как только команда начинает визуализировать рабочий процесс и измерять поток, она понимает, где происходят потери в системе, и использует варианты мышления, чтобы создавать для себя новые возможности и учиться видеть работу системы в целом.
Что вы можете сделать сегодня
Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с вашей командой).
• Если бы вам предложили создать канбан-доску сегодня, то какие столбцы вы бы в нее включили? Если вы еще не создавали карты потока ценности, то сейчас подходящий случай сделать это – они помогут выяснить, как может выглядеть канбан-доска.
• Можно ли рассматривать один из этих столбцов в качестве удачного кандидата для WIP-лимита? Создайте стикеры с рабочими элементами только для этого столбца. Сколько из них задействовано прямо сейчас? Что было бы, если бы вы ввели WIP-лимит?
• Выясните, к кому вы можете обратиться, чтобы ввести WIP-лимит.
• Создайте простую канбан-доску и еженедельно отслеживайте проект. Постройте CFD на основе ваших данных. Стабилен ли ваш список незавершенных дел? А как насчет скорости поступления?
Где вы можете узнать больше
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
• Вы можете узнать больше о канбан-методе в книге Дэвида Андерсона (М.: Манн, Иванов и Фербер, 2017).
• Узнайте больше о системах мышления в книге Мэри и Тома Поппендик Lean Software Development: An Agile Toolkit (Addison-Wesley 2003).
Подсказки
Здесь мы предлагаем советы для agile-коучей, помогающих своей команде разрабатывать идеи этой главы.
• Канбан начинается с бережливого мышления, поэтому первым делом помогите вашей команде освоить это понятие. Вам помогут подсказки для коучей в .
• Самый большой барьер для команд, стремящихся использовать Канбан как средство усовершенствования их процесса, – понимание того, что этот метод – не система управления проектами. В качестве коуча вы подскажете, что это означает для некоторых систем управления проектами и как Канбан помогает командам лучше понять собственную систему, а не управлять проектами.
• Помогите команде научиться видеть преждевременность некоторых ее поступков, что становятся причиной потерь в проекте. Научите людей определять параметры и принимать решения в последний ответственный момент. Некоторые нервные менеджеры или менеджеры с магическим мышлением часто требуют, чтобы команды определились со сроками. Помогите команде научиться выполнять только те обязательства, которые необходимы для проекта.
• Канбан также нуждается в командной работе, чтобы принять системное мышление. Это важная часть Lean и одна из основных идей, которая делает Канбан работающим методом. Помощь команде в визуализации рабочего процесса при помощи канбан-доски – это зачастую удачный первый шаг на пути психологического освобождения людей от роли винтиков в механизме, выполняющем работу.
Назад: Измерение и управление потоком
Дальше: Глава 10. Agile-коуч
