Канбан. Альтернативный путь в Agile - [65]

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

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

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

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