любой заинтересованной стороне. Но самое главное, появлялась возможность демонстрировать программу тем, ради кого она создавалась, – оперативному персоналу и аналитикам.
Этот метод позволяет участникам группы эффективно взаимодействовать как с заказчиком, так и друг с другом во время всего процесса разработки. В правильном ли направлении они движутся? Соответствует ли поставленной задаче то, что они собираются делать дальше? Учитываются ли ошибки, обнаруженные во время предыдущего этапа?
В Scrum такие циклы, или этапы, названы спринтами. Каждый спринт планируется предварительно на специальных встречах. Участники оценивают, какой объем работ, на их взгляд, они смогут сделать, скажем, в течение следующих двух недель. Из списка задач, расставленных по приоритетам, они выбирают очередные единицы работы[7], предназначенные для выполнения, записывают их на стикеры, которые приклеивают на стену. Группа решает, сколько единиц работы они в состоянии выполнить за предстоящий спринт.
На завершающей стадии спринта участники снова собираются вместе и показывают друг другу, чего удалось достичь за время совместной работы. Они смотрят, сколько единиц работы, занесенных на стикеры, действительно доведены до конца. Не все удается выполнить? Значит, для этого спринта было отобрано слишком много задач. Бывает наоборот – недостаточное количество задач. В данном случае важно другое: у группы развивается чувство собственной скорости, то есть появляется необходимое знание, как быстро она может продвигаться в своей работе.
После того как все участники покажут свои результаты, они начинают детально разбирать созданное – собственно, с этого момента и вступают в силу идеи Тайити Оно, поскольку обсуждается не выполненный продукт, а каким образом он делался. «Как улучшить сотрудничество в следующем спринте? Что препятствовало в последнем спринте? Из-за чего мы продвигаемся не так быстро, как хотим?» – вот вопросы, которые они ставят перед собой. Как это работает в Scrum, я подробнее объясню в приложении.
Поэтому Джеффу Джонсону потребовалось почти три месяца, чтобы точно сказать, сколько на самом деле уйдет времени на завершение проекта. Он хотел определить скорость работы каждой группы по длительности нескольких спринтов и выяснить, как можно повысить этот показатель, то есть насколько быстрее они в состоянии работать. Посмотрев, сколько единиц работы каждая группа выполнила за каждый спринт, а потом проверив, сколько единиц еще осталось до конца проекта, он смог назвать срок завершения.
Джонсона интересовало не только как быстро идет разработка, его беспокоила проблема препятствий, замедляющих ее ход. Более всего он хотел бы ускорить процесс, сделать работу групп более динамичной и продуктивной – но не за счет сверхурочных часов (в дальнейшем я подробнее объясню, что это пустая трата времени, лишь тормозящая дело), а при помощи более совершенного и разумного
