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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пэт встретилась с Генри, Мэри и Лори и рассказала, что команда 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). Мы рассмотрим его в следующих разделах этой главы. В одном из упражнений участники группы проверяют, могут ли они участвовать в осмысленном диалоге с по-настоящему жестким клиентом по имени Джордж Штайнбреннер. Им предстоит обсудить с ним несколько трудных решений. Типичные результаты команд представлены в конце кейса.

За последние 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. Он показывает прогноз оставшейся работы по проекту. В начале каждого спринта оставшийся объем работы измеряется путем суммирования оценок всех незакрытых элементов бэклога продукта. От спринта к спринту увеличение или уменьшение этой суммы можно использовать для оценки прогресса в завершении работы релиза.

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

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

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

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

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

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

Получение дополнительной информации в MegaBank

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

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

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

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

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

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

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

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

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

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

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

Не все прозрачно в Service1st

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

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

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

Я порекомендовал Ирен не позволять команде разработки приступать к какой-либо новой функциональности, пока они не завершат уже продемонстрированную. Неполное тестирование, исправление ошибок и другая неоконченная работа должны быть помещены в бэклог продукта как незавершенная работа. Участники команды еще хорошо помнят код, поэтому его отладка в следующем спринте займет меньше времени, чем на более поздних сроках. Если команда разработки отлаживает код сразу, то укрепляется общее понимание, что только полностью завершенная работа может быть принята. Но команда восстала, опасаясь, что следующий обзор спринта станет унизительным. На первом обзоре она выглядела суперкомандой, а на следующем, не показав ничего нового, выглядела бы нелепо, как картавый охотник Элмер Фадд, который гонится за кроликом Багзом Банни в мультсериале «Шоу Луни Тюнз». Разве можно было продемонстрировать ту же функциональность, что и на предыдущем обзоре спринта, добавив, что теперь функциональность работает?

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

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

Команда разработки отличилась в части написания кода, но провалилась в части тестирования, а затем взломала демонстрацию, поскольку система могла работать только в лабораторных условиях по заранее прописанному сценарию. Функциональность, конечно же, не соответствовала «принципу сашими». Если владелец продукта решил бы поставить инкремент продукта после обзора спринта, потребовалось бы проделать еще много работы. В традиционных проектах команды тратят по несколько месяцев на анализ и проектирование, не создавая ничего ценного для заинтересованных лиц. Команда разработки Service1st сделала наоборот: было продемонстрировано функций больше, чем реально завершено. Заинтересованные лица полагали, что прогресс по проекту значительнее, чем на самом деле, – они были в восторге от несуществующей ситуации!

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

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

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

Кто-то подумает, что за один спринт команда могла бы изучить все, что нужно знать о самоуправлении. Но волнение от первого использования скрама может привести к недостаточному вниманию к его сложным частям. Управлять собой трудно. Гораздо легче, хотя и менее приятно позволить кому-то другому управлять вами. На планировании команда разработала бэклог спринта, состоящий из двух видов работ. Для каждой продемонстрированной на обзоре предыдущего спринта функции были добавлены задачи по ее проверке и исправлению найденных ошибок. Задачи по созданию новой функциональности бизнес-процесса составили остальную часть бэклога спринта. Задачи тестирования и отладки были настолько абстрактными и неточными, что невозможно было определить количество необходимого для их выполнения времени. Как определить в ходе спринта, успеваем ли мы завершить все запланированные работы? Никто не знал. Работы по тестированию и отладке нельзя было сжечь[18], поскольку объем оставшейся работы был неизвестен.

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

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

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

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

Становление команды в Service1st

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

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

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

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

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

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

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

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

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

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

3. Мешает ли что-то мне или команде достичь цели спринта?

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

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

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

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

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

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

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

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

Участники команды смотрели на меня смущенно. Они рассказали, что без особенных обстоятельств или указания они собирают систему только в конце шестимесячного цикла разработки релиза. Используя скрам, они планировали начать собирать систему с последней недели месячного спринта. Тогда-то они и приступили бы к чистке кода. Это откровение застало меня врасплох. Когда участники команды сообщали во время ежедневного скрама, что конкретная функция готова, ее код еще даже не был добавлен в единый репозиторий, система не была собрана и протестирована. Я уточнил, так ли это. На встрече неожиданно повисла тишина. Все осознали: есть проблема. Один участник команды разработки, Джареш, поделился, что обычно он дорабатывает локальную копию кода от 5 до 10 дней и только потом отправляет изменения на сервер. Он поинтересовался, как часто он может возвращать[20] измененный код в единый репозиторий? Я спросил, как он понимает, что вносимые им изменения не противоречат коду, над которым работают другие разработчики при столь редких синхронизациях с базовой версией? Джареш ответил, что, если будет возвращать изменения кода часто, ему придется устранять разногласия между фрагментами кода ежедневно, а внося изменения на сервер только после завершения разработки функции, он может производить такую корректировку лишь один раз.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как скрам улучшает оценки

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

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

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

