Методы agile

9.3 Экстремальное программирование – XP

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

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

9.3.1 Большая идея XP

Большая идея XP может быть сформулирована следующим образом:

Это основной цикл, повторяемый, пока разработчики не сделают потребителей счастливыми. Добавляется функциональность, индуцированная TDD (Test Driven Development) с новым тестом, падающим на системе без добавленного кода. Когда все начинает работать, ищутся те повреждения, которые новый код мог нанести простоте системы. Применяется рефакторинг, восстанавливающий простоту.

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

9.3.2 XP: источник

Замечания по поводу описания экстремального программирования помогут тем читателям, которые захотят глубоко изучить XP, помимо того представления, которое дается в этой книге. Хотя различные авторы, в частности Джеффри и Каннингэм, написали хорошие статьи и книги по XP, настоящим источником является книга Бека "Extreme Programming Explained". Книга выдержала два издания, в 2000 и 2005 годах, и вопреки ожиданиям я нахожу первое издание лучшим источником^{1Имеется русский перевод первого издания: Кент Бек "Экстремальное программирование", Питер, 2002 г.}. Во втором издании чувствуется обида автора на некоторые комментарии к первому изданию. Вот небольшая выдержка из второго издания:

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

(Странно: как кто-то купивший книгу по методологии программирования, может жаловаться на то, что ему говорят "программируйте определенным способом".) В результате он смягчил тональность сообщений, уйдя от конкретных, а следовательно, критикуемых утверждений к более нейтральным, но менее интересным обобщениям. Показательным примером является выдержка из первого издания:

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

• Если обзор кода - хорошая вещь, то будем анализировать код постоянно (парное программирование).
• Если тестирование – хорошая вещь, то будем тестировать постоянно (юнит-тестирование), позволяя это делать и пользователям (функциональное тестирование).
• Если проектирование – хорошая вещь, то сделаем это ежедневным занятием (рефакторинг).

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

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

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

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

9.3.3 Ключевые техники XP

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

• короткие итерации (как во всех agile методах);
• парное программирование;
• пользовательские истории;
• рефакторинг;
• открытое рабочее пространство;
• коллективное владение кодом;
• непрерывную интеграцию (continuous integration);
• разработку, управляемую тестами, – TDD.

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

9.3.4 Экстремальное программирование: оценка

Экстремальное программирование обеспечило начальный толчок, благодаря которому на agile методы обратили внимание в программистском мире. Слово "экстремальное" использовалось намеренно, подчеркивая, что лучшие практики расширяются экстремальным способом. Как объяснялось в вышеприведенном отрывке из первого издания книги Кента Бека (если X хорош, то будем применять его непрерывно во всем диапазоне практики X), экстремальность связана и с общими утверждениями метода, в которых настаивается, что предлагаемые техники не только возможны, но и обязательны, например, программировать нужно парами.

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

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

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

9.4 Scrum

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

По Scrum имеется многочисленная литература, включающая несколько книг от его создателей – Швабера и Сазерленда. Авторы и Scrum альянс подготовили много доступных документов, учебные пособия, записи лекций, содержащие конкретные детали. Кон и Ларман являются авторами полезных книг по Scrum^{2Фирма Microsoft, проявляя интерес к agile, включила возможность разработки проектов по методу Scrum, начиная от планирования спринтов и кончая отслеживанием прогресса, в студию разработки Visual Studio Team Foundation Server – TFS. Полезная книга, где описан этот подход: Стив Резник, Аарон Бьйорк, Майкл де ла Маза "Scrum с Team Foundation Server 2010. Профессиональный подход", 2012.}.

9.4.1 Большая идея Scrum

Наиболее отличительная черта Scrum – это правило "закрытого окна", рассмотренное в предыдущих главах:

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

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

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

9.4.2 Ключевые практики Scrum

Итерации Scrum следуют практикам, рассмотренным в предыдущих главах:

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

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

9.4.3 Scrum: оценка

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

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

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

