потерями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ожидание

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

Движение

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

Дефекты

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

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

Платформенная ловушка в

<< | >>
Источник: Эндрю Стеллман, Дженнифер Грин. Постигая Agile. Ценности, принципы, методологии. 2015

Еще по теме потерями.:

  1. Вспомогательная аксиома № 4. Относитесь к мелким потерям спокойно, как к неизбежности. Будьте готовы к тому, что вам придется пройти через несколько таких потерь на пути к крупному успеху
  2. Потенциальный Доход – суммарная арендная плата, получаемая от сдачи объекта недвижимости в аренду без учета потерь и расходов. Действительный (эффективный) доход – это потенциальный доход, скорректированный на величину потерь от незанятости помещений, льгот по арендной плате, потерь от недобросовестных арендаторов и пр., называется действительным (эффективным) доходом
  3. Учет товарных потерь
  4. Проблема 4: Задание остановки потерь
  5. 12.5. Учет товарных потерь
  6. Банковские и биржевые потери
  7. 11.7. Учет потерь от брака
  8. Внутрисменные потери рабочего времени
  9. Учет недостач и потерь от порчи ценностей
  10. Учет недостач и потерь от порчи ценностей
  11. Влияние недостач и потерь от порчи ценностей на финансовый результат
  12. Как победить в торговле, неся потери
  13. 1. Заказ на прекращение потерь
  14. Анализ потерь от брака
  15. Уровень потерь: показатель предельного риска
  16. Близкая остановка потерь по сравнению с далекой