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

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

Автор: Дэйвид Андерсон (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-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая” , однако, не сможет похвастаться тем же в случае с “независимая” и “ценная” . За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Все о Скрам от Майка Кона

На сегодняшний день многие уже знают основы Scrum. Однако я часто сталкиваюсь с разночтениями, и даже спорами по некоторым моментам. Поэтому считаю, что нужно обратиться к истокам. Как, наверняка, многие знают Майк Кон – один из наиболее популярных Scrum-тренеров, он работает с этой методологией более 10 лет, написал 2 концептуальные книги по практикам Agile, а также множество интересных и ценных статей, является одним из основателей Scrum-альянса и Agile-альянса. По праву его можно считать тем специалистом, определениям которого можно доверять. Читать дальше...

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

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

Планирование релиза: уходим от термина, но не от практики

Автор: Майк Кон (Mike Cohn) Перевод с английского. Я хочу обратить внимание на термин, используемый в Скраме (точнее, даже Аджайл термин), который во многом пережил себя: планирование релиза. Общепринятое использование "релизного планирование" заключалось в том(я так тоже делал), что мы смотрели в будущее на несколько спринтов вперед и пытались предсказать, что бы мы могли выпустить. Было бы хорошо в идеале эти предположения выражать в виде диапазона значений, возможно даже с использованием интервалов вероятности. В течение многих лет я учил команды делать именно так. Скажем, мы могли сказать, что “Мы уверены на 90%, что через шесть месяцев сможем выпустить продукт с функционалом в диапазоне между 150 и 200 стори поинтов.” Я до сих пор считаю эту практику полезной и каждый Скрам-мастер должен знать как это делается. Что на самом деле потеряло смысл, так это сам термин “планирование релизов”.

Диаграммы Ганта и Agile проекты. Так уж они несовместимы?

Автор: Алексей Кривицкий. "Планы бесполезны, планирование необходимо". Ейзенхауэр Диаграммы Ганта – это традиционный механизм визуального планирования, который получил свою популярность благодаря артефакту традиционных проектов, который назывался Work Breakdown Structure (WBS), и продуктам Microsoft Project и Microsoft Project Server, которые позволяли конструировать и хранить WBS. Пропоненты Agile принципов много внимания уделяют визуализации и открытости планирования. Так почему же так часто в контексте Agile мы слышим критику в адрес диаграмм Ганта? Давайте разберёмся. Пару слов о терминологии. В данной статье " традиционными подходами " к управлению проектами (или просто традиционными проектами) называются те подходы или проекты, которые противопоставляются Agile проектам. Я не использовал термин «водопадных проектов», так как во-первых на практике настоящих водопадных проектов не так много, а во-вторых по мимо водопадных и Agile проектов есть ещё мн