Канбан. Альтернативный путь в Agile - читать онлайн книгу. Автор: Дэвид Андерсон cтр.№ 19

читать книги онлайн бесплатно
 
 

Онлайн книга - Канбан. Альтернативный путь в Agile | Автор книги - Дэвид Андерсон

Cтраница 19
читать онлайн книги бесплатно

Культурные изменения, опосредованно связанные с тем, что мы сейчас называем Канбаном (с большой буквы), оказались совершенно неожиданными и во многих отношениях противоречили здравому смыслу. Он спросил: «Почему же тогда мы не используем это во всех крупных проектах?» И мы решили внедрить в портфель крупных проектов Канбан, мотивируя это тем, что он создал культуру кайдзен. Эти культурные изменения оказались настолько желательными, что издержки на трансформацию механизмов расстановки приоритетов, планирования, форм отчетности и выполнения, которых требовало внедрение Канбана, не выглядели чрезмерными.

Выводы

Кайдзен переводится как «непрерывное совершенствование».

• В культуре кайдзен люди чувствуют свои полномочия, действуют без страха, произвольно объединяются в группы, сотрудничают и вводят инновации.

• Для культуры кайдзен характерен высокий уровень социального капитала и доверия между людьми независимо от их места в корпоративной иерархии.

• Канбан обеспечивает прозрачность как самой работы, так и рабочего процесса.

• Прозрачность рабочего процесса позволяет всем заинтересованным лицам видеть результаты своей деятельности или бездействия.

• Люди с большей готовностью инвестируют свое время и выражают готовность к сотрудничеству, если они видят результаты своей деятельности.

• Ограничения на число незавершенных задач в Канбане стимулируют принятие ответственности на себя.

• Ограничения на число незавершенных задач в Канбане стимулируют произвольное образование групп для решения проблем.

• Повышение степени сотрудничества в результате формирования групп для решения проблем и взаимодействия с внешними заинтересованными лицами выводит на новый уровень социальный капитал внутри команды и доверие членов команды друг к другу.

• Ограничения на число незавершенных задач в Канбане и введение классов обслуживания позволяют сотрудникам брать работу и принимать решения по расстановке приоритетов и планированию без надзора или руководства вышестоящих лиц.

• Повышенный уровень полномочий увеличивает социальный капитал и доверие между сотрудниками и менеджерами.

• Коллективистское поведение распространяется вирусным образом.

• Сотрудники могут следовать примеру старших руководителей. Их коллегиальное поведение влияет на поведение всех работников организации.

Часть III
Внедрение канбана
Глава 6
Визуализация цепочки создания ценности

Канбан – это подход, который благоприятствует изменениям, оптимизируя ваши процессы. Главное в начале использования Канбана – внесение минимальных изменений в рабочий процесс. Нужно противостоять искушению полностью перестроить рабочий поток, пересмотреть штатное расписание, роли, ответственность и конкретные рабочие методы. Все, что влияет на самооценку, профессиональную гордость и эго членов команды, сотрудников компании и заинтересованных лиц, должно остаться неизменным. Изменения должны быть направлены на количество незавершенных задач и точки взаимодействия с соседями выше и ниже по цепочке создания ценности. Поэтому вам нужно вместе с командой создать схему существующей цепочки создания ценности. Старайтесь ничего не менять и не изобретать в поисках улучшений.

В некоторых ситуациях официальная процедура не выполняется. При попытке составить схему цепочки создания ценности команда будет настаивать на фиксировании официальной процедуры, а не той, что используется фактически. Вы должны противостоять этому, чтобы описать реальную схему работающего процесса. Без этого невозможно использовать стену карточек как средство визуализации процесса, поскольку члены команды могут полагаться на нее, только если она отражает действительность.

Определение стартовой и финишной контрольных точек

Необходимо определиться со стартовой и финишной точками визуализации процесса, а также с точками взаимодействия с вышестоящими и нижестоящими соседями по цепочке создания ценности. Важно ответственно отнестись к этой начальной стадии внедрения Канбана, поскольку неверный выбор может привести вас к провалу. Успешные команды обычно начинают с перехода на визуализацию при помощи карточек и ограничения числа незавершенных задач в пределах своей сферы контроля и переговоров по поводу новых способов взаимодействия с непосредственными партнерами по цепочке создания ценности. Например, если вы контролируете отдел проектирования или разработки и обладаете контролем (влиянием) над анализом, дизайном, тестированием и написанием кода, то составьте схему этой цепочки создания ценности и начните переговоры по поводу нового стиля взаимодействия с вышестоящими деловыми партнерами, от которых зависят требования, расстановка приоритетов и управление портфелем, а также нижестоящими, занимающимися системными операциями и поддержкой продукта. Очертив тем самым границы, вы предлагаете перейти на ограничение числа незавершенных задач только своей команде. Другие не обязаны менять методы работы, ограничивать число незавершенных задач и внедрять вытягивающую систему. Однако вы просите их по-иному взаимодействовать с вами, чтобы это было совместимо с вытягивающей системой, которую вы внедряете у себя.

Типы работ

Выбрав стартовую точку для рабочего процесса или цепочки создания ценности, определите, какие типы работы относятся к этой точке, а какие существуют в рабочем процессе и должны подвергнуться ограничениям. Например, исправление ошибок, скорее всего, относится к типам работ, существующим в рабочем процессе. Возможно, вы выявите и иные типы деятельности, связанные с разработкой: рефакторинг, поддержку систем, обновление инфраструктуры и другие переделки. Для входящей работы это такие типы, как пользовательские истории, прецеденты, функциональные требования или функции. В некоторых случаях входящие типы работы могут быть иерархическими – например, эпики [6] (собрания пользовательских историй).

Вот основные типы работы в командах, использующих Канбан (это неполный список):

• требование;

• функция;

• пользовательская история;

• пользовательский сценарий;

• запрос изменений;

• дефект продукта;

• поддержка;

• рефакторинг из-за ошибки;

• предложение улучшения;

• блокирующая проблема.


Полезно именовать типы работы по источнику, например: регуляторное требование, запрос продаж на местах, требование стратегического планирования и т. д. Если по оглавлению задачи сразу понятен источник, это создает дополнительный контекст и позволяет системе развиваться в сторону обслуживания нескольких клиентов сразу.

Вернуться к просмотру книги Перейти к Оглавлению Перейти к Примечанию