Принципы agile

4.4 Организационные принципы

Организационные принципы воздействуют на управление проектом, расписание работ, организацию команды.

4.4.1 Поставить клиента в центр

"Все мы ориентированы на клиента" – банальное утверждение. Agile разработка придает этой идее некоторую серьезность, требуя включать представителей бизнеса непосредственно в процесс разработки.

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

В agile подходах взаимодействие осуществляется в течение всего проекта. В терминах Бека [Beck 2005]:

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

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

Если клиенты не вовлечены в проект, это рассматривается как одна из наиболее серьезных угроз проекту – построение программной системы, не отвечающей потребностям пользователя. Еще в 1981 году в классической работе Боема [Boehm 1981] "Экономика программной инженерии" приводились примеры систем, в которых все было правильно – надежность, производительность, за исключением маленькой детали – они решали не ту задачу, которая была нужна пользователям. Лутц [Lutz 1993], анализируя ошибки в программных проектах NASA, пишет:

Первичными причинами функциональных дефектов, связанных с безопасностью, являются ошибки в обнаружении и понимании требований (62 % для Вояджер, 79 % для Галилео). Дефекты, возникающие из-за нарушения условий, почти всегда связаны с непониманием требований.

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

Вовлеченность клиентов – это важный вклад agile. Проблема возникает тогда, когда взаимодействие с клиентами заменяет требования. Такой предлагаемый agile подход опасен хотя бы потому, что нет единой сущности – "клиент". Любой серьезный проект включает различные категории сопричастников (термин более общий, чем клиент):

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

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

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

Беку [Beck 2005] знаком риск работы с единственным экспертом:

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

Его ответ на это возражение состоит в следующем:

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

Это спорный аргумент. "Успешная система" может быть так настроена на специфические потребности, что потребуется значительная работа по ее переделке для учета других потребностей. С другой стороны, "система, которая не решает никакой конкретной задачи", может иметь прочную основу и, например, плохой интерфейс, который может быть улучшен. Даже если встать на точку зрения Бека, то это не объясняет, почему беседы с одним экспертом в процессе разработки исключают попытки сбора точек зрения всех сопричастников на определенном этапе проекта. Отрицание такой необходимости довольно безответственно.

4.4.2 Разрешать самоорганизацию команды

В agile подходе у менеджеров отбирается традиционная роль распределения задач и назначения их разработчикам. Здесь верят в способность команды организовать свою собственную работу. Это особенно характерно для подхода Scrum, при котором традиционное понятие менеджера проекта заменяется мощной командой, принимающей собственные решения под контролем "владельца продукта", задающего функциональность продукта, и Scrum-мастера, отвечающего за координацию и устраняющего возникающие препятствия. Подробнее эти роли будут изучаться в следующей главе.

Для многих разработчиков, пострадавших в свое время от плохих менеджеров, этот аспект метода является наиболее привлекательным. В ответ на длинную критическую статью с критикой agile метода один из защитников XP и Scrum пишет:

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

Необходимость в менеджерах, конечно, остается, по-скольку так работают компании и это соответствует словам создателей оригинального метода Scrum (его непрограммной версии): "умный контроль согласуется с самоорганизованным характером команды проекта".

Швабер и Сазерленд [Schwaber 2012], создатели программного Scrum, также придают особое значение умному контролю:

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

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

Может быть, это дело вкуса. Лично я, если уж довелось быть управляемым, то хотел бы знать своего босса, чем считаться самоорганизуемым, а на практике находиться под контролем, использующим тайные методы. Фактически роль менеджеров слабо освещена в agile литературе. Комментарии на эту тему обычно даются в скандально отрицательном стиле: "существует общее неверное представление о их роли в agile проектах…", которое, возможно, истинно, но ничего не говорит нам, почему "неверное представление" ставится на первое место. Более важное рассмотрение – соответствующая роль менеджеров – остается в тени. Швабер и Сазерленд пишут:

Хотя команды, разрабатывающие проект, действуют по собственному усмотрению, они не являются неуправляемыми.

Им вторит Кон:

Общее неверное представление о менеджменте в agile проектах состоит в том, что по причине самоорганизованной команды лидеры играют малую роль или вообще не играют роли. Ничего не может быть далее от истины. В "Биологии Бизнеса" Филипп Андерсон опровергает это ошибочное представление: "Самоорганизация не означает, что работники вместо менеджеров начинают заниматься управлением. Это не означает, что работникам позволительно делать то, что они хотят делать. Это означает, что менеджмент берет на себя обязанность охраны эволюции поведения, возникающего в процессе общения с независимыми агентами, вместо заранее заданной спецификации поведения".

