Скрам

В роли скрам-мастера Том привел в качестве аргументов два правила, которые помогли его команде разработки и, в конечном счете, всей MetaEco. Во-первых, он напомнил о правиле скрама, запрещающем вмешательство в работу команды во время спринта. Во-вторых, он сообщил Полу о правиле, позволяющем изменять порядок элементов в бэклоге продукта и тем самым перенаправлять команду разработки на более ценные требования на планировании спринта.

Первое правило защищало команду и ее работу, а второе уверило Пола, что процесс скрама позволяет реагировать на его запросы и потребности фирмы. Достигнув равновесия между фокусировкой и реагированием на запросы, MetaEco смогла закрыть сделку с новостной службой. Если бы Том не выполнял свою новую роль скрам-мастера и не защищал работу команды в течение спринта, все могло закончиться не так позитивно. Правильно применив правила скрама, Том смог сбалансировать потребности отдела маркетинга и отдела разработки.

Владелец продукта в MegaEnergy

Главная цель владельца продукта – возврат инвестиций (ROI). Бэклог продукта отлично помогает ему управлять проектом и спринт за спринтом направлять команду разработки к созданию наибольшей ценности для повышения рентабельности продукта. Бэклог продукта позволяет владельцу продукта:

■ упорядочить элементы, поместив наиболее ценные для бизнеса требования в самом начале списка;

■ добавить нефункциональные требования, которые облегчают дальнейшую разработку и выпуск новых релизов;

■ постоянно дорабатывать продукт в ответ на изменение бизнес-условий и появление новых конкурентных возможностей.

Ситуация в MegaEnergy

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

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

Компания уже предприняла две попытки автоматизировать процесс, и обе потерпели неудачу. Эти попытки были названы проектом «Участок». Поскольку в каждом штате и провинции свои процедуры, процессы и способы передачи информации о собственности на землю, у отдела учета земельных участков в MegaEnergy возникли проблемы с определением единого способа получения и обработки информации от различных правительственных учреждений. Руководство MegaEnergy решило объединить проект автоматизации с проектом по переносу данных по земельным участкам с мейнфреймов на менее дорогие серверы.

Проект был возобновлен, и на этот раз MegaEnergy решила попробовать скрам. Другие подходы не сработали, так что терять компании было нечего. Кроме того, учитывая высокую комплексность ситуации, казалось, что скрам будет идеальным процессом разработки для этого проекта. Скрам-мастером была назначена Рут, менеджер предыдущих проектов, а владельцем продукта – Джейн, глава Отдела учета земельных участков MegaEnergy.

Владелец продукта в действии

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