Постигая Agile

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

Кент Бек. Extreme Programming Explained: Embrace Change

В главах, посвященных Scrum, была приведена цитата Кена Швабера, объясняющая, что без коллективной ответственности и самоорганизации вы не сможете внедрить этот подход. Теперь вы знаете, как команда, не выполнившая этих требований, идет по пути применения отдельных scrum-практик, но не занимается самоорганизацией, – в итоге получает результат «лучше-чем-ничего».

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

Так откуда же появляются ошибки?

Загляните в любой учебник по разработке программного обеспечения, и вы найдете ответ: переделка[51]. Источников ошибок много, но чаще всего дефекты привносятся в ПО (термин привнесение дефектов вы найдете во многих учебниках по разработке программного обеспечения) именно при переделке. Команда разрабатывает ПО для решения определенных задач, но потом кто-то приходит и говорит, что нужны изменения. Приходится все переделывать: вырезать старый код, вносить изменения в существующий и ставить заплатки нового кода. Именно так чаще всего ошибки попадают в программный продукт.

Но разве нельзя предотвратить такие изменения? Теоретически можно. В том же учебнике по разработке программ есть ответ: документируйте требования к программному обеспечению. Если вы добросовестно собираете требования, записываете их и оцениваете вместе с заказчиками, то можете предотвратить необходимость изменений. Команда способна разработать продукт, наиболее соответствующий всем требованиям пользователей, клиентов и заинтересованных сторон. Конечно, изменения будут, но минимальные!

Однако это в теории.

Но, оказывается, это может работать и на практике. Многие команды создали достаточное количество превосходных программных продуктов, используя четкие требования[52].

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

Именно для таких случаев особенно подходит XP. Оно помогает команде создавать программы таким образом, чтобы внесение изменений наносило наименьший вред исходному коду. Переделка и внесение изменений вполне приемлемы и даже приветствуются, потому что команда пишет код так, чтобы его можно было править.

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