К основному контенту

Что следует и чего не следует делать Канбан-коучу

Автор: Дэйвид Андерсон (David Anderson)
Перевод с английского.


Взято с www.software-kanban.de
Я осознаю, что большинство Agile-коучей и консультантов довольно часто неправильно понимают, что же это значит – быть Канбан-коучем. Следовательно, они склонны считать, что Канбан – это всего лишь еще одна методика, которую они могут легко внедрить, применяя свои привычные тренерские техники, проверенные на опыте внедрения Agile. Но это предположение является в корне ошибочным! В результате него, некоторые Agile-коучи хотят предлагать Канбан, как один из многих инструментов, наряду с их остальными тренерскими услугами. Тем самым они недооценивают важность посещения специализированных мастер-классов по Канбану для тренеров, менеджеров и консультантов.

Особенно интересным является тот факт, что я не замечаю подобного у консультантов по другим областям, таким как CMMI, Six Sigma (6 сигм), Lean (бережливое производство), Теория ограничений, управление рисками и т.д. Они не приходят с предвзятым убеждением, что «Канбан – это не более чем еще одна Agile-методика, поэтому мне нужно только освоить ее основные механизмы и принципы, а затем внедрить, как тот же Скрам или TDD». И это радует, так как на самом деле вы не сможете (по крайней мере, не должны) внедрять Канбан, так же, как Скрам или TDD.

Так что же делают Канбан-коучи и чего, что еще более важно, они не делают?


Прекратите отстаивать! Прекратите пропагандировать! Вместо этого наблюдайте 

Наверное, самая большая трудность в обучении Agile-коуча Канбан-консалтингу – это заставить его прекратить отстаивать и пропагандировать Agile методы и практики. Agile, в своем худшем смысле слова – это религия, т.е. система верований со своими преданными фанатиками, которые слепо верят, что Agile все равно лучше, и не поддаются никакому логическому убеждению. Хуже того, они могут свято верить, что были посланы с небес, чтобы обратить «язычников» на пусть «истинной веры». Такие радикально настроенные Agile-коучи могут никогда не сдвинуться в сторону обучения Канбану. Они просто не в состоянии отложить в сторону весь свой накопленный опыт, чтобы принять более нейтральную позицию, наблюдая за текущим процессом и его текущими трудностями, и предлагая соответствующий курс действий.

Канбан-коучи не отстаивают и пропагандируют Agile, они наблюдают и советуют.

Канбан не осуждает сложившуюся ситуацию 

Канбан-коуч никогда не должен выражать осуждение. Текущее положение дел таково, как оно есть, и стало оно таким из-за текущей команды, их обстоятельств и требований клиента, так что жалеть по этому поводу абсолютно бесполезно. Критиковать людей за то, что их текущие практики не соответствуют модному и современному подходу или же «системе верований» – занятие крайне неуважительное.

Канбан-консультанты всегда уважают сложившуюся ситуацию, и воздерживаются от оценочных суждений в ее адрес. 

Подходит ли нам Канбан? 

Хорошие Канбан-консультанты всегда делают ситуативную оценку, чтобы выяснить, подходит ли проекту Канбан или нет. На наших тренингах мы обычно тратим полдня, вникая в подробности данной темы. Я часто выступаю с докладами, давая советы по поводу применимости Канбана. В итоге, основными преимуществами, которые нам дает система канбан, являются отложенные обязательства, контроль над непостоянством потока, устранение перегруженности команды, уменьшение многозадачности, и лучшая совместимость с управлением высокоуровневыми рисками, в результате которого принимаются решения по распределению ресурсов между задачами сопоставимой степени важности. Если что-либо из вышеперечисленного является слабым местом в текущем процессе, как например, слишком раннее взятие на себя обязательств и последующее их невыполнение, то система канбан здесь может быть очень даже полезной.

Полная методика Канбана использует виртуальные канбан-системы и некоторые другие практики для создания возможностей постепенного развития внутри организации, и в целом содействует постепенным (эволюционным) изменениям. Это очень полезно в сложных предметных областях, которые почти всегда присутствуют в умственной работе.

Хороший канбан-коуч всегда оценивает уместность применения данной методики, прежде чем ее рекомендовать. Вы не должны «продавать» эволюционный подход, революционно настроенному клиенту. Ситуативная осведомленность является неотъемлемым навыком канбан-коуча.

