Скрам

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

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

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

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

Она попросила меня объяснить, что значат мои слова: «Продемонстрированная на обзоре спринта функциональность должна быть потенциально готова к поставке и использованию». Я ответил, что на следующем планировании спринта она может попросить команду разработки поставить этот инкремент пользователям. Джейн решила воспользоваться этой возможностью и провела внеочередной двухнедельный спринт поставки. Поскольку большинство трубопроводов MegaEnergy проходили через Альберту, созданная за этот спринт и предоставленная функциональность уменьшила нагрузку сотрудников отдела учета земельных участков более чем на 40 %.

Ценность владельца продукта

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

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

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

Команда разработки в Service1st

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