Читать онлайн Скрам. Гибкое управление продуктом и бизнесом бесплатно

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

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

Эта книга – именно об этом невероятно трудном процессе создания программного обеспечения. В этой главе я кратко расскажу о скраме – фреймворке, который повышает вероятность успеха разработки ПО. Он специально создан для того, чтобы добывать полезные программные продукты из комплексных проблем. За последние 10 лет скрам успешно использовался в тысячах проектов сотен организаций. Он основан на теории управления производственными процессами, в которой используются такие концепции, как самоорганизация и эмергентность[4].

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

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

Эмпирический процесс управления

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

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

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

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

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

Бабатунде Огуннайке и Хармон Рэй. Динамика, моделирование и управление процессами (Process Dynamics, Modeling, and Control)[5]

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

Любое внедрение управления эмпирическим процессом основывается на трех китах: прозрачность, инспекция и адаптация. Прозрачность означает, что характеристики процесса, влияющие на результат, должны быть видны и известны тем, кто этот процесс контролирует. Одинаково важно и то, чтобы эти характеристики были видны, и то, чтобы они были правдивы. При управлении эмпирическим процессом нет места обману. Например, если кто-то говорит, что конкретная функциональность отмечена как «готовая», что имеется в виду? В сфере разработки ПО утверждение о готовности функциональности может подразумевать выполнение всех следующих условий: аккуратно написан программный код, произведен рефакторинг, протестированы отдельные компоненты, собран дистрибутив для установки, произведена приемка пользователями. При этом кто-то другой может подразумевать, что программный код был только написан, протестирован и собран в дистрибутив. Если нет единого понимания того, что означает слово «готово», то и от наличия информации о «готовности» конкретной функциональности пользы мало.

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

Третий кит управления эмпирическим процессом – адаптация. Если в ходе проверки инспектор выявляет, что одна или несколько характеристик процесса выходят за допустимые пределы значений и полученный продукт будет неприемлемым, то инспектор корректирует процесс или используемое сырье. Корректировка должна быть произведена как можно быстрее, чтобы свести к минимуму дальнейшее отклонение.

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

Разработка комплексного программного обеспечения

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

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

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

На рис. 1.1 вертикальная ось показывает комплексность требований, а горизонтальная – комплексность технологии. Пересечение этих двух видов комплексности определяет общий уровень комплексности проекта. Почти все проекты разработки программного обеспечения сегодня – комплексные. А некоторые даже хаотичны, но в них невозможно работать, пока часть сложностей не будет устранена.

Третье измерение комплексности – люди, разрабатывающие программное обеспечение. У всех разные интеллектуальные способности, навыки, опыт, точки зрения, взгляды, убеждения и предрассудки. В зависимости от качества и количества сна, состояния здоровья, погоды, соседей и отношений в семье каждый человек каждое утро просыпается в настроении, непохожем на вчерашнее. Затем эти разные и переменчивые люди начинают работать вместе, и уровень комплексности зашкаливает. Принимая во внимание третье измерение комплексности – людей – в дополнение к технологиям и требованиям, я считаю, что последний «простой» проект случился в 1969 году, когда один человек из отдела обработки заказов в Sears Roebuck попросил меня отсортировать несколько карточек и создать отчет на IBM 360/20. С тех пор все становится более беспорядочным. Скрам помогает решать проблему комплексности проектов разработки программного обеспечения с помощью эмпирического процесса, включая обязательные требования его прозрачности, инспекции и адаптации, а также с помощью набора простых практик и правил, которые описаны в следующих разделах.

Скелет и сердце скрама

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

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

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

Реализовать этот скелет итеративно-инкрементального процесса в скраме позволяют три роли. В следующих разделах я дам краткий обзор этих ролей, а затем опишу процесс скрама и его артефакты. Приложение A содержит список событий и правил, а Приложение Б – определения терминов скрама. Более подробную информацию о скраме можно найти в Приложении В «Ресурсы», а также в книге «Гибкое управление разработкой ПО по скраму» (Agile Software Development with Scrum).

Роли скрама

В скраме есть только три роли: владелец продукта, команда разработки и скрам-мастер. Вся ответственность в части управления проектом разделена между этими ролями. Владелец продукта отвечает за представление интересов всех лиц, заинтересованных в проекте, в создаваемой программной системе. Чтобы добиться и затем получать регулярное финансирование проекта, владелец продукта описывает первоначальные общие требования проекта, определяет цели по возврату инвестиций (ROI) и поддерживает план релизов в актуальном состоянии. Список требований называется бэклогом продукта. Владелец продукта несет ответственность за поставку заинтересованным лицам максимальной ценности: гарантирует, что наиболее ценная функциональность будет реализована в первую очередь. Это достигается за счет регулярного пересмотра порядка задач в бэклоге так, чтобы в следующую итерацию были взяты самые ценные требования.

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

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

Люди, выполняющие эти роли, должны быть преданы проекту. Остальные тоже могут быть заинтересованы в проекте, но они «не на крючке». Скрам четко различает эти две группы и гарантирует, что те, кто несет ответственность за проект, имеют полномочия делать все необходимое для его успеха, а те, кто не несет такой ответственности, не могут вмешиваться в работу первых. В этой книге я называю эти группы людей «цыплятами» и «поросятами» соответственно. Названия пришли из старого анекдота. Цыпленок и поросенок идут по дороге. Цыпленок говорит поросенку: «Хочешь открыть вместе со мной ресторан?» Поросенок поразмыслил и отвечает: «Да, пожалуй. Как ты хотел бы назвать его?» «Яичница с беконом!» – отвечает цыпленок. Поросенок останавливается и, вздохнув, отвечает: «Знаешь, я передумал. Я не хочу открывать такой ресторан с тобой, потому что мне придется отдать себя проекту целиком, а тебе – лишь поучаствовать!»

Это важное различие, поэтому скрам так настойчив в требовании полной прозрачности: всегда должно быть понятно, кто на крючке, а кто просто назойливый советчик. Кто несет ответственность за возврат инвестиций, а кто имеет долю в ROI, но не отвечает за него. Кому придется превратить новую технологию в функциональность, а кто – лишь беспокойный «адвокат дьявола». Скрам проводит явную черту между цыплятами и поросятами, чтобы положить конец неразберихе, и тем самым повышает производительность и создает продуктивный импульс.

Процесс скрама

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

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

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

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

1. Что я сделал с момента окончания предыдущего ежедневного скрама, чтобы помочь команде достичь цели спринта?

2. Что я планирую сделать до следующего ежедневного скрама, чтобы помочь команде достичь цели спринта?

3. Какие препятствия могут помешать мне и команде достичь цели спринта?

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

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

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

Артефакты скрама

Используемые в скраме артефакты описаны в следующих разделах.

Бэклог продукта

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

Эта таблица – бэклог «Система управления продуктом в скраме» по состоянию на март 2003 года. Я был владельцем этого продукта. Строки таблицы – элементы бэклога. Они разделены подзаголовками «Спринт» и «Релиз». Например, все строки выше «Спринта 1» представляют собой задачи, реализованные в первом спринте, а строки между подзаголовками «Спринт 1» и «Спринт 2» были реализованы во втором спринте. Обратите внимание, что строка «Отобразить древовидную структуру бэклога продукта, релизов, спринтов» дублируется в спринтах 1 и 2. Это потому, что задача в строке 10 не была завершена в спринте 1 и была перенесена в спринт 2. Если бы после завершения первого спринта я решил, что ценность этого требования ниже ценности задач второго, третьего или других спринтов, то я мог бы переместить эту строку еще ниже в списке задач.

Рассмотрим столбцы таблицы с бэклогом продукта:

1. Описание элемента бэклога продукта;

2. Начальная оценка;

3. Коэффициент сложности. Некоторые особенности проекта снижают производительность команды. Этот коэффициент позволяет учесть это в оценке;

4. Скорректированная оценка, получаемая применением коэффициента сложности к начальной оценке;

