Постигая Agile

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

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

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

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

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

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

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

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

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

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

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

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

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

Ожидание

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

Движение