Допустим, я добираюсь из Чикаго в Бостон самолетом. До и во время полета капитан судна получает инструкции от авиадиспетчерской службы. Мы взлетаем по команде и следуем по заданному маршруту. В ходе полета компьютеры будут с точностью до минуты предсказывать время приземления в Бостоне. Если что-то меняется — скажем, плотность воздуха, — пилот должен получить разрешение на переход на другую высоту. При приближении к аэропорту пилоту сообщают, на какую полосу садиться и у каких ворот парковаться.
Если я отправлюсь в Бостон на машине, то смогу поехать когда захочу и как захочу. Я не знаю точного времени прибытия и, скорее всего, не буду планировать, по какому маршруту поеду и где остановлюсь на ночь. В пути я следую правилам дорожного движения: останавливаюсь на красные сигналы светофоров, придерживаюсь стиля вождения другого региона, соблюдаю ограничения скорости, передвигаюсь вместе с потоком. В автомобиле я — независимый агент, принимающий решения в своих собственных интересах в соответствии с правилами игры.
Я не перестаю удивляться, как тысячи тысяч людей каждый день путешествуют на машинах, достигают своих целей в рамках простых правил дорожного движения, без центра управления или диспетчерской службы. Меня также удивляет, что если я захочу отправить посылку, то могу ввести запрос на сайте почтовой службы и водитель прибудет к моей двери к указанному времени. Диспетчер не направляет водителя в каждый дом: водитель получает постоянно обновляемый список адресов и временных окон и должен самостоятельно составить маршрут так, чтобы забрать все посылки вовремя.
Для обеспечения доставки на следующий день достаточно центральной системы диспетчеризации, которая планирует маршрут водителя единожды в начале дня. Но невозможно заранее спланировать маршрут, если клиенты в любое время дня оставляют запросы на отправку посылки сегодня же. Системы центрального управления и диспетчеризации по мере увеличения комплексности выходят из строя. Самоотверженно пытаясь заставить их работать, некоторые люди применяют более жесткий подход — и это действительно помогает, но лишь на время и не в каждом случае. Таксопарки регулируют новые запросы через диспетчерские центры. Некоторые службы доставки закрепляют водителей в районах, отправляют им запросы и позволяют самостоятельно определять оптимальный маршрут на основе текущей ситуации. Однако в долгосрочной перспективе выигрывают те, кто осознаeт необходимость перехода к системе независимых агентов, действующих в соответствии с набором правил.
Чем более комплексной является система, тем выше вероятность сбоя центрального управления. По этой причине компании децентрализуются, а правительства отменяют регулирование. Отказ от контроля над независимыми агентами — это проверенный временем подход к решению комплексных проблем. Чем выше комплексность проекта, тем острее необходимость делегировать принятие решений независимым агентам, непосредственно выполняющим работу. Скрам предлагает проторенную дорожку для перехода от централизованных диспетчеризации и управления расписанием к отдельно работающим командам.
Еще одна причина успешной работы скрама заключается в том, что он значительно сокращает цикл обратной связи между заказчиком и разработчиком, между списком пожеланий и их реализацией, между инвестициями в продукт и их возвратом. Опять же, существенную роль здесь играет комплексность. Когда система проста, нетрудно заранее определить, что делать. Но, имея дело с постоянно меняющейся рыночной экономикой и идущими вперед технологиями, получение новых знаний через короткие циклы исследований и проверки гипотез — проверенный подход к решению проблем.
Мы давно знаем этот подход: проводим различные маркетинговые кампании и выясняем, какой подход работает; моделируем поведение транспортного средства во время проектирования автомобиля, чтобы обнаружить оптимальный наклон капота и лучшее распределение веса. Практически все подходы к улучшению процессов используют некоторую версию цикла Деминга-Шухарта для изучения проблемы, проведения экспериментов с решением, измерения полученных результатов и применения проверенных улучшений. Мы называем это «принятием решений на основе фактов» и знаем, что это работает намного лучше, чем предиктивные подходы.
Скрам основан на спринтах — коротких циклах обучения длительностью до одного месяца, которые подтверждают бизнес-гипотезы. Если все уже известно и нечего открывать, то, возможно, нам не следует использовать скрам. Однако если нам нужно учиться, то настойчивость скрама в предоставлении завершенного инкремента, добавляющего бизнес-ценность, помогает нам учиться быстрее. Преимущество завершенных полноценных инкрементов заключается в том, что мы точно знаем, какую ценность для бизнеса приносят наши эксперименты. Частичные ответы часто вводят нас в заблуждение, заставляя думать, что подход будет работать, хотя при более тщательном рассмотрении мы убедимся, что в действительности он не работает. Скрам побуждает нас тестировать и интегрировать наши эксперименты, а затем выпускать ПО в промышленную среду, проходя полный цикл обучения каждый спринт.
Скрам фокусируется на предоставлении не просто инкремента бизнес-ценности, а на предоставлении бизнес-ценности с наивысшим приоритетом, определенным заказчиком или владельцем продукта. Владелец продукта и команда обсуждают ценность требований для бизнеса, а затем команда определяет, что сможет сделать в течение следующего спринта. При этом короткая петля обратной связи внутри спринта становится петлей обратной связи для бизнеса: скрам часто и рано проверяет, будет ли разрабатываемая система приносить ценность и как именно будет выглядеть эта ценность. Это позволяет последовательно создавать программную систему, приносящую ценность в соответствии с нашим текущим актуальным и основанным на фактах мнением.
Еще одна причина успешной работы скрама заключается в том, что он раскрывает интеллектуальный потенциал сотрудников. Зачастую, когда что-то идет не так, вокруг есть люди, которые знали о потенциальной проблеме, но почему-то их идеи не были учтены. Например, когда при возвращении на Землю 1 февраля 2003 года взорвался космический шаттл «Колумбия», многие предполагали, что инженеры знали о возможных проблемах, но не смогли добиться серьезного отношения руководства NASA к своим опасениям.
По словам Гэри Конвиса, экс-президента Toyota Motor Manufacturing Kentucky, роль менеджеров в здоровой, процветающей рабочей среде заключается в том, чтобы «формировать организацию не силой воли или диктата, а, скорее, собственным примером, коучингом, пониманием и помощью другим в достижении их целей»1.
Скрам превращает участников небольших команд в менеджеров своей судьбы. Мы знаем, что несем ответственность за собственный выбор и обязательно найдем способ добраться в Бостон, если будем самостоятельно выбирать маршрут. Мы станем объезжать ремонтные работы и избегать пробок в часы пик, принимать решения на лету, адаптируясь к независимым решениям других водителей. Аналогичным образом скрам-команды принимают вызов, а затем совместно выясняют, как действовать. Они обходят препятствия такими творческими способами, которые не могли быть спланированы центральным контрольно-диспетчерским центром.
Если размер команд способствует активному вовлечению каждого участника и они чувствуют, что контролируют свою судьбу, то опыт, идеи и опасения отдельных участников будут максимально использованы, а не проигнорированы. Когда участники команды разделяют общую цель, в которую все верят, они находят способ, как ее достичь. Когда команды понимают бизнес-ценность и берут на себя ответственность предоставить ее своим клиентам, когда они свободны решать, как выполнять задачи, когда им предоставляются все необходимые ресурсы, они добиваются успеха.
Гэри Конвис отмечает, что устойчивый успех Toyota обусловлен «взаимосвязанным набором трех основных элементов: философскими основами, управленческой культурой и техническими инструментами. Философские основы включают в себя ориентацию на клиента, акцент в первую очередь на людей, приверженность постоянному совершенствованию. Культура управления основана на нескольких факторах, включая развитие и поддержание чувства доверия, обязательство прежде всего вовлекать тех, кого ситуация затрагивает непосредственно, командную работу, равное и справедливое отношение ко всем и, наконец, принятие решений на основе фактов и анализа влияния действий в долгосрочной перспективе»1.
Скрам успешно работает по тем же причинам. Его философские основы направлены на расширение возможностей команды разработчиков и удовлетворение потребностей клиентов. Его управленческая культура основана на помощи другим в достижении их целей. Его технические инструменты направлены на принятие решений, основанных на получаемых в процессе обучения фактах. Обладая всеми этими характеристиками, скраму трудно не преуспеть.
Poppendieck LLC
Скелет и сердце скрама
Все практики скрама держатся на скелете итеративно-инкрементального процесса. Он изображен на рис. 1. Нижний круг представляет собой итерацию разработки программного обеспечения. Итерации следуют одна за другой. Содержание работы в каждой итерации основывается на списке требований. В результате каждой итерации получается инкремент продукта. Верхний круг представляет собой ежедневную инспекцию в ходе итерации: участники команды разработки собираются вместе для инспекции работы, выполненной каждым за день, и для принятия мер по адаптации дальнейшей работы. Цикл итераций завершается, когда проект перестает финансироваться.
Рассмотрим устройство скелета. В начале итерации команда разработки анализирует, что она должна сделать. Затем выбирает требования, которые сможет к концу итерации превратить в инкремент готовой к поставке2 функциональности. В ходе итерации команда прилагает для этого все усилия, а любые заинтересованные лица не отвлекают команду до конца итерации. По завершении итерации команда разработки демонстрирует созданный за итерацию инкремент продукта, чтобы заинтересованные лица могли произвести его инспекцию и соответствующие адаптации в проекте могли быть произведены своевременно.
Сердцем скрама является итерация. Команда изучает требования, рассматривает доступные технологии и оценивает свои собственные возможности и навыки. Затем сообща определяет, как она будет создавать запланированную функциональность. Сталкиваясь с новыми трудностями и неожиданностями комплексного окружения, команда разработки ежедневно изменяет свой подход к работе. Команда выясняет, что нужно реализовать за итерацию, и самостоятельно выбирает лучший способ сделать это. Этот творческий процесс — основа продуктивности в скраме.
Реализовать этот скелет итеративно-инкрементального процесса в скраме позволяют три роли.
Роли скрама
В скраме есть только три роли: владелец продукта, команда разработки и скрам-мастер. Вся ответственность в части управления проектом разделена между этими ролями. Владелец продукта отвечает за представление интересов всех лиц, заинтересованных в проекте, в создаваемой программной системе. Чтобы добиться и затем получать регулярное финансирование проекта, владелец продукта описывает первоначальные общие требования проекта, определяет цели по возврату инвестиций (ROI) и поддерживает план релизов в актуальном состоянии. Список требований называется бэклогом продукта. Владелец продукта несет ответственность за поставку заинтересованным лицам максимальной ценности: гарантирует, что наиболее ценная функциональность будет реализована в первую очередь. Это достигается за счет регулярного пересмотра порядка задач в бэклоге так, чтобы в следующую итерацию были взяты самые ценные требования.
Команда разработки отвечает за создание функциональности. Команда является самоуправляющейся, самоорганизующейся и кросс-функциональной3. Она несет ответственность за организацию своей работы и за решения о том, как в рамках итерации превратить часть бэклога продукта в инкремент потенциально поставляемой функциональности. Участники команды несут коллективную ответственность за успех каждой итерации и проекта в целом.
Скрам-мастер отвечает за организацию процесса скрама, за обучение скраму всех участников проекта, за то, чтобы каждый следовал правилам и практикам скрама, за внедрение скрама так, чтобы он и соответствовал культуре компании, и позволял получать ожидаемые преимущества.
Люди, выполняющие эти роли, должны быть преданы проекту. Остальные тоже могут быть заинтересованы в проекте, но они «не на крючке». Скрам четко различает эти две группы и гарантирует, что те, кто несет ответственность за проект, имеют полномочия делать все необходимое для его успеха, а те, кто не несет такой ответственности, не могут вмешиваться в работу первых. В этой книге я называю эти группы людей «цыплятами» и «поросятами» соответственно. Названия пришли из старого анекдота. Цыпленок и поросенок идут по дороге. Цыпленок говорит поросенку: «Хочешь открыть вместе со мной ресторан?» Поросенок поразмыслил и отвечает: «Да, пожалуй. Как ты хотел бы назвать его?» «Яичница с беконом!» — отвечает цыпленок. Поросенок останавливается и, вздохнув, отвечает: «Знаешь, я передумал. Я не хочу открывать такой ресторан с тобой, потому что мне придется отдать себя проекту целиком, а тебе — лишь поучаствовать!»
Это важное различие, поэтому скрам так настойчив в требовании полной прозрачности: всегда должно быть понятно, кто на крючке, а кто просто назойливый советчик. Кто несет ответственность за возврат инвестиций, а кто имеет долю в ROI, но не отвечает за него. Кому придется превратить новую технологию в функциональность, а кто — лишь беспокойный «адвокат дьявола». Скрам проводит явную черту между цыплятами и поросятами, чтобы положить конец неразберихе, и тем самым повышает производительность и создает продуктивный импульс.
Процесс скрама
Скрам-проект начинается с описания видения системы, которую предстоит разработать. Вначале это видение может быть нечетким, выраженным в маркетинговых, а не системных и технических терминах. Однако с развитием проекта оно становится яснее и конкретнее. Владелец продукта отвечает перед инвесторами проекта за разработку и поставку описанной в видении продукта функциональности, которая позволит добиться максимального возврата инвестиций. Владелец продукта создает соответствующий план, в том числе и бэклог продукта — список функциональных и нефункциональных требований, необходимых для реализации описанной в видении системы. Элементы бэклога продукта располагаются в порядке убывания ценности: в верхней части списка расположены наиболее ценные или прибыльные элементы. Бэклог продукта разделен на части — предполагаемые релизы. Такой упорядоченный бэклог продукта — лишь отправная точка, поскольку его содержимое, порядок и группировка в релизы обычно изменяются уже в момент начала проекта. Изменения бэклога продукта отражают изменчивость бизнес-требований и то, насколько быстро или медленно команда разработки превращает элементы бэклога в работающую функциональность.
Вся работа выполняется в спринтах. Каждый спринт — итерация длиной максимум в один месяц — начинается с планирования спринта — события, на котором владелец продукта и команда разработки совместными усилиями определяют, что будет сделано за следующий спринт. Владелец продукта выбирает из бэклога продукта наиболее ценные элементы и рассказывает команде, какой результат хочет получить в конце спринта. В свою очередь команда сообщает владельцу продукта, какие элементы из запрошенной им функциональности она сможет разработать за спринт. Считается, что спринт стартовая, как только началось планирование спринта. Планирование спринта должно длиться не более восьми часов. Событие ограничено по времени, чтобы не затягивать обсуждение и не вступать в бесполезные споры о том, что можно сделать в течение спринта. Цель планирования — договориться и начать работу, а не обдумывать ее снова и снова.
Планирование спринта состоит из двух частей. В течение первых четырех часов владелец продукта рассказывает команде о наиболее важных задачах, расположенных в верхней части бэклога, а команда разработки расспрашивает его о содержании задач, их сути, назначении и целях. Прояснив необходимые детали, команда выбирает только те элементы бэклога продукта, которые сможет разработать за спринт, то есть превратить в готовый к выпуску инкремент продукта. Она обещает владельцу продукта, что сделает для этого все от нее зависящее. В течение вторых четырех часов планирования спринта команда разработки создает план спринта. Поскольку команда сама отвечает за организацию своей работы, ей необходим предварительный план, чтобы начать разработку задач спринта. Все взятые в спринт элементы бэклога продукта и необходимые для их реализации подзадачи составляют бэклог спринта. В течение спринта могут добавляться дополнительные подзадачи.
Ежедневный скрам — это 15-минутное событие команды, которое проводится каждый день в ходе спринта. Его цель — ежедневно синхронизировать информацию о состоянии работы всех участников команды, а также запланировать встречи, которые помогут команде выполнить задачи из бэклога спринта. Для этого участники могут использовать формат трех вопросов, которые позволяют сфокусироваться на цели спринта и командной ответственности:
- Что я сделал с момента окончания предыдущего ежедневного скрама, чтобы помочь команде достичь цели спринта?
- Что я планирую сделать до следующего ежедневного скрама, чтобы помочь команде достичь цели спринта?
- Какие препятствия могут помешать мне и команде достичь цели спринта?
В конце спринта проводится обзор спринта — событие, в ходе которого команда разработки демонстрирует любым заинтересованным лицам результаты выполненной за спринт работы. Обзор спринта должен длиться не более четырех часов. Это неформальное событие, цель которого — совместно обсудить разработанную командой функциональность и определить, над чем нужно работать в следующих спринтах.
После обзора спринта и перед планированием следующего спринта скрам-мастер проводит с командой ретроспективу спринта. Событие должно длиться не более трех часов. Скрам-мастер побуждает команду анализировать и улучшать процесс разработки в рамках фреймворка скрама. Это необходимо, чтобы в следующем спринте повысить эффективность работы и получать большее удовольствие от нее.
Все перечисленные регулярные события (планирование спринта, ежедневный скрам, обзор спринта, ретроспектива спринта) являются формальными возможностями для инспекции и адаптации, на которых основано управление эмпирическим процессом по скраму. Схема процесса скрама представлена на рис. 2.