9.5 Crystal

Имя Crystal обозначает массив методов, разработанных Алистером Кокбурном. Слово "массив" можно понимать буквально. Каждый метод массива характеризует разработку проектов в зависимости от двух критериев – критичности проекта и его размера. Каждый критерий имеет четыре уровня, что в совокупности дает матрицу из 16 окрашенных элементов. Понятно, что только немногие из этих слотов заполнены детальными описаниями методов. Метод Crystal Clear предназначен для работы с небольшими проектами, Crystal Orange был первым разработанным методом и ориентирован на большие проекты.

9.5.1 Большая идея Crystal

Crystal особое внимание уделяет взаимодействию в команде благодаря принципу, который превращает желеобразную группу в единое целое:

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

Так определяется осмотическая коммуникация в версии Crystal Clear. Для больших групп или групп, разделенных пространственно, концепция обобщается на "ядерную коммуникацию".

9.5.2 Принципы Crystal

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

• "Частая поставка" – реальным пользователям выполняемого, прошедшего тестирование кода является наиболее важным свойством любого проекта. Эта идея общая для всех agile методов.
• "Рефлексивные улучшения" – требуют, чтобы команда раз или два в месяц в течение цикла поставки собиралась вместе на рефлексивный семинар или ретроспективу итерации для обсуждения того, насколько хорошо все работает. Эта идея является аналогом уровня "оптимизация" в модели, пришедшей из другого края программной инженерии, модели CMMI. Эта практика характерна и для Scrum, где она носит название "ретроспектива".
• "Осмотическая коммуникация" – подталкивающая коммуникация предполагает, как отмечалось выше, постоянный и свободный поток информации между членами команды.
• "Персональная безопасность" – ответ Crystal на необходимость устойчивого темпа. Принцип устанавливает, что члены команды должны без страха наказания или других неприятных последствий высказывать все, что считают нужным, например, утверждать, что расписание нереалистично.
• "Фокус" – определяет условия, при которых разработчики могут выполнять работу без всяких помех. В частности, от них нельзя требовать одновременного выполнения нескольких задач, поскольку это мешает сосредоточиться (сфокусировать внимание) на решении основной задачи. Они не должны иметь дело с задачами, не относящимися к проекту. Разработчик может справиться с задачей за два часа сосредоточенной работы или, например, за два дня, в то время как ему пришлось бы потратить четыре часа или всю неделю в ситуации, когда он вынужден отвлекаться на другие работы.
• "Простой доступ к пользователям, выступающим в роли экспертов" – Crystal-вариант общего agile принципа вовлечения потребителей. Метод не приписывает включения пользователей в команду – стиль XP, или определения владельца продукта, как в Scrum, хотя и не исключает подобные приемы. Все, что требуется в методе, – это гарантия свободного доступа представителям пользователей, обладающих знаниями. Даже один час в неделю, дающий возможность общения с реальным и опытным пользователем, имеет большую ценность. Эта рекомендация свидетельствует о реализме Crystal. Как отмечалось в предыдущих обсуждениях, настоящие эксперты весьма занятые и высоко ценимые специалисты, так что нельзя рассчитывать на их постоянное присутствие в проекте, не говоря уже о полном рабочем дне. Но вполне обоснованно требовать, чтобы высокое начальство гарантировало минимальный уровень доступа.
• "Техническое окружение с автоматизацией тестов, управлением конфигурацией и частой интеграцией" – длинное название для принципа, но достаточно ясное – программист должен иметь современные средства. Вряд ли эта идея может сегодня кого-либо удивить, за исключением менеджеров, рожденных в эпоху кринолинов, но повторять эту истину стоит.

9.5.3 Crystal: оценка

Как и Lean, Crystal не является методом, шаг за шагом рассказывающим подробности организации проекта, как это делает Scrum, не предлагает технологические детали, как это делает XP. Crystal – это скорее концентрация программистской мудрости.

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

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

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