Канбан дэвид андерсон краткое содержание

Обновлено: 07.07.2024

Также данная книга доступна ещё в библиотеке. Запишись сразу в несколько библиотек и получай книги намного быстрее.

Те, кто искали эту книгу – читают

Объем: 350 стр. 58 иллюстраций
Жанр:з арубежная деловая литература, о рганизационный менеджмент, п роизводственный менеджмент, с тратегический менеджмент, т айм-менеджмент, у правление бизнесом, у правление качеством, у правление персоналом, я понский менеджмент
Теги:A gile, п роизводительность труда, р ешение задач, у правление поставками, у правление предприятием, э ффективное руководствоРедактировать

Эта и ещё 2 книги за 299 ₽

По абонементу вы каждый месяц можете взять из каталога одну книгу до 600 ₽ и две книги из персональной подборки.Узнать больше

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

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

На русском языке публикуется впервые.

Возрастное ограничение: 16+
Дата выхода на ЛитРес: 02 марта 2017
Дата перевода: 2017
Дата написания: 2010
Объем: 350 стр. 58 иллюстраций

ISBN: 9785001005308
Переводчик:
Правообладатель: Манн, Иванов и Фербер (МИФ)

чего вы добились вчера? Что вы будете делать сегодня? Что вам мешает, нужна ли помощь?

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

Чтобы подарить книгу, измените количество списываемых фишек. Стоимость книги не может быть меньше 1 .

О книге

Подробное руководство по канбану от человека с опытом, впервые применившего этот метод в разработке ПО.

Дэвид Андерсон, внедрявший метод канбана в нескольких компаниях и постоянно его улучшавший, рассказывает, как эффективно вводить идеи бережливого производства в технологические разработки и IT-операции — с минимальным сопротивлением изменениям и при этом сохраняя оптимальный для всех вовлеченных в работу сотрудников темп.

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

Простое ограничение незаконченных заданий посредством канбана приводит к повышению качества работы и ее производительности. Сочетание оптимизации потока работы и повышенного качества помогает сократить время выполнения и повышает предсказуемость и вероятность выполнения работы в срок. Установив регулярные каденции релиза и постоянное следование расписанию, канбан помогает создать доверительные отношения с клиентами и другими участниками потока создания ценностей — другими отделами, поставщиками и зависящими от вас партнерами.

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

Эта книга отвечает на вопросы:

· Что такое канбан?

· Зачем он нужен вашей компании?

· Как его внедрить?

· Как распознать возможности для улучшений в бизнесе — и что с ними делать?

Наша команда знакома с гибкими методологиями разработки, двухнедельные спринты — наше все. Недавно руководство решило распространить наш опыт на другие подразделения и попросило нас помочь в этом деле. Трезво оценив обстановку, мы поспешно отказались от этого предложения, но обещали подкинуть литературы, чтобы коллегам было с чего начать.

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

Как растет спрос на гибкие методологии

В 2019 году мы зафиксировали скачкообразный рост. Похоже, 2020-й не станет исключением. Пунктиром — наш прогноз до конца года.

А тут разбивка по месяцам. Особенно впечатляет пик в апреле, во время самоизоляции:

Ну а в июне уже чувствуется сезонный спад активности.

По Scrum — похожая ситуация, где по годам наблюдается даже более быстрый рост:

Хотя по месяцам цифры достаточно ровные:

А вот с Kanban все скромнее: пять мероприятий в 2019 году и три — за первые пять месяцев 2020 года.

Мы взяли яндексовский WordStat и посмотрели динамику числа запросов по соответствующим ключевым словам за последние полгода:

Период ограничен, и здесь виден только небольшой всплеск интереса в апреле.
Где еще можно посмотреть на тренды? Например, в Российской государственной библиотеке. Ну и заодно выяснить, что хорошего можно почитать по этой теме.

Итак, возьмем статистику по количеству книг с упоминанием наших терминов по году издания. Получается вот такая картина:

В поисках правильных критериев оценки

Самый очевидный способ — собрать список топовых книг по Agile и посмотреть, что советуют гуру этого направления. Это будет субъективная подборка, и доверие к ней сравнимо с доверием к самим гуру. Но для формирования шорт-листа и последующего статистического анализа — самое то.

Вот так выглядит один из субъективных рейтингов, который нам встретился:
Лучшие книги по Agile, Scrum и Kanban, по версии одного из экспертов

