Это показывает рост, а не поток. Безусловно придавая больший вес вашему отчету и помогая произвести впечатление на старшего менеджера (поскольку демонстрирует, что команда проделала огромный объем работы), это не слишком-то полезно для управления потоком. Удаление с диаграммы работ со статусом «сделано» дает более четкую визуализацию того, как со временем изменяется протекание потока ценности.
Рис. 8.6. WIP-диаграмма показывает, как работа прогрессирует со временем
Рис. 8.7. Когда команда хочет показать руководителю, сколько работы выполнено, она оставляет задачи со статусом «сделано» на графике, потому что это выглядит впечатляюще. К сожалению, это делает его менее удобным для измерения прогресса работ
Рис. 8.8. Полезно удалять задачи со статусом «сделано» с графика и использовать разные оттенки для каждой полосы, чтобы было понятно, каким столбцам они соответствуют
Вот почему большинство WIP-диаграмм не включают в себя завершенные задачи. Таким образом, если проект стабилизируется с течением времени, то WIP-диаграмма также выглядит стабильной[80].
Когда ММФ переходит из одного этапа потока создания ценности в следующий, полоса старого этапа становится тоньше, а полоса нового – толще.
Это позволяет легко обнаруживать тенденции – как, например, когда много ММФ переходят из одного столбца в другой (или удаляются из потока ценности полностью) в одно и то же время.
Рис. 8.9. WIP-диаграмма помогает видеть, как работает поток создания ценности, а также легче обнаруживать задержки и другие потенциальные потери – например, те истории, которые слишком долго ожидают своего развертывания в производство
Есть важная идея, которую использует теория массового обслуживания. Это теория ограничений, созданная физиком и гуру менеджмента Элияху Голдраттом. Одна из главных идей этой теории заключается в том, что особое ограничение (например, работа, которая копится перегруженной командой) устанавливает предел общего объема работ, который можно пропустить через систему. Когда данное ограничение устранено, другое ограничение становится критическим. Теория ограничений утверждает: каждый перегруженный рабочий процесс имеет по крайней мере одно ограничение.
Когда ограничение накапливается в определенной точке рабочего процесса, люди часто называют это узким местом или бутылочным горлышком. Если убрать одно узкое место в системе (за счет изменения процесса или добавления людей), то можно добиться, чтобы работа протекала более гладко. Теория ограничений говорит нам, что обнаружится, однако же, какое-нибудь иное ограничение или узкое место где-то еще в системе. Между тем можно уменьшить общий объем потерь путем систематического отслеживания критических ограничений и их ликвидации.
Каково это – работать в команде, которая ежедневно имеет дело с одним из этих ограничений? Другими словами, как быть, если вы и ваша команда – это и есть узкое место?
Оказавшись узким местом в системе, всегда ожидаешь работы в многозадачном режиме с постоянным переключением между нормальной работой с полной занятостью и более редкими эпизодами разовых задач. Имейте в виду: множество команд, как правило, нагружены массой задач, возложенных на них в то же самое время, но не называйте это «многозадачностью». Люди обычно используют термин «многозадачность», чтобы замаскировать факт перегруженности команды. Разделение работы и подталкивание команды к многозадачному режиму часто удерживает вас от признания, что работы больше, чем времени, особенно если учесть дополнительное время и когнитивные усилия, необходимые для переключения между задачами.
Например, команда, которая 100 % своего времени посвящает разработке, может иметь руководителя с магическим мышлением, который просит ее потрудиться несколько часов в неделю в режиме многозадачности, в связи с чем люди уже не имеют ни поддержки, ни обучения, ни ремонта, ни совещаний, ни других дел. Им трудно однозначно определить, что работы оказалось больше, чем времени, особенно если лишние задачи добавляются понемногу, а не за один раз. Разработчики начинают чувствовать себя перегруженными, и, поскольку все это носит название «многозадачность», они не всегда догадываются, почему им так тяжело. Появится чувство, будто есть много работ на неполный рабочий день, за которыми невозможно угнаться. Можно помочь команде, применяя теорию массового обслуживания, чтобы разобраться в проблеме. Теперь мы знаем, что работа накапливается в узком месте где-то в рабочем процессе и растет взваленный на разработчиков ее объем.
И у меня есть философия, которой я живу. Все, кто работает со мной, знают об этом, вот она – на стене: «Если глупость входит в комнату, то у вас есть моральный долг застрелить ее независимо от того, кто ее сопровождает».
Система вытягивания – способ выполнения проекта или процесса, который использует очереди или буферы для устранения ограничений. Это еще одна концепция из тех, что возникли в японской автомобильной промышленности, но впоследствии нашли свое место в области разработки программного обеспечения. Производители автомобилей, в частности Toyota, в 1950-х и 1960-х годах оценили свои склады комплектующих и попыталась найти способы уменьшить количество деталей, которые должны там лежать. После длительных экспериментов они обнаружили, что даже если в наличии почти все детали, необходимые для сборки автомобилей, то дефицит нескольких деталей может задержать всю линию. Потому что в итоге все монтажные бригады ждут поставки недостающих запчастей. Стоимость задержки становится важна: если деталь в дефиците, то задержка ее поставки на конвейер оказывается очень дорогой, а если часть имеется в изобилии, то стоимость задержки низкая.
Команды Toyota обнаружили, что можно сократить расходы и поставлять автомобили гораздо быстрее, если знать, какие запчасти нужны прямо сейчас, и поставлять на линию только их. Чтобы реализовать это, они придумали производственную систему Toyota (TPS). Это предшественница бережливого производства, которые Том и Мэри Поппендик адаптировали для создания бережливой разработки программного обеспечения.
В основе TPS лежит идея существования трех типов потерь, которые создают трудности в рабочем процессе и должны быть удалены.
Муда (無駄), что означает «бесполезность, бесперспективность, праздность, избыточность, потери, расточительность».
Мура (斑), что означает «неравномерность, неритмичность, отсутствие единообразия, неоднородность, неравенство».
Мури (無理), что означает «неразумность, невозможность, перегруженность, излишняя сложность, пересиливание, принуждение, превышение, чрезмерность».
Любой, кто участвовал в плохо управляемых, буксующих проектах программного обеспечения – особенно тех, что используют неэффективный процесс, – не понаслышке знаком с идеями неравномерности, бесполезности и неразумности. Это верно для неэффективных водопадных процессов, но любой работавший, скажем, в команде с неправильным мышлением, способной достигать только результата «лучше-чем-ничего» (или еще худшего) с применением Scrum или XP-практики, также может распознать эти случаи.
Не кажутся ли вам знакомыми какие-либо из перечисленных ниже действий?
• Заставить всех подписать спецификацию занимает много времени, а разработчики между тем сидят и ждут старта проекта. Как только он начнется, они уже опоздали.
• Вечная забота менеджмента – обеспечить бюджет. К тому времени, когда проект получает зеленый свет, думать об этом уже поздно.
• На середине разработки группа признает, что важные элементы дизайна или архитектуры программного обеспечения должны быть изменены, но это вызовет большие проблемы, потому что зависят от них многие другие вещи.
• QA-команда (Quality Assurance) не начинает тестирования программного обеспечения, пока каждая функция не будет завершена. Позднее они найдут серьезную ошибку или проблемы с производительностью, и команде разработки придется отвлекаться от текущей работы, чтобы это исправить.
• Анализ и дизайн продолжаются так долго, что, когда кодирование все-таки начнется, каждый программист вынужден работать по ночам и выходным, чтобы уложиться в срок.
• Архитектор программного обеспечения проектирует большие красивые сложные системы, которые внедрять нецелесообразно.
• Даже мельчайшие изменения в спецификации, документе или плане проекта должны пройти трудоемкий процесс управления изменениями. Вместе с тем люди находят способы, чтобы обойти его, внося радикальные, крупномасштабные изменения в систему заявок на техподдержку или отслеживание ошибок.
• Проект не успевает завершиться в срок, поэтому руководитель добавляет людей в команду в последние несколько недель. Вместо ускорения выполнения проекта этот шаг создает путаницу и хаос[81].
Вспомните ваши собственные проекты, которые столкнулись с проблемами из-за заведомо глупых действий. Возможно, это правила, которые пришлось выполнять (или обходить), установленные вашим руководителем или являющиеся частью культуры компании. А может быть – ненужные дедлайны, произвольно назначенные, чтобы мотивировать вас.
Эти вещи неслучайны. Найдите время поразмыслить над определениями «муда», «мура» и «мури». Обдумайте список знакомых проблем проекта, а также тех, с которыми вы сталкивались сами. Сможете ли вы сопоставить каждую из них с одной из этих трех категорий. Были ли действия, которые пришлось выполнять, тщетными, бесполезными или лишними? Это