Скрам - Кен Швабер

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

На планировании спринта первой команды мы создали бэклог продукта, поместив вверху списка нефункциональные требования к структурам XML и возможностям WebPub, необходимым для публикации журнала. Команда разработки взяла на себя обязательство по реализации готового к поставке инкремента продукта в ходе спринта.

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

Разработчики XML и WebPub, назначенные в четыре журнальные команды разработки, разрешали зависимости, возвращаясь в свои команды XML и WebPub. Они знали о задачах отдельных журнальных команд и добивались, чтобы функциональность для их поддержки была разработана параллельно в командах XML и WebPub.

Извлеченные уроки

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

Уровень комплексности в Tree был ошеломляющим, а ситуация была близка к хаосу. Команды XML, WebPub и журналов разрабатывали зависимые функции параллельно. Реализуемые командами разработки требования были крепко переплетены и взаимозависимы. Обычные механизмы инспекции и адаптации скрама были бы перегружены, если бы я организовал команды как обычно: одна команда XML, одна команда WebPub и по одной команде для каждого журнала. Ежедневный скрам не предоставил бы достаточно возможностей для инспекции прогресса, обнаружения зависимостей и, как следствие, поиска, отбора и принятия необходимых мер по адаптации к сложившейся ситуации.

Ключевой модификацией скрама в этом случае было изменение состава команды разработки. Я укомплектовал команды сотрудниками так, чтобы для любого компонента комплексной системы в команде разработки находился хотя бы один сотрудник, знакомый с этим компонентом и имеющий возможность влиять на него. Частично привлекаемый в команду разработчик из группы XML давал обязательство реализовать в ходе спринта функционал XML, необходимый для поддержки функций журнала. Частично привлекаемый в команду разработчик из группы WebPub делал то же самое. Будучи одновременно и частью какой-то из четырех команд журналов, и частью групп XML или WebPub, эти люди отвечали за координацию разработки инкрементов продукта. С одной стороны, хорошо понимая бэклоги спринтов журналов, они могли обеспечить, чтобы работа групп XML и WebPub была сконцентрирована только на функциональности, которая отвечала потребностям команд журналов. С другой стороны, они синхронизировали работу журнальных команд разработки с работой групп XML и WebPub.

Эта кросс-командная координация очень похожа на то, что позже стало называться скрам скрамов (Scrum of Scrums) – встреча и подход, при котором работа нескольких команд разработки координируется участниками от каждой команды. Такой способ самоорганизации работы команд заметно помог издательству Tree, и первые четыре журнала начали появляться в сети в течение трех месяцев, а пятый и следующие не заставили себя долго ждать.

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

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

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

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

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

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

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

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

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

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