Читать «Скрам (Гибкое управление продуктом и бизнесом)» онлайн - страница 42

К несчастью, покупка 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 зависимости были настолько сильными, что скрам скрамов не работал.