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

Пример Service1st показывает, насколько бывает трудно в комплексном проекте выяснить все детали заранее. Взаимодействие двух продуктов было настолько сложным, комплексным и неопределенным, что задачи, запланированные менеджерами в начале цикла создания релиза, устаревали вскоре после их назначения исполнителям. Работа только началась, а проект почти сразу стал отставать от расписания.

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

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

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

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

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

Издательство 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. Разработчики стреляли по движущейся цели, остановка которой не предвиделась.