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

Для более глубокого понимания скрама на сессии обучения и сертификации используются командные упражнения, основанные на кейсах – реальных или адаптированных ситуациях из опыта организаций. Один из таких кейсов описывает гипотетический запуск сайта Высшей лиги бейсбола (Major League Baseball, MLB). Мы рассмотрим его в следующих разделах этой главы. В одном из упражнений участники группы проверяют, могут ли они участвовать в осмысленном диалоге с по-настоящему жестким клиентом по имени Джордж Штайнбреннер. Им предстоит обсудить с ним несколько трудных решений. Типичные результаты команд представлены в конце кейса.

За последние 10 лет суммарная посещаемость бейсбольных матчей увеличилась. В некоторых городах, например в Бостоне, почти все билеты распроданы и достать их по обычным каналам распространения практически невозможно. Спекуляция билетами запрещена правилами MLB и законом и основным каналом сбыта является сайт онлайн-аукциона xAuction. Несмотря на то что цены билетов на xAuction должны быть ограничены розничной ценой с прибавлением расходов, лига MLB узнала, что благодаря множеству обходных путей билеты перепродаются по цене до 1000 % от розничной.

Руководство лиги MLB наняло внешнюю консалтинговую организацию Denture для планирования проекта по управлению перепродажей билетов на бейсбол. Итоговый план был представлен компанией Denture 15 ноября и вскоре одобрен лигой. Выдержки из этого плана приведены далее.

Согласно новому законодательству, в бейсбольном сезоне 2004 года все перепродажи билетов должны происходить через уполномоченный лигой MLB механизм – интернет-сайт MLBTix. Функционал подобен онлайн-аукциону xAuction, с возможностью покупать и продавать билеты MLB онлайн и некоторыми специфическими для MLB особенностями. Продавцы могут продавать билеты по самой высокой цене, установив первоначальную цену торгов по своему усмотрению без нижних или верхних границ со стороны MLBTix. Также продавцы могут ограничить продолжительность аукциона, установив даты и время начала и окончания. После того как продавец выбрал покупателя, последний оплачивает билеты кредитной картой через онлайн-кассу MLBTix, а продавец отправляет покупателю билеты по почте. Продавцы получают автоматические уведомления о получении билетов покупателями. После этого MLBTix отправляет продавцу чек на получение стоимости проданных билетов за вычетом 25 %-ной комиссии лиги MLB.

Лига планирует анонсировать MLBTix на пресс-конференции 15 января. Руководство надеется, что функциональность будет частично доступна ко дню открытия сайта 30 марта 2004 года, а полностью – к ежегодной летней игре звездных игроков двух лиг бейсбола, знаменующей середину сезона, которая состоится 18 июля 2004 года. Поэтому 30 марта 2004 года – дата релиза. 30 марта сайт MLBTix должен быть запущен, покупатели и продавцы могут зарегистрироваться. Продавцы могут выставлять билеты по фиксированной цене, а покупатели – оплачивать в полном объеме с помощью кредитной карты. MLBTix – посредник в сделке, и все билеты будут передавать непосредственно от продавцов покупателям. Уже 30 июня на сайт должна быть добавлена возможность аукциона. Наконец, с 30 августа покупатели могут приобретать комплекты билетов на расположенные рядом места, просматривать размещение мест и уточнять доступный остаток.

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

Функциональные требования к MLBTix:

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

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

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

■ клиенты могут размещать билеты на аукционе, объявляя нижний порог цены, дату/время начала и окончания аукциона. Должна быть предоставлена достаточная информация, чтобы покупатели могли убедиться, что билеты соответствуют их требованиям (на правильные даты, на правильные команды, правильное количество мест с номерами, и расположение по секторам на стадионе);

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

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

■ MLBTix уведомляет продавца об успешной продаже билетов и предоставляет информацию об успешной доставке покупателю;

■ MLBTix предоставляет покупателю механизм указания того, что билеты не были получены в указанный срок с даты продажи (например, плюс одна неделя);

■ в случае успешного получения билетов покупателем и если он не указал иное, MLBTix перечисляет продавцу денежные средства в размере стоимости билетов за вычетом 25 %;

■ MLBTix автоматически перечисляет 25 % плюс любую комиссию со своего счета на расчетный счет MLB;

■ MLBTix предоставляет клиентам возможность просматривать остатки и искать билеты по командам, датам и местам;

■ MLBTix предоставляет возможность рекламных акций на сайте;

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

Нефункциональные требования к MLBTix:

■ обработка 250 000 одновременных пользователей со временем отклика менее секунды;

■ обеспечение безопасности при ожидаемом уровне финансовой активности (2000 билетов в день при средней цене продажи $50 США);

■ возможность масштабирования до 1 000 000 одновременных пользователей при необходимости;

■ доступность сайта 99 % в течение 24 часов в сутки 7 дней в неделю.