5. Остальные столбцы представляют спринты, в течение которых реализуются требования бэклога продукта. Добавляя новый элемент в бэклог, мы указывали начальную оценку в столбец текущего спринта. Пример применения этого правила вы можете увидеть только в строке «Возможность публикации всего проекта, публикация в виде веб-страниц HTML», об этой задаче мы не задумывались до третьего спринта, а остальные элементы этого бэклога я и разработчики создали еще до начала первого спринта проекта.

График сгорания показывает объем работы, оставшийся к определенному моменту времени. Он изображен на рис. 1.5. Это отличный способ увидеть корреляцию между объемом оставшейся работы и прогрессом команды (или нескольких команд) проекта в сокращении этого объема. Пересечение линии тренда оставшейся работы и горизонтальной оси показывает наиболее вероятное на текущий момент время завершения работы. Это позволяет понять, «что будет, если» мы, желая получить больше функциональности, добавим в релиз дополнительные элементы, или «что будет, если» мы, стремясь выпустить функциональность раньше, уберем часть элементов бэклога из релиза. График сгорания – это столкновение реальности с планом: того, что уже сделано и за какое время, с тем, что мы надеемся сделать.

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

Бэклог спринта

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

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

Потенциально готовый к поставке инкремент продукта

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

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

■ быть тщательно протестирована;

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

Перечисленные требования – определение «готового» инкремента продукта.

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

Резюме

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

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

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

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

Скрам-мастер в MetaEco

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

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

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

Ситуация в MetaEco

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

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

Скрам-мастер в действии

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

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

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

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

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

Пол был связан. С одной стороны, он не хотел упускать ни единой возможности привлечь новых клиентов, а с другой – не хотел навредить проекту новостной службы. Том сочувствовал Полу, но также и понимал, что, если не будет твердо стоять на своем и придерживаться правил скрама, ничего не получится. Наконец Пол сказал: «Ладно! Хотя мне и не нравятся правила скрама, я их знаю, понимаю и буду им следовать. Но будь готов к крутым поворотам на планировании спринта!»

Ценность скрам-мастера

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

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

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

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

Владелец продукта в MegaEnergy

Главная цель владельца продукта – возврат инвестиций (ROI). Бэклог продукта отлично помогает ему управлять проектом и спринт за спринтом направлять команду разработки к созданию наибольшей ценности для повышения рентабельности продукта. Бэклог продукта позволяет владельцу продукта:

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

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

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

Ситуация в MegaEnergy

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

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

Компания уже предприняла две попытки автоматизировать процесс, и обе потерпели неудачу. Эти попытки были названы проектом «Участок». Поскольку в каждом штате и провинции свои процедуры, процессы и способы передачи информации о собственности на землю, у отдела учета земельных участков в MegaEnergy возникли проблемы с определением единого способа получения и обработки информации от различных правительственных учреждений. Руководство MegaEnergy решило объединить проект автоматизации с проектом по переносу данных по земельным участкам с мейнфреймов на менее дорогие серверы.

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

Владелец продукта в действии

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

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

На планировании спринта Джейн представила бэклог продукта команде. Просматривая его, команда увидела возможность оптимизации процесса и автоматизации некоторых этапов. База данных MegaEnergy содержала информацию обо всех земельных участках, по которым необходимо производить выплаты. Из Альберты можно было получить данные по изменениям прав собственности за последние 12 месяцев. Затем для каждого соответствия между полученными и имеющимися в базе данными можно было создать транзакции, которые проверит и подтвердит аналитик отдела учета земельных участков MegaEnergy и, в случае необходимости, обновит базу данных. Аналитику больше не придется проверять имя и адрес каждого отдельного участка. Автоматизация получения данных и экраны для их сверки с существующими помогли бы значительно сократить объем работы.

Команда была довольна этой находкой, ведь теперь она сможет, во-первых, доработать структуру базы данных по участкам для соответствия новым требованиям, во-вторых, изучить и проверить новые серверные технологии и, в-третьих, реализовать унифицированный формат обмена данными в формате XML[8], который отдел учета земельных участков сможет использовать при взаимодействии с каждым госорганом.

Через тридцать дней на первом обзоре спринта команда разработки представила созданный инкремент продукта. Все это время Джейн работала вместе с командой и уже знала, что будет продемонстрировано, но тем не менее осталась в восторге.

Она попросила меня объяснить, что значат мои слова: «Продемонстрированная на обзоре спринта функциональность должна быть потенциально готова к поставке и использованию». Я ответил, что на следующем планировании спринта она может попросить команду разработки поставить этот инкремент пользователям. Джейн решила воспользоваться этой возможностью и провела внеочередной двухнедельный спринт поставки. Поскольку большинство трубопроводов MegaEnergy проходили через Альберту, созданная за этот спринт и предоставленная функциональность уменьшила нагрузку сотрудников отдела учета земельных участков более чем на 40 %.

Ценность владельца продукта

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

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

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

Команда разработки в Service1st

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

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

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

Ситуация в Service1st

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

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

Команда разработки в действии

Я провел с командой упражнение «Быстрый старт». Это интенсивная двухдневная сессия, в которой участники изучают практики скрама и готовятся к запуску своего первого спринта. Учебная часть сессии прошла хорошо, но, когда я добрался до первой части планирования спринта, все начало рассыпаться. Комната была переполнена: 17 участников команды разработки плотно расположились вокруг небольшого стола, а заинтересованные лица сформировали кольцо за ними. Более активные участники команды расспрашивали и общались с владельцем продукта, а более пассивные – выпали из процесса. К началу второй части планирования спринта, когда команда разработки определяет свой бэклог спринта, по-прежнему участвовали только самые бойкие. Прерывая их, я несколько раз старался вовлечь молчунов и спрашивал, над чем они будут работать. Я уточнил, понимают ли они, что нет ничего хуже, чем во время ежедневного скрама сознаваться, что они ничего не делали и вообще не сильно вовлечены в проект. Имея благие намерения, этим своим замечанием я добился лишь того, что пассивным участникам стало только хуже.

Команда разработки была слишком большой, поэтому вовлечь всех не удалось. Оптимальный размер команды – от трех до девяти человек, чтобы во время планирования спринта они могли общаться, глядя друг другу в глаза, взаимодействовать и формировать общий план действий. Команда из 17 человек сделала фактически то же самое: 7 активных участников планировали спринт, а 10 пассивных сотрудников не участвовали в процессе. Что мог сделать я? Понимая, что пересобирать команду уже поздно, я решил оставить все как есть и посмотреть, что произойдет. Несколько дней спустя я присутствовал на ежедневном скраме этой команды разработки. К моему большому удивлению, о выполненной и планируемой работе рассказывали все. Конечно, с таким количеством людей ежедневный скрам длился 20 минут вместо 15, но это была активная, оживленная сессия, и все участники команды, казалось, были увлечены работой. После встречи они поделились со мной своими соображениями. Они решили, что менеджмент сформировал такую большую команду разработки по ошибке, однако не хотели перечить ему, полагая, что мудрое руководство знает о причинах, по которым команда должна быть настолько многочисленной. Но большая команда разработки не функционировала – прогресса в работе над задачами спринта почти не было. Команда решила разделиться на четыре подгруппы численностью от трех до пяти участников каждая. Руководители программистов и тестировщиков помогли сформировать эти подгруппы и разделить работу так, чтобы сложносоставные задачи выполнялись внутри подгрупп, а коммуникации между ними свелись к минимуму. Также они взяли на себя ответственность за устранение зависимостей, возникающих между участниками команды в ходе работы. Эти руководители были частью команды разработки, они были преданы работе и общей цели, поэтому их действия являлись проявлением самоорганизации.

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

Ценность команды разработки

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

Выводы

