Scrum

Группа «Стража» пыталась выяснить главное: «Ладно, мы ведем этот гигантский проект, который нам жизненно необходим и на который мы угробили уже миллионы долларов. Когда мы его закончим?» Продумав все нюансы, разработчики пообещали сдать проект осенью 2011 года. В отчете генерального инспектора, представленном осенью 2010 года, каждая страница была пропитана недоверием:

В ФБР утверждают, что для завершения проекта «Страж» они прибегнут к «гибкой методологии разработки», то есть будут использовать меньшее количество сотрудников самого ФБР и Lockheed Martin, а также компаний, поставляющих основные стандартные компоненты для системы «Страж». В общей сложности ФБР планирует сократить число привлеченных по контракту специалистов, задействованных в разработке «Стража», приблизительно с двухсот двадцати человек до сорока. В ФБР сообщили, что количество сотрудников ФБР, принимающих участие в работе над проектом, тоже уменьшится с тридцати до двенадцати… ФБР уверило нас, что предполагает завершить проект за двенадцать месяцев с момента внедрения нового подхода, не выходя за рамки оставшихся в бюджете проекта двадцати миллионов{3}.

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

Разумеется, Джефф Джонсон отчасти лукавил, давая обещание уложиться в двенадцать месяцев. Такой информацией в ФБР никто не владел. Они просто не могли знать фактической даты окончания проекта, поскольку были не в курсе, с какой скоростью в состоянии трудиться их группы. Вот о чем я постоянно твержу руководству: «Я смогу назвать срок, только когда увижу, насколько эффективно будет действовать команда. Насколько быстро исполнители станут работать. В какой степени они разгонятся».

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

Не буду углубляться в детали, но остановлюсь на одном из понятий, внедренных Тайити Оно, – создание непрерывного потока. Идея заключается в том, что процесс производства должен быть быстрым и бесперебойным, а одна из ключевых задач руководства – выявлять и устранять препятствия на пути течения потока. Все, что мешает его непрерывности, классифицируется как потери. В своей книге «Производственная система Тойоты»[5] Тайити Оно дает оценку этому явлению не только с деловой, но и с моральной точки зрения:

Не будет преувеличением сказать, что в периоды медленного роста потери являются в большей степени преступлением перед обществом, чем просто коммерческими потерями. Устранение потерь должно быть первой целью бизнеса{4}[6].