Другими словами, agile менеджеры "управляют", за тем исключением, что они делают не слишком много или делают "несмотря на…".

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

Утверждение Кона, что самоорганизация не означает, что "работникам позволительно делать то, что они хотят делать", вызывает недоумение. Если здесь есть разница, то она слишком тонкая. Дерби в статье, посвященной все тем же "неверным представлениям", уверяет, что "самоорганизуемая" не означает "самоорганизованная":

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

"Создавать новые подходы и адаптировать их при встрече с новыми вызовами" не может не вызывать восхищения. Но что мешает в нормально ведущихся проектах, включая традиционные проекты во главе с менеджером, стиль которого "командуй и контролируй", создавать "новые подходы"? "Самоорганизуемые команды, видимо, более амбициозны. Миттал [Mittal 2013] пишет, что самоорганизуемая команда все же требует существования наставника и тренера, но не требует "команд и контроля".

Хотя наставники и тренеры и в самом деле играют важную роль в agile, как будет видно в следующей главе, негативный характер этого наблюдения снова разочаровывает: "командуй и контролируй" – это то, что традиционно делают менеджеры. Как указывает Кон, они все же должны делать что-то подобное, но полезно было бы знать, что именно.

Хотя ответ нельзя найти в agile литературе, в конечном итоге его можно вывести, пользуясь здравым смыслом. Большинство проектов нуждается в менеджере, исповедующем стиль "командуй и контролируй". Недостаток такой военизированной схемы, где один человек играет эту роль, в том, что при этом сдерживается креативность членов команды. В качестве другого крайнего случая можно рассматривать талантливую команду, которая может быть полностью самоорганизуемой и не нуждается ни в менторах, ни в тренерах.

увеличить изображение
Рис. 4.1. Камерный ансамбль без дирижера I Musici

В мире музыки известным примером является легендарный камерный оркестр I Musici, существующий с 1952 года – один из лучших камерных оркестров мира.

Как о нем сказано в Википедии: "I Musici представляет ансамбль без дирижера. Но отношения между музыкантами таковы, что они создают великолепную гармонию в создании музыки". И действительно! Если собрать вместе группу первоклассных программистов, то они вполне могут работать подобно I Musici. Достаточно глупо пытаться втиснуть их в какие-то рамки. С другой стороны, попросите группу неопытных начинающих музыкантов сыграть вместе – ничего хорошего из этого не получится. Даже профессионалы, собирающиеся для разового выступления, не могут работать таким образом. Вот почему большинство оркестров, даже небольшие ансамбли, нуждаются в дирижере. Большинству команд программистов-разработчиков требуется менеджер проекта.

Уроки, которые можно извлечь из agile подхода к самоорганизующейся команде:

• в ряде случаев опытные и тесно связанные команды ("I Programmatori") могут работать без менеджера, большинство команд должны его иметь;
• некоторые из традиционных для менеджера обязанностей, такие как выбор задач для очередной итерации, могут быть переданы другим членам команды;
• менеджер должен поощрять инициативу членов команды и постепенно двигаться к частичной или полной степени самоорганизованности.

4.4.3 Поддерживайте устойчивый темп

Agile методы настаивают на центральной роли программистов, на необходимости создать им такие условия работы, которые позволили бы полностью раскрыть их потенциал. Из этого, в частности, следует отказ от того, что Эд Жордан в популярной и полезной книге [Yourdon 2003] называет "маршами смерти": практика, при которой менеджмент соглашается на недостижимые, нереализуемые условия – проект с расплывчатыми и растущими требованиями, жесткими контрольными сроками. В результате менеджер пытается давить на команду разработчиков, как следствие – авралы, бессонные ночи, работа без выходных и праздников.

Большое влияние оказала и книга Де Марко и Листера "People Ware" [DeMarco 1999], впервые опубликованная в 1987 году, которая в простых и ясных терминах объясняла, как работают программисты и как важно обеспечить им достойные условия работы.

Кокбурн [Cockburn 2005], в частности, продвигает принцип "персональной безопасности" разработчиков, включающий свободу высказываний. Он заявляет:

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