Вот контекст разработки для участников торгов. Система будет разработана в среде с открытым исходным кодом, с использованием технологий и программного обеспечения Intel, работающих на сервере базы данных OpenSQL. В среде разработки используются инструменты с открытым исходным кодом, например Eclipse. Участники группы разработчиков будут работать в пределах легкой досягаемости, планировка помещения свободная. Среда разработки беспроводная, уже обеспечена электропитанием и сетевым доступом. Команда разработки должна использовать репозиторий исходного кода, проверять код после каждого изменения, собирать дистрибутив как минимум ежедневно, при каждой сборке проводить модульное и приемочное тестирование программного обеспечения. В качестве процесса разработки будет использоваться скрам. Использование стандартов кодирования и любых других инженерных практик, например из экстремального программирования (Extreme Programming), остается на усмотрение команды. Все разработчики команды должны обладать отличными инженерными навыками и быть хотя бы знакомыми со скрамом и экстремальным программированием. Команда должна состоять из инженеров-разработчиков с превосходными навыками проектирования и написания кода. Инженеры отвечают за все тестирование и пользовательскую документацию, однако могут нанимать подрядчиков в помощь. Инженеры команды должны в среднем иметь 10 лет передового опыта в проектах разработки систем с использованием комплексных технологий и программных продуктов с открытым исходным кодом. Все участники команды разработки должны быть поклонниками бейсбола.

Представьте себе, что в своей конкурсной заявке вы заверили лигу бейсбола, что сможете соответствовать расписанию релизов, и почти сразу руководство MLB выбрало для разработки сайта MLBTix именно вашу организацию. Первый спринт начался 7 декабря 2003 года, а через месяц, 7 января 2004 года, состоялся обзор спринта. На пресс-конференции 15 января лига анонсировала сайт MLBTix. Вы присутствовали там и продемонстрировали функциональность, реализованную за первый спринт.

Еще через два месяца, 7 марта 2004 года, ваша команда закончила третий спринт и продемонстрировала разработанную за него функциональность руководству MLB. Все необходимые для первого релиза функции успешно реализованы. Вы намерены развернуть систему MLBTix в промышленной среде до 30 марта – к началу бейсбольного сезона MLB 2004, как и было запланировано.

Во время события планирования четвертого спринта вы и команда обеспокоены способностью MLBTix обрабатывать потенциальный объем посетителей и запросов. Для продвижения MLBTix на рынке лига наняла рекламное агентство, которое отработало слишком хорошо: MLBTix был на каждой спортивной странице в интернете и в каждом спортивном журнале. Каждый любитель бейсбола знал, что аукцион MLBTix начнет работу 30 марта 2004 года в 12:00 по восточному времени. Вы знаете, что поклонников более 40 млн, а система не может обрабатывать 40 млн одновременных обращений.

Вы предоставляете руководству лиги справочную информацию, приведенную далее. Команда связалась с несколькими розничными интернет-магазинами и выяснила, что каждой продаже предшествует в среднем 100 посещений. Команда не может оценить точное количество обращений в первое время после запуска сайта, но обеспокоена тем, что оно превышает пропускную способность системы. Исследование лиги MLB указывает на то, что сайт, скорее всего, будет продавать 2000 билетов в день в апреле 2004 года и 5000 в день в последующие месяцы сезона. Вы уже предупреждали лигу бейсбола о том, что рекомендованная к использованию консалтинговой компанией Denture технология базы данных ненадежна, а тесты показали, что база данных приложения будет нагружена. Даже при всех усилиях консультантов по настройке и запуску OpenSQL на самых быстрых массивах дисков, максимальное количество одновременных транзакций со временем отклика менее трех секунд составляет 100 операций. Ожидается, что нагрузка будет расти во время обеда и после ужина. Команда обеспокоена тем, что пиковые объемы могут перегружать сервер и что кривая роста производительности будет очень близка к 110 транзакциям в секунду. Вы выяснили, что база данных Miracle будет легко поддерживать требования к масштабированию, предъявленные руководством MLB, но потребуется еще один спринт, чтобы выторговать замену OpenSQL и на Miracle. Результат? Приложение будет готово только через месяц после открытия сезона.

Вы все это говорите менеджменту лиги и замечаете, что руководитель начинает все больше беспокоиться: постукивает ногами, плюется на пол и бубнит ругательства себе под нос – кажется, он очень недоволен. Он просит вас опустить все эти технические детали и сказать ему, что нужно сделать. Интересуется, пора ли ему звонить в рекламное агентство и сообщать, что он хочет объявить о недоступности аукциона MLBTix к 30 марта. Учитывая упомянутые риски, механизм вознаграждения и личные инстинкты, что вы должны посоветовать руководителю лиги?

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

