Книги

Постигая Agile

22
18
20
22
24
26
28
30

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

Рис. 8.3. Мы будем использовать карту потока ценности для построения WIP-диаграммы

Цель WIP-диаграммы состоит в том, чтобы показать полную историю прогресса работ и все те ценные характеристики, над которыми команда работает в настоящий момент. График демонстрирует, сколько ММФ находятся в работе в любой из дней и как они разбиваются на различные этапы потока создания ценности. Прогресс работ – это измерение, касающееся функционала, несущего ценность заказчику, а не технических задач. Другими словами, он показывает количество функционала или частей продукта, которые находятся в работе, а не конкретные задачи, выполняемые командой, чтобы произвести их. В Scrum мы называли их историями. Команда разбивала истории на задачи, которые перемещала на доске задач. Здесь, по аналогии, мы проводим измерение потока историй. Пользовательская история – хороший способ понять ММФ, потому что она представляет собой небольшой, самодостаточный кусок ценности, поставляемой клиенту. История могла бы появиться в WIP-диаграмме, но задачи, которые команда использует, чтобы реализовать историю, этого не могут.

Чтобы построить WIP-диаграмму, начните с оси X, показывающей дату, и оси Y, которая обозначает количество ММФ. Диаграмма содержит линию для каждого из элементов на карте потока ценности. Линии делят диаграмму на области для элементов карты потока ценности.

Нет прогресса никаких ММФ до начала проекта, так что есть только одна точка при Х = 0 в левой части диаграммы (день 0). Допустим, что при запуске проекта команда начинает работать с пользователями над девятью пользовательскими историями, и она применяет их как ММФ для своего проекта. Несколько дней спустя добавляются еще три истории. Вы сможете нарисовать точку на 9 в первый день, потом еще на 9 + 3 = 12, и, когда эти новые ММФ добавятся, вы сможете соединить точки линией.

Рис. 8.4. Начните строить WIP-графики, создавая линейную диаграмму ММФ (например, пользовательских историй) на первом этапе потока создания ценности, и затените область под ней

Несколько дней спустя программисты начинают работать над созданием дизайн-макетов для четырех историй, так что эти истории прогрессируют к следующему этапу потока создания ценности. Общее количество ММФ в системе – по-прежнему 12, но теперь они разделены на 8, еще находящихся в разработке (или ожидающих, поскольку карта потока ценности описывает и время работы, и время ожидания), – на первом этапе потока создания ценности, и 4 – на втором этапе. Так что вы можете добавлять точки на 4 и 12 ММФ, чтобы представить это.

Рис. 8.5. Когда работа прогрессирует к следующему этапу в потоке ценности, на WIP-диаграмме добавляется новая линия, разделяя ее на две зоны. Верхняя линия по-прежнему представляет общее количество ММФ в прогрессе, а пространство между ней и новой линией представляет количество ММФ, находящихся на первом этапе

Поскольку ММФ перемещаются по потоку создания ценности, общее количество задач растет и с течением времени WIP-диаграмма приобретает вид полосок, соответствующих каждому из этапов карты потока ценности. Что происходит, когда создание всех ММФ завершено? Если вы продолжаете показывать их на графике, то в конце концов количество ММФ в стадии «сделано» разрастается до таких размеров, что мешает воспринимать все остальные столбцы. Это делает активные ММФ похожими на ленту на вершине горы.

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

Рис. 8.6. WIP-диаграмма показывает, как работа прогрессирует со временем

Рис. 8.7. Когда команда хочет показать руководителю, сколько работы выполнено, она оставляет задачи со статусом «сделано» на графике, потому что это выглядит впечатляюще. К сожалению, это делает его менее удобным для измерения прогресса работ

Рис. 8.8. Полезно удалять задачи со статусом «сделано» с графика и использовать разные оттенки для каждой полосы, чтобы было понятно, каким столбцам они соответствуют

Вот почему большинство WIP-диаграмм не включают в себя завершенные задачи. Таким образом, если проект стабилизируется с течением времени, то WIP-диаграмма также выглядит стабильной[80].

Когда ММФ переходит из одного этапа потока создания ценности в следующий, полоса старого этапа становится тоньше, а полоса нового – толще.

Это позволяет легко обнаруживать тенденции – как, например, когда много ММФ переходят из одного столбца в другой (или удаляются из потока ценности полностью) в одно и то же время.

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

Контролируйте узкие места, ограничивая выполняемую работу

Есть важная идея, которую использует теория массового обслуживания. Это теория ограничений, созданная физиком и гуру менеджмента Элияху Голдраттом. Одна из главных идей этой теории заключается в том, что особое ограничение (например, работа, которая копится перегруженной командой) устанавливает предел общего объема работ, который можно пропустить через систему. Когда данное ограничение устранено, другое ограничение становится критическим. Теория ограничений утверждает: каждый перегруженный рабочий процесс имеет по крайней мере одно ограничение.

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

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