Scrum

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

Джефф Джонсон осознавал, что препятствия станут его проблемой.

Почти три месяца выясняли разработчики «Стража», сколько им действительно понадобится времени на завершение проекта. Почему так долго? В поисках ответа обратимся к процессу «проверять и адаптироваться», о котором я говорил ранее.

Процесс разработки, основанный на принципах Scrum, дает возможность в фиксированные и довольно короткие циклы достигать требуемых результатов, причем каждая новая версия поддерживает функционал предыдущей. В ФБР остановились на двухнедельных циклах исходя из предположения, что в конце каждого этапа они будут иметь полностью

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

Этот метод позволяет участникам группы эффективно взаимодействовать как с заказчиком, так и друг с другом во время всего процесса разработки. В правильном ли направлении они движутся? Соответствует ли поставленной задаче то, что они собираются делать дальше? Учитываются ли ошибки, обнаруженные во время предыдущего этапа?

В Scrum такие циклы, или этапы, названы спринтами. Каждый спринт планируется предварительно на специальных встречах. Участники оценивают, какой объем работ, на их взгляд, они смогут сделать, скажем, в течение следующих двух недель. Из списка задач, расставленных по приоритетам, они выбирают очередные единицы работы[7], предназначенные для выполнения, записывают их на стикеры, которые приклеивают на стену. Группа решает, сколько единиц работы они в состоянии выполнить за предстоящий спринт.

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

После того как все участники покажут свои результаты, они начинают детально разбирать созданное – собственно, с этого момента и вступают в силу идеи Тайити Оно, поскольку обсуждается не выполненный продукт, а каким образом он делался. «Как улучшить сотрудничество в следующем спринте? Что препятствовало в последнем спринте? Из-за чего мы продвигаемся не так быстро, как хотим?» – вот вопросы, которые они ставят перед собой. Как это работает в Scrum, я подробнее объясню в приложении.

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

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