В поисках новых методов для себя и своей команды вам еще не раз предстоит столкнуться с термином «гибкий» (agile). Любой эффективный метод разработки программного обеспечения является таким по свой природе. Гибкость означает способность к адаптации, к изменяющимся требованиям и развивающейся технологии, в том числе на этапе конструирования проекта. Мнения большинства специалистов в области разработки программных средств сходятся в одном: гибкость – это священный Грааль всех методик разработки. Существует даже общественная организация, состоящая из ведущих специалистов по разработке программных продуктов и ставящая своей целью пропаганду концепции гибкости[121]. Эти деятели даже опубликовали манифест, в котором обозначены четыре основные проблемы, свидетельствующие, в зависимости от решения, о гибкости тех или иных методов[122].

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

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

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

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

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

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

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

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

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

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

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

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

В статье под этим заголовком речь идет о зрелости программных продуктов (см. главу 6, в которой упоминается модель оценки зрелости продуктов) и количестве ошибок в расчете на строку кода. Там обсуждаются методы измерения количества ошибок, но совершенно не уделяется внимание наиболее важной проблеме: программные продукты создают люди, а отнюдь не процессы, исполняемые автоматами.

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

Кто создает программные продукты? Мастера. Осознав, что мастера совершенно не пренебрегают наукой и инженерией, вам будет легче признать, что искусство (мастерство) главенствует над научным подходом. Рекомендую поразмыслить над тем, как нам всем прийти к достойному балансу искусства и науки/инженерии в себе, чтобы обеспечить превращения кода в полезные и качественные программные продукты. Я абсолютно согласен с Питом Макбрином (Pete МсВгееп) в том, что он пишет в предисловии к своей книге по мастерству разработки программных продуктов: