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

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

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

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

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

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

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

Знайте цели и формулируйте преимущества

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

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

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

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

Шаги для начала действий

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

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

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

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

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

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

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

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

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

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

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

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

8. Подготовьте доску (стену) карточек для отслеживания работ в цепочке создания ценности, которую вы контролируете (см. главу 6 и главу 7).

9. При желании заведите электронную систему для отслеживания и подготовки отчетов о ней же (см. главу 6 и главу 7).

10. Договоритесь с командой о проведении ежедневного стендап-совещания возле доски, пригласите на них коллег выше и ниже по цепочке создания ценности, но не поощряйте их вмешательства (см. главу 7).

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

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

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

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

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

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