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

Все, что поддерживает масштабирование проекта, должно быть разработано и реализовано до начала масштабирования. Вся эта работа выполняется в спринтах.

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

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

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

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

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

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

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

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

Эти подходы оказались полезными при масштабировании проекта «Год 2000» (Y2K). В конце 1990-х годов почти каждая организация пыталась добиться, чтобы ее программное обеспечение поддерживало даты позднее 1999 года и не создавало проблем на заре XXI века. В следующем разделе я расскажу, как одна компания успешно применила подходы к масштабированию скрама в крупном проекте, направленном на обновление программного обеспечения для Y2K, и помогла клиентам обновить версию системы.