С MegaBank мы знакомились в пятой и шестой главах. Дочерняя организация MegaBank Information Technology (MBIT) – управляет всеми операциями, технологиями и инфраструктурой MegaBank. Банки компании разрабатывают программное обеспечение для себя и своих клиентов, и каждый из них обязан следовать решениям и стандартам MBIT.

MBIT – это технологический мозговой центр для MegaBank, под его руководством исследуются и вводятся в обращение биометрия и другие передовые технологии. С конца 1990-х годов для хранения, публикации и размещения чатов групп по изучению новых технологий MBIT использовала сайт MBITWeb. Он был неудобным, пользователи часто жаловались на него, поэтому использовали редко. Для решения этих проблем MBIT профинансировала проект модернизации сайта. В качестве процесса разработки был выбран скрам, потому что некоторые банки его уже успешно использовали и MBIT хотела разобраться в деталях. Разработчики одного из банков MegaBank и технологи MBIT вошли в состав объединенной команды. В роли скрам-мастера к ним присоединился уже использовавший скрам сотрудник MegaBank Том, а в роли владельца продукта – менеджер MBIT Энди.

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

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

Хелен встретилась с Томом и Энди и рассказала им, что Джим недоволен текущими отчетами – они не удовлетворили его техническое любопытство о деталях разработки. Кроме того, Джим работал в интеллектуально агрессивной организации: в MBIT каждый мог расспросить вас о текущих проектах, поэтому ожидалось, что все подробности всегда под рукой. Если Джим не разберется, что происходит в его проекте, он не сможет ответить на эти вопросы и будет в слабой позиции.

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

Хелен, Джим и Энди рассказали об этой проблеме команде. Упростив схему технологической архитектуры системы, размещенную на стене в комнате команды разработки, они вместе разработали вариант для демонстрации менеджменту. Он изображен на рис. 7.5. Архитектуру разделили на слои и сервисы: представление, приложение и данные. Затем команда назначила цвета этапам проекта. К финальным датам каждого этапа руководство ожидало определенных возможностей продукта. Позднее они были синхронизированы с датами обзоров спринтов. Первый этап – синий цвет, второй – зеленый. Перед началом работы над сервисом команда окрашивала его в светлый оттенок цвета, а после завершения заменяла на темный.

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

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

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

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