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

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

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

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

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

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

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

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

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

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