В MetaEco в роли скрам-мастера Том защищал производительность команды разработки и помогал ей выполнять прогнозы. В MetaEnergy Джейн оптимизировала приносимую проектом ценность, выполняя обязанности владельца продукта. В Service1st команда разработки путем формирования подгрупп проявила свою способность к самоорганизации, которая помогла им достичь цели спринта. Действия каждой роли требовали смекалки и инициативы, они были критичны для успеха проекта.

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

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

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

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

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

По мере распространения скрама я стал больше беспокоиться о наличии достаточного количества квалифицированных скрам-мастеров. Недавно мне позвонил руководитель команды, которая разрабатывает полупроводники для крупной компании в Техасе. Он хотел узнать больше обо «всем этом скраме». Я уточнил, чем вызван его интерес, и получил ответ, что четыре месяца назад менеджер команды проектирования в Германии позвонил и сказал: «Мы стали применять скрам для управления нашим процессом проектирования, поэтому не ждите от нас привычных отчетов», – а вчера он же сообщил, что команда проектировщиков отстала от графика на три недели. Техасский руководитель хотел понять: «Это и есть скрам?»

Такие звонки мне очень знакомы. Недавно я столкнулся с похожим случаем на конференции: менеджер из Бразилии рассказал, что использует скрам уже более полугода. Когда он прослушал один из докладов, ему очень понравилась идея ежедневного скрама. Он считал, что внедрение таких ежедневных встреч значительно поможет коммуникациям внутри команды. Я не мог поверить, что он читал о скраме, применял его и до этого доклада не понимал, насколько критично это событие для социализации и синхронизации.

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

Давайте рассмотрим другие примеры реальных ситуаций, с которыми сталкивались скрам-мастера с разным опытом работы. Они покажут, насколько важно иметь в команде высококвалифицированного скрам-мастера.

Необученный скрам-мастер в Trey Research

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

Зачастую люди нанимают консультантов, чтобы получить другую точку зрения на свою ситуацию. Этот свежий взгляд часто кажется более правильным, чем мнение, которое сложилось внутри компании. По-моему, такого объяснения вполне достаточно, чтобы клиенты дважды подумали, выбирая между местным и внешним консультантами. Представьте, как я был удивлен, когда мне позвонил представитель фирмы, расположенной в городе, где я и моя семья проживали последние 23 года.

Стартап-компания Trey Research приобретала тканевые культуры у организаций здравоохранения и перепродавала их фармацевтическим компаниям. Перед продажей культур фирма добавляла ценность продукту: производила инвентаризацию и для каждого образца определяла место происхождения, заболевание и его стадии. Перегруженный новыми программными системами, которые необходимо было создать и запустить, ИТ-директор внедрил скрам. Он хотел получить мою оценку применения скрама в его компании и предложения по улучшению.

Что было не так

В начале визита я встретился с командой руководителей, подчинявшихся ИТ-директору, и кратко рассказал им о скраме. Затем мы обсудили текущие проекты в Trey Research и то, как фирма использует скрам. Каждая команда уже завершила по несколько спринтов, и все были довольны результатами изменений и достигнутым прогрессом.

Самый опытный скрам-мастер компании пригласил меня посетить «его ежедневный скрам». В моей голове тут же раздался первый тревожный звонок. Почему это был «его ежедневный скрам», а не «ежедневный скрам команды»? Я решил придержать язык за зубами и искать ответ. Скрам-мастер привел меня в большую комнату в подвале старого особняка, который был штаб-квартирой Trey Research. Девять разработчиков трудились за компьютерами: пятеро располагались в центре и по паре на каждом конце комнаты. С точки зрения расположения рабочих мест все было хорошо: такая открытая рабочая зона обеспечивает быстрые коммуникации, что критично для успешной совместной деятельности.

Скрам-мастер начал ежедневный скрам, вытащив план работ. Зачитывая пункты списка, он ходил по комнате, спрашивая каждого присутствующего, выполнил ли он задачи, записанные напротив его имени. В частности, он задавал такие вопросы: «Мэри, ты закончила дизайн экрана, который я передал тебе вчера? Готова ли ты приступить к диалоговым окнам сегодня?» Дойдя до конца списка и поговорив с каждым в комнате, он спросил, нужна ли команде разработки его помощь. Участники команды молчали.

Я сомневался, надо ли сообщить ему, что думаю о его методах. Конечно, работа в моем родном городе была, безусловно, удобнее командировок. Но как он мог понять совершенно неправильно все, что я написал о скраме? Почему мне не удалось передать дух скрама? Он повернулся ко мне и гордо спросил, что я думаю. Сделав паузу, я похвалил его за открытое расположение в комнате, формирующее командный дух. Затем спросил, как он понимает, над чем работает команда разработки. Скрам-мастер начал объяснять, что знает это, потому что сотрудники работали над тем, что он им поручил, как вдруг в его взгляде проявились озарение и шок. Он осознал, что забыл применить один из ключевых элементов скрама.

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

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

1. Что я сделал с момента окончания предыдущего ежедневного скрама, чтобы помочь команде достичь цели спринта?

2. Что я планирую сделать до следующего ежедневного скрама, чтобы помочь команде достичь цели спринта?

3. Какие препятствия могут помешать мне и команде достичь цели спринта?

Однако он был давним практиком традиционных методов управления проектами, потратил годы на планирование задач и обеспечение их выполнения, поэтому интерпретировал прочитанное примерно так:

1. Он проверит, что участники команды выполнили его поручения, данные во время предыдущего ежедневного скрама.

2. Он скажет каждому участнику команды, что нужно сделать до следующего ежедневного скрама.

3. Он уточнит, может ли чем-то помочь команде, чтобы участники выполнили полученные задачи.

Чтобы сэкономить время, последний вопрос он задал всей команде разработки сразу.

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

Необученный скрам-мастер в Litware

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

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

Что было не так

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

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

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

Я рассказал о сложившейся ситуации вице-президенту по разработке. Понимая недопустимость поведения и отношения Джона, он предложил Эльзе выполнять роль скрам-мастера команды. Когда участники команды разработки пришли на планирование первого спринта, Эльза уже была их скрам-мастером. В отличие от Джона она заботилась о них, как заботится о своих подопечных хорошая пастушья собака.

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

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

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

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

Чрезмерное усердие в Contoso.com

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

Чтобы противостоять этой угрозе, Contoso учредила дочернюю интернет-компанию Contoso.com. Эта компания должна была предложить клиентам новый портал для пациентов, интегрированный с уже существующими системами Contoso. В короткие сроки были запущены несколько проектов, включая проекты по разработке, маркетингу и рекламе. Я был скрам-мастером нескольких из них. Целями проекта по рекламе были повышение осведомленности рынка о новой стратегии Contoso и привлечение нынешних и потенциальных клиентов к продуктам Contoso.com в качестве альтернативы сторонним интернет-компаниям.

Недостаточно просто быть правым

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

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

За день до встречи с аналитиками один из участников команды разработки сообщил о препятствии на ежедневном скраме. По выражению его лица можно было понять, что препятствие крупное: президент Contoso.com пригласила всех на обязательное выездное мероприятие. Явка обязательна, все остальные задачи – второстепенны. Я был настроен скептически. Что может быть важнее нашей цели спринта – презентовать Contoso.com в качестве жизнеспособной альтернативы новым интернет-компаниям? Команда помогла мне ответить на этот вопрос: президент была обеспокоена моральным состоянием в Contoso.com и организовала пикник, чтобы поднять боевой дух всех сотрудников.

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

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

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

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

Скрам-мастер балансирует на тонкой грани между желанием организации как можно быстрее производить изменения и ее скудной терпимостью к этим изменениям.

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

Волк в MegaFund

MegaFund – одна из крупнейших в мире компаний по управлению фондами: ее инновационные фонды привлекали инвесторов сильнее, чем фонды других организаций. Однако к 1997 году eTrade, Charles Schwab и другие финансовые компании произвели революцию в торговле акциями: у клиентов появилась возможность управлять своими счетами, покупать и продавать акции без участия и помощи профессиональных биржевых брокеров.

