Скрам

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

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

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

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

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

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

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

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