Кен Швабер - Скрам

Пол был связан. С одной стороны, он не хотел упускать ни единой возможности привлечь новых клиентов, а с другой – не хотел навредить проекту новостной службы. Том сочувствовал Полу, но также и понимал, что, если не будет твердо стоять на своем и придерживаться правил скрама, ничего не получится. Наконец Пол сказал: «Ладно! Хотя мне и не нравятся правила скрама, я их знаю, понимаю и буду им следовать. Но будь готов к крутым поворотам на планировании спринта!»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На планировании спринта Джейн представила бэклог продукта команде. Просматривая его, команда увидела возможность оптимизации процесса и автоматизации некоторых этапов. База данных MegaEnergy содержала информацию обо всех земельных участках, по которым необходимо производить выплаты. Из Альберты можно было получить данные по изменениям прав собственности за последние 12 месяцев. Затем для каждого соответствия между полученными и имеющимися в базе данными можно было создать транзакции, которые проверит и подтвердит аналитик отдела учета земельных участков MegaEnergy и, в случае необходимости, обновит базу данных. Аналитику больше не придется проверять имя и адрес каждого отдельного участка. Автоматизация получения данных и экраны для их сверки с существующими помогли бы значительно сократить объем работы.