В духе PeopleWare^{1PeopleWare – известная книга Тома Демарко и Тимоти Листера "Человеческий фактор: успешные проекты и команды".} agilism настаивает на уважении труда программистов, на необходимости обеспечения их хорошими условиями работы. Эти идеи перемежаются с другими аспектами метода: предпочтение устных коммуникаций письменным документам; советом использовать открытые пространства, а не замкнутые офисные кабинки. Шваббер [Schwaber 2004a] описывает, как открытое пространство влияет на атмосферу в компании, рассматривая ситуацию до и после:

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

Компания прислушалась к его советам, и во время следующего спринта:

Все обстояло совершенно по-другому. Люди беседовали, раздавался смех, дружественное общение наполняло рабочее пространство.

Социологические аспекты такого подхода представляются интересными. Мы уже отмечали в первой главе, что agile идеи имеют социальную интерпретацию: "революция офисных работников". Движение agile отражает стремление программистов к самоутверждению, установление примата, верховенство кода над артефактами "Джилберт босса" – планами, моделями и документами.

Дебаты эти не новы. Еще в 1977 году в книге Филиппа Крафта [Kraft 1977], насыщенной марксистским анализом, осуждались предшественники сегодняшних методов "предваряющего анализа" (что включало даже структурное программирование) как попытка менеджмента применять капиталистические методы при производстве программных продуктов и превратить программистов в безгласных пролетариев. Марксистский анализ ушел, сторонники agile беззастенчиво вводят ROI и другие капиталистические штучки, но проталкивание пролетариев-программистов на первые роли остается.

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

• XP и Crystall – это движение за истинную программистскую гордость. Цитируемое выше утверждение Кокбурна типично для этих подходов, фокусируясь на восстановлении чувства собственного достоинства программистов в противовес менеджерам.
• Дух Scrum и Lean отличен. Их методы корнями уходят в индустриальные методы производства; их авторы склонны ссылаться на "Тойоту", превознося производительность и борясь с ненужными затратами.

Примером подхода второй школы может служить рассказ Швабера [Schwaber 2004a], когда, будучи Scrum-мастером, он обнаружил, что ключевой программист исчез, взяв впервые за два года отпуск, и как он наивно полагал, отправившись в Йеллоустонский парк, что стал недоступным для контактов (попытался бы он найти подобное место в Европе). Беззастенчивый Scrum-мастер из-за того, что срывались контрольные сроки проекта, нанял детектива и отловил программиста (попробовал бы он это сделать в Европе), сумев спасти сроки и выдержать темпы проекта. Возможно, такой способ управления можно отнести к "тонким методам управления", но возникает чувство ностальгии по старым добрым временам, когда были менеджеры с их правами, но и установленными границами этих прав. Кажется, в намерение автора входило не только похвастаться бесстрашным стилем управления, но и дать некоторый общий урок. Одурманенному читателю остается гадать, как примирить принципы устойчивого темпа и персональную безопасность Crystal.

Примером приема достижения устойчивости является рекомендуемая XP практика создания запасок (slack), как отмечается в еще одной книге Де Марко [DeMarco 2001]. Бек [Beck 2000] пишет:

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

Далее:

Вы можете создавать запаски разными способами. Одна неделя из восьми может быть "Geek Week^{2Geek Week – неделя на увлечения, хобби, не занятая основным делом. Geek (гик) – программист, увлеченный своим делом.}" неделей. Двадцать процентов еженедельного бюджета может отводиться для задач, выбираемых самим программистом.

Допуск в двадцать процентов – это известная практика в Google.

4.4.4 Разрабатывайте минимальный продукт

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

Дух минимализма в agile выражается в нескольких формах: производить только запрашиваемый продукт, создавать только код и тесты. Давайте проэкзаменуем их, а затем оценим достоинства минимализма.

Создавать минимальную функциональность

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

