Постигая Agile

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

Дефекты

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

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

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

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

Используйте карту потока ценности, чтобы ясно увидеть потери

В своей книге Lean Software Development Мэри и Том Поппендик рекомендуют запастись карандашом и бумагой и выполнить простое упражнение, чтобы помочь вам найти потери. Его называют «карта потока ценности», и вы можете реализовать его для любого процесса. Как и многие методы, используемые в сочетании с Lean, он возник в производственной сфере, но актуален и для разработки программного обеспечения.

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

Концепция ММФ очень важна. К счастью, вам уже знакомо это понятие. Когда владелец продукта в scrum-команде управляет элементами в бэклоге, он имеет дело с типичными ММФ. Они часто принимают форму пользовательских историй, требований или запросов.

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

Рисунок 8.2 показывает пример карты потока ценности для реального объекта, проходящего через традиционный процесс водопада.

Рис. 8.2. Эта карта потока ценности показывает, как объект в проекте разработки программы проходит через традиционный цикл управления проектами. Команда может его использовать, чтобы отчетливее видеть, где время тратится впустую