Дж.Ханк Рейнвотер - Как пасти котов. Наставление для программистов, руководящих другими программистами

«При помощи ХР заказчики и руководители смогут каждую неделю разработки получать максимальный результат. С регулярностью в несколько недель они будут оценивать конкретный результат работы над решением задач, которые для них наиболее важны. Корректировать направление разработки проекта можно будет в самый разгар трудовой деятельности программистов, причем никаких сверхъестественных затрат на это не потребуется» [119] Kent Beck, Extreme Programming Explained (Reading, MA: Addison-Wesley, 2000), p. xvi. Русский перевод книги доступен на http://lib.rus.ec/b/101297 (прим. сост. FB2) .

Каким образом метод ХР реализует эти перспективы? Путем введения ряда принципов программирования, которым группы должны следовать неукоснительно. Вместо того чтобы перекладывать отдельные аспекты разработки на руководящее звено, метод ХР концентрируется на функциях собственно программистов, то есть на конструировании программных продуктов.

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

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

Буква «X» в аббревиатуре ХР означает «экстремальный». Эту характеристику многие деятели нашей индустрии признали вполне удачной. Впрочем, есть и такие, которые, уважая суть концепции, с некоторым презрением относятся к ее названию [120] См. колонку «Feedback» в журнале Software Developments за ноябрь 2001 года. . По-моему, в публикациях, посвященных этой «новой» методологии, равно как и в практической деятельности по реализации ее принципов, очень много полезного. Полагаю также, что материалы сайта http://www.extremeprogramming.org помогут вам сориентироваться в том, какие методы этого заметного (пожалуй, даже крикливого) течения стоит принять на вооружение. Хотя, если уж следовать духу ХР, получается, что вычленять из этой методологии отдельные элементы или смешивать ее с другими стилями нельзя – либо вы «экстремал», либо нет. Меня на это не купишь, хотя мотивация мне вполне понятна. Поборники экстремального программирования пытаются сказать примерно следующее: «Либо дисциплинируйтесь, либо убирайтесь из профессии – вам в ней нечего делать!» Вот это мне по душе – надеюсь, и вам тоже.

В поисках новых методов для себя и своей команды вам еще не раз предстоит столкнуться с термином «гибкий» (agile). Любой эффективный метод разработки программного обеспечения является таким по свой природе. Гибкость означает способность к адаптации, к изменяющимся требованиям и развивающейся технологии, в том числе на этапе конструирования проекта. Мнения большинства специалистов в области разработки программных средств сходятся в одном: гибкость – это священный Грааль всех методик разработки. Существует даже общественная организация, состоящая из ведущих специалистов по разработке программных продуктов и ставящая своей целью пропаганду концепции гибкости [121] См. http://www.AgileAlliance.org. . Эти деятели даже опубликовали манифест, в котором обозначены четыре основные проблемы, свидетельствующие, в зависимости от решения, о гибкости тех или иных методов [122] См. Alistair Cockburn, Agile Software Development (New York: Addison-Wesley, 2002), Appendix A. .

1. Отдельные лица и взаимодействие или процесс и инструментальные средства.