Поставляйте как можно быстрее

Есть еще одна lean-ценность – поставляйте как можно быстрее.

Как вы это понимаете? Возможно, вам представляется, как грозный руководитель или менеджер проекта принуждает команду работать допоздна, чтобы поскорее выпустить готовый код. Означает ли решение «поставлять как можно быстрее» отказ от тестов, низкоприоритетных функций и всего остального, что считается «посторонним» или низкоприоритетным? А может быть, вы вспоминаете о героических разработчиках, засиживающихся в офисе до поздней ночи и в выходные или стремящихся пропихнуть свои «быстрые-и-грязные» костыли, чтобы получить важную функцию на выходе. Как раз все это рождается в умах большинства менеджеров, когда они слышат фразу «поставляйте как можно быстрее». Многие разработчики, тестировщики и другие инженеры думают то же самое.

Agile-команды знают, что подобные вещи заставят команду поставлять программные продукты медленнее, а не быстрее. Это идея о том, почему есть agile-принцип содействия устойчивому развитию («спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп в течение неопределенного срока» – один из принципов, о которых вы узнали в главе 3). Срезание пути и углов и сверхурочная работа требуют больше времени и денег, чем экономят. Команды выполняют работу лучше и быстрее, когда у них есть время, чтобы сделать все правильно.

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

Цель теории массового обслуживания – это необходимость убедиться, что люди не перегружены работой и у них есть время делать вещи правильно. Очередь представляет собой список задач, функций или элементов для группы либо индивидуального разработчика. Очереди имеют порядок. Это, как правило, «первый вошел, первый вышел». Согласно данному правилу, никто не может изменять очередность и элемент, который попал в очередь первым, прежде других вытягивается следующим участником и берется в работу. Теория массового обслуживания является математическим исследованием очередей, и одно из ее направлений включает в себя предсказание тех последствий, которые вызываются добавлением очередей на входе системы. Lean говорит, что если сделать очередь как поток командной работы публичной и центральным местом в процессе принятия решений, то это поможет командам поставлять результаты работы значительно быстрее.

Ключевые моменты

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

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

Любая деятельность, которая явно не добавляет ценности проекту, считается потерями. Lean-команды стремятся увидеть их и исключить из проектов, насколько это возможно.

Мэри и Том Поппендик зафиксировали семь потерь разработки программного обеспечения: частично проделанная работа, дополнительные процессы, лишние функции, переключение между задачами, ожидание, движение и дефекты.

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

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

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

Используйте графики для визуализации незавершенных работ

Как узнать, сможете ли вы поставить программный продукт максимально быстро?

Бережливое мышление предлагает использовать для этого измерения. Эффективный способ определить, как команда поставляет ценные продукты, – применение диаграммы незавершенных работ (work-in-progress, WIP-диаграмма). Это простая схема, которая показывает, как минимальные маркетинговые функции протекают через ваш поток создания ценности.

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