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