Мы рассматривали компанию MegaFund в третьей и пятой главах. Если вы, будучи клиентом MegaFund в 1997 году, хотели перевести деньги, открыть счет, торговать ценными бумагами или воспользоваться любым другим финансовым предложением MegaFund, у вас было два варианта: позвонить агенту по телефону или пойти в ближайший офис MegaFund и использовать туповатый терминал типа IBM 3270, подключенный через сеть к мейнфреймам компании. Хотя эта технология и была новаторской в 1980-х годах, спустя 17 лет конкуренты MegaFund позволяли клиентам самостоятельно управлять своими учетными записями с домашних или офисных компьютеров, сотовых телефонов, веб-устройств, пейджеров и телефонных голосовых систем в любой день в любое время. Это несоответствие стало неотложной бизнес-проблемой MegaFund. Требовалось как можно скорее устранить отставание от конкурентов и предоставить клиентам новую технологию. Все в MegaFund хотели начать свой собственный проект и тут же создать конкурентоспособное предложение.

MegaFund Systems Company (MSC) предоставляла MegaFund технологические услуги. MSC выявила, что лучшим способом быстро создать новые конкурентные продукты будет использование существующих баз данных через промежуточные серверы. Каждая организация должна была реализовывать собственные бизнес-функции, исполняемые на их серверах, а MSC реализовывала общие функции доступа к данным. Серверы должны были обрабатывать практически любые объемы транзакций в безопасной, перезапускаемой среде. Перечисленные характеристики были первыми нефункциональными требованиями, добавленными в бэклог продукта.

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

Затем мы добавили небольшое количество функциональных бизнес-требований. Например, подразделение по управлению счетами хотело предоставить клиентам возможность напрямую обращаться к своим счетам и просматривать балансы и предыдущие транзакции через интернет. Разделив эти требования на мелкие части, мы поместили какую-то часть из них в каждый спринт, планируя создавать бизнес-функции одновременно с настраиванием масштабируемой инфраструктуры. Укомплектовывая команду, мы выбрали лучших проектировщиков и архитекторов MegaFund. Для реализации помещенных в бэклог продукта требований по определению стандартов и развертыванию инфраструктуры мы пригласили в команду технических писателей и инженеров по настройке аппаратного и программного обеспечения. В результате команда состояла из 10 человек.

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

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

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

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

1. Еще до начала масштабирования постройте соответствующую инфраструктуру.

2. Даже при построении инфраструктуры всегда создавайте и предоставляйте ценность для бизнеса.

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

Эти практики более подробно описаны в следующем разделе.