Введение. Обзор

ПРЕДИСЛОВИЕ К РУССКОМУ ИЗДАНИЮ

С большим удовольствием представляю российским читателям свою книгу "Agile! The Good, the Hype and the Ugly". Перевел ее профессор Владимир Биллиг, ранее сделавший прекрасный перевод моих книг "Object-Oriented Software Construction" и "Touch of Class"^{1Объектно-ориентированное конструирование программных систем. М.: "Русская редакция" и "ИНТУИТ.ру", 2005 г. Почувствуй класс. М.: "ИНТУИТ.ру" и "Бином. Лаборатория знаний", 2011 г.}, за что я ему очень благодарен. Надеюсь, что и это издание в переводе Владимира Биллига будет интересно и полезно читателям.

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

Реакция на английское издание книги "Agile! The Good, The Hype and The Ugly" была потрясающей. Конечно, некоторые энтузиасты agile решили, что я покусился на их "священную корову", но большинство комментариев были одобрительными. Так, один из обозревателей (Т. Андерсон, я с ним незнаком) написал на Амазоне:

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

Вот мнение другого читателя (Comai Adriano, я с ним также незнаком):

Бертран Мейер дал на данный момент лучшую и всеобъемлющую оценку agile методов разработки программных систем. Его книга "Agile!" является редким примером качественной критики в программной инженерии. В традиции лучших образцов литературной и музыкальной критики его критика анализирует произведения (в данном случае наиболее известные agile методы – Scrum, XP, Crystal и Lean), указывая их сильные и слабые стороны, в живой и остроумной манере.

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

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

В России с ее известными софтверными компаниями и разработками мирового уровня agile привлекает особое внимание. Последние годы я работаю не только в Европе и США, но и в России: в 2011–2014 годы – в ИТМО в Санкт-Петербурге, а теперь в университете Иннополис в Казани, где мы создаем амбициозный проект по программной инженерии. О нашей работе и о доступных вакансиях можно узнать на сайте http://university.innopolis.ru/en/research/selab/research.

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

Бертран Мейер Казань, 2015 г.

ПРЕДИСЛОВИЕ РЕДАКТОРА ПЕРЕВОДА

Профессор Бертран Мейер написал книгу по agile, в самом названии которой заключена интрига: Agile – Прекрасный и Agile – Ужасный. Что же прекрасного увидел Бертран Мейер в agile и что ужасного нашел он в нем? Чтобы понять суть agile, стоит прочесть эту книгу.

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

Привлекательны, особенно для молодежи, сами названия методов agile: "Экстремальное программирование" (Extreme Programming), "Схватка" (Scrum), "Экономное программирование" (Lean), "Парное программирование" (Pair Programming). Однако в этой внешней привлекательности есть и обратная сторона.

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

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

Как преподаватель вуза, я рекомендовал бы прочесть эту книгу всем будущим ИТ-специалистам. Она поможет им понять простую истину: для успеха в работе недостаточно обладать специальными знаниями – нужно уметь взаимодействовать с коллегами, быть членами одной команды (взаимодействие важнее собственных знаний!).

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

Книг по agile много. Почему следует прочесть именно эту? Во многом это обусловлено личностью ее автора: в Бертране Мейере сочетаются, казалось бы, трудносочетаемые ипостаси ученого, преподавателя, практика. Бертран Мейер – ученый с мировым именем, автор "Проектирования по контракту", теоретик объектно-ориентированного программирования, создатель языка Eiffel, в котором эти концепции нашли достойное воплощение. Его многостраничный труд "Объектно-ориентированное конструирование программных систем" (оригинальное издание появилось в 1988 году) во многом способствовал утверждению объектно-ориентированного программирования как основного метода разработки программных систем.

Относительно недавно вышедшая книга "Почувствуй класс. Учимся программировать хорошо с объектами и контрактами" обобщает его преподавательский опыт на самой известной в мире кафедре программной инженерии в университете ETH в Цюрихе, которой он руководит. Этой кафедрой долгие годы заведовал Никлас Вирт – создатель серии замечательных языков программирования Euler и Pascal, Modula и Oberon. Хотя на практике преобладают такие языки, как С++, Java, C#, важность и роль "академических" языков, например Pascal и Eiffel, трудно переоценить, поскольку они во многом определяют направление развития.

Немаловажную роль в жизни профессора Мейера играет практическая деятельность. Он является создателем успешно работающей фирмы "Eiffel Software", научное руководство фирмой – часть его повседневной работы. С методами agile Бертран Мейер знаком не только по книгам. Подходы agile с успехом используются в работе его фирмы, а сам он является сертифицированным Scrum-мастером.

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

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

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

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

Владимир Биллиг Тверь, 2015

Введение

Перед вами книга для практиков. Она не для философов, не для теоретиков.

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