Интернет и мобильные технологии сделали возможным использование карманных персональных компьютеров, сотовых телефонов и интерактивных голосовых меню. К сожалению, MegaFund осталась в стороне. Ее технологическое подразделение было громоздким и неповоротливым. Вдобавок в течение предыдущего года внедрялся стандарт CMM[10] уровня 3, который при некорректном применении мог усугубить бюрократию в организации. Это и произошло в MegaFund: добиться чего-либо стало неимоверно тяжело.

Специалисты компании изучили новые технологии и начали проект, который позволил бы получить доступ к старым базам данных, где хранилась вся информация о счете клиента и торговых операциях. После нескольких провальных запусков руководство MegaFund решило сделать все правильно. Обычно, когда менеджеры говорят, что собираются «сделать проект правильно», этот проект постепенно умирает от микрокоординации и избыточного администрирования. С этим проектом случилось то же: через девять месяцев он застопорился на неугасающих спорах о том, какие технологии использовать. Операционной системой должна быть Microsoft Windows NT 4.0, Solaris или AIX? Должна ли MegaFund стандартизировать технологию Intel? Какие серверы более масштабируемы: Sun или IBM? Использовать технологию COM или CORBA? Споры внутри организации продолжались, а конкуренты шли вперед.

Чтобы сдвинуться с мертвой точки и заставить проект двигаться, MegaFund решил применить скрам. Менеджер проекта Терри Адамс обладал хорошей технической экспертизой и интуитивным пониманием своей новой роли скрам-мастера: во время ежедневного скрама он внимательно слушал каждого участника команды. Когда возникала проблема с оборудованием, Терри протягивал руку помощи. Когда не хватало знаний и навыков, он помогал получить помощь извне. Когда не проходили заказы на покупку, Терри помогал их ускорить. Он умел устранять препятствия, не нарываясь на неприятности и не ставя свою работу под угрозу.

Атака волка

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

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

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

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

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

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

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

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

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

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

Выводы

В Trey Research и Litware мы увидели, как нелегко бывает понять роль скрам-мастера, в Contoso.com – как скрам-мастер может нарваться на увольнение, а в MegaFund – как скрам-мастер одновременно и выполняет обязанности новой роли, и внедряет правила и практики скрама в организации. В каждой компании произошло что-то уникальное. Зная о практиках и правилах скрама, скрам-мастера по-разному реагировали на ситуации: в одних случаях реакция была подходящей для организации, в других – нет. В каждом случае скрам-мастер интерпретировал свои обязанности и цели по-своему, поэтому и результаты значительно отличались.

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

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

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

Обязанности скрам-мастера можно резюмировать следующим образом:

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

■ научить владельца продукта максимизировать рентабельность инвестиций (ROI) и достигать своих целей с помощью скрама;

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

■ повышать производительность команды разработки любыми способами;

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

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

Когда скрам-мастер выполняет эти обязанности, прогресс проекта обычно стабилен, а цель спринта достигается. Этих обязанностей достаточно, чтобы скрам-мастер был занят и у него не оставалось времени на поведение типичного босса. Обратное тоже верно: скрам-мастер, который ведет себя как менеджер проекта, скорее всего, не выполняет все свои обязанности скрам-мастера.

По моему опыту, некоторые люди интуитивно понимают роль скрам-мастера и ощущают себя в ней словно рыба в воде. Другим это понимание дается с трудом; обучаясь, они совершают неприятные ошибки. Но даже успешному скрам-мастеру требуется несколько спринтов, чтобы влиться в работу.

Когда я не знаю, чем могу помочь, я повторяю в уме фразу: «Скрам – искусство возможностей». Вместо того чтобы расстраиваться тому, что не удается или нельзя сделать, сосредоточьтесь на том, что можно сделать сейчас. Эта установка помогает направлять мои действия как в проектной деятельности, так и в повседневной жизни.

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

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

■ как ограничение по времени помогает постичь «искусство возможностей» и избежать перфекционизма;

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

■ как наделения полномочиями и самоорганизация помогают развить креативность и повысить удовлетворенность сотрудников.

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

Второй организацией будет издательство Tree Business Publishing, где инициатива по переносу печатных журналов в интернет совпала с несколькими другими крупными и запутанными проектами. В результате работа групп разработчиков была почти парализована, а сроки постоянно нарушались и переносились.

Третья фирма – научно-исследовательская организация Lapsec, которая проверяет реалистичность идей программных приложений для правительства США. После событий 11 сентября компании было поручено быстро разработать новую систему для анализа информации о потенциальных террористических угрозах. Этот проект требовал объединения нескольких технологий, включая одну новую и непроверенную. Она называлась «слияние данных» (data fusion) и представляла собой усовершенствованную форму глубинного анализа данных (data mining).

Ситуация в Service1st

Длительность цикла разработки новой версии программного обеспечения в Service1st составляла 12 месяцев. Последние два месяца каждого цикла всегда были похожи на тушение пожара. После каждого такого «выталкивания» нового релиза в боевую среду сотрудники были выжаты, а ПО оказывалось нестабильным. Чтобы избавиться от переработок и повысить качество релизов, руководство компании решило равномернее распределить интенсивность усилий по более короткому отрезку времени в шесть месяцев.

Вице-президент по разработке провел для меня экскурсию по рабочим местам программистов. Было тихо, спокойно и безлюдно: только каждый четвертый кабинет или сектор был кем-то занят. Сначала я подумал, что еще слишком рано и люди просто не приехали. Потом увидел, что уже 9:00 часов, и предположил, что недавно прошла волна увольнений и ряды поредели. Но нет, Service1st – успешная и растущая компания-разработчик, за 20 лет работы не было никаких сокращений персонала.

Вице-президент объяснил мне ситуацию: компания только что закончила шестимесячный цикл разработки, последний релиз вышел три недели назад, и персонал еще не восстановился после сверхусилий. Чтобы выпустить релиз вовремя, последние два месяца команды работали до позднего вечера и по выходным. Такой режим плохо сказывался не только на сотрудниках Service1st, но и на клиентах: из-за безумных темпов разработки последние версии каждого релиза были полны ошибок. Вице-президент сказал, что хочет внедрить скрам, чтобы впредь не вынуждать своих сотрудников идти на такие жертвы и повысить качество программного обеспечения Service1st.

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

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

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

У каждого сотрудника было много задач. Так почему же почти все подразделение в 9 утра еще не приступило к работе? Вице-президент отметил, что команды обычно не испытывали никакого давления в течение первых трех из шести месяцев цикла создания релиза и что участники принимались за разработку всерьез лишь в течение последних двух месяцев.

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

Следующий релиз был запланирован на 7 апреля, в марте должна была бы состояться демонстрация пользователям. Шел конец октября: сотрудники уже сосредоточились на предстоящих праздниках[12], постепенно восстанавливались после кризиса при завершении последнего релиза. В то же время менеджеры уже всерьез переживали, хотя шестимесячный цикл подготовки нового релиза начался всего три недели назад. Успеем ли вовремя? Неужели сотрудникам снова придется трудиться в поте лица, постоянно перерабатывая в течение последних двух месяцев? Несмотря на сокращение цикла с года до полугода, никто не заметил каких-либо существенных изменений, поэтому все ожидали худшего.

Применение скрама

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

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

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

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

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

1. Вход в систему для инициирования кредита;

2. Запуск процесса инициирования кредита;

3. Унифицированный внешний вид продукта;

4. Унифицированная для обоих продуктов безопасность;

5. Бесшовное и масштабируемое исполнение процесса.

