Постигая Agile

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

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

Другими словами, BRUF позволяет создавать то, что вы задумали, а XP – то, что действительно нужно пользователям. И все счастливы: члены команды – потому что могут тратить время на решение реальных проблем, а не бороться с кодом, внося в него правки, а пользователи – потому что получают то, что им действительно нужно (а не то, что они хотели полгода назад). В результате формируется команда, включающая пользователей, клиентов и стейкхолдеров. Им не нужно предугадывать, что потребуется через полгода, а можно сосредоточиться на создании ПО, соответствующего текущим нуждам.

Так как же XP добивается этого?

Практиковать только метод кнута, если команда действительно в него верит

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

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

Рис. 6.3. Очень распространенная реакция на внедрение XP заключается в том, что, хотя в теории это звучит хорошо, на практике парное программирование и разработка через тестирование «непригодны для нашей команды». Это не обязательно аргумент против данных практик, а скорее предчувствие сложности их реализации

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

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