Книга: Постигая Agile

Ликвидируйте потери

Ликвидируйте потери

Не всегда легко увидеть потери или признать, что вы и ваша команда тратите время на то, что не имеет значения для проекта. Lean-ценность под названием «ликвидируйте потери» говорит о выявлении деятельности, не добавляющей ценности, и о том, как ее устранить.

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

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

При знакомстве с XP мы узнали, что, когда команды привыкают постоянно проводить рефакторинг своего кода, они получают гораздо более гибкие архитектуры. Та же идея применима к осмыслению деятельности команды: привыкнув постоянно проводить «рефакторинг» создания проекта, вы окажетесь в итоге с более гибкой командой с большими возможностями.

Итак, как вы проводите «рефакторинг» выполнения проекта?

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

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

Мы часто сталкиваемся с ситуацией, при которой значительный объем работ по проекту не имеет никакого отношения к улучшению программы. Например, менеджер проекта может потратить немало усилий на большую диаграмму Ганта или иную форму плана проекта, который не соответствует действительности, поскольку основан на информации, значительно изменившейся между этапом написания плана и моментом, когда началась работа над созданием ПО. Еще хуже, если руководитель проекта вложит много сил в актуализацию плана для периодических статус-митингов. Ясно, что это не поможет программному обеспечению: к тому времени, когда план будет готов, программа уже будет поставлена клиенту. Может быть, теперь этот менеджер проекта вовсе не станет вкладывать усилия в то, что не используется его командой. Тогда не исключено, что некий топ-менеджер засуетится, видя отличие плана от жесткой установки «всё всегда вовремя и в рамках бюджета». Всем, включая руководителя проекта, прекрасно известно, что эти волнения не помогут делу.

Типичный пример потерь – это работа менеджера проекта над планом, который не отражает действительности и фактически не используется командой разработки программного обеспечения. Но не с каждым планом происходит такая история – даже на водопадных проектах. Множество из них планируются эффективно (по крайней мере, настолько, насколько это возможно в неэффективной компании). Но если вы руководитель или разработчик проекта, подобного описанному, то уже узнали этот антипаттерн. Абсолютно ясно, что перед нами потери.

Когда вы объективно оцениваете то, что делает команда каждый день, вы определите все виды потерь. Может быть, у вас на полке давно пылится папка спецификаций? Силы, потраченные на создание этих документов, – потери. Если вы часами сидите над обзором кода, который полностью сосредоточен на поверхностных ошибках или личных предпочтениях, но не влияет на дизайн и выявление реальных проблем, – это тоже потери. Некоторые виды документов появляются до начала проекта, например подробное описание работ. На его изучение команда тратит целый день, но документ выбрасывают, когда начинается фактическая работа. Вы часами занимаетесь отладкой и проблемами развертывания, которые можно решить при помощи скриптов? Это явные потери. Бесполезные встречи, где участники по очереди сообщают свои индивидуальные статусы, чтобы координатор проекта смог записать их в протокол, куда никто никогда не заглянет, – также типичный пример потерь. Scrum-команда, даже получающая результат «лучше-чем-ничего», заменяет бесполезные совещания ежедневными scrum-митингами, тем самым исключая потери. В книге представлены и другие примеры потерь, которые также могут быть устранены.

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

Устранение потерь начинается с выявления. Умение видеть их – первый инструмент мышления для данной ценности.

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

Мэри и Том Поппендик решили определить семь потерь разработки программного обеспечения. Как и многое другое, связанное с Lean, эта идея позаимствована у компании Toyota в середине прошлого века. Поппендик обнаружили, что это поможет увидеть потери в вашем проекте.

Частично проделанная работа

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

Дополнительные процессы

Пример дополнительного процесса – антипаттерны управления проектом (глава 7), где команда тратит 20 % времени на отчет о состоянии проекта и оценки, которые используются исключительно для обновления отчета о его состоянии. Все это требует дополнительных усилий в процессе отслеживания проекта и формирования отчетности, но не создает стоимости.

Лишние функции

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

Переключение между задачами

Некоторые команды работают в многозадачном режиме, и часто он выходит из-под контроля. Люди понимают, что полностью заняты (созданием программного обеспечения) и к тому же имеют дополнительные задачи, относящиеся к частичной занятости (поддержка, обучение и т. д.). И каждый кусочек работы важен и приоритетен. Scrum-ценность «сосредоточенность» демонстрирует нам, что переключение между проектами или не связанными между собой задачами в рамках одного проекта вызывает неожиданные задержки и усилия, потому что создает дополнительную нагрузку на способность к восприятию задач. Теперь мы можем назвать это иначе: потери.

Ожидание

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

Движение

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

Дефекты

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

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

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

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

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

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

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

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

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

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

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

Для команды, возможно, это ожидание не казалось слишком долгим, потому что она наверняка занималась работой над другой функцией. Но клиент, который нуждается в этой функции, не всегда знает о других приоритетах команды. И, откровенно говоря, они ему неинтересны. Главное он знает точно: на создание нужной ему функции от момента запуска проекта до момента поставки ушел 71 день.

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

Оглавление книги