В итоге после объединения различных списков из разных источников удалось собрать шорт-лист из 22 книг. Как понять, какие из них наиболее полезные?

Если свести все данные в единую тепловую карту, получится вот такая картина.

Рейтинг книг на основании оценок пользователей специализированных сайтов

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

Продолжаем искать более объективные метрики.

Вариант 2: посмотреть на популярность книг по числу запросов в Яндексе и количеству страниц, на которых эти книги упоминаются.

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

Рейтинг книг на основании количества упоминаний

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

Вариант 3: создать сводный рейтинг на основании нескольких метрик обоих типов. Выбор этих метрик — наше субъективное решение, здесь вы можете критиковать и предлагать свой набор.

Итак, мы выбрали для себя пять метрик, по каждой из них отсортировали книги. Затем 10 лучшим в каждом чарте присвоили по 1 баллу. Если значение метрики одинаковое у 10-й и 11-й книг, даем баллы обеим. Суммируем баллы и сортируем по их возрастанию.

Метрики, на которых остановились мы: рейтинг Livelib как самый полный, упоминания на сайте HSE, количество запросов в апреле, количество страниц с книгой в Яндексе и… Вот здесь мы решили использовать еще один интересный параметр — количество пользователей, прочитавших книгу на Bookmate, так как он показался более наглядным, чем количество положительных оценок.

Вот что получилось:

Кратко расскажем о каждой из них.

1. Джефф Сазерленд. Scrum. революционный метод управления проектами

Книга основателя Scrum пользуется высокой популярностью с 1995 года. Она пережила множество изданий и доступна в нескольких переводах. На 280 страницах хватает воды, но есть и четкое описание придуманной автором методологии. Правильнее будет именно с нее начинать свое знакомство со Scrum.

Книга объяснит, как правильно управлять проектами быстрее и эффективнее, затрачивая при этом меньше ресурсов.

3. Майк Кон. Agile: Оценка и планирование проектов

Майк Кон, эксперт в области Agile, в этой книге не стал впадать в долгие рассуждения, но вывалил большую гору фактов, примеров, графиков и советов, которые помогут читателю разобраться с Agile.

Упор в книге делается на две составляющие успеха любого проекта — планирование и оценку. Книга немаленькая — более 500 страниц, но потраченное время стоит полученных знаний. Между прочим, именно эта книга чаще всего упоминается на сайте ВШЭ.

4. Дженнифер Грин, Эндрю Стиллмен. Постигая Agile

Этот объемный труд (450 страниц) включает в себя описание всех основных agile-методологий: Scrum, Kanban, Lean и XP (eXtremal Programming). Книга легко читается, методологии даются несколько поверхностно, в обзорном режиме.

Для знакомства — самое то. Постоянные повторения одного и того же призваны занести в память читателей самые важные моменты.

5. Хенрик Книберг. Scrum и XP: заметки с передовой

Эту книгу непросто найти в русскоязычном переводе, но это одно из лучших практических пособий по Scrum в области разработки ПО. Практические советы, наглядные примеры — все, как мы любим.

Книга небольшая, в сети можно найти перевод, сделанный энтузиастами из Agile Ukraine.

6. Борис Вольфсон. Гибкое управление проектами и продуктами

Основное отличие этой книги от других — акцент на создание продуктов, взгляд на Agile глазами продакт-менеджера на всем жизненном пути продукта. Здесь вы найдете и бизнес-моделирование, и аналитику требований, и методы управления командой, и даже управление рисками.

В книге рассказывается о трех методиках: Scrum, Kanban и XP и их правильном использовании. Воды почти нет, и в целом книга более похожа на студенческий конспект.

7. Майк Кон. Scrum: гибкая разработка ПО

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

8. Дэвид Андерсон. Канбан. Альтернативный путь в Agile

Стоит обратить внимание, что здесь Kanban рассматривается в разрезе разработки ПО, что делает книгу полезной именно для ИТ-продуктологов, разработчиков и руководителей проектов.

Согласны ли вы с нашим топ-8? Какие книги еще маст-хэв для тех, кто изучает Agile? Если вам есть чем поделиться или покритиковать, пишите в комментариях — этим вы поможете другим в поиске знаний и добавите себе кармы.