После составления списка я объяснил команде разработки концепцию трассирующей пули, представленную Эндрю Хантом и Дэвидом Томасом в книге «Программист-прагматик. Путь от подмастерья к мастеру»[13]. Концепция заключается в следующем: стреляя из автоматического оружия в темноте, трудно поразить цель, но каждая 50-я пуля оставляет видимый след, его можно использовать для корректировки прицела. Я попросил команду создать трассирующую функциональность, проходящую через все слои системы, чтобы проложить и показать путь для всех других функций. Такую функциональность, чтобы вход в систему и бизнес-процесс инициирования кредита частично или целиком задействовали оба продукта и отвечали всем перечисленным в бэклоге нефункциональным требованиям.

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

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

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

Пример Service1st показывает, насколько бывает трудно в комплексном проекте выяснить все детали заранее. Взаимодействие двух продуктов было настолько сложным, комплексным и неопределенным, что задачи, запланированные менеджерами в начале цикла создания релиза, устаревали вскоре после их назначения исполнителям. Работа только началась, а проект почти сразу стал отставать от расписания.

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

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

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

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

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

Ситуация в издательстве Tree Business Publishing

Издательство Tree Business Publishing (Tree) – подразделение холдинга Tree Holdings, публикует профессиональные журналы в самых разных отраслях. Прошло почти 10 лет с тех пор, как Tree решило публиковать свои журналы не только в печатном виде, но и в интернете. Редакторы Tree распорядились как можно скорее опубликовать электронные версии, однако за два года в сети оказался только один журнал. Причиной промедления стало открытие, что веб-публикация не похожа на печатную. Прогресс застопорился, потому что Tree хотело предварительно получить ответы на ряд вопросов:

1. Как представить журнал эффективно и «вкусно» для онлайн-версии?

2. Как изменятся внутренние процессы редактуры и производства, когда журналы станут публиковаться и в печатном виде, и в интернете?

3. Какой наилучший механизм публикации контента в сети следует использовать?

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

В отчаянии менеджеры Tree искали способ ускорить доставку журналов в интернет и поэтому привлекли небольшую двухлетнюю интернет-компанию WebPub, способную быстро создавать сайты для размещения материалов. У WebPub уже было несколько клиентов с похожими кейсами. Издательство купило решение WebPub и объявило, что будет использовать его для веб-публикации всех журналов Tree. Руководству журналов было поручено сосредоточить свои усилия по публикации в интернете на WebPub.

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

Чтобы устранить неразбериху и продвинуться в достижении цели, был принят ряд решений:

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

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

■ веб-разработчики журналов остановят всю внутреннюю разработку, будут учиться использовать платформу WebPub и работать над интеграцией редакционного процесса своего журнала с платформой WebPub посредством XML.

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

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

Применение скрама

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

Отдельные усилия по усовершенствованию платформы WebPub, стандартизации XML и публикации журналов в сети оказывались неразрывно переплетенными. К счастью, скрам-команды являются кросс-функциональными. Аналогично ежедневному скраму, который координирует работу нескольких людей в одной команде разработки, встреча скрам скрамов (Scrum of Scrums) координирует работу нескольких команд, работающих над одним проектом. Эта встреча по сути – ежедневный скрам, в котором принимают участие по одному человеку от каждой команды разработки. Перед официальным стартом проекта его планировщики разделяют работу на крупные блоки для минимизации зависимостей между командами, и те работают над условно независимыми частями архитектуры проекта. Такая встреча эффективно координирует команды, когда обсуждения требуют незначительные связи и зависимости. Однако в Tree зависимости были настолько сильными, что скрам скрамов не работал.

Чтобы быстро создать инкремент продукта, была необходима параллельная разработка функциональности XML, WebPub и журналов. Компоненты XML и WebPub были объемны и имели инфраструктурный характер. Зависимости были слишком комплексными, устранение или разрешение их до начала работы заняло бы много времени и остановило бы работу. Я решил, что наилучшим вариантом станет координация зависимостей теми, на кого они влияют: командам разработки придется самоорганизовываться для поиска путей преодоления этих препятствий.

Я попросил издательство выбрать четыре журнала к публикации онлайн в первую очередь. Каждая команда журнала была укомплектована разработчиками. Затем мы выбрали кого-то из команды XML и кого-то из команды WebPub для работы с каждой из четырех команд. В каждой команде получилось около девяти участников, включая участников от команд XML и WebPub с частичной занятостью. Владельцами продуктов были назначены редакторы соответствующих журналов.

На планировании спринта первой команды мы создали бэклог продукта, поместив вверху списка нефункциональные требования к структурам XML и возможностям WebPub, необходимым для публикации журнала. Команда разработки взяла на себя обязательство по реализации готового к поставке инкремента продукта в ходе спринта.

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

Разработчики XML и WebPub, назначенные в четыре журнальные команды разработки, разрешали зависимости, возвращаясь в свои команды XML и WebPub. Они знали о задачах отдельных журнальных команд и добивались, чтобы функциональность для их поддержки была разработана параллельно в командах XML и WebPub.

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

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

Уровень комплексности в Tree был ошеломляющим, а ситуация была близка к хаосу. Команды XML, WebPub и журналов разрабатывали зависимые функции параллельно. Реализуемые командами разработки требования были крепко переплетены и взаимозависимы. Обычные механизмы инспекции и адаптации скрама были бы перегружены, если бы я организовал команды как обычно: одна команда XML, одна команда WebPub и по одной команде для каждого журнала. Ежедневный скрам не предоставил бы достаточно возможностей для инспекции прогресса, обнаружения зависимостей и, как следствие, поиска, отбора и принятия необходимых мер по адаптации к сложившейся ситуации.

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

Эта кросс-командная координация очень похожа на то, что позже стало называться скрам скрамов (Scrum of Scrums) – встреча и подход, при котором работа нескольких команд разработки координируется участниками от каждой команды. Такой способ самоорганизации работы команд заметно помог издательству Tree, и первые четыре журнала начали появляться в сети в течение трех месяцев, а пятый и следующие не заставили себя долго ждать.

Ситуация в Lapsec

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

В течение нескольких лет компания Lapsec исследовала возможность «слияния данных» (data fusion) для получения ценных знаний из массива разрозненной информации – усовершенствованной формы глубинного анализа данных (data mining). В момент слияния к крупным массивам применялись передовые алгоритмы, которые быстро помещали данные в хранилище и преобразовывали их в формат, который подходит для анализа и поиска цепочек подозрительных фактов. В начале 2002 года Lapsec получила добро на этот проект, и компании был предоставлен доступ ко всем транзакционным базам данных американского правительства различных уровней.

В проекте хватало головоломок и сложностей, решение и преодоление которых требовало разной степени мастерства, интенсивности и упорства. Было необходимо:

■ постоянно и своевременно получать данные от агентств, которые не знали слова «сотрудничество»;

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

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

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

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

В этом проекте Lapsec многое пробовала впервые, например использование непроверенных технологий и обеспечение высокой степени сотрудничества многочисленных сторон. Соответственно, первой задачей стало доказательство работоспособности идеи и технологии.

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

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

Применение скрама

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

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

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

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

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

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

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

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

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

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

■ декомпозировать результаты запроса;

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

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

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

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

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

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

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

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

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

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

Выводы

Проекты Service1st, Tree и Lapsec были настолько комплексными, что обычные методы планирования и управления не работали – проекты требовали тесной синхронизации многих видов деятельности. Во всех одновременно трудились несколько команд разработки, которые за короткий промежуток времени должны были создать готовый к демонстрации продукт. И все топтались на месте, пытаясь выяснить, с чего следует начать, как изменить свои ситуации и создать работоспособные планы.

Готовый скрам «из коробки» не содержит подходов, учитывающих комплексность любого взятого проекта. Тем не менее скрам-мастерам достаточно обратиться к теории скрама, чтобы найти методы, которые можно легко адаптировать для применения в проектах любой комплексности.

Таким подходом для всех трех проектов в Service1st, Tree и Lapsec была самоорганизация. Выступая в роли тренера или наставника, я учил команды применять практики скрама, включая самоорганизацию, чтобы справляться с возрастающим уровнем комплексности. Так мы понижали уровень сложности до степени, при которой команды разработки могли функционировать самостоятельно.

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

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

