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

2. Функционирующее программное обеспечение или комплексная документация.

3. Сотрудничество заказчиков или переговоры по контракту.

4. Реакция на изменения или следование плану.

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

Между так называемой «гибкой» школой и экстремальным программированием много параллелей. Действительно, в совещании, на котором был принят манифест гибкости, участвовали, помимо прочих, основатели концепции ХР. На самом деле методология гибкости – это, скорее, совокупность принципов, применимая к любым процессам и мероприятиям в области планирования, направленным на конструирование программных средств. В главе 6, рассуждая о методах технического проектирования, я упомянул термин [123] Этот термин взят из одноименной книги Джима Хайсмита (Jim Highsmith). См. библиографию. «адаптивная разработка программных средств», имея в виду деятельность, обусловливающую ваш успех в роли технического лидера. Так вот, адаптивная разработка тоже происходит от гибкости.

Мнения большинства специалистов в области разработки программных средств сходятся в одном: гибкость – это священный Грааль всех методик разработки.

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

«Некоторые считают, что необходимым условием успешности проекта является следование заданному процессу. Те, кто придерживается такого мнения, тратят уйму энергии на проверку его соблюдения. Человек, твердо убежденный в том, что именно в процессе вся суть, может очень долго не обращать внимания на несоответствие между практикой следования процессу и его исходом» [124] Cockburn, op. cit., p. 5. .

Иначе говоря, методология гибкости снимает с нас шоры и открывает глаза на те вещи, которые рабы процесса не замечают.

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

Я крайне рекомендую вам порыться в литературе, посвященной гибким методам. Ресурсов по этому вопросу великое множество [125] Примеры приводятся в работе Cockburn, op. cit. Обзор имеющихся ресурсов имеется также на сайте http://www.adaptivesd.com. . Не менее важно оценивать по стандарту гибкости те методы, которыми вы пользуетесь в данный момент. Представьте себе ситуацию, в которой плохо сформулированное коммерческое требование уточняется ближе к сроку завершения кодирования. Сможет ли ваша группа отреагировать на такое изменение без недопустимых задержек? Когда требования меняются во время цикла разработки, большинство из нас проклинают все вокруг. Тем самым мы пытаемся дистанцироваться от реального положения вещей – ведь чем глубже мы разрабатываем проблему реализации требования, тем больше двусмысленности обнаруживаем, а значит, возвращаемся к этапу определения продукта. Гибкие методы культивируют определенное восприятие неопределенности.

Приведенный обзор методологий разработки приводит, как мне кажется, к единственному выводу – разрабатывать программы должны не инженеры, а мастера. Понятие мастерства не всегда легко поддается осмыслению. Я пришел из академической науки и на раннем этапе своей деятельности занимался инженерией; по этой причине я сперва отказывался признавать приоритет искусства перед наукой в процессе создания программных средств. Впрочем, вскоре я понял, что «сопротивление бессмысленно» [126] Похоже на «Звездные войны» правда? . Посмотрим, под каким заголовком вышел один из ведущих технических журналов в 1990 году [127] Как вы помните, тогда не было ни Windows, ни графических пользовательских интерфейсов. :