Kanban может быть запущен как для одной команды, организуя его работу, с постепенным расширением области применения на смежные команды, так и для компании в целом, соорганизуя и оркеструя работы многих команд. Его естественным развитием является Lean, ориентированный на оптимизацию цепочек создания ценности. Отмечу, что речь тут идет об IT-вариантах Kanban и Lean, а не об их производственных вариантах, разработанных в Toyota. Kanban, насколько я представляю его историю, является оригинальной конструкцией, собранной на основе разных источников. Хотя он и получил свое название от использования Kanban-доски, которая является первым шагом метода и применяется для визуализации потока работ.

Во-вторых, по содержанию: если посмотреть на набор практик, описанный в книге Андерсона, то в целом он хорошо соответствует набору практик Scrum, а также принципам Agile. Что не удивительно, потому что они в целом отражают эффективные методы для IT-разработки. А, в третьих, на уровне культуры: хотя Kanban стартует от существующего процесса и не предъявляет требования какой-либо особой Agile-культуры, прозрачность потока создания ценности, ориентация на его улучшения и сотрудничество со смежниками неизбежно ведет к изменению культуры как раз в том направлении, в котором это сформулировано в Agile-манифесте.

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

В книге Андерсона два уровня: первый показывает набор практик, а второй – эволюционную логику их появления.

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

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

Основная идея Kanban – представить компанию в сервисной структуре

Представление через сервисы означает, что у отдела появляется SLA, Service Layer Agreement, описывающий условия для обслуживания им внешних и внутренних клиентов, и такие же SLA появляются у его поставщиков и смежных отделов, которых он привлекает для выполнения своих обязательств. Такой характер взаимоотношений принципиально отличается от привычной работы по обработке задач.

Самое существенное изменение касается отношения к простоям. Задача сервиса не в том, чтобы все сотрудники были максимально загружены, задача в том, чтобы все внешние запросы обрабатывались в соответствии с соглашением. Типичный пример, который, я думаю, всем будет понятен – кассы в супермаркете. Нет задачи, чтобы кассир все время выбивал чеки, есть задача, чтобы очередь была маленькой: увидев хвост, покупатели просто пойдут в соседний магазин. Для оказания сервиса требуемого уровня в условиях неоднородного потока запросов нужны избыточные мощности. А когда покупателей мало, кассира можно занять чем-нибудь полезным, но при этом основная его задача – сервис на кассе.

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

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

Основными характеристиками сервиса является мощность потока задач, которые он обрабатывает и скорость прохождения отдельных задач через сервис. Как учит теория ограничений Голдратта, для высокой скорости прохождения задач необходимо ограничить количество незавершенной работы. Для этого в Kanban есть механизм WIP-лимитов, которые ограничивают незавершенную работу. При этом используется разные виды лимитов: на человека, на задачу в целом, на классы обслуживания, на этапы работ. Отметим, что в случае обычного производства ограничением является какие-то конкретные этапы обработки. А в IT из-за высокой неопределенности, связанной с исполнением задачи и длинного хвоста распределения вероятности выполнения, мы, как правило, не можем уверенно выделить этапы, являющиеся ограничениями. Поэтому WIP-лимиты устанавливаются для всех этапов.

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

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

Отдельно стоит сказать про буферную зону входных задач. Для начала можно его не ограничивать, наблюдая за пополнением. И начать регулярно проводить процедуру оценки актуальности задач в буфере: очень часто срочные задачи перестают быть срочными, а не выполненные становятся не актуальными, и нет никакого смысла сохранять их в буфере. И уже после этого вводить ограничения.

Отдельно стоит сказать про запуск в работу задач, имеющих фиксированную дату завершения, например, связанных с подготовкой к каким-либо праздникам или датам изменениям нормативных документов. Эмпирическое правило, о котором говорит Андерсон в своей книге, состоит в том, что их следует запускать в работу как можно позже, однако с учетом разумной оценки времени выполнения и определенного резерва времени. Потому что опыт говорит, что чем ближе к дате – тем выше определенность, касающаяся содержания задачи, включая работу смежников. Впрочем, на практике применить это правило довольно сложно, что знают все, кто готовился к экзаменам. Подготовка заранее не имеет особого смысла – ты забудешь выученное. Но вот оценить адекватно время подготовки сложно, в результате последняя ночь перед экзаменом часто проходит вовсе не так, как хотелось бы. Зато это будет одна ночь, а не нервная неделя – время аврала сокращается ☺

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