В засекреченном проекте Lapsec я должен был помочь команде начать применять скрам. Лекция по теории и практике скрама оказалась не очень полезной. Без упражнения с настоящими задачами и проблемами команда вряд ли поняла бы суть скрама. Показав участникам учебный пример, похожий на их реальную работу, я пробился к команде и помог ей прочувствовать, как применять скрам. Попав в рамки спринта, ограниченного максимум одним месяцем, участники команды разработки атаковали свою реальную проблему, словно стая диких собак, – ограничение во времени превосходно сработало. Марк Твен однажды сказал об этом: «Ничто не фокусирует ум так, как петля». Упражнение было той самой петлей фокусировки.

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

Чтобы заказчики могли выражать свои потребности напрямую владельцу продукта и команде разработки, скрам-мастер устраняет возникающие между ними препятствия, а также несет ответственность за объяснение владельцу продукта, как использовать скрам для максимизации рентабельности инвестиций (ROI) и соответствия целям проекта.

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

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

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

Сотрудничество заказчика и команды

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

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

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

Разработчики и менеджеры ставят заказчикам условие: «Мы собрали ваши требования и на их основании создали модели. Вместе они составляют полное и точное описание того, что вы хотите, посмотрите его. Имейте в виду, что после ответа “да” вам будет стоить намного дороже передумать!» Такая формулировка подразумевает контракт между заказчиками и разработчиками: «Если вы согласны с тем, что представленное нами является полным описанием ваших требований, мы начнем их реализацию. Если нет, то мы продолжим сбор требований, пока вы не сдадитесь!» Личного сотрудничества практически не остается.

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

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

Давайте рассмотрим некоторые примеры, в которых скрам помог владельцам продуктов и группам разработчиков работать вместе, чтобы максимизировать ценность проекта. В Service1st мы увидим, как высшее руководство приняло непосредственное участие в работе через роли владельцев продуктов. В TechCore мы увидим, как молодой предприниматель смог удачно продать свою компанию, сосредоточив усилия на роли владельца продукта. Наконец, в MegaBank мы увидим, как скрам-мастер аккуратно добился того, чтобы заказчики стали владельцами продуктов, и одновременно он сократил временные затраты на обучение и внедрение скрама.

Руководители Service1st снова в действии

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

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

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

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

Обзор спринта

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

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

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

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

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

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

Устранение проблемы XFlow в MegaFund

С компанией MegaFund вы познакомились в третьей главе. Там работал Джефф – менеджер продукта XFlow, который управляет всеми бизнес-процессами фирмы. Он был «теневым владельцем продукта», потому что использовал скрам, но никто в MegaFund не знал об этом. Вот что Джефф писал мне о своем опыте в роли тайного владельца продукта:

Большой причиной моего успеха в этом году стало применение скрама с помощью вас и Джека. Если я правильно помню, в ноябре прошлого года вы оба сказали мне встречаться с заказчиками каждый спринт. Эта ежемесячная встреча стала образцом для успешных подразделений MegaFund. Все заинтересованные лица XFlow восхищаются тем, насколько они вовлечены в работу инженеров и насколько точно в любой момент знают, над чем работают команды. Также заказчики довольны своевременностью наших поставок. Другие подразделения в настоящее время пытаются организовать аналогичные встречи, чтобы улучшить взаимодействие команд и заказчиков.

Как Джеффу удалось внедрить скрам, не сказав об этом никому? Да и зачем он это сделал? На оба вопроса я отвечу в этом разделе.

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

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

Скрам-мастер Джек, я и Джефф встретились для мозгового штурма. Может ли скрам чем-то помочь и спасти XFlow? Мы сосредоточились на событиях по планированию и обзору спринта. Если Джефф организует такие встречи для инженеров и клиентов, это поможет? Ни инженеры, ни клиенты не предоставили ему право создавать или упорядочивать элементы бэклога продукта – и вряд ли предоставят, – но, вероятно, он сможет организовать рабочую сессию, на которой это произойдет само собой.

Решение проблемы

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

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

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

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

Через месяц инженеры представили результаты своей работы. Они перечислили технические проблемы, с которыми столкнулась команда, и способы их обхода для реализации желаемой функциональности и устранения дефектов. Заказчики были впечатлены тем, какой объем работы команда проделала всего за один месяц: создала работающую функциональность, а не только внутренние модели и другие вещи, не представляющие для клиентов интереса. Клиенты также были довольны тем, что создано было именно то, о чем они предварительно договорились, – клиенты чувствовали, что команда инженеров действительно их услышала. Инженеры были довольны тем, что клиенты довольны. Они создали нечто, что одновременно и продвинуло продукт с коммерческой точки зрения, и удовлетворило внутренних заказчиков MegaFund.

Джефф показал всем список наиболее срочных функций, созданный на предыдущей встрече, и попросил комментариев инженеров и заказчиков.

■ Изменились ли потребности кого-то из внутренних заказчиков?

■ Изменились ли требования внешнего рынка?

■ Найдены ли какие-то критические дефекты?

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

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

Классический владелец продукта по скраму должен как минимум:

■ вести бэклог продукта;

■ упорядочивать его элементы по важности;

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

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

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

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

Цели компании TechCore

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

В конце 1990-х годов в Бостоне было много стартапов в области телекоммуникаций, и TechCore – один из них. У всех этих компаний был один лозунг: «Чем выше пропускная способность каналов, тем выше скорость!» Работавшие в TechCore молодые кандидаты наук из Массачусетского технологического института знали, как добиться повышения скорости, и владели патентами на новые разработки. Используя спектральное уплотнение каналов и на стыках избегая переходов от световой волны к электрической, компания Майкла увеличила пропускную способность более чем на 4000 %.

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

Когда в TechCore поступило предложение о приобретении компании и ее новой технологии за $540 млн, Майкл и инвесторы TechCore сочли сумму недостаточной. Майкл намеревался создать на технологии TechCore подсистему, которая бы показала на конференции по телекоммуникациям, что технология стоит больше.

Конференция должна была состояться через четыре месяца. А пока доходы от производства составляли 1 к 1000, отдел кадров приводил в компанию не тех людей, финансисты были заняты планированием очередной экспансии, а Майкл старался лично заниматься всем и даже спроектировал помещение, в котором на предстоящей выставке будет продемонстрирована подсистема.

Как скрам помог TechCore

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

Совместное формирование бэклога продукта оказалось очень полезным. Ранее Майкл считал, что может сделать все: и обеспечивать поставку нового продукта, и управлять остальными задачами компании. В результате его усилия распределялись между многочисленными объектами и ни один не получал должного внимания. Решив, что требования к разработке продукта сейчас важнее, чем производство, планирование пространства и подбор персонала, Майкл признал, что обладает ограниченным ресурсом энергии и должен выбирать, как ее использовать.

Раньше Майкл дни напролет участвовал в обзорных встречах, чтобы поделиться своей экспертизой и задать направление работы для инженеров-разработчиков. Эти встречи часто перерастали в совещания про разработку одной части подсистемы, помогая только небольшому сегменту команды и отнимая время у остальных.

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

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

Заказываемые компоненты и детали были новыми на рынке, часто новее доступных прототипов, их было трудно найти. К тому же сотрудникам отдела закупок часто приходилось описывать компоненты поставщику, не имея технических знаний, которые позволили бы им это сделать качественно. Результат – потерянное время и недовольство. Инженеры запрашивали компонент, закупщики старались найти его, поставщики старались предоставить альтернативу, закупщики возвращались к инженеру с альтернативным предложением, иногда инженеры соглашались на аналог, тогда закупщики возвращались к поставщику, но за это время компонент продавался кому-то другому. Такое происходило каждую неделю.

