Сосредоточив внимание только на создаваемом в рамках спринта инкременте продукта, команда последовательно продвигается к созданию запланированного релиза. Каждый инкремент тестируется по мере создания программного кода, поэтому количество дефектов невелико, они не перегружают команду разработки, а в конце каждого спринта качество продукта соответствует приемлемому уровню.
Итеративно-инкрементный подход дает команде чувство удовлетворения и понимание, где она находится в цикле создания релиза. Скрам требует, чтобы каждый инкремент продукта потенциально мог быть предоставлен пользователям, а это означает необходимость постоянного устранения дефектов и минимизации их текущего количества.
Скрам – эмпирический процесс. Вместо того чтобы следовать устаревшим сценариям, скрам использует частую регулярную инспекцию и адаптацию действий команд разработки для достижения желаемой цели. Инспекция в ходе обзора спринта особенно эффективна, потому что проверяется реальная действующая функциональность. Используя скрам, команды наделяются полномочиями находить свои собственные варианты преодоления препятствий. Эта свобода, наряду с вытекающим из нее творчеством, является одним из основных преимуществ скрама.
Ситуация в издательстве Tree Business Publishing
Издательство Tree Business Publishing (Tree) – подразделение холдинга Tree Holdings, публикует профессиональные журналы в самых разных отраслях. Прошло почти 10 лет с тех пор, как Tree решило публиковать свои журналы не только в печатном виде, но и в интернете. Редакторы Tree распорядились как можно скорее опубликовать электронные версии, однако за два года в сети оказался только один журнал. Причиной промедления стало открытие, что веб-публикация не похожа на печатную. Прогресс застопорился, потому что Tree хотело предварительно получить ответы на ряд вопросов:
1. Как представить журнал эффективно и «вкусно» для онлайн-версии?
2. Как изменятся внутренние процессы редактуры и производства, когда журналы станут публиковаться и в печатном виде, и в интернете?
3. Какой наилучший механизм публикации контента в сети следует использовать?
Редакторы, писатели и команды разработчиков программного обеспечения Tree потратили некоторое время, пытаясь найти приемлемое решение. Первоначально все редакторы запрашивали создание «медианейтральных» инструментов публикации, которые генерировали бы потоки данных на XML для дальнейшего преобразования контента в любой требуемый формат. Менеджеры компании Tree принципиально одобрили такой подход, однако решили, что создание и управление таким медианейтральным контентом будут труднее, чем предполагалось вначале. В результате уровень комплексности и неопределенности задачи по переходу на медианейтральный режим работы оказался настолько высоким, что затормозил движение в направлении главной цели – представления журналов Tree в интернете.
В отчаянии менеджеры Tree искали способ ускорить доставку журналов в интернет и поэтому привлекли небольшую двухлетнюю интернет-компанию WebPub, способную быстро создавать сайты для размещения материалов. У WebPub уже было несколько клиентов с похожими кейсами. Издательство купило решение WebPub и объявило, что будет использовать его для веб-публикации всех журналов Tree. Руководству журналов было поручено сосредоточить свои усилия по публикации в интернете на WebPub.
К несчастью, покупка WebPub сделала проблему веб-публикации еще более комплексной. Для публикации журналов Tree необходимо было усовершенствовать платформу WebPub. Издательство полагало, что приобрело универсальное решение, однако платформа WebPub обладала специфическими характеристиками, разработанными для ее текущей клиентской базы. Теперь Tree предстояло решить, что делать с платформой WebPub: доработать для публикации журналов Tree или превратить в универсальную платформу для публикации в любых форматах.
Чтобы устранить неразбериху и продвинуться в достижении цели, был принят ряд решений:
■ платформа WebPub будет усовершенствована для универсальной публикации, но в первую очередь необходимо реализовать поддержку публикации журналов Tree;
■ медианейтральные потоки данных XML будут поступать в платформу WebPub из редакционного процесса каждого журнала. XML уже был основным входным форматом для этой платформы, но было необходимо определить универсальный обобщенный формат данных XML, удовлетворяющий требованиям всех журналов;
■ веб-разработчики журналов остановят всю внутреннюю разработку, будут учиться использовать платформу WebPub и работать над интеграцией редакционного процесса своего журнала с платформой WebPub посредством XML.
Эти решения стали важным прорывом для Tree: они уменьшили количество доступных вариантов для журналов, WebPub и управляющего подразделения Tree. Однако эти решения имели и негативный побочный эффект: менеджеры решили, что могут озвучить новые сроки публикации журналов в сети.
Чтобы оправдать довольно дорогостоящее приобретение WebPub, сроки установили очень сжатые, а разработчики WebPub зависели от результатов двух незавершенных и неопределенных активностей. Задачи постоянно менялись по мере уточнения требований журналов к универсальному XML-формату и параллельной доработки основного функционала платформы WebPub. Разработчики стреляли по движущейся цели, остановка которой не предвиделась.
Применение скрама
Издательство Tree наняло меня, чтобы запустить скрам в WebPub. Несколько лет назад я уже рассказывал этой компании о фреймворке. Руководители вспомнили презентацию и решили, что скрам может стать подходящим способом улучшить ситуацию. Им особенно понравилась идея инкрементальной поставки функциональности с демонстрацией осязаемого результата. Более 100 человек было задействовано в инициативе по публикации журналов в интернете, и все ощущали срочность этой задачи, однако заметного прогресса не было.
Отдельные усилия по усовершенствованию платформы WebPub, стандартизации XML и публикации журналов в сети оказывались неразрывно переплетенными. К счастью, скрам-команды являются кросс-функциональными. Аналогично ежедневному скраму, который координирует работу нескольких людей в одной команде разработки, встреча скрам скрамов (Scrum of Scrums) координирует работу нескольких команд, работающих над одним проектом. Эта встреча по сути – ежедневный скрам, в котором принимают участие по одному человеку от каждой команды разработки. Перед официальным стартом проекта его планировщики разделяют работу на крупные блоки для минимизации зависимостей между командами, и те работают над условно независимыми частями архитектуры проекта. Такая встреча эффективно координирует команды, когда обсуждения требуют незначительные связи и зависимости. Однако в Tree зависимости были настолько сильными, что скрам скрамов не работал.
Чтобы быстро создать инкремент продукта, была необходима параллельная разработка функциональности XML, WebPub и журналов. Компоненты XML и WebPub были объемны и имели инфраструктурный характер. Зависимости были слишком комплексными, устранение или разрешение их до начала работы заняло бы много времени и остановило бы работу. Я решил, что наилучшим вариантом станет координация зависимостей теми, на кого они влияют: командам разработки придется самоорганизовываться для поиска путей преодоления этих препятствий.
