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

Эта книга – прекрасное руководство для тех, кто хочет улучшить процесс разработки программного обеспечения. Я настоятельно рекомендую ее!

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

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

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

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

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

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

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

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

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

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