Чтобы решить проблему закупки компонентов, мы наняли в группу инженеров-разработчиков двух младших инженеров. Они были «младшими» только потому, что у них не было кандидатской степени MIT. Теперь старший инженер обращался с запросом компонента к младшему инженеру, а уже тот работал с отделом закупок и был уполномочен принимать решения по аналогам и идти на компромиссы. Чтобы повысить вероятность получения наиболее подходящей альтернативы, всех инженеров оснастили сотовыми телефонами. Решение по предлагаемому аналогу принималось в реальном времени поставщиком, отделом закупок, младшим инженером и, при необходимости, старшим инженером, который запросил эту деталь.

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

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

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

Результатом стала успешная демонстрация подсистемы на выставке, через месяц после которой BigTel купила TechCore за $1,43 млрд. Майкл помог команде сфокусироваться на наиболее ценных задачах, и это обеспечило рентабельность инвестиций в размере почти $1 млрд за шесть месяцев. Неплохо.

Цели компании MegaBank Funds Transfer System

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

MegaBank – это один из крупнейших финансовых институтов Соединенных Штатов с филиалами по всей стране и достаточной капитализацией для влияния на финансовые рынки. За год компания MegaBank осуществила внутренние и внешние переводы на сумму $39,6 трлн. Эти переводы осуществлялись с помощью «Системы денежных переводов» (Fund Transfer System, FTS), которая успешно завершает все транзакции, обеспечивает их безопасность и ведет журналы для аудита.

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

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

Руководство MegaFund FTS назначило дату релиза на 15 октября. Шел май, а команда все еще не понимала, как FTS может добиться от заказчиков четкого направления развития и сотрудничать с ними для обсуждения возможных альтернативных вариантов достижения целей второй версии системы.

Как скрам помог проекту MegaBank FTS

Пэт встретилась с Генри, Мэри и Лори и рассказала, что команда FTS собирается использовать скрам, который уже применяется для успешного управления другими проектами в MegaBank. Не понимая, что это для них значит и сколько времени на это потребуется, Генри, Мэри и Лори просто надеялись, что скрам поможет им более тесно сотрудничать с командой разработки FTS.

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

Генри, Мэри и Лори остались очень довольны: скрам казался им легким, понятным и требовал только одной официальной встречи в месяц (обзора спринта). С таким объемом они точно справятся, хотя до встречи опасались, что переход на новый процесс разработки потребует обучения, новых форм, новых отчетов и множества накладных расходов. Однако скрам показался им очень простым.

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

После такой оценки и группировки все стали спокойнее и увереннее: Генри, Мэри, Лори и команда разработки чувствовали, что ситуация под контролем, объем работы понятен, задачи каждого спринта потенциально выполнимы за месяц. Вместе они договорились о предварительном плане релиза на общем для заинтересованных лиц и разработчиков языке. Мы освободили вторую половину дня для определения задач следующего спринта, но команде, работающей с Мэри и Лори, удалось выбрать элементы бэклога продукта всего за час. Затем команда приступила к работе над созданием бэклога спринта, а Генри, Мэри и Лори вернулись на рабочие места с чувством удовлетворенности от работы, проделанной для следующего релиза.

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

Я намеренно скупо рассказал о скраме команде разработки и руководству MegaFund FTS. Термины вроде «элементы бэклога продукта» вызвали бы лишние вопросы. Ни одна из сторон не испытывала потребности в изучении языка и процесса скрама, поэтому я начал знакомить их с конкретными подходами, которые они могли использовать для более эффективного взаимодействия. «Бэклогом продукта» был упорядоченный список требований. А забавное слово «спринт» для обозначения отрезка времени между встречами (обзорами спринта) мы вообще не использовали, это был просто месяц.

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

Выводы

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

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

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

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

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

Такими безжалостными упражнениями я помогаю будущим скрам-мастерам понять величину языкового барьера, разделяющего заказчиков и разработчиков. Преодоление этого разрыва критически необходимо: если две стороны не могут говорить на одном языке, сотрудничество невозможно! Владелец продукта часто не заинтересован в преодолении разрыва, у него нет для этого ни образования, ни опыта. Для него это сложнее, чем для команды, поэтому остается один вариант – скрам-мастер должен помочь команде преодолеть этот разрыв.

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

К заинтересованным лицам проекта относятся:

■ те, кто финансирует проект;

■ те, кто намерен использовать создаваемую в рамках проекта функциональность;

■ те, на кого так или иначе повлияют ход или результаты проекта.

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

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

Процесс планирования в скраме включает в себя поиск ответов на три серии вопросов:

■ Каких изменений могут ожидать те, кто финансирует проект? Когда он завершится?

■ Какие результаты будут достигнуты в конце каждого спринта?

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

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

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

Одна из целей плана – убедить кого-то финансировать проект. В плане должны быть представлены сведения, достаточно подробные для объяснения источнику финансирования, что:

■ проект целесообразен;

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

■ выгоды перевешивают риски и издержки;

■ команда проекта достаточно компетентна для исполнения этого плана.

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

Управление денежными средствами в MegaBank

MegaBank является одним из крупнейших финансовых институтов в мире. Мы уже познакомились с ним в пятой главе и еще встретим в следующих главах. Спустя два года после первого рассказа о скраме представителям компании 20 % всех программных продуктов MegaBank используют его. Одна команда узнала об успехе скрама в других подразделениях MegaBank и захотела попробовать его в пилотном проекте по миграции с мейнфреймов в интернет приложения учета денежных переводов. Финансирование было одобрено, команда сформирована, план разработан. Команда проекта получила указание, предписывающее полную готовность к внедрению веб-версии приложения через пять месяцев. Других деталей не требовалось, поскольку новое приложение полностью должно было повторить функциональность своего мейнфрейм-предшественника без добавления каких бы то ни было новых функций.

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

Событие «Планирование спринта»

На этом собрании присутствовал владелец продукта Джули, скрам-мастер Том, менеджер по разработке систем Эд и команда разработки из пяти человек. За первые три часа встречи я рассказал основы скрама в объеме первой главы этой книги. Затем объявил, что мы почти готовы начать обычное событие по планированию спринта. Почти готовы, потому что нам не хватало только одного – бэклога продукта. Владельцу продукта нужен бэклог, чтобы идентифицировать элементы с наивысшим приоритетом. Команде нужен бэклог, чтобы из его верхней части выбрать элементы, которые она за один спринт сможет превратить в готовый к поставке инкремент продукта. Я заверил участников, что к концу дня мы сформируем бэклог продукта. Тем не менее все ныли, а команда разработки считала это упражнение пустой тратой времени. Они спросили: «Зачем нам создавать бэклог всего продукта, почему нельзя просто обсудить и договориться о составе работ следующего спринта? В конце концов, разве не в этом суть аджайла?» Я ответил, что всем нам нужно получить представление о проекте, а поскольку мы применяем скрам, то будем использовать бэклог продукта. Он нужен, чтобы определить базовый уровень ожиданий от проекта, относительно которого руководство MegaBank могло бы проследить прогресс.

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

Оценка бэклога продукта

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

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

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

Что означает «готово»

Прежде чем разделять элементы бэклога на спринты для сравнения с ожиданием руководства в пять месяцев, я спросил у команды разработки, какие работы включены в их оценки. Учтены ли задачи по анализу, проектированию, написанию кода? Учтено ли время на модульное тестирование? Учтена ли автоматизация модульных тестов на чем-то вроде JUnit? Время на ревью кода другим разработчиком, его рефакторинг? Предполагалось ли при оценке, что код написан чисто и разборчиво, оформлен согласно командным правилам, удалены временные фрагменты, ненужный код, лишние комментарии? Важно, чтобы все участники команды разработки и заинтересованные лица точно понимали, какие работы учтены при оценке элемента бэклога, чтобы никто не называл и не считал требование «готовым», пока вся необходимая работа не выполнена полностью. Владелец продукта Джули поинтересовалась, почему это так важно обсудить. Я ответил, что состав пунктов этого соглашения влияет на то, насколько ценной будет разработанная функциональность. Например, если команда не выполнила модульное тестирование, мы, вероятно, должны принимать во внимание возможное обнаружение ошибок позже, а значит, выделять больше времени на тестирование приложения, последующее исправление ошибок и повторное тестирование перед внедрением. Если команда проводит рефакторинг кода в рамках реализации каждого требования, то легче исправить ошибки в будущем и приложение в целом легче поддерживать, оптимизировать и дорабатывать.

Джули не знала, что такое JUnit; тогда один из участников команды разработки пояснил ей, что это среда автоматического модульного тестирования, в которой команда может создать набор автоматизированных тестов для приложения. Всякий раз, когда добавляется новый фрагмент кода, команда сразу же узнает, ломает ли он разработанные ранее функции. Джули обрадовалась такой возможности, поскольку хотела получать проверенное и легко поддерживаемое приложение, а не что-то быстро состряпанное. Она всегда предполагала, что команда разработки должна поставлять приложение проверенным, и была рада, что может закрепить это в договоренностях. Я попросил команду переоценить элементы бэклога продукта с учетом услышанных ожиданий Джули. Проведя час за обсуждением влияния этого нового определения «готовности», команда обновила оценки. Затем Джули обсудила бэклог продукта с командой разработки. Какие требования следует взять в работу первыми? Поскольку тестировщики не были частью команды, какую работу пять разработчиков могут выполнить, чтобы передать функционал в тестирование в конце каждого спринта? Какие нефункциональные требования более приоритетны? Результатом этого обсуждения стал упорядоченный бэклог продукта.

Насколько трудно это изменить

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

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

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

Эд был крайне недоволен таким подходом. Раньше он всегда придерживался своих первоначальных оценок, и команда никогда его не подводила. И хотя он согласился, что теперь обладал более полной информацией о проекте, чем раньше, культура в MegaBank была такой, что, как только вы произносите «пять месяцев», именно это и запоминается. Эд повернулся к команде и сказал: «Послушайте, я знаю, что сейчас мы точнее понимаем объем работы, но это по-прежнему лишь оценка. Впереди у нас пять месяцев. Вы меня никогда не подводили, и я рассчитываю, что и в этот раз не подведете».

Последовало глубокое молчание. Позже один участник команды поделился со мной, что просьба Эда прозвучала так, будто все осталось по-прежнему, называем мы это скрамом или нет. Итеративно-инкрементальная разработка? Никаких возражений. Но по мере необходимости все равно придется халтурить и срезать углы. Эд не желал говорить своему руководству, что разработка программного обеспечения комплексна, а любая оценка – это просто оценка. Вместо этого в MegaBank будет преобладать культура веры в то, что можно предсказать будущее, и никогда не появится необходимость корректировать прогнозы. Планирование спринта выявило, что до сих пор команда жертвовала качеством, чтобы поддержать это убеждение. Джули услышала, как Эд сказал команде разработки, что дата важнее качества и что участники должны во что бы то ни стало уложиться в изначально озвученный срок, несмотря на ее просьбу предоставить качественный продукт.

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

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

Мы оценили стоимость повышения качества функциональности с уровня «работы как обычно» до чистого, прошедшего рефакторинг и оттестированного кода. У нас на руках была оценка стоимости создания более устойчивой и поддерживаемой системы, но не было количественной оценки этих характеристик. Эд поручил команде снизить качество ради повышения скорости. Какой будет стоимость последствий этого решения для организации? Насколько эта стоимость сопоставима со стоимостью создания качественного продукта сразу? Ответы на эти вопросы, возможно, убедили бы Эда пересмотреть свое обещание руководству.

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

Профессиональные сертифицированные скрам-мастера берутся за рентабельность инвестиций

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

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

MLBTix

За последние 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 по восточному времени[15]. Вы знаете, что поклонников более 40 млн, а система не может обрабатывать 40 млн одновременных обращений.

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

Что посоветуете?

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

Как команды отвечают на этот вопрос

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

Совет команды 1

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

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

Совет команды 2

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

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

Совет команды 3

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

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

Совет команды 4

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

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

Выводы

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

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

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

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

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

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

Новая отчетность в проекте MegaEnergy

Компания MegaEnergy познакомилась со скрамом через пилотный проект по учету земельных участков, который рассматривался во второй главе. Этот проект уже дважды стартовал и завершался без результатов. ИТ-директор узнал о скраме и убедил своих коллег-менеджеров попробовать. Они считали, что проект по учету земельных участков станет хорошей возможностью оценить применимость скрама в организации: если скрам поможет исправить ситуацию, то будет считаться достойным дальнейших проб в других проектах MegaEnergy.

Команда проекта в MegaEnergy создавала внутренние артефакты: технические задания, архитектуры, модели, код. Если проект не стопорился на разработке этих артефактов, то в самом конце они объединялись и превращались в рабочую систему. Только тогда заинтересованные лица могли увидеть то, что будут в дальнейшем использовать. Заинтересованные лица – это те, кто заинтересован в результатах проекта, включая тех, кто финансирует проект, и тех, кто будет пользоваться разрабатываемой системой.

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

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

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

Это подкинуло нам задачку. Должны ли мы проводить обучение высшего руководства скраму, включая сотрудников офиса управления программами? Должны ли мы сообщить им о радикально ином подходе, который мы собрались использовать в проекте «Участок»? Должны ли мы вступить с ними в долгую дискуссию о различиях в управлении предопределенным и эмпирическим процессами? Мы знали, что эта дискуссия будет эмоциональной, ведь офис управления программами имел большую историю успеха в MegaEnergy. Их подход использовался для управления гораздо более массивными проектами, чем проект «Участок», а причиной неудач предыдущих двух попыток называли человеческие ошибки, а не недостатки процесса. Как убедить их в обратном?

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

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

Решение проблемы

Скрам-мастер Рут была опытным менеджером проектов в MegaEnergy. Она знала культуру MegaEnergy изнутри и снаружи, знала директоров, которые получали отчеты о прогрессе проекта «Участок». Она работала с сотрудниками из офиса управления программами и точно знала, чего они хотят и почему. Она знала, что отчеты с диаграммами Ганта являются основой их системы отчетности. Рут умела создавать и поддерживать в актуальном состоянии календарный и ресурсный планы проекта в Microsoft Project, который был стандартным инструментом управления проектами в MegaEnergy.

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

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

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

В скраме существует четыре отчета, которые владелец продукта и скрам-мастер создают в конце каждого спринта. Первым делом я познакомил с ними Рут:

1. Старый бэклог – содержит элементы бэклога по состоянию на начало предыдущего спринта;

2. Новый бэклог – содержит бэклог продукта в начале следующего спринта;

3. Отчет об изменениях – описывает все различия между бэклогами продукта в первых двух отчетах;

4. График сгорания элементов бэклога продукта.

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

■ Почему содержание будущих спринтов было изменено?

■ Почему дата или содержание релиза были изменены?

■ Почему во время спринта команда реализовала меньше требований, чем ожидалось?

■ Куда помещена невыполненная в спринте работа?

■ Почему команда разработки была менее или более эффективной, чем ожидалось?

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

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

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

Рут открыла файл с электронной таблицей бэклога проекта в Microsoft Excel и создала новый проект в Microsoft Project. Она скопировала и вставила весь список элементов бэклога из Excel в Project в столбец «Название задачи», а оценки – в колонку «Длительность». Это был прямой перенос из одного продукта Microsoft в другой. Она сгруппировала требования (MS Project считал их задачами) в спринты, как показано на рис. 7.3.

Затем Рут заполнила представления «Задачи» и «Отслеживание», для каждого элемента бэклога указав длительность работы, а для каждого спринта – дату его начала. Столбец «% завершения» обычно содержал значение 100 почти для каждой строки в конце спринта. Мы договорились, что, если где-то будет не 100 %, она разделит элементы и поместит невыполненную работу в будущие спринты.

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

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

В конце первого спринта руководство получило новые отчеты. Они были во мно