Кен Швабер - Скрам [Гибкое управление продуктом и бизнесом] [litres]

Издательство Tree наняло меня, чтобы запустить скрам в WebPub. Несколько лет назад я уже рассказывал этой компании о фреймворке. Руководители вспомнили презентацию и решили, что скрам может стать подходящим способом улучшить ситуацию. Им особенно понравилась идея инкрементальной поставки функциональности с демонстрацией осязаемого результата. Более 100 человек было задействовано в инициативе по публикации журналов в интернете, и все ощущали срочность этой задачи, однако заметного прогресса не было.

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

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

Я попросил издательство выбрать четыре журнала к публикации онлайн в первую очередь. Каждая команда журнала была укомплектована разработчиками. Затем мы выбрали кого-то из команды 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 года. Внезапно детали, казалось бы, не связанных между собой событий сложились в цельную картину. Вопрос, который мы до сих пор задаем себе: как мы могли не знать об этой угрозе? Неужели, ежедневно собирая внушительное количество данных на уровне страны, штатов и муниципалитетов, мы не могли обнаружить цепочку подозрительных фактов и своевременно выявить угрозу? Дело в том, что лишь малая часть этих данных используется отдельными органами для достижения локальных целей. Проблемы конфиденциальности и отсутствие явной необходимости препятствовали попыткам обмениваться этими данными или формировать единое хранилище.