Извлеченные уроки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компания Medcinsoft использовала скрам для управления проектом Y2K, целями которого были адаптация продуктов Medcinsoft к датам после 31 декабря 1999 года, установка обновлений программного обеспечения более чем в 350 крупных организациях здравоохранения, обучение персонала больниц, стабилизация установленного обновления до 1 октября 1999 года. Программное обеспечение Medcinsoft автоматизирует административные документы организаций здравоохранения, включая регистрацию пациентов, выписки, выставление счетов на оплату, страхование, ведение медицинских карт, учет задолженностей клиентов. Неудача такого программного обеспечения имела бы катастрофические последствия для этих организаций и обслуживаемого ими населения. До начала использования скрама компания Medcinsoft для управления проектами применяла диаграммы Ганта, но они оказались крайне неуместными. Клиенты были недовольны: релизы часто задерживались на несколько месяцев, имели пугающее количество ошибок и не содержали ожидаемых функций.