Читаем Постигая Agile полностью

Руководитель команды: идея хорошая, но это потребует слишком больших изменений. Запиши ее, и мы проведем ее оценку, когда сможем уложить наш бэклог в шесть месяцев.

Программист: но я могу изменить это за десять минут!

Менеджер проекта: это слишком рискованно. Мы видели, как даже небольшое изменение может вызвать волну ошибок во всей программе. Не волнуйся, мы не говорим тебе «нет», просто не сейчас!

Услышать такое неприятно. Наверняка в следующий раз, если у этого программиста появится отличная идея, он не станет ею делиться.

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

ХР помогает программистам научиться работать с пользователями

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

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

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

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

ХР помогает командам избежать этой проблемы, предоставляя практики, которые помогают создавать базу кода, легко поддающуюся изменениям. (Вы больше узнаете об этом в главе 7.)

Но XP также изменяет представление каждого члена команды о качестве. Качество – не просто способ исключить ошибки. Это возможность предоставить пользователям такое программное обеспечение, которое отвечает их потребностям, даже если это не совсем то, о чем они изначально просили. Традиционные BRUF-команды отделяют проектирование функций (что делает программа) от разработки внутреннего устройства (как она устроена). Функциональность записывается в спецификации, которые затем передаются команде для реализации. Если программистам что-то непонятно или функциональность кажется неверной, они могут задать вопросы тому человеку, который подготовил спецификацию. Затем начинается «игра в испорченный телефон» – автор спецификаций опрашивает пользователей, менеджеров и тех, с кем еще не говорил, и переводит их требования на язык, понятный программистам. BRUF-команды считают это очень эффективным способом, потому что разработчики «не убивают» время на разговоры с клиентами. (Всем известно, что у программистов слабо развиты навыки общения, не так ли?)