Команда 1 говорит руководителю лиги, что проблема в масштабируемости. Из-за его агрессивной рекламной кампании инфраструктуре MLBTix придется обрабатывать больше транзакций, чем первоначально предполагалось. Команде велено использовать базу OpenSQL, которая просто не масштабируется до такого объема. В результате команда предлагает произвести замену OpenSQL на базу данных Miracle. Работа начнется сразу же, и, как только выяснится, займет она один или два месяца, руководство будет незамедлительно проинформировано о сроке. Тем временем команда советует комиссару отложить MLBTix на неопределенный срок – по крайней мере до поры, пока проблема масштабируемости не будет решена.

Ответ руководителя лиги: «Из сказанного вами я не понял ни слова, кроме того, что подвергнусь публичному унижению. Я уже объявил всем, что сайт будет доступен 30 марта, а вы не только говорите мне, что это не случится к указанной дате, но и не можете сказать точно, когда он будет. Если бы агент Дерека Джитера попробовал такое, ему пришлось бы иметь дело с моим руководством».

Команда 2 предлагает руководителю лиги ни о чем не беспокоиться. Участники команды очень рады, что MLBTix добился такого успеха, и уверены, что рекомендованная Denture технология будет работать прекрасно, иначе компания не стала бы ее рекомендовать.

Ответ руководителя лиги: «Вы хотите меня успокоить, я понял. Но я также заметил, что вы будете готовы покинуть корабль, обвиняя Denture, если технология не сработает. Мне нужен совет, а не обходительная формулировка».

Команда 3 предлагает руководителю лиги подход, позволяющий обслужить любое количество посетителей MLBTix. Если на стадионе Yankee не будет достаточного количества открытых касс, образуются длинные очереди болельщиков. Поэтому команда реализует функцию, которая будет выводить посетителям сообщение: «Ввиду повышенного спроса на билеты просим вас подождать». Затем каждые 30 секунд будет выводиться сообщение: «Пожалуйста, оставайтесь в очереди. Ваш запрос важен, и мы хотим вам помочь». Команда считает, что при таком подходе MLBTix может обслуживать любое количество клиентов без каких-либо дополнительных затрат.

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

Команда 4 считает, что успех рекламной кампании повлек дополнительную работу для команды разработки. Выводить сайт в текущем состоянии рискованно – работать он, может, и будет, но первые несколько дней его функционирования будут плачевными. Команда подготовила несколько вариантов. Первый вариант – уже на следующей неделе позволить людям начать использовать сайт MLBTix для регистрации и посмотреть, что будет происходить. До 30 марта клиенты не смогут покупать и продавать билеты, но возможность зарегистрироваться и посетить сайт уже сейчас может снизить нагрузку в день открытия. Конечно, по-прежнему останется риск возникновения проблем, которые невозможно рассчитать количественно. Однако этот вариант не требует никаких дополнительных затрат. Второй вариант – усилить текущие аппаратные мощности системы для команд с самым высоким ожидаемым объемом обращений: Yankees, Red Sox, Mariners, Braves и Giants. Это аналогично открытию дополнительных касс по продаже билетов. Этот вариант обойдется в $3,4 млн и позволит сайту MLBTix выйти по графику с минимальным риском. Третий вариант – отложить релиз MLBTix на месяц, чтобы улучшить систему для обработки большего, чем ожидалось, объема клиентов. Стоимость этого варианта составляет $1,1 млн за дополнительный месяц работы и $425 000 в виде упущенной выгоды лиги MLB от 25 %-ной комиссии.

Ответ руководителя лиги: «Я понимаю. Вы четко изложили альтернативы, и их нетрудно сравнить, потому что вы очень понятно все объяснили. Хм. С одной стороны имеем непредсказуемый риск потерять все, с другой – можем потратить $3,4 млн, чтобы продолжить работать по плану и свести риск к минимуму, а с третьей стороны – заплатить $1,525 млн, испытать смущение и стыд за месячное опоздание, но решить проблему наверняка. Мы не оценили, сколько клиентов мы потеряем, опоздав на месяц, но это не должно стать слишком большой проблемой, поскольку мы – монополисты. Куда еще могут пойти клиенты? Значит, мне следует решить, стоит ли моя гордость около $1,9 млн. Я горд, но не глуп. Действуем по третьему варианту!»

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

Вспомните о проекте приложения для денежных переводов MegaBank. Когда менеджер по разработке заподозрил, что проект займет больше времени, чем он пообещал своему руководству, он поручил команде сделать все необходимое, чтобы успеть к назначенной дате. Будь у него адекватные количественные данные, он мог бы сравнить затраты на повышение качества системы в течение дополнительных двух месяцев с расходами на поддержание некачественно реализованной и запутанной системы в течение ее жизненного цикла. Он решил больше тратить на дальнейшее обслуживание, хотя и не знал, насколько дорогим окажется его выбор. Как сказал мне участник команды: «Несмотря на использование нами скрама, мы работаем так же, как раньше».

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

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