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

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

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

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

В 2007 году в Corbis это достигалось постепенно. Сначала внедрили канбан-систему – визуальную доску и электронное средство отслеживания. Вместе с этим пришла прозрачность. Бизнес оказался сильнее вовлечен в процесс разработки ПО и в наблюдение за производительностью этого подразделения. Создавались отчеты, демонстрирующие количество нерешенных проблем и заблокированных единиц работы, а также среднее время разрешения этих задач. ( Рис. 12.6.Отчет о проблемах и заблокированных единицах работы)

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

Рис. 19.1. Доска с мусорной корзиной

Рис. 19.2. Отчет о непринятой и отмененной работе, демонстрирующий незавершенные рабочие единицы за прошлый месяц

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

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

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

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

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