Практики agile: производственные процессы

6.7 Процессы в миниатюре

Тренировки для освоения agile часто используют технику, которую Кокбурн называет "процессом в миниатюре". Суть ее в том, чтобы освоить приемы agile, решая задачи, далекие от программирования, в течение короткого периода – день, час или десяток минут. Учебные сессии Scrum прославились тем, что предлагают участникам спроектировать бумажные самолетики, применяя роли, принципы и практики Scrum. Запускать в полет изготовленные бумажные самолетики – забавное дело.

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

6.8 Итерационное планирование

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

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

1. Цель итерации, описывающая, чего команда планирует достичь на данной итерации, кратко – одно или два предложения, в терминах, понятных обычным сопричастникам проекта. Типичный пример (предположим, речь идет о проекте компилятора): реализовать новые расширения функционального языка.
2. Бэклог итерации, список задач, подлежащих реализации. Этот результат работы предназначен, главным образом, для внутреннего использования командой.
3. Список критериев приема для каждой задачи.

Заметьте, отсутствуют такие цели, как

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

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

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

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

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

6.9 Подведение итогов

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

На встрече команда представляет полученные результаты потребителям, в частности владельцу продукта в Scrum. Обсуждается, что достигнуто из запланированного, что нет; соответствие критериям приема задач, реальная стоимость задач.

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

6.10 Ретроспектива

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

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

6.11 Scrum Скрумов

Основные agile приемы применимы для небольших команд, до 10 человек. Возникает вопрос, как масштабировать процесс разработки на большие проекты. Вот как на этот вызов отвечает Scrum. Подход называется "Scrum of Scrums" (Scrum Скрумов) и определяется следующим образом:

Ежедневный Scrum, на котором присутствуют по одному человеку из каждой команды в многокомандном проекте.

Такие встречи необязательно проводятся каждый день, чаще два-три раза в неделю. Целью таких встреч является координация, позволяющая выяснить:

• изменения в интерфейсе;
• зависимости между частичными проектами.

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

Что касается второй проблемы, то лучший agile ответ, который я видел, состоит в том, что зависимостей следует избегать. В соответствии со Швабером [Schwabber 2004]:

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

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

6.12 Коллективное владение кодом

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

Во многих проектах за каждый модуль проекта, за каждую подсистему несет ответственность один человек. Типичный комментарий, характерный для команд Майкрософт: "Если вы хотите изменить нечто в этом API, вы должны связаться с Лизой, поскольку она владеет этим элементом". Здесь не имеется в виду, что Лиза – "собственник" кода, владелец интеллектуальной собственности; речь идет лишь о технических аспектах, она тот, кто решает все вопросы, связанные с изменениями этой части кода. Владение кодом в этом смысле характерно не только для коммерческого ПО: многие проекты с открытым кодом, такие как Mozilla, также применяют подобную модель, где требуется разрешение владельца модуля на просмотр кода модуля. В обмен на это мы ожидаем, что владелец модуля несет ответственность за корректную работу, рассматривает заплатки, предлагаемые другими, и способен оценить код, разработанный другими людьми.

6.12.1 Дебаты по поводу владения кодом

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

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

XP предлагает коллективное владение кодом [Back 2005]:

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

В этом утверждении нюансов больше, чем в его предшественнике [Back 2000]:

Любой, кто видит возможность внести улучшения в любую часть любого кода, должен это сделать в любой момент.

Обе версии удивительным образом игнорируют роль другой практики – парного программирования, изучаемой в следующей главе. В фактическом применении XP, как описано у Кокбурна [Cockburn 2005], парное программирование сдерживает практику "свободно-для-всех":

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

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

В методе Crystall применяется более умеренный подход:

Большинство из проектов Crystall, с которыми пришлось познакомиться, применяют политику "измени, но дай мне знать".

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

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

На самом деле этот вопрос более важен, чем контроль изменений при владении кодом. При наличии современных средств конфигурации возможно автоматическое применение правил, запрещающих, например, внесение изменений до тех пор, пока другой человек не санкционирует их применение. Google имеет такое правило. Более формальная версия требует "обзора кода прежде чем он будет изменен"; правило известно как правило RTC (Review Then Commit) – "Осмотри Потом Выполни). Этому правилу отвечала начальная политика Apache. После жалоб на то, что оно слишком строгое, в 1998 году Apache ввел правило CTR (Выполни Потом Осмотри), когда изменения сдерживаются редко используемой, но заставляющей программиста быть начеку возможностью наложения запрета на изменения.

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

6.12.2 Коллективная собственность и кроссфункциональность

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

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

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