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

1.4 Практики

Для достижения принципов, представленных выше, agile методы применяют множество приемов, или практик (practice).

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

Все agile методы выступают за частые контакты (встречи лицом к лицу). В частности, Scrum включает требование ежедневных встреч в начале рабочего дня, известных как "ежедневный Scrum". Встреча должна быть короткой: 15 минут – типичный вариант. Эта цель достижима для групп из 10–15 человек, поскольку рамки встречи строго ограничены. Каждый член команды должен ответить на три вопроса:

• что было сделано за прошлый день;
• что предполагается сделать за текущий день;
• с какими трудностями пришлось столкнуться.

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

Любая разработка ПО сталкивается с проблемой планирования, в частности, с проблемой компромиссного планирования функциональности и сроков ее реализации. Методы agile предлагают "игру в планирование" (planning game в XP) и "планирующий покер" (planning poker в Scrum). Оба варианта представляют вариации группового оценивания, где участникам предлагается вначале дать свою независимую оценку, затем проанализировать оценки других участников игры, затем итеративными шагами прийти к консенсусу.

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

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

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

1.4.2 Технические практики

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

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

Эта последовательность шагов, применяемая с самого начала, когда программа пуста и, следовательно, "падает" на любом нетривиальном тесте, продолжается далее и далее вплоть до завершения разработки. Такова форма разработки, характерная для экстремального программирования.

Рефакторинг – это процесс критического анализа реализации проекта, в результате которого выполняются любые трансформации, необходимые для улучшения согласованности и эффективности. Существуют каталоги стандартных трансформаций рефакторинга. В частности, есть книга [Fowler 1999], популяризирующая эти идеи, в которой приводятся типичные примеры трансформаций. Для объектно-ориентированного программирования примером стандартной трансформации является перенос свойства одного класса в другой класс вверх или вниз по иерархии семейства классов, связанных отношением наследования. Предполагается, что переносимое свойство концептуально ближе к новому классу, в котором оно появляется. Рефакторинг особенно необходим при тест-управляемой разработке, поскольку с каждым новым тестом в программу добавляется код, где каждая часть программы скроена под специфический тест, что само по себе приводит к запутанной структуре. Рефакторинг позволяет придать проекту четкую структуру. Точно так же, как сценарии и тесты представляют замену требований, рефакторинг является agile ответом на "Предваряющий анализ".

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

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

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

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

1.5 Артефакты

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

1.5.1 Виртуальные артефакты

Варианты использования и особенно пользовательские истории являются сценариями, представляющими взаимодействие пользователей с системой. Варианты использования получили популярность еще до agile во многом благодаря книге Ивара Якобсона [Jacobson 1992]. Пользовательские истории появились как часть agile движения. Разница в гранулярности. Вариант использования представляет полный проход по системе, начиная, например, от просмотра продукта на сайте E-commerce до заполнения заказа. Пользовательская история – это небольшой модуль, задающий взаимодействие, например такого вида: "Как пользователь я хочу видеть список моих текущих заказов, так, чтобы я смог отследить мои закупки у интересующей меня компании".

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

Рис. 1.2. График ликвидации нереализованных задач. Убывающая диаграмма выполнения

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

1.5.2 Материальные артефакты

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

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

Карты историй представляют бумажные карточки (agile проповедники предписывают даже размер: 3 на 5 дюймов или 8 на 13 сантиметров), используемые для записи пользовательских историй. Эти карточки размещаются на панели историй, достаточно большой для размещения всех карточек. Команда динамически меняет расположение карточек на панели, группируя их по категориям.

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

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

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

1.6 Первая оценка

Достаточно полной информации для полноценного анализа всех "за" и "против" agile подхода (прекрасного, ужасного, рекламного) у нас пока нет. Такой анализ будет сделан в финальной главе. Но уже теперь можно сформулировать первое впечатление.

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

Самюэль Джонсон^{9Samuel Johnson – английский поэт и литературный критик эпохи Просвещения (1709–1784).} как-то ответил одному ретивому автору:

"В вашей работе, сэр, много нового и полезного! Но то, что является новым, не является полезным, а то, что полезно, не является новым".

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

1.6.1 Ни нового, ни полезного

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

увеличить изображение
Рис. 1.4. Из комикса про Тинтина

