С большим удовольствием представляю российским читателям свою книгу "Agile! The Good, the Hype and the Ugly". Перевел ее профессор Владимир Биллиг, ранее сделавший прекрасный перевод моих книг "Object-Oriented Software Construction" и "Touch of Class"
Я написал эту книгу, так как понимал важность некоторых из 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.
Я вижу, как много в России талантов и креативных идей в нашей интереснейшей области работы. Надеюсь, что данная книга будет способствовать дальнейшему развитию.
Профессор Бертран Мейер написал книгу по 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 подходами. Эта книга будет интересна не только профессионалам, но, как и другие книги профессора Бертрана Мейера, и широкому кругу читателей, являясь примером книги высокой общечеловеческой культуры, выходящей за пределы мира программных систем.
Перед вами книга для практиков. Она не для философов, не для теоретиков.
Ее цель – дать возможность разработчикам ПО, ИТ-менеджерам, преподавателям оценить преимущества хороших идей 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 (неизящный)
Но имя – это просто имя; мы же должны без всяких эмоций, шаг за шагом дать оценку конкретным принципам и практикам, которые стоят за ним.
Оценка усложняется экстремизмом. Проектировщики ряда методов упорно настаивают, что их методы следует применять в полном объеме. Не все проповедуют принцип "все или ничего": подход Crystal, например, не столь жесткий. Но превалирование этого принципа характерно для многих основополагающих книг по agile, что усложняет понимание того, какие приемы будут работать в вашем проекте с пользой, а какие нет.
Среди многих книг по agile методам я знаю только три, в которых отсутствует тон преклонения:
В первой книге выяснение вопросов производит печальное впечатление, оставляя у читателя неопределенность относительно любых серьезных проблем XP (eXtremal Programming) – экстремального программирования.
Вторая книга чувства печали не создает – это памфлет, забавный и назидательный, но, как и всякий памфлет, он, скорее, выявляет абсурдность утверждений, чем выполняет серьезный анализ всех аргументов "за" и "против".
Наиболее серьезная попытка такого анализа предпринята в третьей книге. Здесь сопоставляются agile подходы и традиционные методы планово-управляемой разработки, характерные для инженерии ПО. Достоинство этой книги в том, что она основана на эмпирических данных, позволяющих сравнивать эффективность agile методов и их классических двойников. По-моему, в книге слишком заметна осторожность в суждениях, возможно, потому, что Боем – весьма уважаемая фигура в мире ИТ – боится прослыть защитником "старого порядка", так что авторы избегают резких критических суждений.
В данной книге не ожидайте такой робости (упоминаю об этом на тот случай, если вас это может беспокоить). Уважение – есть, почитания – нет. Все хорошие идеи будут выявлены и получат заслуженную хвалу. Но всякий раз, когда мы столкнемся с вздором и чепухой, будет ясно сказано, что это вздор и чепуха.
Книга имеет простую структуру и предполагает последовательное чтение.
Следующие главы представляют обзор основных agile идей:
Мы не фокусируем внимание ни на каком конкретном agile методе – нас интересуют концепции и инструменты, общие для всех или почти всех методов. Этот подход высвечивает то общее, что присуще разным методам, и позволяет проэкзаменовать agile идеи в чистом виде, давая возможность решить, какие из них являются подходящими в конкретном контексте. Некоторые идеи являются специфическими и применимы только к одному методу.
Если в предыдущих главах главным образом обсуждаются общие особенности, то в главе 9 рассматриваются четыре принципиальные для agile метода: Scrum, Lean, XP, Crystall. Поскольку их общие черты уже рассмотрены в главах 4, 5, 6, 7, 8, то внимание концентрируется на характерной для метода комбинации принципов, ролей, практик и артефактов и, что важно, на духе (spirit) самого метода. Анализ показывает, что каждый из них имеет свою собственную "большую идею", выделяющую его среди других методов и поддержанную рядом дополнительных концепций.
Любая книга окрашена авторским опытом. Характеризуя свой опыт, могу сказать, что он представляет смесь индустриальной практики (это большая часть моей профессиональной карьеры) и академической работы (в течение последнего десятилетия). Полезно отметить ограничение на содержание – то, что не вошло в эту книгу, – всестороннее описание подходов к разработке ПО. В моих предыдущих книгах описывались методы построения качественного ПО и продвигались специфические подходы, в частности объектная технология и проектирование по контракту. Эта же книга отличается тем, что в ней исследуются работы других людей. Даже тогда, когда я чувствую, что мои работы имеют непосредственное отношение к обсуждаемым вопросам или предвосхищают некоторые из полезных agile идей, я избегаю подобных обсуждений (за исключением нескольких кратких советов).
Методология ПО – это своего рода искусство, поскольку в данной области трудно что-либо доказать. Многие идеи воспринимаются лишь благодаря силе авторской убежденности. И это не означает, что идеи хороши или плохи. Авторы используют четыре вида аргументов:
Не следует снисходительно относиться к внутренней убежденности. В конце концов на этом основана знаменитая статья Дейкстры 1968 года "О вреде оператора Go TO" – родоначальнице всех методологических текстов ИТ. В ней он писал:
Недавно я понял, почему использование оператора go to приводит к таким пагубным последствиям, и теперь я совершенно убежден, что он должен быть изъят из всех языков высокого уровня.
Но если вы не Дейкстра, то ваше внутреннее чувство вряд ли поможет убедить все сообщество программистов.
Опыт также был использован в качестве аргументов, приводимых Дейкстрой:
В течение ряда лет мои наблюдения показывали, что качество работы программистов представляет функцию, убывающую в зависимости от плотности операторов go to в программах, которые они производят.
Аргументы, основанные на опыте, являются любимым средством agile авторов. Типичная agile книга содержит последовательность перемежающихся общих наблюдений, случаев из практики спасения проектов (спасенных, как правило, автором) и проектных неудач (неудач вследствие того, что не следовали советам авторов). Эти случаи из практики обычно развлекательны, иногда назидательны. Учебный пример – это всего лишь учебный пример, и мы никогда не знаем, насколько он допускает обобщения. В конечном итоге каждый может привести пример в поддержку практически любой рекомендации.
Примеры могут иметь доказательную силу, но только в одном случае – когда опровергают общее утверждение, касающееся всех случаев. Если такое утверждение высказывается, то достаточно единственного примера для его опровержения. Например, если кто-то, допустим, Аристотель, утверждает, что скорость падения зависит от массы тела, то достаточно подняться на Пизанскую башню, как это сделал Галилей, сбросить два тела – тяжелый и легкий шары – и убедиться, что тела достигнут земли в один и тот же момент времени.
Логический вывод является мощным инструментом. Он сыграл важную роль в выводах, сделанных Дейкстрой. Некоторые авторы утверждают, что Галилей не поднимался на башню, а доказал свою гипотезу, проведя исключительно мысленный эксперимент. Но логический вывод правомерен настолько, насколько правомерны гипотезы, лежащие в его основе; всегда существует риск, что вывод будет иметь чисто академический интерес.
Что нам крайне необходимо, так это эмпирические свидетельства. Дает ли парное программирование лучшие результаты, чем инспекция кода? Предпочтительнее постоянное общение с заказчиком или строгий процесс формирования требований? Заслуживающие доверия ответы на вопросы методологии построения ПО требуют систематического, тщательного, реалистичного изучения реализации программных проектов. Эта книга основывается на таких результатах в той мере, насколько они доступны, но таковых не столь много. Дающие первые ростки эмпирические исследования в программной инженерии еще не обеспечивают ответы на многие фундаментальные вопросы. Наверное, в этом заключалась основная трудность в подготовке данной книги. Поскольку нет достаточных убедительных эмпирических свидетельств, обсуждение главным образом основывается на рассуждениях. Я не склонен полностью игнорировать свой персональный опыт и случаи из практики, но пытаюсь применять их как иллюстрации к точке зрения, поддержанной логическими аргументами, а также в тех случаях, когда пример может опровергнуть утверждение, претендующее на общность.
По своей сути эта работа предполагает критические комментарии. Следует сказать несколько слов о духе, в котором они написаны.
Прогресс в науке и инженерии основывается на свободном, критическом анализе предыдущих работ. Анализируя литературу по agile, я обнаружил несколько поводов для несогласия с авторами, а в некоторых случаях был просто шокирован. Я не столь робок, чтобы бояться подвергнуть их притязания проверке.
Нужно заметить, что я нашел также элементы, достойные восхищения, и воспринял ряд новых положений в разработке ПО.
Ни в коем случае критика не означает неуважение. Пионеры agile – это опытные профессионалы, со всей страстью отдающиеся делу развития ИТ. Даже полагая, что они ошибаются, я ценю их точку зрения и разделяю их страстность. Мы все в одной лодке,
Так как в этой книге осуждаются некоторые 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). Немаловажна и роль студентов.
Курс привел к нескольким опубликованным эмпирическим исследованиям, которые существенно помогли в моей работе.
Появление идеи agile датируется 1990 годом и связано с разработкой XP – экстремального программирования, но слава пришла к agile после опубликования манифеста в 2001 году [Agile 2001].
(рис 1.1) Agile-манифест разработки программного обеспечения
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, непосредственно занимаясь разработкой и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
То есть, не отрицая важности того, что справа, мы всетаки больше ценим то, что слева.
|
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler |
James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick |
Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas |
Создатели Agile-манифеста опубликовали этот документ на фоне, изображающем полдюжины мужчин среднего возраста, носящих джинсы, располневших, повернувшихся к нам спиной, слушающих оратора, видимо, рассказывающего об agile-манифесте. Все это должно символизировать неотразимую силу призыва, содержащегося в манифесте. Лично я, когда хотел выразить сущность agile, то выбрал фотографию, представленную на обложке этой книги (балерина Наталья Осипова в "Лебедином озере"), что может говорить о том, насколько я не иду "в ногу со временем". Эта фотография прекрасна.
Идеи agile подняли шумиху в индустрии, стали находкой для технической прессы, явились тем видом аргументов, которые в жестком соперничестве компании использовали для привлечения лучших программистов: "Приходите к нам! Наши разработки – agile!" Не будучи единой концепцией, под agile понимается совокупность идей, содержащихся в нескольких методах, применяемых в разнообразных вариациях. К ним относятся, в частности, такие методы, как экстремальное программирование (eXtremal Programming -XP),
Принципы следуют из предпосылок. Практики, роли, артефакты следуют из принципов. В последнем параграфе (1.6) дается первая оценка подхода.
Эта глава представляет своего рода концентрат всей книги, инспекторский обзор ключевых идей. За исключением последнего параграфа, она носит описательный характер, нейтрально представляя agile идеи. Для краткости, обобщенное описание agile методов дается здесь без ссылки на какие-либо источники. В последующих главах приводятся пространные цитаты agile авторов, где они детально обосновывают методы.
Из текста agile манифеста с очевидностью следует, что agile – это не просто собрание ряда методов, а некоторое движение, идеология. Прежде чем рассматривать специфические принципы, практики, роли и артефакты, следует проникнуться духом agile философии. Она базируется на пяти доктринах или предпосылках.
Первая доктрина связана с фундаментальной проблемой: каковы
Переопределение ролей касается и потребителей ПО, тех, кто в agile мире не является пассивными фигурами, молчаливо потребляющими произведенный продукт. Потребители в этом мире – активные участники процесса разработки, выступающие в роли заказчиков. В большинстве agile методов потребители включаются в команду разработчиков.
Вторая доктрина связана с отказом от "Предваряющего анализа" и веры в то, что все следует предусмотреть. Порицая существующие методы разработки ПО, в agile мире их называют "Предваряющий анализ" (Big Upfront). Под этим понимается экстенсивное планирование в начале проекта, включающее:
С точки зрения agile:
Вместо документа требований agile методы рекомендуют постоянное взаимодействие с потребителями (customers) – заказчиками и пользователями. Как следствие, представители потребителей включаются в состав команды, что, с одной стороны, дает возможность им посмотреть "изнутри" на возникающие проблемы, а с другой – позволяет команде быстро реагировать на эти проблемы, имея обратную связь.
Вместо этапа проектирования agile предлагает строить систему итеративно, находя на каждом шагу "наиболее простое решение, отвечающее целям работы" (девиз экстремального программирования).
Если в процессе разработки решение перестает работать или становится неэффективным, выполняется рефакторинг – изменение проекта, устраняющее неэффективность.
Как следствие, agile процесс является итеративной разработкой с временными рамками. Ближайшая альтернатива документу требований – список функций с расставленными приоритетами, из которого команда выбирает функции для реализации на итерации, исходя из критерия максимизации "Возврата Инвестиций" – ROI (Return On Investment). Вследствие отсутствия "больших" задач этот выбор делается последовательными шагами, называемыми итерациями ("спринтами" в Scrum), каждый из которых занимает фиксированное время – не более нескольких недель, отсюда – "с временными рамками". В процессе разработки итеративно добавляется функциональность. Каждое добавление представляет ограниченную договорную функциональность. Литература agile изобилует причитаниями по поводу того, что при традиционном проектировании создается множество свойств, которые вряд ли кто-либо будет использовать. Стратегия agile предлагает радикально ограничивать функциональность, оставляя лишь наиболее важные свойства, оцениваемые их вкладом – их ROI. Экономное программирование – LSD ссылается на опыт, полученный в других видах деятельности, в частности, в автомобильной промышленности, где "минимизация расточительности" является одной из ключевых проблем. Система "Канбан" (Kanban), разработанная японской фирмой "Тойота", обеспечивает поставку продукции заданного качества точно в указанные сроки при минимизации затрат на всех этапах процесса работы.
На каждой итерации при выборе функциональности требуется "договоренность". С позиций agile, как невозможно в начале разработки сформулировать все требования к системе, точно так же невозможно обеспечить одновременно желаемую функциональность и выдержать сроки поставки. Для разработки с "временными рамками" достижение компромисса (вы хотите все или вы хотите получить нечто уже в следующем месяце?) достигается обычно выбором второго решения. Если не все функции, планируемые на итерации, могут быть реализованы в заданный срок, то урезается функциональность, а не передвигается срок исполнения. Пропущенная функциональность либо будет реализована на следующем шаге, либо (если последующий анализ ROI покажет ее неэффективность) будет опущена. Этот процесс планирования и согласований требует постоянных договоренностей с потребителями.
Заключительной доктриной является фокусирование на качестве, которое с точки зрения agile сводится к непрерывному тестированию (в отличие от других подходов к обеспечению качества, в частности, основанных на методах проектирования, формальной методологии, презрительно называемой "Предваряющий анализ").
Здесь мало внимания уделяется обеспечению качества в традиционном понимании, зато крайне отрицательно относятся к попыткам продолжать разработку, если уже созданный код не прошел всестороннее тестирование. Одним из вкладов гибкой разработки является повышение внимания к
Оставшаяся часть книги исходит из того, что следующие восемь принципов (три из которых являются частичными принципами) составляют agile канон.
Организационные
Эти принципы следуют из пяти "общих предпосылок", рассмотренных в предыдущем параграфе, преобразуя предпосылки в фактические предписания.
Это не те двенадцать принципов, которые перечислены в Agile манифесте. Те, официальные принципы, обсуждаемые в последующей главе, менее подходят для анализа. Они избыточны, комбинируют идеи различных уровней, ставят на одну доску пожелания (Строить проекты с командой высокомотивированных личностей, кто с этим станет спорить) и избыточно конкретизированные правила, такие как выпускать очередной релиз ПО в срок от двух недель до двух месяцев. В официальных принципах отсутствуют некоторые ключевые идеи, как например, ключевая роль тестов. Восемь принципов, представленных здесь, обеспечивают лучшую абстракцию.
Пять принципов руководят организацией и управлением agile проектов.
Как сказано выше, agile разработка представляет итеративный процесс, состоящий из последовательного выполнения итераций. Каждая итерация совершенно короткая – несколько недель, ее результатом является рабочий релиз системы, возможно, носящий довольно частный характер. Представители пользователей могут провести испытания, результат которых может стать источником новых идей для следующей итерации. Scrum вводит важное правило – замораживание требований на время выполнения итерации. Если идея новой функции появляется во время разработки, то рассмотрение нового свойства откладывается до новой итерации.
Первенство тестов представляет воплощение подхода к достижению качества. Этот принцип имеет два следствия. Поскольку оба следствия важны, их можно рассматривать как частичные принципы:
Последний принцип – использование сценариев для определения функциональности – составляет еще одну часть замены требований. Сценарий представляет описание варианта взаимодействия пользователя с системой. Например, при проектировании системы для мобильных телефонов описание сценария разговора по телефону начинается от момента вызова абонента до момента разъединения. "Сценарий" не является общепринятым agile термином, но покрывает такие agile понятия, как варианты использования (use cases) и пользовательские истории (user stories), отличающиеся уровнем гранулярности. Вариант использования – это описание законченного взаимодействия, а пользовательская история – более мелкая единица по функциональности. Сценарии приходят от потребителей и определяют фундаментальную функциональность системы с их точки зрения. Собрание сценариев, в частности, пользовательских историй, отличается от традиционных требований по двум фундаментальным аспектам:
В главе 4 организационные и технические принципы agile будут обсуждаться в деталях.
Методы agile определяют роли различных действующих лиц (actors) в программных проектах.
Первая и наиболее важная роль отводится команде – самоорганизующейся группе разработчиков и других членов команды (таких как представители потребителей). Команда ответственна за распределение задач между членами команды.
Scrum идет дальше в определении новых ролей с обязанностями традиционных менеджеров. Определение свойств программного продукта возлагается на владельца продукта (product owner). Он получает право изменять свойства продукта при одном важном ограничении, никакие изменения не допускаются во время итерации (спринт в Scrum). Менеджерские обязанности – консультанта, тренера, ментора, гуру, администратора – возлагаются на Scrum-мастера, который не может быть одновременно владельцем продукта.
Общим для всех agile методов является включение такой роли, как
Экстремальное программирование, по меньшей мере, в его ранних версиях, предписывало встраивать потребителей в команду как ее полноценных членов. Это положение легко декларировать, но трудно воплотить на практике. Возникающие при этом проблемы будут в дальнейшем проанализированы. Но даже если кто-то не следует этому правилу буквально, для всех agile проектов роль потребителя крайне важна. В главе 5 эта и другие роли будут обсуждаться подробнее.
Для достижения принципов, представленных выше, agile методы применяют множество приемов, или практик (practice).
Организационные:
Технические
Все agile методы выступают за частые контакты (встречи лицом к лицу). В частности, Scrum включает требование ежедневных встреч в начале рабочего дня, известных как "ежедневный Scrum". Встреча должна быть короткой: 15 минут – типичный вариант. Эта цель достижима для групп из 10–15 человек, поскольку рамки встречи строго ограничены. Каждый член команды должен ответить на три вопроса:
Никакие другие вопросы не обсуждаются, в том числе и то, как преодолеть возникшие нетривиальные помехи. Такая форма ежедневных встреч применима тогда, когда вся команда расположена в одном месте. Она помогает согласованию усилий в команде: каждый знает, что делается, возникающие проблемы выявляются на ранних стадиях.
Любая разработка ПО сталкивается с проблемой планирования, в частности, с проблемой компромиссного планирования функциональности и сроков ее реализации. Методы agile предлагают "игру в планирование" (planning game в XP) и "планирующий покер" (planning poker в Scrum). Оба варианта представляют вариации группового оценивания, где участникам предлагается вначале дать свою независимую оценку, затем проанализировать оценки других участников игры, затем итеративными шагами прийти к консенсусу.
Наиболее убедительной является концепция непрерывной интеграции. Лет десять–двадцать тому назад не было ничего необычного в том, чтобы разделять систему на подсистемы и объединять независимо разрабатываемые подсистемы с интервалом в несколько месяцев. Это было ужасно, так как при попытке интеграции зачастую возникали ситуации несовместимости подсистем и приходилось прилагать много усилий для достижения их согласования. Современная практика разработки, включающая agile подходы, сводится к частой интеграции – не реже нескольких дней, максимум нескольких недель. Некоторые agile методы настаивают на ежедневной интеграции или даже интеграции несколько раз в течение дня.
Еще один из agile приемов – это ретроспектива, суть которой в том, что команда, закончив очередную итерацию, тратит время на обобщение полученного опыта, уроков, которые можно извлечь из проделанной работы, с целью улучшения процесса разработки.
Во многих программистских командах различные модули (unit) имеют владельца – программиста, разработавшего модуль. Это "владение" не является формальным, но обычно такой владелец единолично решает, что можно, а что нельзя изменять в модуле. Такая практика общепринята, например, в Мicrosoft. Методы agile выступают за другой подход – разделяемое владение кодом, при котором вся команда ответственна за весь код. Такой подход позволяет избежать зависимости от личностей. Смысл в том, что все члены команды в равной степени причастны ко всему проекту, что позволяет избежать территориальных споров, когда требуется внести изменение, затрагивающее разные части системы.
Тест-управляемая разработка превращает принцип "Вначале тест" в специфический прием. Применяемый итеративно, этот прием состоит в следующем:
Эта последовательность шагов, применяемая с самого начала, когда программа пуста и, следовательно, "падает" на любом нетривиальном тесте, продолжается далее и далее вплоть до завершения разработки. Такова форма разработки, характерная для экстремального программирования.
Рефакторинг – это процесс критического анализа реализации проекта, в результате которого выполняются любые трансформации, необходимые для улучшения согласованности и эффективности. Существуют каталоги стандартных трансформаций рефакторинга. В частности, есть книга [Fowler 1999], популяризирующая эти идеи, в которой приводятся типичные примеры трансформаций. Для объектно-ориентированного программирования примером стандартной трансформации является перенос свойства одного класса в другой класс вверх или вниз по иерархии семейства классов, связанных отношением наследования. Предполагается, что переносимое свойство концептуально ближе к новому классу, в котором оно появляется. Рефакторинг особенно необходим при тест-управляемой разработке, поскольку с каждым новым тестом в программу добавляется код, где каждая часть программы скроена под специфический тест, что само по себе приводит к запутанной структуре. Рефакторинг позволяет придать проекту четкую структуру. Точно так же, как сценарии и тесты представляют замену требований, рефакторинг является agile ответом на "Предваряющий анализ".
Парное программирование является приемом, используемым в экстремальном программировании. Код разрабатывается парой программистов, работающих за одним компьютером. Один пишет код, объясняя свои мысли, другой их комментирует, критикует, предлагает свои соображения. Ситуацию хорошо иллюстрирует метафора "пилот и штурман".
Целью парного программирования является попытка выявить ошибки на самых ранних стадиях. Так как пилот обязан вслух объяснять свои действия, то часто сам осознает, что он ошибается, не учитывает некоторые факторы. С другой стороны, "штурман" может остановить пилота, если перестает понимать его действия. В XP парное программирование применяется систематически и представляет универсальный прием. В других agile методах этот прием используется нерегулярно.
В XP также популярна практика построения решения простейшего, насколько это возможно. Исходя из минималистского принципа, описанного выше, усилия направляются на реализацию только того, на что есть запрос. При этом отвергается любая работа, направленная на расширения, на возможность повторного использования, всего того, что рекомендуется принципами программной инженерии, в частности, объектно-ориентированной разработки. С точки зрения agile выгода от такой работы иллюзорна, поскольку повторное использование может не понадобиться, мы никогда не знаем, в каком направлении будет развиваться система.
Наконец, agile методы требуют использования стандартов кодирования – определенных правил стиля, которым подчиняется весь код, создаваемый командой.
Виртуальные
Методы agile поддерживаются рядом инструментов. Некоторые из них концептуальны, например, пользовательские истории, другие – материальны, как карты историй, на которых истории записываются.
Варианты использования и особенно пользовательские истории являются сценариями, представляющими взаимодействие пользователей с системой. Варианты использования получили популярность еще до agile во многом благодаря книге Ивара Якобсона [Jacobson 1992]. Пользовательские истории появились как часть agile движения. Разница в гранулярности. Вариант использования представляет полный проход по системе, начиная, например, от просмотра продукта на сайте E-commerce до заполнения заказа. Пользовательская история – это небольшой модуль, задающий взаимодействие, например такого вида: "Как пользователь я хочу видеть список моих текущих заказов, так, чтобы я смог отследить мои закупки у интересующей меня компании".
График ликвидации (убывающая диаграмма выполнения) представляет запись скорости разработки проекта: как быстро он продвигается, ликвидируя нереализованные элементы в списке задач, другими словами, график демонстрирует, как быстро осуществляется реализация запланированных задач.
(рис 1.2) График ликвидации нереализованных задач. Убывающая диаграмма выполнения
По оси абсцисс задается время в днях, отведенных на итерацию. Ось ординат задает число еще нереализованных задач. Прямая линия на графике показывает, как скоро должны "ликвидироваться" задачи из списка при постоянной скорости развития проекта. Каждый день на график наносится очередная точка, отмечающая число задач, которые осталось выполнить. Если точка лежит выше прямой, то это свидетельствует об отставании от графика, ниже прямой – процесс разработки идет с опережением. График позволяет команде следить за ходом работы и своевременно понимать, когда выполнение задач идет недостаточно быстро.
Оставшиеся артефакты по своей форме представляют материальные объекты. Для всех их существуют как коммерческие, так и проекты с открытым кодом, предлагающие программный инструментарий, обеспечивающий частичную или полную замену артефактов.
(рис 1.3) Панель задач, отражающая динамику развития проекта
Карты историй представляют бумажные карточки (agile проповедники предписывают даже размер: 3 на 5 дюймов или 8 на 13 сантиметров), используемые для записи пользовательских историй. Эти карточки размещаются на панели историй, достаточно большой для размещения всех карточек. Команда динамически меняет расположение карточек на панели, группируя их по категориям.
Панель историй часто преобразуется в панель задач, которая дополняет график ликвидации, отображающий прогресс в развитии проекта.
По мере выполнения работ карточки, представляющие задачи, перемещаются слева направо.
Подход agile включает рекомендации по организации работы офиса, в котором работают программисты, – он должен работать в режиме открытой комнаты, обеспечивая возможность постоянного взаимодействия между членами команды.
Достаточно полной информации для полноценного анализа всех "за" и "против" agile подхода (прекрасного, ужасного, рекламного) у нас пока нет. Такой анализ будет сделан в финальной главе. Но уже теперь можно сформулировать первое впечатление.
Заметьте, в этом параграфе дается только общий взгляд и заключительной оценкой является та, что будет дана после изучения agile методов.
"В вашей работе, сэр, много нового и полезного! Но то, что является новым, не является полезным, а то, что полезно, не является новым".
Это высказывание (вероятно, являющееся апокрифом) привело нас к мысли проведения классификации agile подходов на четыре категории, используя два критерия – новизну и полезность. Для каждой категории будем приводить только несколько примеров.
Подход agile к требованиям основывается на пользовательских историях, тем самым на вариации идеи о вариантах использования: модулях функциональности, соответствующих взаимодействию пользователей с системой. Пользовательские истории и варианты использования являются ценным инструментом проверки требований, проверки того, что функциональность покрывает наиболее общие сценарии работы. Эти средства не являются адекватным инструментом определения требований, поскольку они документируют только некоторые примеры выполнения системы. Цель требований не сводится к заданию индивидуальных примеров, которые могут лишь частично покрывать возможности работы с системой, они должны идентифицировать наиболее общие функции системы. Если вы отказались от этого шага обобщения и абстракции, то получите систему, которая способна на немногое – реализует пользовательские истории, может быть, еще кое-что.
(рис 1.4) Из комикса про Тинтина
При работе с программной системой, например с веб-приложением, не возникало ли у вас ощущение, что вы оказались в положении
Парное программирование введено в экстремальном программировании. Характеризовать его как "бесполезное" не вполне справедливо, поскольку при разумном применении оно может быть эффективным приемом. В XP настаивают на его абсолютном применении, однако концептуального смысла в этом немного, так как при этом не учитывается индивидуальность программистов. Некоторые сильные программисты предпочитают концентрироваться на программе, работая в одиночку. Как показывает опыт, у парного программирования нет преимущества перед классической техникой "ревизии кода". В определенном смысле к парному программированию можно относиться как к фольклору, побасенкам. Многие проекты, в которых были попытки его применения, прекратили эту практику.
Худшие последствия agile методов связаны с предписанием создания минимального продукта, как следует из принципа под номером 4. Реализующие этот принцип правила 4.2 (создавать только запрашиваемый продукт) и 4.3 (разрабатывать только код и тесты) могут восприниматься неопытными менеджерами проектов как путь к совершенству, обеспечивающий возможность быстрой поставки результатов, сосредоточившись на сути.
С позиций программной инженерии это не очень хороший принцип. Здесь отрицаются усилия, которые следует приложить, следуя одному из наиболее плодотворных приемов программной инженерии – обобщению кода в целях простоты расширения проекта и его повторного использования, разработки инструментария, пригодного для автоматизации повторяющихся процессов.
В терминологии LSD эти усилия являются "расточительством", бесполезными затратами, поскольку они не поставляются потребителю. В реальности, когда они применяются подходящим образом, эти усилия дают ключ к непрерывному улучшению программного продукта, создаваемого компанией, и свидетельствуют о профессионализме разработчиков.
Еще худшим является запрет на разработку предваряющих проект требований. Базисное наблюдение вполне корректно: требования будут меняться, их трудно полностью описать в начале проектирования. Но отсюда вовсе не следует столь драматический вывод о бесполезности требований. Действительно, следует лишь то, что требования являются предметом изменений подобно всем артефактам в процессе создания ПО. Эта точка зрения многократно высказана в многочисленной литературе по программной инженерии, и она по-прежнему остается справедливой. К несчастью, многие проекты в последние годы следуют упрощенным agile советам, опуская фазу разработки систематических требований, заменяя ее попытками итеративного построения системы, опираясь на взаимодействие с потребителями. Результаты часто (вполне предсказуемо) оказываются разочаровывающими, поскольку требования появляются на поздних этапах жизненного цикла, когда функциональность уже реализована и должна быть существенно изменена. Советы agile в данном случае носят безответственный характер, и в серьезных проектах их следует игнорировать. Разумная практика состоит в том, чтобы формулировать требования в самом начале, создавать предварительную версию, удовлетворяющую проекту, и рассматривать требования как живой продукт, подлежащий постоянной адаптации в ходе развития проекта.
Литературе agile свойственен очаровательный юношеский задор: я та-ак уникален! Никто до меня не понимал в чем смысл жизни! Мои приверженцы та-ак соответствуют новым временам!
Восхваление собственных подходов сопровождается едкими нападки на традиционную программную инженерию, бранью и оскорблениями, выкриками – "водопад!". В реальности, многие из продуктивных идей в agile методах обсуждались в традиционной литературе задолго до появления этих методов. Мы познакомимся с рядом примеров по ходу книги, сейчас же приведем только два.
Первый – это итеративная разработка. Еще в восьмидесятые годы прошлого столетия индустрии было понятно, что старая модель независимой разработки подсистем в течение нескольких месяцев, а затем попытка их сбора чреваты бедствиями. Появившаяся в 1995 году книга Майкла Кузумано и Ричарда Селби "Секреты Microsoft" [Cusumano 1995]стала настоящим бестселлером. В частности, речь в ней шла о "ежедневной сборке" – практике, чье название говорит, что рабочая версия проекта создается каждый день
Лучшая часть книг по программной инженерии уже давно выражает ту точку зрения, что изменения играют важную роль в разработке ПО. Объектная технология, которая подобно шторму охватила мир разработки ПО, является успешной именно по той причине, что она лучше приспособлена к введению изменений, чем прежние методы конструирования ПО. Методы agile способны облегчить возможность внесения изменений благодаря организационным приемам, но не сделали никакого технического вклада в эту область и не имеют никакого права презрительно относиться к давно существующим приемам расширения существующей функциональности.
Если в этот момент вы готовы выплеснуть вместе с грязной agile водой экстремального и экономного программистского ребенка, то не торопитесь выбивать затычку из бочки. Вы можете пропустить некоторые удивительно полезные вещи.
Первый и главный вклад – это расширение полномочий команды. Центральная роль отдается команде, полагая, что именно она может и должна выполнять традиционные менеджерские обязанности. Это дает большие преимущества любым проектам, выполняемым компетентной командой.
Некоторые из управленческих приемов, используемых в agile методах, могут вначале показаться бесхитростными идеями, но фактически они вносят большой вклад в успех проекта. Один из таких важных приемов – ежедневные встречи в Scrum. Регламентированное взаимодействие, описание того, что каждый член команды уже сделал, что он собирается сделать, с какими проблемами столкнулся – все это является блестящей идеей сродни решению Колумбом проблемы "как заставить яйцо стоять". Конечно, можно сказать: "И я мог бы это придумать". Вполне возможно, но вы этого не сделали. Эта техника прекрасно работает, когда она применима, то есть тогда, когда команда находится в одном месте.
Интерес представляет идея "замораживания требований на время итерации". Этот принцип, хотя в некоторой степени противоречит agile манифесту, привносит стабильность в процесс разработки. Изменения не отрицаются, просто задерживаются, типично на небольшой срок, так как agile итерации коротки.
Итерации с временными рамками – также весьма продуктивный прием, особенно в сочетании с процессом планирования, что позволяет избегать неоправданных обещаний.
С технической точки зрения главное достижение agile методов состоит в установлении практической важности тестов и особенно регрессионных тестов. Идея регрессии стара, но agile напоминает нам, что система тестов является ключевым фактором успеха проекта, что во многом деятельность команды должна быть связана с организацией тестирования, независимо от того, является ли разработка тест-управляемой или нет. Важным является правило, не позволяющее переходить к разработке нового функционала, пока не пройдены все тесты для уже реализованной функциональности. Здесь можно видеть то лучшее, что свойственно agile школе – борьбу за профессионализм и качество продукта.
Подобные наблюдения применимы к некоторым идеям, обсуждаемым в разделе "Полезны, но не новы". Даже если agile методы не могут претендовать на изобретение приемов, созданных и продвигаемых авторами других концепций, то они способствуют их эффективному распространению в программистском сообществе. Это само по себе важное достижение. Двумя принципиальными примерами являются:
Придавая особое значение этим принципам и популяризуя их, agile движение действует в лучших традициях программной инженерии, собирая крупицы мудрости, накапливаемой десятилетиями, которая иногда с пренебрежением отбрасывалась.
Когда осядет пыль и поле очистится, мы будем вспоминать самопровозглашенную agile революцию как еще один шаг вперед, который улучшил наше понимание существующих концепций и ввел несколько драгоценных находок. Что же касается утверждений и деятельности отдельных agile фанатиков, то о них скоро забудут.
С большим удовольствием представляю российским читателям свою книгу "Agile! The Good, the Hype and the Ugly". Перевел ее профессор Владимир Биллиг, ранее сделавший прекрасный перевод моих книг "Object-Oriented Software Construction" и "Touch of Class"
Я написал эту книгу, так как понимал важность некоторых из 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.
Я вижу, как много в России талантов и креативных идей в нашей интереснейшей области работы. Надеюсь, что данная книга будет способствовать дальнейшему развитию.
Профессор Бертран Мейер написал книгу по 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 подходами. Эта книга будет интересна не только профессионалам, но, как и другие книги профессора Бертрана Мейера, и широкому кругу читателей, являясь примером книги высокой общечеловеческой культуры, выходящей за пределы мира программных систем.
Перед вами книга для практиков. Она не для философов, не для теоретиков.
Ее цель – дать возможность разработчикам ПО, ИТ-менеджерам, преподавателям оценить преимущества хороших идей 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 (неизящный)
Но имя – это просто имя; мы же должны без всяких эмоций, шаг за шагом дать оценку конкретным принципам и практикам, которые стоят за ним.
Оценка усложняется экстремизмом. Проектировщики ряда методов упорно настаивают, что их методы следует применять в полном объеме. Не все проповедуют принцип "все или ничего": подход Crystal, например, не столь жесткий. Но превалирование этого принципа характерно для многих основополагающих книг по agile, что усложняет понимание того, какие приемы будут работать в вашем проекте с пользой, а какие нет.
Среди многих книг по agile методам я знаю только три, в которых отсутствует тон преклонения:
В первой книге выяснение вопросов производит печальное впечатление, оставляя у читателя неопределенность относительно любых серьезных проблем XP (eXtremal Programming) – экстремального программирования.
Вторая книга чувства печали не создает – это памфлет, забавный и назидательный, но, как и всякий памфлет, он, скорее, выявляет абсурдность утверждений, чем выполняет серьезный анализ всех аргументов "за" и "против".
Наиболее серьезная попытка такого анализа предпринята в третьей книге. Здесь сопоставляются agile подходы и традиционные методы планово-управляемой разработки, характерные для инженерии ПО. Достоинство этой книги в том, что она основана на эмпирических данных, позволяющих сравнивать эффективность agile методов и их классических двойников. По-моему, в книге слишком заметна осторожность в суждениях, возможно, потому, что Боем – весьма уважаемая фигура в мире ИТ – боится прослыть защитником "старого порядка", так что авторы избегают резких критических суждений.
В данной книге не ожидайте такой робости (упоминаю об этом на тот случай, если вас это может беспокоить). Уважение – есть, почитания – нет. Все хорошие идеи будут выявлены и получат заслуженную хвалу. Но всякий раз, когда мы столкнемся с вздором и чепухой, будет ясно сказано, что это вздор и чепуха.
Книга имеет простую структуру и предполагает последовательное чтение.
Следующие главы представляют обзор основных agile идей:
Мы не фокусируем внимание ни на каком конкретном agile методе – нас интересуют концепции и инструменты, общие для всех или почти всех методов. Этот подход высвечивает то общее, что присуще разным методам, и позволяет проэкзаменовать agile идеи в чистом виде, давая возможность решить, какие из них являются подходящими в конкретном контексте. Некоторые идеи являются специфическими и применимы только к одному методу.
Если в предыдущих главах главным образом обсуждаются общие особенности, то в главе 9 рассматриваются четыре принципиальные для agile метода: Scrum, Lean, XP, Crystall. Поскольку их общие черты уже рассмотрены в главах 4, 5, 6, 7, 8, то внимание концентрируется на характерной для метода комбинации принципов, ролей, практик и артефактов и, что важно, на духе (spirit) самого метода. Анализ показывает, что каждый из них имеет свою собственную "большую идею", выделяющую его среди других методов и поддержанную рядом дополнительных концепций.
Любая книга окрашена авторским опытом. Характеризуя свой опыт, могу сказать, что он представляет смесь индустриальной практики (это большая часть моей профессиональной карьеры) и академической работы (в течение последнего десятилетия). Полезно отметить ограничение на содержание – то, что не вошло в эту книгу, – всестороннее описание подходов к разработке ПО. В моих предыдущих книгах описывались методы построения качественного ПО и продвигались специфические подходы, в частности объектная технология и проектирование по контракту. Эта же книга отличается тем, что в ней исследуются работы других людей. Даже тогда, когда я чувствую, что мои работы имеют непосредственное отношение к обсуждаемым вопросам или предвосхищают некоторые из полезных agile идей, я избегаю подобных обсуждений (за исключением нескольких кратких советов).
Методология ПО – это своего рода искусство, поскольку в данной области трудно что-либо доказать. Многие идеи воспринимаются лишь благодаря силе авторской убежденности. И это не означает, что идеи хороши или плохи. Авторы используют четыре вида аргументов:
Не следует снисходительно относиться к внутренней убежденности. В конце концов на этом основана знаменитая статья Дейкстры 1968 года "О вреде оператора Go TO" – родоначальнице всех методологических текстов ИТ. В ней он писал:
Недавно я понял, почему использование оператора go to приводит к таким пагубным последствиям, и теперь я совершенно убежден, что он должен быть изъят из всех языков высокого уровня.
Но если вы не Дейкстра, то ваше внутреннее чувство вряд ли поможет убедить все сообщество программистов.
Опыт также был использован в качестве аргументов, приводимых Дейкстрой:
В течение ряда лет мои наблюдения показывали, что качество работы программистов представляет функцию, убывающую в зависимости от плотности операторов go to в программах, которые они производят.
Аргументы, основанные на опыте, являются любимым средством agile авторов. Типичная agile книга содержит последовательность перемежающихся общих наблюдений, случаев из практики спасения проектов (спасенных, как правило, автором) и проектных неудач (неудач вследствие того, что не следовали советам авторов). Эти случаи из практики обычно развлекательны, иногда назидательны. Учебный пример – это всего лишь учебный пример, и мы никогда не знаем, насколько он допускает обобщения. В конечном итоге каждый может привести пример в поддержку практически любой рекомендации.
Примеры могут иметь доказательную силу, но только в одном случае – когда опровергают общее утверждение, касающееся всех случаев. Если такое утверждение высказывается, то достаточно единственного примера для его опровержения. Например, если кто-то, допустим, Аристотель, утверждает, что скорость падения зависит от массы тела, то достаточно подняться на Пизанскую башню, как это сделал Галилей, сбросить два тела – тяжелый и легкий шары – и убедиться, что тела достигнут земли в один и тот же момент времени.
Логический вывод является мощным инструментом. Он сыграл важную роль в выводах, сделанных Дейкстрой. Некоторые авторы утверждают, что Галилей не поднимался на башню, а доказал свою гипотезу, проведя исключительно мысленный эксперимент. Но логический вывод правомерен настолько, насколько правомерны гипотезы, лежащие в его основе; всегда существует риск, что вывод будет иметь чисто академический интерес.
Что нам крайне необходимо, так это эмпирические свидетельства. Дает ли парное программирование лучшие результаты, чем инспекция кода? Предпочтительнее постоянное общение с заказчиком или строгий процесс формирования требований? Заслуживающие доверия ответы на вопросы методологии построения ПО требуют систематического, тщательного, реалистичного изучения реализации программных проектов. Эта книга основывается на таких результатах в той мере, насколько они доступны, но таковых не столь много. Дающие первые ростки эмпирические исследования в программной инженерии еще не обеспечивают ответы на многие фундаментальные вопросы. Наверное, в этом заключалась основная трудность в подготовке данной книги. Поскольку нет достаточных убедительных эмпирических свидетельств, обсуждение главным образом основывается на рассуждениях. Я не склонен полностью игнорировать свой персональный опыт и случаи из практики, но пытаюсь применять их как иллюстрации к точке зрения, поддержанной логическими аргументами, а также в тех случаях, когда пример может опровергнуть утверждение, претендующее на общность.
По своей сути эта работа предполагает критические комментарии. Следует сказать несколько слов о духе, в котором они написаны.
Прогресс в науке и инженерии основывается на свободном, критическом анализе предыдущих работ. Анализируя литературу по agile, я обнаружил несколько поводов для несогласия с авторами, а в некоторых случаях был просто шокирован. Я не столь робок, чтобы бояться подвергнуть их притязания проверке.
Нужно заметить, что я нашел также элементы, достойные восхищения, и воспринял ряд новых положений в разработке ПО.
Ни в коем случае критика не означает неуважение. Пионеры agile – это опытные профессионалы, со всей страстью отдающиеся делу развития ИТ. Даже полагая, что они ошибаются, я ценю их точку зрения и разделяю их страстность. Мы все в одной лодке,
Так как в этой книге осуждаются некоторые 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). Немаловажна и роль студентов.
Курс привел к нескольким опубликованным эмпирическим исследованиям, которые существенно помогли в моей работе.
Появление идеи agile датируется 1990 годом и связано с разработкой XP – экстремального программирования, но слава пришла к agile после опубликования манифеста в 2001 году [Agile 2001].
(рис 1.1) Agile-манифест разработки программного обеспечения
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, непосредственно занимаясь разработкой и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
То есть, не отрицая важности того, что справа, мы всетаки больше ценим то, что слева.
|
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler |
James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick |
Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas |
Создатели Agile-манифеста опубликовали этот документ на фоне, изображающем полдюжины мужчин среднего возраста, носящих джинсы, располневших, повернувшихся к нам спиной, слушающих оратора, видимо, рассказывающего об agile-манифесте. Все это должно символизировать неотразимую силу призыва, содержащегося в манифесте. Лично я, когда хотел выразить сущность agile, то выбрал фотографию, представленную на обложке этой книги (балерина Наталья Осипова в "Лебедином озере"), что может говорить о том, насколько я не иду "в ногу со временем". Эта фотография прекрасна.
Идеи agile подняли шумиху в индустрии, стали находкой для технической прессы, явились тем видом аргументов, которые в жестком соперничестве компании использовали для привлечения лучших программистов: "Приходите к нам! Наши разработки – agile!" Не будучи единой концепцией, под agile понимается совокупность идей, содержащихся в нескольких методах, применяемых в разнообразных вариациях. К ним относятся, в частности, такие методы, как экстремальное программирование (eXtremal Programming -XP),
Принципы следуют из предпосылок. Практики, роли, артефакты следуют из принципов. В последнем параграфе (1.6) дается первая оценка подхода.
Эта глава представляет своего рода концентрат всей книги, инспекторский обзор ключевых идей. За исключением последнего параграфа, она носит описательный характер, нейтрально представляя agile идеи. Для краткости, обобщенное описание agile методов дается здесь без ссылки на какие-либо источники. В последующих главах приводятся пространные цитаты agile авторов, где они детально обосновывают методы.
Из текста agile манифеста с очевидностью следует, что agile – это не просто собрание ряда методов, а некоторое движение, идеология. Прежде чем рассматривать специфические принципы, практики, роли и артефакты, следует проникнуться духом agile философии. Она базируется на пяти доктринах или предпосылках.
Первая доктрина связана с фундаментальной проблемой: каковы
Переопределение ролей касается и потребителей ПО, тех, кто в agile мире не является пассивными фигурами, молчаливо потребляющими произведенный продукт. Потребители в этом мире – активные участники процесса разработки, выступающие в роли заказчиков. В большинстве agile методов потребители включаются в команду разработчиков.
Вторая доктрина связана с отказом от "Предваряющего анализа" и веры в то, что все следует предусмотреть. Порицая существующие методы разработки ПО, в agile мире их называют "Предваряющий анализ" (Big Upfront). Под этим понимается экстенсивное планирование в начале проекта, включающее:
С точки зрения agile:
Вместо документа требований agile методы рекомендуют постоянное взаимодействие с потребителями (customers) – заказчиками и пользователями. Как следствие, представители потребителей включаются в состав команды, что, с одной стороны, дает возможность им посмотреть "изнутри" на возникающие проблемы, а с другой – позволяет команде быстро реагировать на эти проблемы, имея обратную связь.
Вместо этапа проектирования agile предлагает строить систему итеративно, находя на каждом шагу "наиболее простое решение, отвечающее целям работы" (девиз экстремального программирования).
Если в процессе разработки решение перестает работать или становится неэффективным, выполняется рефакторинг – изменение проекта, устраняющее неэффективность.
Как следствие, agile процесс является итеративной разработкой с временными рамками. Ближайшая альтернатива документу требований – список функций с расставленными приоритетами, из которого команда выбирает функции для реализации на итерации, исходя из критерия максимизации "Возврата Инвестиций" – ROI (Return On Investment). Вследствие отсутствия "больших" задач этот выбор делается последовательными шагами, называемыми итерациями ("спринтами" в Scrum), каждый из которых занимает фиксированное время – не более нескольких недель, отсюда – "с временными рамками". В процессе разработки итеративно добавляется функциональность. Каждое добавление представляет ограниченную договорную функциональность. Литература agile изобилует причитаниями по поводу того, что при традиционном проектировании создается множество свойств, которые вряд ли кто-либо будет использовать. Стратегия agile предлагает радикально ограничивать функциональность, оставляя лишь наиболее важные свойства, оцениваемые их вкладом – их ROI. Экономное программирование – LSD ссылается на опыт, полученный в других видах деятельности, в частности, в автомобильной промышленности, где "минимизация расточительности" является одной из ключевых проблем. Система "Канбан" (Kanban), разработанная японской фирмой "Тойота", обеспечивает поставку продукции заданного качества точно в указанные сроки при минимизации затрат на всех этапах процесса работы.
На каждой итерации при выборе функциональности требуется "договоренность". С позиций agile, как невозможно в начале разработки сформулировать все требования к системе, точно так же невозможно обеспечить одновременно желаемую функциональность и выдержать сроки поставки. Для разработки с "временными рамками" достижение компромисса (вы хотите все или вы хотите получить нечто уже в следующем месяце?) достигается обычно выбором второго решения. Если не все функции, планируемые на итерации, могут быть реализованы в заданный срок, то урезается функциональность, а не передвигается срок исполнения. Пропущенная функциональность либо будет реализована на следующем шаге, либо (если последующий анализ ROI покажет ее неэффективность) будет опущена. Этот процесс планирования и согласований требует постоянных договоренностей с потребителями.
Заключительной доктриной является фокусирование на качестве, которое с точки зрения agile сводится к непрерывному тестированию (в отличие от других подходов к обеспечению качества, в частности, основанных на методах проектирования, формальной методологии, презрительно называемой "Предваряющий анализ").
Здесь мало внимания уделяется обеспечению качества в традиционном понимании, зато крайне отрицательно относятся к попыткам продолжать разработку, если уже созданный код не прошел всестороннее тестирование. Одним из вкладов гибкой разработки является повышение внимания к
Оставшаяся часть книги исходит из того, что следующие восемь принципов (три из которых являются частичными принципами) составляют agile канон.
Организационные
Эти принципы следуют из пяти "общих предпосылок", рассмотренных в предыдущем параграфе, преобразуя предпосылки в фактические предписания.
Это не те двенадцать принципов, которые перечислены в Agile манифесте. Те, официальные принципы, обсуждаемые в последующей главе, менее подходят для анализа. Они избыточны, комбинируют идеи различных уровней, ставят на одну доску пожелания (Строить проекты с командой высокомотивированных личностей, кто с этим станет спорить) и избыточно конкретизированные правила, такие как выпускать очередной релиз ПО в срок от двух недель до двух месяцев. В официальных принципах отсутствуют некоторые ключевые идеи, как например, ключевая роль тестов. Восемь принципов, представленных здесь, обеспечивают лучшую абстракцию.
Пять принципов руководят организацией и управлением agile проектов.
Как сказано выше, agile разработка представляет итеративный процесс, состоящий из последовательного выполнения итераций. Каждая итерация совершенно короткая – несколько недель, ее результатом является рабочий релиз системы, возможно, носящий довольно частный характер. Представители пользователей могут провести испытания, результат которых может стать источником новых идей для следующей итерации. Scrum вводит важное правило – замораживание требований на время выполнения итерации. Если идея новой функции появляется во время разработки, то рассмотрение нового свойства откладывается до новой итерации.
Первенство тестов представляет воплощение подхода к достижению качества. Этот принцип имеет два следствия. Поскольку оба следствия важны, их можно рассматривать как частичные принципы:
Последний принцип – использование сценариев для определения функциональности – составляет еще одну часть замены требований. Сценарий представляет описание варианта взаимодействия пользователя с системой. Например, при проектировании системы для мобильных телефонов описание сценария разговора по телефону начинается от момента вызова абонента до момента разъединения. "Сценарий" не является общепринятым agile термином, но покрывает такие agile понятия, как варианты использования (use cases) и пользовательские истории (user stories), отличающиеся уровнем гранулярности. Вариант использования – это описание законченного взаимодействия, а пользовательская история – более мелкая единица по функциональности. Сценарии приходят от потребителей и определяют фундаментальную функциональность системы с их точки зрения. Собрание сценариев, в частности, пользовательских историй, отличается от традиционных требований по двум фундаментальным аспектам:
В главе 4 организационные и технические принципы agile будут обсуждаться в деталях.
Методы agile определяют роли различных действующих лиц (actors) в программных проектах.
Первая и наиболее важная роль отводится команде – самоорганизующейся группе разработчиков и других членов команды (таких как представители потребителей). Команда ответственна за распределение задач между членами команды.
Scrum идет дальше в определении новых ролей с обязанностями традиционных менеджеров. Определение свойств программного продукта возлагается на владельца продукта (product owner). Он получает право изменять свойства продукта при одном важном ограничении, никакие изменения не допускаются во время итерации (спринт в Scrum). Менеджерские обязанности – консультанта, тренера, ментора, гуру, администратора – возлагаются на Scrum-мастера, который не может быть одновременно владельцем продукта.
Общим для всех agile методов является включение такой роли, как
Экстремальное программирование, по меньшей мере, в его ранних версиях, предписывало встраивать потребителей в команду как ее полноценных членов. Это положение легко декларировать, но трудно воплотить на практике. Возникающие при этом проблемы будут в дальнейшем проанализированы. Но даже если кто-то не следует этому правилу буквально, для всех agile проектов роль потребителя крайне важна. В главе 5 эта и другие роли будут обсуждаться подробнее.
Для достижения принципов, представленных выше, agile методы применяют множество приемов, или практик (practice).
Организационные:
Технические
Все agile методы выступают за частые контакты (встречи лицом к лицу). В частности, Scrum включает требование ежедневных встреч в начале рабочего дня, известных как "ежедневный Scrum". Встреча должна быть короткой: 15 минут – типичный вариант. Эта цель достижима для групп из 10–15 человек, поскольку рамки встречи строго ограничены. Каждый член команды должен ответить на три вопроса:
Никакие другие вопросы не обсуждаются, в том числе и то, как преодолеть возникшие нетривиальные помехи. Такая форма ежедневных встреч применима тогда, когда вся команда расположена в одном месте. Она помогает согласованию усилий в команде: каждый знает, что делается, возникающие проблемы выявляются на ранних стадиях.
Любая разработка ПО сталкивается с проблемой планирования, в частности, с проблемой компромиссного планирования функциональности и сроков ее реализации. Методы agile предлагают "игру в планирование" (planning game в XP) и "планирующий покер" (planning poker в Scrum). Оба варианта представляют вариации группового оценивания, где участникам предлагается вначале дать свою независимую оценку, затем проанализировать оценки других участников игры, затем итеративными шагами прийти к консенсусу.
Наиболее убедительной является концепция непрерывной интеграции. Лет десять–двадцать тому назад не было ничего необычного в том, чтобы разделять систему на подсистемы и объединять независимо разрабатываемые подсистемы с интервалом в несколько месяцев. Это было ужасно, так как при попытке интеграции зачастую возникали ситуации несовместимости подсистем и приходилось прилагать много усилий для достижения их согласования. Современная практика разработки, включающая agile подходы, сводится к частой интеграции – не реже нескольких дней, максимум нескольких недель. Некоторые agile методы настаивают на ежедневной интеграции или даже интеграции несколько раз в течение дня.
Еще один из agile приемов – это ретроспектива, суть которой в том, что команда, закончив очередную итерацию, тратит время на обобщение полученного опыта, уроков, которые можно извлечь из проделанной работы, с целью улучшения процесса разработки.
Во многих программистских командах различные модули (unit) имеют владельца – программиста, разработавшего модуль. Это "владение" не является формальным, но обычно такой владелец единолично решает, что можно, а что нельзя изменять в модуле. Такая практика общепринята, например, в Мicrosoft. Методы agile выступают за другой подход – разделяемое владение кодом, при котором вся команда ответственна за весь код. Такой подход позволяет избежать зависимости от личностей. Смысл в том, что все члены команды в равной степени причастны ко всему проекту, что позволяет избежать территориальных споров, когда требуется внести изменение, затрагивающее разные части системы.
Тест-управляемая разработка превращает принцип "Вначале тест" в специфический прием. Применяемый итеративно, этот прием состоит в следующем:
Эта последовательность шагов, применяемая с самого начала, когда программа пуста и, следовательно, "падает" на любом нетривиальном тесте, продолжается далее и далее вплоть до завершения разработки. Такова форма разработки, характерная для экстремального программирования.
Рефакторинг – это процесс критического анализа реализации проекта, в результате которого выполняются любые трансформации, необходимые для улучшения согласованности и эффективности. Существуют каталоги стандартных трансформаций рефакторинга. В частности, есть книга [Fowler 1999], популяризирующая эти идеи, в которой приводятся типичные примеры трансформаций. Для объектно-ориентированного программирования примером стандартной трансформации является перенос свойства одного класса в другой класс вверх или вниз по иерархии семейства классов, связанных отношением наследования. Предполагается, что переносимое свойство концептуально ближе к новому классу, в котором оно появляется. Рефакторинг особенно необходим при тест-управляемой разработке, поскольку с каждым новым тестом в программу добавляется код, где каждая часть программы скроена под специфический тест, что само по себе приводит к запутанной структуре. Рефакторинг позволяет придать проекту четкую структуру. Точно так же, как сценарии и тесты представляют замену требований, рефакторинг является agile ответом на "Предваряющий анализ".
Парное программирование является приемом, используемым в экстремальном программировании. Код разрабатывается парой программистов, работающих за одним компьютером. Один пишет код, объясняя свои мысли, другой их комментирует, критикует, предлагает свои соображения. Ситуацию хорошо иллюстрирует метафора "пилот и штурман".
Целью парного программирования является попытка выявить ошибки на самых ранних стадиях. Так как пилот обязан вслух объяснять свои действия, то часто сам осознает, что он ошибается, не учитывает некоторые факторы. С другой стороны, "штурман" может остановить пилота, если перестает понимать его действия. В XP парное программирование применяется систематически и представляет универсальный прием. В других agile методах этот прием используется нерегулярно.
В XP также популярна практика построения решения простейшего, насколько это возможно. Исходя из минималистского принципа, описанного выше, усилия направляются на реализацию только того, на что есть запрос. При этом отвергается любая работа, направленная на расширения, на возможность повторного использования, всего того, что рекомендуется принципами программной инженерии, в частности, объектно-ориентированной разработки. С точки зрения agile выгода от такой работы иллюзорна, поскольку повторное использование может не понадобиться, мы никогда не знаем, в каком направлении будет развиваться система.
Наконец, agile методы требуют использования стандартов кодирования – определенных правил стиля, которым подчиняется весь код, создаваемый командой.
Виртуальные
Методы agile поддерживаются рядом инструментов. Некоторые из них концептуальны, например, пользовательские истории, другие – материальны, как карты историй, на которых истории записываются.
Варианты использования и особенно пользовательские истории являются сценариями, представляющими взаимодействие пользователей с системой. Варианты использования получили популярность еще до agile во многом благодаря книге Ивара Якобсона [Jacobson 1992]. Пользовательские истории появились как часть agile движения. Разница в гранулярности. Вариант использования представляет полный проход по системе, начиная, например, от просмотра продукта на сайте E-commerce до заполнения заказа. Пользовательская история – это небольшой модуль, задающий взаимодействие, например такого вида: "Как пользователь я хочу видеть список моих текущих заказов, так, чтобы я смог отследить мои закупки у интересующей меня компании".
График ликвидации (убывающая диаграмма выполнения) представляет запись скорости разработки проекта: как быстро он продвигается, ликвидируя нереализованные элементы в списке задач, другими словами, график демонстрирует, как быстро осуществляется реализация запланированных задач.
(рис 1.2) График ликвидации нереализованных задач. Убывающая диаграмма выполнения
По оси абсцисс задается время в днях, отведенных на итерацию. Ось ординат задает число еще нереализованных задач. Прямая линия на графике показывает, как скоро должны "ликвидироваться" задачи из списка при постоянной скорости развития проекта. Каждый день на график наносится очередная точка, отмечающая число задач, которые осталось выполнить. Если точка лежит выше прямой, то это свидетельствует об отставании от графика, ниже прямой – процесс разработки идет с опережением. График позволяет команде следить за ходом работы и своевременно понимать, когда выполнение задач идет недостаточно быстро.
Оставшиеся артефакты по своей форме представляют материальные объекты. Для всех их существуют как коммерческие, так и проекты с открытым кодом, предлагающие программный инструментарий, обеспечивающий частичную или полную замену артефактов.
(рис 1.3) Панель задач, отражающая динамику развития проекта
Карты историй представляют бумажные карточки (agile проповедники предписывают даже размер: 3 на 5 дюймов или 8 на 13 сантиметров), используемые для записи пользовательских историй. Эти карточки размещаются на панели историй, достаточно большой для размещения всех карточек. Команда динамически меняет расположение карточек на панели, группируя их по категориям.
Панель историй часто преобразуется в панель задач, которая дополняет график ликвидации, отображающий прогресс в развитии проекта.
По мере выполнения работ карточки, представляющие задачи, перемещаются слева направо.
Подход agile включает рекомендации по организации работы офиса, в котором работают программисты, – он должен работать в режиме открытой комнаты, обеспечивая возможность постоянного взаимодействия между членами команды.
Достаточно полной информации для полноценного анализа всех "за" и "против" agile подхода (прекрасного, ужасного, рекламного) у нас пока нет. Такой анализ будет сделан в финальной главе. Но уже теперь можно сформулировать первое впечатление.
Заметьте, в этом параграфе дается только общий взгляд и заключительной оценкой является та, что будет дана после изучения agile методов.
"В вашей работе, сэр, много нового и полезного! Но то, что является новым, не является полезным, а то, что полезно, не является новым".
Это высказывание (вероятно, являющееся апокрифом) привело нас к мысли проведения классификации agile подходов на четыре категории, используя два критерия – новизну и полезность. Для каждой категории будем приводить только несколько примеров.
Подход agile к требованиям основывается на пользовательских историях, тем самым на вариации идеи о вариантах использования: модулях функциональности, соответствующих взаимодействию пользователей с системой. Пользовательские истории и варианты использования являются ценным инструментом проверки требований, проверки того, что функциональность покрывает наиболее общие сценарии работы. Эти средства не являются адекватным инструментом определения требований, поскольку они документируют только некоторые примеры выполнения системы. Цель требований не сводится к заданию индивидуальных примеров, которые могут лишь частично покрывать возможности работы с системой, они должны идентифицировать наиболее общие функции системы. Если вы отказались от этого шага обобщения и абстракции, то получите систему, которая способна на немногое – реализует пользовательские истории, может быть, еще кое-что.
(рис 1.4) Из комикса про Тинтина
При работе с программной системой, например с веб-приложением, не возникало ли у вас ощущение, что вы оказались в положении
Парное программирование введено в экстремальном программировании. Характеризовать его как "бесполезное" не вполне справедливо, поскольку при разумном применении оно может быть эффективным приемом. В XP настаивают на его абсолютном применении, однако концептуального смысла в этом немного, так как при этом не учитывается индивидуальность программистов. Некоторые сильные программисты предпочитают концентрироваться на программе, работая в одиночку. Как показывает опыт, у парного программирования нет преимущества перед классической техникой "ревизии кода". В определенном смысле к парному программированию можно относиться как к фольклору, побасенкам. Многие проекты, в которых были попытки его применения, прекратили эту практику.
Худшие последствия agile методов связаны с предписанием создания минимального продукта, как следует из принципа под номером 4. Реализующие этот принцип правила 4.2 (создавать только запрашиваемый продукт) и 4.3 (разрабатывать только код и тесты) могут восприниматься неопытными менеджерами проектов как путь к совершенству, обеспечивающий возможность быстрой поставки результатов, сосредоточившись на сути.
С позиций программной инженерии это не очень хороший принцип. Здесь отрицаются усилия, которые следует приложить, следуя одному из наиболее плодотворных приемов программной инженерии – обобщению кода в целях простоты расширения проекта и его повторного использования, разработки инструментария, пригодного для автоматизации повторяющихся процессов.
В терминологии LSD эти усилия являются "расточительством", бесполезными затратами, поскольку они не поставляются потребителю. В реальности, когда они применяются подходящим образом, эти усилия дают ключ к непрерывному улучшению программного продукта, создаваемого компанией, и свидетельствуют о профессионализме разработчиков.
Еще худшим является запрет на разработку предваряющих проект требований. Базисное наблюдение вполне корректно: требования будут меняться, их трудно полностью описать в начале проектирования. Но отсюда вовсе не следует столь драматический вывод о бесполезности требований. Действительно, следует лишь то, что требования являются предметом изменений подобно всем артефактам в процессе создания ПО. Эта точка зрения многократно высказана в многочисленной литературе по программной инженерии, и она по-прежнему остается справедливой. К несчастью, многие проекты в последние годы следуют упрощенным agile советам, опуская фазу разработки систематических требований, заменяя ее попытками итеративного построения системы, опираясь на взаимодействие с потребителями. Результаты часто (вполне предсказуемо) оказываются разочаровывающими, поскольку требования появляются на поздних этапах жизненного цикла, когда функциональность уже реализована и должна быть существенно изменена. Советы agile в данном случае носят безответственный характер, и в серьезных проектах их следует игнорировать. Разумная практика состоит в том, чтобы формулировать требования в самом начале, создавать предварительную версию, удовлетворяющую проекту, и рассматривать требования как живой продукт, подлежащий постоянной адаптации в ходе развития проекта.
Литературе agile свойственен очаровательный юношеский задор: я та-ак уникален! Никто до меня не понимал в чем смысл жизни! Мои приверженцы та-ак соответствуют новым временам!
Восхваление собственных подходов сопровождается едкими нападки на традиционную программную инженерию, бранью и оскорблениями, выкриками – "водопад!". В реальности, многие из продуктивных идей в agile методах обсуждались в традиционной литературе задолго до появления этих методов. Мы познакомимся с рядом примеров по ходу книги, сейчас же приведем только два.
Первый – это итеративная разработка. Еще в восьмидесятые годы прошлого столетия индустрии было понятно, что старая модель независимой разработки подсистем в течение нескольких месяцев, а затем попытка их сбора чреваты бедствиями. Появившаяся в 1995 году книга Майкла Кузумано и Ричарда Селби "Секреты Microsoft" [Cusumano 1995]стала настоящим бестселлером. В частности, речь в ней шла о "ежедневной сборке" – практике, чье название говорит, что рабочая версия проекта создается каждый день
Лучшая часть книг по программной инженерии уже давно выражает ту точку зрения, что изменения играют важную роль в разработке ПО. Объектная технология, которая подобно шторму охватила мир разработки ПО, является успешной именно по той причине, что она лучше приспособлена к введению изменений, чем прежние методы конструирования ПО. Методы agile способны облегчить возможность внесения изменений благодаря организационным приемам, но не сделали никакого технического вклада в эту область и не имеют никакого права презрительно относиться к давно существующим приемам расширения существующей функциональности.
Если в этот момент вы готовы выплеснуть вместе с грязной agile водой экстремального и экономного программистского ребенка, то не торопитесь выбивать затычку из бочки. Вы можете пропустить некоторые удивительно полезные вещи.
Первый и главный вклад – это расширение полномочий команды. Центральная роль отдается команде, полагая, что именно она может и должна выполнять традиционные менеджерские обязанности. Это дает большие преимущества любым проектам, выполняемым компетентной командой.
Некоторые из управленческих приемов, используемых в agile методах, могут вначале показаться бесхитростными идеями, но фактически они вносят большой вклад в успех проекта. Один из таких важных приемов – ежедневные встречи в Scrum. Регламентированное взаимодействие, описание того, что каждый член команды уже сделал, что он собирается сделать, с какими проблемами столкнулся – все это является блестящей идеей сродни решению Колумбом проблемы "как заставить яйцо стоять". Конечно, можно сказать: "И я мог бы это придумать". Вполне возможно, но вы этого не сделали. Эта техника прекрасно работает, когда она применима, то есть тогда, когда команда находится в одном месте.
Интерес представляет идея "замораживания требований на время итерации". Этот принцип, хотя в некоторой степени противоречит agile манифесту, привносит стабильность в процесс разработки. Изменения не отрицаются, просто задерживаются, типично на небольшой срок, так как agile итерации коротки.
Итерации с временными рамками – также весьма продуктивный прием, особенно в сочетании с процессом планирования, что позволяет избегать неоправданных обещаний.
С технической точки зрения главное достижение agile методов состоит в установлении практической важности тестов и особенно регрессионных тестов. Идея регрессии стара, но agile напоминает нам, что система тестов является ключевым фактором успеха проекта, что во многом деятельность команды должна быть связана с организацией тестирования, независимо от того, является ли разработка тест-управляемой или нет. Важным является правило, не позволяющее переходить к разработке нового функционала, пока не пройдены все тесты для уже реализованной функциональности. Здесь можно видеть то лучшее, что свойственно agile школе – борьбу за профессионализм и качество продукта.
Подобные наблюдения применимы к некоторым идеям, обсуждаемым в разделе "Полезны, но не новы". Даже если agile методы не могут претендовать на изобретение приемов, созданных и продвигаемых авторами других концепций, то они способствуют их эффективному распространению в программистском сообществе. Это само по себе важное достижение. Двумя принципиальными примерами являются:
Придавая особое значение этим принципам и популяризуя их, agile движение действует в лучших традициях программной инженерии, собирая крупицы мудрости, накапливаемой десятилетиями, которая иногда с пренебрежением отбрасывалась.
Когда осядет пыль и поле очистится, мы будем вспоминать самопровозглашенную agile революцию как еще один шаг вперед, который улучшил наше понимание существующих концепций и ввел несколько драгоценных находок. Что же касается утверждений и деятельности отдельных agile фанатиков, то о них скоро забудут.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.