Нет ничего удивительного в том, что многие практики пренебрегают требованиями использовать во всей полноте те или иные agile методы – такие как Scrum, eXtreme Programming (XP), LSD (Lean Software Development), Crystal. Индустрии виднее, и каждая agile команда создает свой собственный коктейль из agile практик, отклоняя те, которые не соответствуют специфике разработки. Каждая организация должна повторять этот процесс, отделяя золотой песок от руды. Какая напрасная трата сил! Эта книга поможет вам справиться с трудностями, представляя всестороннее описание и оценку ключевых agile идей.

Описание и оценка

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

Описательный компонент книги важен, поскольку, несмотря на обилие литературы по agile методам, до сих пор, насколько я знаю, невозможно найти полное и точное представление основ agile – идей, не привязанных к конкретному методу, не сводящихся к призывам, напоминающим культовые обряды. Моральные наставления играют полезную роль, но для большинства людей интереснее вникнуть в смысл таких терминов, как "velocity"(скорость разработки), "continuous integration" (непрерывная интеграция), "user story" (пользовательская история), "self-organizing team" (самоорганизующаяся команда), "sprint review" (обзор спринта), "planning game" (игра в планирование). Выяснить смысл этих и других терминов – это то, что я попытаюсь сделать на последующих страницах.

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

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

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

Сохраняя беспристрастность

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

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

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

Литература по agile часто носит характер устрашения, запугивания. Она отклоняет предыдущие подходы как старомодные, пренебрежительно называя их "водопадом" (хотя ни в одной компании модель "водопада" не применяется в чистом виде), создавая впечатление, что всякий, кто поддерживает "старый подход", является закостенелым, консервативным типом. Мы сталкивались с авторами, для которых любая критика agile методов является признаком бюрократии, некомпетентности и посредственности. Само выбранное для подхода имя – agile, то есть "гибкость" – является примером блестящего маркетингового решения. Гениальное решение, заставляющее любого скептика дважды подумать: кто же захочет быть признанным "негибким"? Если в английских словарях поискать антонимы к слову agile, то можно найти такие слова, как awkward (неуклюжий), lumbering (тяжело двигающийся) и ungraceful (неизящный)^{2Слово agile многозначно. Один из переводов – "резвый". В контексте методов разработки ПО используется перевод "гибкий". В русском языке антонимы к слову "гибкий" (упругий, несгибаемый) не носят отрицательного заряда, за исключением, быть может, антонима "жесткий" и отрицания "негибкий".}. Если альтернативы таковы, то и вы, и я, и любой другой захочет быть гибким (agile)!

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

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

Предыдущие попытки

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