При работе с программной системой, например с веб-приложением, не возникало ли у вас ощущение, что вы оказались в положении Тинтина^{10Tintin – герой популярного комикса, путешествующий по свету и попадающий в различные сложные ситуации.}, марширующего в смирительной колодке? Как только вы отважитесь выйти за пределы сценария, предусмотренного проектировщиками с их безмерной мудростью, все перестает работать. Такие системы являются прямым результатом требований, основанных единственно на анализе вариантов использования и пользовательских историй. Хорошие требования исходят из абстрактных спецификаций, обобщающих многие частные сценарии и поддерживающих разработку гибких, расширяемых приложений.

1.6.2 Новое и бесполезное

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

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

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

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

Еще худшим является запрет на разработку предваряющих проект требований. Базисное наблюдение вполне корректно: требования будут меняться, их трудно полностью описать в начале проектирования. Но отсюда вовсе не следует столь драматический вывод о бесполезности требований. Действительно, следует лишь то, что требования являются предметом изменений подобно всем артефактам в процессе создания ПО. Эта точка зрения многократно высказана в многочисленной литературе по программной инженерии, и она по-прежнему остается справедливой. К несчастью, многие проекты в последние годы следуют упрощенным agile советам, опуская фазу разработки систематических требований, заменяя ее попытками итеративного построения системы, опираясь на взаимодействие с потребителями. Результаты часто (вполне предсказуемо) оказываются разочаровывающими, поскольку требования появляются на поздних этапах жизненного цикла, когда функциональность уже реализована и должна быть существенно изменена. Советы agile в данном случае носят безответственный характер, и в серьезных проектах их следует игнорировать. Разумная практика состоит в том, чтобы формулировать требования в самом начале, создавать предварительную версию, удовлетворяющую проекту, и рассматривать требования как живой продукт, подлежащий постоянной адаптации в ходе развития проекта.

1.6.3 Не новое, но полезное

Литературе agile свойственен очаровательный юношеский задор: я та-ак уникален! Никто до меня не понимал в чем смысл жизни! Мои приверженцы та-ак соответствуют новым временам!

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

Первый – это итеративная разработка. Еще в восьмидесятые годы прошлого столетия индустрии было понятно, что старая модель независимой разработки подсистем в течение нескольких месяцев, а затем попытка их сбора чреваты бедствиями. Появившаяся в 1995 году книга Майкла Кузумано и Ричарда Селби "Секреты Microsoft" [Cusumano 1995]стала настоящим бестселлером. В частности, речь в ней шла о "ежедневной сборке" – практике, чье название говорит, что рабочая версия проекта создается каждый день^{11Примерно в эти же годы Евгений Веселов – известный российский программист, ставший ведущим сотрудником в Microsoft, рассказывал мне о том, как в Microsoft создается ПО. Подобно известному лозунгу "Шоу должно продолжаться" девиз программистов Microsoft – "Build должен работать". Это достигалось за счет того, что каждое изменение, предлагаемое программистом, во-первых, подписывалось его коллегой, которому нужно было рассказать о сути изменений (аналог парного программирования). Затем это изменение поступало в тестирующую лабораторию, куда программисты не допускались. Практически на "голое железо" с нуля ставилась операционная система, ставился проект с новым изменением, запускались все тесты из базы тестов (расширенный вариант регрессионного тестирования). Только при прохождении всех тестов новая версия сборки передавалась программистам для работы. Так что сборка осуществлялась при внесении каждого изменения, а не только раз в сутки. Другой наш российский программист Алексей Пажитнов, автор известной игры "Тетрис", также работающий в Microsoft, рассказывал, что он как-то предложил разработать новую игру и получил одобрение на создание пробной версии продукта. На следующий день его встретил тестер, занимающийся его проектом, и сказал, что в базе тестов зафиксированы три теста, связанные с ошибками в его первичном документе, занимающем полторы странички, когда ни о каком коде еще речи не было. Так что правило "вначале тест" также широко применялось в индустрии без всякой ссылки на agile.}. Проекты с открытым кодом, популярные в течение десятилетий, имеют практику создавать релизы рано и часто. С появлением web-приложений эта тенденция только усилилась. Инструментарий Google и многие облачные приложения часто обновляются без всякого официального объявления новой версии. Литература agile помогла закрепить в сознании программистов полезность идеи частых релизов, но не agile методам принадлежит первенство в этом вопросе.

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

1.6.4 Новое и полезное!

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

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

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

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

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

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

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

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

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

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