Соединенные Штаты Америки осознали свою уязвимость перед терроризмом 11 сентября 2001 года. Внезапно детали, казалось бы, не связанных между собой событий сложились в цельную картину. Вопрос, который мы до сих пор задаем себе: как мы могли не знать об этой угрозе? Неужели, ежедневно собирая внушительное количество данных на уровне страны, штатов и муниципалитетов, мы не могли обнаружить цепочку подозрительных фактов и своевременно выявить угрозу? Дело в том, что лишь малая часть этих данных используется отдельными органами для достижения локальных целей. Проблемы конфиденциальности и отсутствие явной необходимости препятствовали попыткам обмениваться этими данными или формировать единое хранилище.

В течение нескольких лет компания Lapsec исследовала возможность «слияния данных» (data fusion) для получения ценных знаний из массива разрозненной информации – усовершенствованной формы глубинного анализа данных (data mining). В момент слияния к крупным массивам применялись передовые алгоритмы, которые быстро помещали данные в хранилище и преобразовывали их в формат, который подходит для анализа и поиска цепочек подозрительных фактов. В начале 2002 года Lapsec получила добро на этот проект, и компании был предоставлен доступ ко всем транзакционным базам данных американского правительства различных уровней.

В проекте хватало головоломок и сложностей, решение и преодоление которых требовало разной степени мастерства, интенсивности и упорства. Было необходимо:

■ постоянно и своевременно получать данные от агентств, которые не знали слова «сотрудничество»;

■ тщательно фильтровать и сокращать эти данные для минимизации времени извлечения, переноса и загрузки;

■ разработать алгоритмы для просмотра, поиска, анализа, корреляции и хранения промежуточных результатов;

■ приобрести или создать новые технологии для хранения промежуточных данных в динамически изменяющихся структурах;

■ использовать алгоритмы слияния данных для поиска в стоге сена иголок, которые могли представлять угрозу национальной безопасности.

В этом проекте Lapsec многое пробовала впервые, например использование непроверенных технологий и обеспечение высокой степени сотрудничества многочисленных сторон. Соответственно, первой задачей стало доказательство работоспособности идеи и технологии.

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

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

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

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

Я не мог помочь им: каждый раз, когда предлагал команде обсудить цели и бэклог продукта, они отвечали, что, если будут говорить в моем присутствии, им придется меня убить. Руководство компании Lapsec считало проект настолько срочным, что я не успевал получить разрешение на изучение основ проекта от службы безопасности. По крайней мере, мне так сказали, хотя, возможно, я просто не прошел проверку безопасности. В любом случае команда разработки не могла рассказать мне ничего о своей работе.

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

Перед вторым днем запуска команды я плохо спал: переживал, что следующий день станет катастрофой, а тренинг в целом может провалиться. Наконец я решил, что у меня достаточно информации для формирования гипотетического проекта. Мне сказали, что видение проекта заключается в поддержании национальной безопасности посредством слияния и анализа данных. Каждый гражданин США был знаком с критикой в адрес правительства относительно сбора и использования разведданных перед 11 сентября. Я знал, что одни участники команды являлись ведущими экспертами страны по данным, другие – отвечающими за разработку алгоритмов математиками, а третьи – специалистами по поиску в интернете. Понимая, однако, что могу ошибаться в деталях, я ощущал уверенность, что смогу создать адекватный гипотетический бэклог продукта, чтобы помочь команде разработки объединиться.

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

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

■ выявить людей, которые посещали летную школу в течение последних трех месяцев и соответствуют профилю кандидата к совершению террористического акта против Соединенных Штатов;

■ отображать информацию графически, чтобы облегчить операции объединения и детализации, сворачивания и развертывания данных;

■ объединить информацию из нескольких источников на основании запроса или введенных критериев;

■ декомпозировать результаты запроса;

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

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

Команда начала выполнять упражнение. Разработала предварительную архитектуру, изучила объем данных, которые могли быть извлечены, проанализировала элементы и атрибуты, необходимые для поддержки требуемой функциональности, разработала несколько простых алгоритмов слияния. Участники изо всех сил пытались ограничить свою работу. Понимая, что время ограничено одним спринтом и поэтому не получится создать формальные интерфейсы баз данных, команда разработки решила использовать разовое извлечение данных из баз-источников. Также команда осознала, что не стоит начинать создавать все части продукта сразу, а достаточно начать с отображаемых частей.

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

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

Я попросил команду разработки следующий день провести за реальной работой. Ее первым шагом станет превращение гипотетического бэклога продукта в реальный, а вторым – двухчасовое событие по планированию спринта уже с настоящим бэклогом реального проекта. Я попросил команду позвонить мне при появлении любых вопросов или, по крайней мере, тех, на которые я мог бы ответить без получения разрешения от службы безопасности.

Позднее я получил электронное письмо от человека, который привлек меня к запуску этого проекта по скраму. Он писал, что на следующий день команда разработки успешно провела планирование и начала свой первый спринт. Больше никаких вестей от команды не было, а мои электронные письма остались без ответа. Полагаю, что команда работает и сейчас, производя программное обеспечение, которое делает меня более защищенным. Видимо, оно слишком секретно, чтобы я о нем знал. Интересно, был ли я тогда единственным человеком в комнате, который использовал свое настоящее имя.

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

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