• McBreen: "Questioning Extreme Programming" (Макбрин: "Вопросы к экстремальному программированию");
• Stephens and Rosenberg: "Extreme Programming Refactored: The Case Against XP" (Стефенс, Розенберг: "Рефакторинг экстремального программирования: Case против XP");
• Boehm and Turner: "Balancing Agility with Discipline" (Боем, Тёрнер: "Балансирование между гибкостью и дисциплиной".

В первой книге выяснение вопросов производит печальное впечатление, оставляя у читателя неопределенность относительно любых серьезных проблем XP (eXtremal Programming) – экстремального программирования.

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

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

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

Структура книги

Книга имеет простую структуру и предполагает последовательное чтение.

"Введение. Обзор" представляет сводку agile идей и первую общую оценку. Она формирует каркас книги в целом.

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

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

Следующие главы представляют обзор основных agile идей:

• принципы в "Принципы agile" ;
• роли – в "Роли agile" (речь идет о персональных ролях, таких как пользователь или менеджер);
• практики в "Практики agile: производственные процессы" и "Практики agile: технические" ;
• артефакты в "Артефакты agile" , как материальные, так и виртуальные.

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

Если в предыдущих главах главным образом обсуждаются общие особенности, то в главе 9 рассматриваются четыре принципиальные для agile метода: Scrum, Lean, XP, Crystall. Поскольку их общие черты уже рассмотрены в "Принципы agile" , "Роли agile" , "Практики agile: производственные процессы" , "Практики agile: технические" , "Артефакты agile" , то внимание концентрируется на характерной для метода комбинации принципов, ролей, практик и артефактов и, что важно, на духе (spirit) самого метода. Анализ показывает, что каждый из них имеет свою собственную "большую идею", выделяющую его среди других методов и поддержанную рядом дополнительных концепций.

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

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

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

Рамочные ограничения

Любая книга окрашена авторским опытом. Характеризуя свой опыт, могу сказать, что он представляет смесь индустриальной практики (это большая часть моей профессиональной карьеры) и академической работы (в течение последнего десятилетия). Полезно отметить ограничение на содержание – то, что не вошло в эту книгу, – всестороннее описание подходов к разработке ПО. В моих предыдущих книгах описывались методы построения качественного ПО и продвигались специфические подходы, в частности объектная технология и проектирование по контракту. Эта же книга отличается тем, что в ней исследуются работы других людей. Даже тогда, когда я чувствую, что мои работы имеют непосредственное отношение к обсуждаемым вопросам или предвосхищают некоторые из полезных agile идей, я избегаю подобных обсуждений (за исключением нескольких кратких советов).

Анализ: интуитивный, практический, логический или эмпирический

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

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

Не следует снисходительно относиться к внутренней убежденности. В конце концов на этом основана знаменитая статья Дейкстры 1968 года "О вреде оператора Go TO" – родоначальнице всех методологических текстов ИТ. В ней он писал:

Недавно я понял, почему использование оператора go to приводит к таким пагубным последствиям, и теперь я совершенно убежден, что он должен быть изъят из всех языков высокого уровня.

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

Опыт также был использован в качестве аргументов, приводимых Дейкстрой:

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

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

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

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

Что нам крайне необходимо, так это эмпирические свидетельства. Дает ли парное программирование лучшие результаты, чем инспекция кода? Предпочтительнее постоянное общение с заказчиком или строгий процесс формирования требований? Заслуживающие доверия ответы на вопросы методологии построения ПО требуют систематического, тщательного, реалистичного изучения реализации программных проектов. Эта книга основывается на таких результатах в той мере, насколько они доступны, но таковых не столь много. Дающие первые ростки эмпирические исследования в программной инженерии еще не обеспечивают ответы на многие фундаментальные вопросы. Наверное, в этом заключалась основная трудность в подготовке данной книги. Поскольку нет достаточных убедительных эмпирических свидетельств, обсуждение главным образом основывается на рассуждениях. Я не склонен полностью игнорировать свой персональный опыт и случаи из практики, но пытаюсь применять их как иллюстрации к точке зрения, поддержанной логическими аргументами, а также в тех случаях, когда пример может опровергнуть утверждение, претендующее на общность.

О роли критики

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

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

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

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

Бертран Мейер Декабрь, 2013

Благодарности

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

Это предупреждение особенно относится к первой группе людей – авторам лучших agile книг, которым я высказываю свою благодарность, хотя, повторяю, некоторые из них могут не во всем со мной соглашаться. Я многое узнал, читая об agile методах, в частности, нахожусь в долгу перед Кентом Беком (Kent Beck), Майклом Коном (Mike Cohn), Крейгом Ларманом (Craig Larman), Кеном Швабером (Ken Schwaber) и Майклом Беедли (Mike Beedle), Барри Боэмом (Barry Boehm) и Рихардом Тернером (Richard Turner), Алистером Кокбурном (Alistair Cockburn). Я многим обязан моему первому проводнику в мире agile – прекрасной презентации по Экстремальному Программированию, сделанной Питом Мак-Брином (Pete McBreen) на летней школе в 1999 году. Я благодарен Майклу Кону (Mike Cohn) за пояснения к одному из его текстов. Я получил несомненную пользу от отличного семинара по Scrum, организованного Джефом Сазерлендом (Jeff Sutherland) в Москве, на котором, говорю с гордостью, стал сертифицированным agile специалистом – Certified Scrum Master.

В университете ETH мною были организованы несколько семинаров по этой тематике для ИТ-специалистов, и комментарии их участников, несомненно, были полезны. Я благодарен Ральфу (Ralf Gerstner) из издательства Шпрингер (Springer) за советы при расстановке акцентов в этой книге.

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

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

Я использую в книге некоторые материалы, ранее опубликованные в блоге bertrandmeyer.com и в моем блоге на сайте Communications of the ACM (cacm.acm.org/blogs/blog-cacm), и благодарен читателям за комментарии, сделанные к статьям, размещенным в этих блогах.

Я признателен членам кафедры программной инженерии (Chair of Software Engineering at ETH Zurich) за многочисленные дискуссии по основам инженерии программ. Признателен всем, но особо хочу отметить, что замечания Тила Бэя (Till Bay) были той искрой, которая привела процесс разработки EiffelStudio на переключение к agile стилю временных рамок (time-boxed release). Марко Пиккони (Marco Piccioni) был первым, кто привлек мое внимание к Scrum. Марко сделал также ряд важных замечаний к тексту рукописи.

В университете ETH нами разработан курс "Распределенная лаборатория программной инженерии" (Distributed Software Engineering Laboratory), в котором десятки студентов всего мира совместно работают над распределенными проектами. Инструкторами курса вместе со мной уже несколько лет являются Питер Колб (Peter Kolb) и Мартин Нордио (Martin Nordio), сделавшие немало полезных замечаний, как и ассистенты Роман Милтин (Roman Mitin), Джулиан Тшанен (Julian Tschannen), Кристиан Эстлер (Christian Estler). Немаловажна и роль студентов.

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