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

Руководители бизнеса хотят давать обещания своим коллегам по совету директоров и по исполнительному комитету, акционерам, клиентам, рынку в целом – и выполнять их. Успех на уровне высшего руководства во многом зависит от доверия, которое, в свою очередь, требует надежности. Высшие руководители стремятся минимизировать риски, чтобы выдавать предсказуемые результаты.

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

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

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

Все эти желания соответствуют организации, действующей на том уровне, который определяется институтом SEI как четвертый или пятый уровень зрелости по пятибалльной шкале модели CMMI. Четвертый и пятый уровни этой шкалы считаются уровнями высокой зрелости. Ее достигли очень немногие независимо от того, подавали ли они заявку на формальную сертификацию SCAMPI [10]. Поэтому неудивительно, что большинство руководителей крупных технологических компаний недовольны результатами своих команд разработчиков, потому что уровень зрелости организации часто не совпадает с желаемым.

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

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

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

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

1. Определите набор целей внедрения Канбана.

2. Составьте схему цепочки создания ценности (последовательности всех действий, которые предпринимает организация по разработке, чтобы удовлетворить запрос клиента или заинтересованного лица) (см. главу 6).

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

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

5. Определите типы рабочих единиц на основе типов рабочих запросов, поступающих от заинтересованных лиц выше по цепочке (см. главу 6). Есть ли разделение на типы, чувствительные и нечувствительные ко времени выполнения? Если да, то задумайтесь о введении классов обслуживания (см. главу 11).

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

7. Назначьте встречу с коллегами выше и ниже по цепочке создания ценности – это может быть одно большое или много мелких совещаний (подробнее – ниже в этой главе):

а) – обсудите правила, касающиеся мощности того элемента цепочки создания ценности, который вы хотите контролировать, и договоритесь о WIP-лимите (см. главу 10);

б) – обсудите и установите с партнерами выше по цепочке создания ценности механизм координации входа – например, регулярное совещание по расстановке приоритетов (см. главу 9);

в) – обсудите и установите с партнерами ниже по цепочке создания ценности механизм координации релиза – например, регулярный релиз ПО (см. главу 8);

г) – возможно, потребуется ввести разные классы обслуживания для рабочих запросов (см. главу 11);

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