Канбан должен быть подобен воде

Вода может омывать камни. Такими камнями является эмоциональное сопротивление изменениям, которые могут привести к лучшим экономическим и социальным последствиям для всех заинтересованных лиц, и в результате принести всеобщее удовлетворение сторон. Канбан-коучи должны учиться предвидеть это эмоциональное сопротивление, что называется, идентифицировать все «камни» перед внедрением системы канбан в рабочий процесс.

Канбан-коучи должны избегать рисков на самой начальной стадии. Там, где не удается избежать камней, они создают такую канбан-систему, которая повышает осведомленность о них, и создают эмоциональную мотивацию к изменениям. Вода со временем точит камни. Хорошие канбан-коучи знают, что хватит и одного коуча, чтобы «сменить лампочку», главное, чтобы сама «лампочка» имела желание меняться. Создание условий для мотивированных изнутри изменений – это и есть работа по-настоящему хорошего Канбан-коуча.

Построение канбан-систем – это продвинутый навык

Хорошие Канбан-коучи знают, что нет смысла силой навязывать изменения, встречаемые с отпором. Они должны избегать построения канбан-системы, которая бы сразу же решила все проблемы существующего процесса, выявленные при начальном наблюдении. Возможно, введение ограничений на выполняемую в текущий момент работу (WIP – work in progress), в качестве решения проблемы перегруженности команды, вызвало бы сопротивление с их стороны? Это сопротивление можно предвидеть заранее, если понимать с эмоциональной точки зрения, как это может отразиться на всех участниках команды, их личном образе, самооценке, эго, социальном статусе и других аспектах.

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



Переведено с английского проектом Agile Translations.
Оригинальная статья "WHAT KANBAN COACHES DO, AND DON’T DO" опубликована на сайте http://agilemanagement.net.

ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence Переведено с английского проектом Agile Translations   Хорошие Пользовательские Истории следуют INVEST модели , предложенной Биллом Вейком (Bill Wake). Они независимые ( I ndependent), обсуждаемые ( N egotiable), ценные ( V aluable), поддающиеся оценке ( E stimable), небольшие ( S mall) и тестируемые ( T estable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели. Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко . Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности. Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь ): « Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы

Ретроспектива спринта - эффективный формат

Автор: Майк Кон (Mike Cohn) Перевод с английского Неважно, насколько опытной является Скрам-команда, при этом всегда существует возможность для ее улучшения. Не смотря на то, что хорошая Скрам-команда будет постоянно искать возможности для своего улучшения, она должна выделять короткий период времени в конце каждого спринта для сознательного размышления над тем, как идут их дела, и для поиска способов их улучшения. Все это происходит во время Ретроспективы спринта.

Аджайл Менеджер Проектов – кто это?

Автор: Карлтон Неттлетон (Carlton Nettleton) Переведено с английского проектом Agile Translations . Несколько недель назад я получил сообщение от своего бывшего ученика с печальными новостями – его компания уволила всех Скрам-мастеров и заменила их на “Аджайл Менеджеров Проектов”. Теперь он остался без работы, а Cкрам потерпел серьезную неудачу в их организации. Это было довольно грустно :(

Какие проекты лучше всего подходят для применения Agile

Автор: Майк Кон (Mike Cohn) Переведено с английского проектом Agile Translations . Недавно меня спросили, для какого вида проектов больше всего подходит применение гибкого подхода разработки, и сейчас я хотел бы об этом поговорить. Мне кажется, самыми подходящими для использования гибких методик являются проекты с агрессивными сроками выполнения, высокой степенью сложности и так же высоким уровнем инновации (уникальности). Мы хотим использовать Agile, когда делаем что-то новое, по крайней мере, новое для конкретной команды разработки. Если команда делает то, что она уже делала не один раз, она, вероятно, не нуждается в гибком подходе. На мой взгляд, здесь было бы уместным привести аналогию с промышленным производством. День за днем, собирая один и тот же тип автомобиля, мы довольно быстро учимся всем нюансам сборки этой модели. Здесь нам не нужны гибкие подходы, потому что степень новшества данного процесса является довольно низкой. Однако, инновация сама по себе не означает, что