Лозунг, популярный в экстремальном программировании, – "Тебе Это Не Понадобится" (YAGNI – You Ain't Gonna It), который напоминает нам:

всегда работать над историей пользователя, которую мы имеем, а не над тем, что мы думаем, что это нам понадобится. Даже если мы собираемся это использовать. [Jeffries 2001]

Поппендиксы [Poppendieck 2010] пишут:

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

(Я не знаю, коэффициент 10 является литературным приемом или точной оценкой: в любом случае мне неизвестны опубликованные данные, дающие точные эмпирические оценки на основе проведенных исследований.)

Далее они добавляют:

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

Если код сегодня не требуется, то помещать его в систему – расточительство. Сопротивляйтесь таким искушениям.

Производить только запрашиваемый продукт

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

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

Для методов agile эти цели не считаются важными и, более того, вообще не считаются целями. Целью является разработка продукта, работающего здесь и сейчас. Вот типичные высказывания, иллюстрирующие отрицание всего, что не связано с текущими потребностями. Вард Каннингхэм [Ward Cunningham 2004] пишет:

Нас всегда учили делать настолько много, насколько это возможно. Всегда выполнять проверки. Всегда заботиться об исключениях. Всегда ориентироваться на наиболее общий случай. Всегда давать пользователям лучшие подсказки. Всегда выводить осмысленные и полные сообщения об ошибке. Всегда то, всегда это. Вам приходится делать так много фоновых вещей, что не остается времени на размышления. Я говорю, выбросите все это из головы, и спросите себя: "Какова простейшая вещь, которая может еще выполнять работу?"

Эта фраза: "Делайте простейшую вещь, которая может еще выполнять работу" стала подобно YAGNI (Это Тебе Не Понадобится) еще одной мантрой agile. Рон Джефрис [Jeffries 2001], объясняя, почему не следует заботиться о повторном использовании, пишет:

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

Я строю абстракции, когда они мне необходимы. Если абстракция понадобится мне снова в другом контексте, я приспособлю ее. Но моей целью не является построение вещей для других проектов. Я не пытаюсь зря тратить время и деньги на построения для других проектов.

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

Как и во многих подобных случаях, все начинается совершенно корректно, даже с приведения впечатляющих наблюдений. Проектирование для будущего может отличаться от решения проблемы здесь и сейчас. Проектирование для повторного использования трудное дело. Показательным примером является проектирование класса, описывающего точку в двумерном пространстве. Как можно его обобщить? Можно думать о точках в -мерном пространстве, можно рассматривать любые объекты с двумя координатами (точки, вектора, комплексные числа…) или о любых фигурах в двумерном пространстве (точки, линии, многоугольники). Существует много способов обобщения, и нет способа понять, какое из обобщений будет полезным. В этом случае лучше не пытаться догадаться, каким будет будущее, а дождаться, когда это будущее настанет.

Но из такого наблюдения, имеющего общий смысл, можно ли делать вывод о том, что мы можем забыть об обобщении, "проверках", "исключениях" и повторном использовании? Такие запреты лишь поддерживают плохую практику разработки. Простейшим примером является использование встроенных констант. Вы создаете продукт для небольшой компании, и требуется структура данных, представляющая список сотрудников. Массив из 1000 элементов вполне достаточен, не правда ли? Но компания выросла, и неожиданно ваш продукт загадочным образом перестал работать. Исторические катастрофы, стоящие миллиарды долларов, являлись следствием подходов "давайте делать то, что нам нужно теперь", – ограничение памяти в МS DOS 640 K, Миллениум 2000, начальный размер IP-адресов.

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

Разрабатывайте только код и тесты

Один из наиболее радикальных принципов agile отрицает необходимость всех стандартных продуктов, относящихся к процессу разработки, в частности, отрицает необходимость документов – документов требований, документов этапа проектирования, планов, программной документации, полагая, что они только отвлекают разработчика от основной работы – создания работающего кода и тестов. Вот что можно прочитать [Poppendick 2001]:

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

Под расходными материалами понимается все, что не поставляется пользователю. Все, что не является кодом и тестами, все традиционные артефакты, создаваемые в процессе разработки: технико-экономическое обоснование проекта, записи и видео интервью и семинаров при выработке требований к проекту, документ требований, документы этапа проектирования, презентации Power Point по будущему развитию системы, электронная переписка, UML-диаграммы…

Вот что говорит Бек [Beck 2005], описывая роль архитекторов:

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

Это высказывание совершенно четко является провокационным, поскольку перечисленные задачи имеют весьма слабое отношение к тому, чем традиционно занимаются архитекторы, – определяют архитектуру системы. Здесь изначально предполагается, что строится "простейшая вещь, которая может еще выполнять работу", после чего архитекторы должны выполнить рефакторинг (другими словами, улучшить архитектуру, если она post facto оказалась неудовлетворительной), провести тестирование и подобно любому другому члену команды реализовать пользовательские истории.

Некоторые авторы, хотя и с неохотой, но признают, что поставляться могут не только тесты. Кокбурн [Kockburn 2005], например, пишет, какие артефакты могут приносить выгоду разработчикам:

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

Заметьте, сдержанное "Okay" – некоторые исключения могут быть, но только код и тесты остаются элементами проекта, представляющими истинный интерес.

Минимализм. Оценка

Настаивание на минимальном продукте в трех вышеописанных формах приводит к наиболее абсурдному и вредному вкладу agile методов.

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

Ничто из этого не оправдывает отказ от предваряющего планирования в целом.

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

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

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

Когда 1 октября 2013 года начал действовать закон президента Обамы "О доступном здравоохранении", то, к радости его противников, те, кто им воспользовался, стали жертвами успеха закона. Практически никто не мог им воспользоваться, более того, не мог даже приобрести страховку. Вину списали на высокий уровень активности, но это лишь жалкая отговорка. В конце концов, коммерческие сайты регулярно обрабатывают гораздо большие объемы данных и сталкиваются с большими сложностями. Если только не предположить полную некомпетентность разработчиков, то, похоже, что в процессе разработки и тестирования пользовательских историй все, казалось, хорошо работало. Просто здесь недостаточно хорошо была продумана архитектура и на раннем этапе разработки не убедились, что система хорошо масштабируется.

Еще одной иллюстрацией угроз от такого плохо согласованного подхода может служить эпизод с Боингом. Пример соответствует духу примеров agile – из областей, не связанных с программированием. Исходное развертывание флагмана Боинга 787 Dreamliner было приостановлено из-за угроз, связанных с батареями. Полеты были отменены на несколько месяцев. Джеймс Суровицки так комментировал эту ситуацию в газете "New Yorker":

Решив быстрее поставить свои самолеты пользователям, Боинг построил много экземпляров, не дожидаясь их сертификации Федеральным Авиационным Агентством, разрешающим полеты. Ему пришлось вернуться к модернизации самолетов в соответствии с требованиями ФАА. Если говорят "семь раз отмерь – один отрежь", то в данном случае "дважды строили, один раз проверяли" (как признался мне аналитик из корпорации). Спешка и погоня за снижением стоимости – лучший рецепт нарваться на трудности.

Это только примеры. Но они подтверждают, как наивно ожидать, что рефакторинг может решить все остающиеся проблемы, если то, что уже сделано, работает лишь частично. Эти проблемы могут быть очень трудными, например, если источником проблемы является производительность, то зачастую ее решение требует полного перепроектирования системы. Эмпирические свидетельства подтверждают это предположение. Боем и Тернер [Boehm 2004] пишут:

Эксперименты показывают, что на низкостоимостной рефакторинг нельзя рассчитывать при масштабировании проекта.

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

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

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

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

увеличить изображение
Рис. 4.2. Итальянская лазанья – иллюстрация аддитивной сложности

Аддитивная и мультипликативная сложность: лазанья или лингвини

Несмотря на аргументы в пользу того, что начинать нужно с построения прочного основания, agile методы продолжают продвигать подход "дайте сразу нечто, уже работающее". Типичным примером может служить видео, знакомящее со Scrum, где одетый с иголочки менеджер говорит разработчику, носящему красный шарф и очки пилота:

Я могу жить с чем-то достаточно простым, лишь бы оно работало подходящим образом. Сложность может появиться и позднее.

увеличить изображение
Рис. 4.3. Итальянское лингвини – иллюстрация мультипликативной сложности

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

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

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

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

Памела Зэйв [Zave FAQ] из AT&T, посвятившая большую часть своей профессиональной деятельности изучению свойств взаимодействия, начиная с телекоммуникационного ПО, пишет:

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

Она приводит типичный пример:

Рассмотрим проблему в телефонии: "вызов занятого абонента". Есть несколько способов действий в данной ситуации: переадресовать вызов, прервать разговор, попытаться позвонить позже, предложить вызывающему оставить голосовое сообщение. Предположим, что у нас есть язык описания функций, в котором проблема занятости специфицируется описанием предпринимаемого действия, условием его включения и приоритетом. Предположим также, что разработан специальный оператор, который в момент возникновения ситуации включает действие с наиболее высоким приоритетом.

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

Такие случаи типичны, вот почему мы не можем просто предполагать, что мы будем "делать простейшую вещь, которая может еще выполнять работу", а затем добавлять необходимые функцию. Если так поступать, то придем к коллизиям с ранними разработками, и нам придется все переделывать. Представьте стандартный agile подход к проблеме, основанный на пользовательских историях. Истории пользователей в рекомендуемом agile стиле могли бы быть следующими:

(История # 1) Как исполнительный директор я хочу в случае занятости переадресации вызова моему секретарю.

Немного позже мы вспоминаем о приоритетах и формулируем еще одну историю:

(#2) Как системный администратор я хочу иметь возможность задавать приоритеты различным действиям.

Проходит время и появляется история:

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

(#4) Как ответственный исполнитель я хочу быть уверенным, что по окончании моего разговора я буду связан с вызывающим меня абонентом.

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

У Боба включено свойство "переадресации вызова" – все его вызовы направляются Кэрол. Кэрол установила свойство "не тревожить". Алиса звонит Бобу, вызов направляется Кэрол, ее телефон звонит, несмотря на установленный ею запрет на звонки.

Алиса звонит в группу продаж. Согласно установленной функциональности, вызов попадает к Бобу, телефон которого занят, абоненту предлагается оставить голосовое сообщение. Было бы намного лучше переадресовать в данной ситуации вызов другому члену группы продаж.

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

Это типичные примеры того, почему простой итеративный подход, начинающийся с базисной функционирующей системы, в которую последовательно добавляется новый функционал, может приводить к краху системы. И все же эта мантра остается в agile, выраженная, например, в одной из глав книги Кона [Cohn 2006] цитатой из Поппендик:

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

Для продуктов типа "все перемелется" – возможно, для сложных систем мультипликативного вида, необходим систематический подход. Такой подход включает предвидение, вероятно, дальнее предвидение, и, нравится это или нет, предваряющий анализ.

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

Роль документов

Поппендик пишет:

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

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

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

Критика документов должна основываться на лучших аргументах. Фактически ключевым фактором является изменение. Программный продукт, как нам напоминает Agile Манифест, подвержен изменениям. Если в проекте создаются документы требований и документы проектирования, то трудно сохранить их синхронизацию с артефактом, за которым остается последнее слово, с кодом! У программных продуктов есть важная особенность, отличающая их от всех других продуктов, его уникальность связана с той скоростью, с которой он может изменяться, и с отсутствием издержек при создании копий продукта. Создатели автомобиля не могут работать без планов и документов. Разработав проект автомобиля, они запускают производство, изготавливая многочисленные копии – сами автомобили. Изменение проекта является важным решением, но не самым дорогим. Изменения в изготовлении автомобилей обходятся дороже, так как приходится изменять производственный процесс. Программные системы недаром называются софтом (soft – мягкий). Внести изменения в код нетрудно. Трудно обновлять документы синхронно с изменениями кода. И в этом заключается главная проблема документов требований, проектирования и других документов – они могут не отражать изменения, внесенные в код.

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

Что есть простота?

Еще одна мантра, заслуживающая анализа, – это простота. В предыдущих разделах мы уже изучали специфические последствия поиска простоты: разрабатывать минимальную функциональность не более той, чем это требуют текущие запросы, разрабатывать только код и тесты. Мы видели постоянное акцентирование на "Делайте простейшую вещь, которая может еще выполнять работу" и "Это Тебе Не Понадобится". В заключение этого обзора эджайловского минимализма полезно понять, что концепция простоты может существенно отличаться от ее толкования в agile, где простота понимается как "искусство максимизации работы, которую не следует делать" [A10].

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

В интервью Стива Джобса, которое он дал в 1998 году Business Week, эта мысль хорошо выражена:

Это была одна из моих мантр – фокус и простота. Просто может быть труднее, чем сложно: вы должны много поработать, чтобы мышление прояснилось, и вы нашли простое решение. Но в конечном итоге это стоит делать, поскольку, достигнув результата, вы чувствуете, что можете свернуть горы.

Эту же мысль о совершенстве простоты прекрасно выразил Антуан де Сент-Экзюпери в "Планете людей":

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

Как видно, совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять.

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

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

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

• простота в программировании давно пропагандируется сторонниками строгих элегантных методов такими известными людьми, как Дейкстра, Вирт, Хоар, Грис Парнас; для них поиск простоты часто эквивалентен поиску простых математических моделей программы, что в корне отличается от подхода agile авторов;
• избегать работы, которая не является необходимой, – ключевая тема в agile литературе, как мы видели; в подходе Lean это сводится к принципам: "Исключайте ненужные затраты" и "Откладывайте решение настолько, насколько это возможно".

Обе точки зрения хорошо известны, но не всегда изложены так, как этого хотелось бы авторам agile. В 1995 году Вирт опубликовал статью "Призыв к экономному программированию" (Plea for Lean Software). Заметьте, он использовал слово "экономный" (lean), как и авторы подхода agile. Вирт также критиковал тенденцию, характерную для ряда современных программных систем, аккумулировать бесполезные свойства и рекомендовал писать небольшие когерентные системы, отвечающие ее духу. Но какой ценой достигается простота? Вирт писал:

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

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

Другими словами: следует все хорошо продумать и постараться сделать это как можно раньше.

4.4.5 Принятие изменений

Мир и наше восприятие мира меняются; это же справедливо и по отношению к требованиям к системе. Непосредственное включение потребителей в проект ведет даже к большим запросам на изменение.

Манифест Agile не только допускает изменения, но и приветствует их. Это преувеличение. Справедливо, что изменения – это нормальная практика в разработке ПО, другое дело – приветствовать появление изменений. Для сравнения рассмотрим службу резервации мест в гостиницах booking.com, которая позволяет клиентам изменять сроки резервирования, не штрафуя их. Но трудно себе представить, чтобы служащие компании, приходя по утрам на работу, с нетерпением ожидали бы, чтобы как можно больше клиентов изменили сроки проживания. Разумная политика допускает изменения, но каждое изменение становится причиной дополнительных забот.

Точным признаком того, что методы agile принимают, но не "приветствуют" изменения, как сказано в манифесте, является то, что на практике изменения ограничиваются. Scrum, например, имеет строгое правило (будем называть его правилом закрытого окна) – запрет для владельца продукта и, тем более, для любого другого лица вносить изменения в период спринта – проведения сессии разработки.

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

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

Говорят, что программная система, которая может легко изменяться, обладает свойством расширяемости. Вряд ли это свойство можно назвать новой концепцией. Фактически это одна из центральных тем, обсуждаемая в течение десятилетий. Манифест прав, внедряя в сознание важность и полезность этого свойства. Но проблема эта не столько психологическая, сколько техническая. Какие методы можем мы применять, чтобы быть уверенным, что нам не придется откатываться назад, начиная все с нуля, когда потребитель изменит свой взгляд или изменятся некоторые свойства проблемной области?

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

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

Примером такой идеи, фактически полноценного метода разработки ПО, спроектированного для поддержки расширяемости, является объектно-ориентированное программирование. Его инструменты – абстракция, скрытие информации, наследование, универсализм, полиморфизм, динамическое связывание и другие конкретные механизмы непосредственно спроектированы для облегчения изменений ПО. Поппендик [Poppendieck 2010] утверждает, что ООП этой цели не достигает:

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

ООП критикуют, но ничего лучшего не предлагают. Сам комментарий вызывает недоумение: о каком виде ОО разработки идет речь без подходящего использования скрытия информации – одной из важнейших характеристик метода? Любой подход даст плохие результаты, если его используют люди, глубоко не понимающие его основ или неэффективно его применяющие. Можно ли отвергать идею использования автомобилей, ссылаясь на существование плохих водителей? Или можно ли отрицать метод Lean, предлагаемый авторами, если кто-то будет неправильно его применять. Еще один пример странной agile логики.

Проблема agile не ограничивается такими снисходительными и алогичными комментариями. Некоторые agile практики и принципы напрямую вредят расширяемости. Наиболее поразительный пример – это кампания за минимизацию: стройте только необходимый продукт. Мантра YAGNI (Это вам не потребуется) призывает не включать код, который прямо сейчас не нужен – это лишние траты. Вас убеждают, что не следует пытаться рассматривать наиболее общий случай, а вместо этого программировать здесь и сейчас. Этот подход несовместим с поддержкой изменений. Разработчики, заботящиеся об изменениях, должны пытаться предвидеть развитие и всюду, где возможно, строить больше, чем то, что предлагается сию минуту, предвосхищая будущие изменения.

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

Как и в других случаях, agile критика некоторых общих практик корректна: программистам не следует стремиться включать необоснованные и непроверенные обобщения. Но отсюда не следует, что программисты в профессиональной практике не должны стремиться рассматривать если не наиболее общий случай, то хотя бы случай более общий, чем тот, что отвечает сегодняшним потребностям.

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

Защита изменений, провозглашенная в Манифесте agile, – это правильная цель, но только цель.