Что происходит, если фактические значения сравниваются с оценками и планами

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

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

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

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

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

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

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

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

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

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

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

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

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

WebNewSite: дать команде шанс

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

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

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

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

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

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

Масштабирование в MegaFund

Мы рассматривали компанию MegaFund в третьей и пятой главах. Если вы, будучи клиентом MegaFund в 1997 году, хотели перевести деньги, открыть счет, торговать ценными бумагами или воспользоваться любым другим финансовым предложением MegaFund, у вас было два варианта: позвонить агенту по телефону или пойти в ближайший офис MegaFund и использовать туповатый терминал типа IBM 3270, подключенный через сеть к мейнфреймам компании. Хотя эта технология и была новаторской в 1980-х годах, спустя 17 лет конкуренты MegaFund позволяли клиентам самостоятельно управлять своими учетными записями с домашних или офисных компьютеров, сотовых телефонов, веб-устройств, пейджеров и телефонных голосовых систем в любой день в любое время. Это несоответствие стало неотложной бизнес-проблемой MegaFund. Требовалось как можно скорее устранить отставание от конкурентов и предоставить клиентам новую технологию. Все в MegaFund хотели начать свой собственный проект и тут же создать конкурентоспособное предложение.

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

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

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

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

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

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

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

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

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

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

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

Масштабирование скрама

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

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

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

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

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

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

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

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

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

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

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

Масштабирование в Medcinsoft

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

Проект Y2K был комплексным и требовал масштабирования в нескольких измерениях одновременно. Необходимо было координировать работу более 300 разработчиков, определив приоритеты задач по реализации нового функционала различных продуктов, устранению «ошибки 2000 года» и исправлению дефектов. Более 400 полевых сотрудников поддержки нуждались в приоритизации и координации их работы и взаимодействия с клиентами Medcinsoft. Более 600 сотрудников из 350 организаций-клиентов нуждались в возможности сообщать в Medcinsoft о планах и изменениях в них. Клиенты работали с разными версиями программного обеспечения Medcinsoft, доработанными и настроенными под их конкретные потребности. У каждого клиента был свой уникальный график обновления используемых им систем, в том числе и обновления программного обеспечения Medcinsoft по проблеме Y2K. У клиентов также были уникальные расписания тестирования устанавливаемых систем и обновлений. Проще говоря, графики установки и тестирования и уровни знаний и навыков клиентов Medcinsoft существенно различались.

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

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

Перечисленных проблем было предостаточно, но список трудностей Джека на этом не заканчивался. Несмотря на то что ранее проводились обширные и внимательные поиски недочетов по проблеме Y2K в соответствии с отраслевыми и внутриорганизационными рекомендациями, новые дефекты Y2K все еще регулярно обнаруживались. Кроме того, Medcinsoft планировала добавить в релиз Y2K новую функциональность веб-доступа, а ошибки, возникающие при ее реализации, оказались трудными для обнаружения. По мере устранения новых дефектов часто создавались другие – регрессионные дефекты. Некоторые части программного обеспечения были очень древними. Написавшие код разработчики уже не работали в компании и не могли внести исправления Y2K или хотя бы помочь советом, поэтому сегодняшним разработчикам приходилось параллельно изучать и обновлять код. При этом базовое программное обеспечение было велико согласно почти любым стандартам, оно оценивалось в 2500 функциональных единиц[24]. Особенности управления программным обеспечением со стороны клиентов Medcinsoft дополнительно осложняли ситуацию. Многие компании никогда не проводили столь массивную модернизацию своих систем и не были готовы к этому. У неожиданно большого числа клиентов не было ни тестовых сред, ни понятных отлаженных процессов проверки новых релизов.

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

Полевые инженеры агрегировали бэклоги клиентов в бэклоги Medcinsoft по районам, затем районные – в бэклоги по регионам (см. рис. 9.3), а региональные – в единый «бэклог службы поддержки Medcinsoft». При любом изменении бэклога клиента изменялась и соответствующая ему часть в бэклоге службы поддержки Medcinsoft. Затем этот комбинированный бэклог упорядочивался по приоритету, чтобы планировать работу среди всех клиентов. Руководители полевых инженеров использовали его, чтобы распределять персонал на местах для выполнения настроек и оказания помощи во внедрении, тестировании и тиражировании программного обеспечения.

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

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

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

Часть верхних элементов бэклога продукта в начале спринта могла выглядеть так:

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

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

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

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

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

■ клиент MediLife запрашивает релиз для внедрения (в настоящее время установлена версия 8.1);

■ клиент MedClinic запрашивает релиз для внедрения (в настоящее время установлена версия 7.2).

Команды разработки были сгруппированы по функциональности, например СОЗ (счета клиентов, оплата по выставленным счетам, задолженность клиентов), РАСП (ведение расписаний) и т. д. (см. рис. 9.4). На планировании спринта Джуди помогала каждой команде разработки выбрать элементы бэклога продукта, соответствующие ее функциональной области. Участники команды работали в Medcinsoft достаточно долго, поэтому выбор исполнителей не вызывал вопросов. Если задач для полной загрузки команды было недостаточно, то команда во время этого спринта работала над проектом Y2K только часть своего времени, а оставшуюся часть – над другими проектами. Джек использовал такой подход, чтобы обеспечить четкое разделение работы, поскольку над элементами бэклога продукта Y2K могли одновременно работать до 20 команд по 10 участников в каждой. Среди этих команд находились функциональные команды, команды сборки системы, команды обнаружения дефектов Y2K, команды тестирования и команды релизов.

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

Обнаруживаемые ошибки вносились в систему отслеживания дефектов. Одни ошибки команда тестирования находила при регрессионной проверке создаваемого инкремента продукта. Другие были ошибками Y2K и выявлялись в ходе их постоянного поиска для снижения возможных последствий неправильной работы программного обеспечения в связи с этой проблемой. Третья группа ошибок возникала при установке и тестировании релизов Y2K на площадках заказчиков. Изначально Medcinsoft намеревалась исправить все ошибки и дефекты вплоть до финальной версии релиза Y2K, запланированной к выпуску 1 октября 1999 года. Но такой план был отвергнут клиентами. Они хотели как можно скорее обезопасить себя, «задраив люки» задолго до начала 2000 года. Чтобы успеть в более сжатые сроки и повысить целостность каждого релиза, Джуди анализировала новые дефекты перед ежедневным скрамом, а затем добавляла все критические и высокоприоритетные ошибки в бэклоги спринтов различных команд, работавших над этим релизом. Этим действием Джуди явно нарушала правило скрама, согласно которому никакая внешняя работа не может добавляться в спринт команды после его начала. Тем не менее другая практика скрама – «руководствуйся здравым смыслом» – одержала верх, поскольку поставка новых релизов без незамедлительного устранения дефектов просто впустую потратила бы время клиентов и спровоцировала бы дополнительные проблемы.

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

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

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

Выводы

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

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

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

Планирование спринта

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

В ходе планирования спринта скрам-команда принимает решения по двум темам:

■ каким будет инкремент продукта в конце спринта;

■ как организовать свою работу, чтобы получить готовый к поставке инкремент.

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

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

■ бизнес-цели, которые должны быть достигнуты в спринте;

■ элементы бэклога продукта, необходимые для достижения цели спринта.

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

Цель спринта

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

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

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

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

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

Ежедневный скрам

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

Команда разработки использует это событие:

■ для инспектирования своего продвижения к цели спринта;

■ для отслеживания прогресса по работе над бэклогом спринта;

■ для понимания, успевает ли она завершить задачи спринта в срок.

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

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

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

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

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

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

Те, кто не соблюдает вышеуказанные правила, могут быть исключены из собрания (цыплята) или удалены из команды разработки (поросята).

Команда сама определяет формат ежедневного скрама, но акцент всегда остается на достижении цели спринта. Какие-то команды организуют дискуссию, какие-то используют вопросы, например:

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

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

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

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

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

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

Спринт

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

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

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

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

Во время спринта:

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

■ качество продукта не должно снижаться;

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

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

У участников команды есть две обязанности во время спринта:

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

■ поддерживать бэклог спринта в актуальном состоянии и доступным в общей папке на общем сервере.

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

Отмена спринта

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

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

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

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

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

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

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

Ниже перечислены ключевые аспекты обзора спринта.

■ Владелец продукта начинает обзор спринта, представляя цель спринта.

■ Владелец продукта рассказывает, какие элементы бэклога готовы, а какие нет.

■ Команда разработки рассказывает о том, что удалось выполнить во время спринта, какие проблемы возникли и как они были решены.

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

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

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

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

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

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

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

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

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

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

■ В конце обзора спринта скрам-мастер сообщает место и дату следующего обзора спринта владельцу продукта, команде разработки и всем заинтересованным лицам.

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

Ретроспектива спринта

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

Цели проведения ретроспективы спринта:

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

■ создание плана внедрения улучшений в процесс работы скрам-команды.

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

Ретроспектива может проходить в разных форматах. Например, скрам-мастер может попросить всех участников ответить на два вопроса:

■ Что было хорошо во время последнего спринта?

■ Что можно улучшить в следующем спринте?

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

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