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

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

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

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

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

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

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

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