Работа с метриками - это не поиск виноватых, а решение проблем и взаимопомощь в команде

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

Во-первых, реальное понимание способов работы встречается редко. Распространены примитивные рецепты, которые хорошо показывает анекдот про консультанта:

– Как сделать, чтобы моя ферма давала больше молока, а расходы на корма уменьшились?
– Очень просто, коров надо чаще доить и реже кормить!

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

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

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

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

Отметим, что часть из перечисленных выше проблем представляют собой примеры тех или иных потерь (waste в Lean) в рабочем процессе, то есть работ, не несущих ценности: согласовать без необходимости, сделать оказавшееся ненужным, переделывать ранее сделанное и так далее. В IT-разработке и в любой другой интеллектуальной работе потери тоже присутствуют, как и в физическом производстве, просто они носят другой характер, поэтому производственный lean напрямую не применим. А задача метрик – наблюдать за ходом процесса и потерями, и служить сигналом, что какие-то из них превысили допустимый объем и требуют устранения.

Отмечу, кстати, что встречаются очень простые потери, связанные с незнанием приемов эффективной работы с текстами на компьютере. Наверное, все вспомнили про 10-пальцевую слепую печать. Это верно, но лишь отчасти: слепая печать очень актуальна, когда человек перепечатывает готовый текст, а это встречается относительно редко. В остальных случаях достаточно успевать вводить лишь со скоростью своей мысли. А вот владение hotkey, особенно при работе с буфером обмена для быстрого переноса текстов, чтобы не надо было переключаться на мышь – гораздо важнее. Почему-то на это не обращают должного внимания. А очень жалко наблюдать, как люди медленно делают то, что можно сделать гораздо быстрее… Впрочем, я отвлекся от рассказа про метрики.

Agile-методы предъявляют к метрикам и их визуализации особые требования: работа с ними перестает быть уделом избранных, а становится предметом заботы всех членов команды. А это означает наглядное представление, позволяющее быстро провести анализ ситуации по графикам, с тем, чтобы возникла эмпатия к графикам, подобная эмпатии к доске. Scrum решил такую задачу в частном случае, там придумали burndown chart.

Другая полезная диаграмма – частотная диаграмма. По горизонтали откладываем срок выполнения задач в днях, по вертикали – число таких задач. Диаграмму строим в разрезе классов обслуживания, выделенных в SLA. Если задачи в потоке однородны, то мы получим пуассоново распределение или его аналог. А вот если у полученного распределения есть несколько максимумов, то значит мы имеем дело с существенно неоднородным потоком задач. В этом случае имеет смысл провести анализ, чтобы научиться заранее разделять классы задач и с этой помощью улучшить предсказуемость их выполнения и учесть это в SLA. Потому что предсказуемость для бизнеса часто имеет гораздо большее значение, чем скорость.

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

Как известно, в Scrum со спринтом связан ряд встреч: daily scrum, планирование, демо, ретро, а помимо них есть и другие встречи, такие как story mapping для планирования релизов. Все они обеспечивают синхронизацию процесса и взаимодействие со стейкхолдерами. Как легко догадаться, эти функции являются необходимыми для организации потока создания ценности и должны быть выполнены при любом способе организации процесса. В Kanban для выполнения этих функций используются каденции – регулярные встречи, каждая из которых посвящена определенному вопросу и имеет свой собственный ритм, зависящий от соответствующего потока работы.

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

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

Заметим, что все они в том или ином виде есть в Sсrum, только привязаны к спринту, за исключением последней.

Однако, Kanban не диктует, что в процессе обязательно должно быть семь описанных выше серий встреч. Набор конкретных встреч зависит от конкретных условий работы. Например, если команда взаимодействует с разными смежными подразделениями, например, юристами и HR по совершенно разным вопросам и в разном темпе, то это можно обсуждать на разных сериях встреч. Если подразделение предоставляет сервис нескольким разным клиентам с разными циклами поставки, то эти встречи могут проводиться независимо. Более того, далеко не все встречи необходимы. Например, по пополнению может быть принято решение, что каждый стейкхолдер ведет свой список срочных задач, а выбор задач для выполнения происходит по очереди, и специальная встреча назначается, только если этот порядок надо нарушить.

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

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

На этом я заканчиваю свой рассказ про Kanban. Он получился очень длинным, и, возможно, стоило поделить эту статью на две, как вы думаете?

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

Читайте также: