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

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

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

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

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

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

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

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

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