Скрам - Кен Швабер

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

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

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

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

Скрам доказывает свою ценность успехом проектов. Однако предлагает подход, который радикально отличается от традиционного управления проектами: ожидание перемен и приветствие изменений вместо избегания их. Адаптация – естественная часть проекта, а вовсе не исключение из правил. Когда эти концепции обсуждаются теоретически, большинство людей соглашаются с обоснованностью подхода, но, когда мы предлагаем использовать эти концепции в очень важном проекте, руководство действует крайне осторожно. Менеджеры хотят знать, чем этот подход лучше. Они спрашивают, насколько он рискованный и не приведет ли такое количество изменений к катастрофе. В рассмотренной ситуации Рут доказала ценность нового подхода, представив его на языке инвесторов проекта. Она продемонстрировала преимущества и ценность скрама руководителям, не обучая их концепциям и теории аджайловых процессов. В результате у руководства сложилось положительное отношение к скраму. Как сказал генеральный директор другой компании во время обзора спринта: «Я не знаю, что такое скрам, но он мне нравится». Пусть так и будет.

С 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. Архитектуру разделили на слои и сервисы: представление, приложение и данные. Затем команда назначила цвета этапам проекта. К финальным датам каждого этапа руководство ожидало определенных возможностей продукта. Позднее они были синхронизированы с датами обзоров спринтов. Первый этап – синий цвет, второй – зеленый. Перед началом работы над сервисом команда окрашивала его в светлый оттенок цвета, а после завершения заменяла на темный.