Коктейль Waterfall и Agile на масштабе: технарский взгляд SAFe®

Вольный перевод статьи Alex Yakyma Mixing Agile and Waterfall at Scale: A Technical Perspective — Scaled Agile Framework.

Scaled Agile Framework® (SAFe®) широко применяется в индустрии. Однако в большинстве крупных организаций существует переходный период, когда часть программ продолжают реализовываться по водопадной (Waterfall, последовательной или каскадной) модели, а часть программ быстро переходят на итеративно-инкрементальную поставку ценности (Agile) с помощью Agile Release Train (ART). При этом программы зависят друг от друга организационно и на уровне программного кода. Это приводит к конфликту методов, ожиданий и ставит под угрозу совместную поставку. Так как эту проблему быстро не решить, имеет смысл предоставить  рекомендации по выбору методов продуктивного взаимодействия между этими двумя подходами.

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

Общие требования и воркшопы по дизайну

С одной стороны, водопадный метод разработки требует сразу на старте разработать полный дизайн систем (Big Design Up Front, BDUF). С другой стороны, почему эту задачу не могут решить Agile- и Waterfall-команды сообща? Гораздо проще выявить и разрешить зависимости, когда обе команды собираются вместе перед белой маркерной доской. Вот несколько советов для эффективного проведения такого воркшопа:

• Сделайте домашнее задание перед встречей. Не нужно выявлять все зависимости, сначала постарайтесь сформировать целостное понимание всей работы. После этого зависимости начнут быстро выявляться. Каждая группа должна провести такой анализ перед встречей. Иначе на совместной встрече у участников не будет необходимого понимания текущего состояния дел и общего контекста.
• Активно используйте маркерную доску, флипчарты и стикеры.
• Используйте метод “Спецификации на примерах” (Specification By Example) для определения конкретного поведения системы и устранения неопределенности, там где это возможно. “Приведи пример!” — должно стать фразой, вокруг которой строится воркшоп. Поможет подход на основе показа (Demo-Driven): представьте, что команды у финишной черты и начинают демонстрацию. Опишите, что показывается. Эти примеры будут использованы обеими группами для формирования цели совместного проекта.
• Определите зависимости, составьте интеграционный план и выберите механизмы интеграции.

Заглушки и дизайн интерфейсов

Agile-команды применяют заглушки (mockups, mocks), чтобы проверить поведение интерфейсов еще до того, как реализующий их программный код или система станут доступны. Конечно, нужна реальная интеграция, но если только одна из двух команд часто поставляет программный продукт конечному пользователю, интерфейсы становятся самой возможной из реальных вариантов интеграции. Вот несколько советов:

• Заглушки хороши, когда они одновременно устраняют пробелы в личном общении между командами и в интеграции между системами.  Заглушки имитируют интерфейсы, и, следовательно, сначала должны быть обсуждены на воркшопе. В идеале Waterfall-команды берут на себя работу по созданию заглушек для Agile-команд. Иначе Agile-команда может это сделать сама, но Waterfall-команда должна тщательно проверить. Если не сделать одно из двух, заглушки будут проверять набор неверных предположений.
• Проектируйте интерфейсы, когда пишете заглушки. Крайне рекомендуется объединить проектирование заглушек с нативной структурой интерфейса в конкретном языке программирования (например, интерфейсы в Java и C#, или абстрактные классы в С++ и т. д.). Это позволит разработчикам просто заменять каждую заглушку реальным кодом, как только он будет разработан. Если будут обнаружены несоответствия – немедленно зафиксируйте их.

Частая интеграция

Частая интеграция проверяет код и заложенные в него предположения. На рисунке вы видите, что “часто” — это не один раз в конце проекта. Заглушки требуют реализации логики, связанной с интерфейсом заглушки, что само по себе способствует интеграции.

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

Паттерны проектирования и рефакторинг

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

Применение паттернов Мост (Bridge), Адаптер (Adapter), Декоратор (Decorator), Цепочка Обязанностей (Chain of Responsibility) также полезно — они способствуют применению принципа разделения ответственности. Паттерн Фабрика (Factory) способствует использованию заглушек, ранней интеграции и повышает тестируемость кода, так как создание экземпляров объектов отделено от их использования. Применение паттерна Фасад (Facade) стимулирует раннюю проверку интеграции с устаревшими системами. Рассматривайте паттерны не только как строительные элементы кода, но и как способ изоляции изменчивости, которая, вероятно, будет выше, если она зависит от более поздних разработок Waterfall-команды.

Резюме

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

В продолжении темы рекомендуем статью Асхата Уразбаева Четыре способа взаимодействия Agile-команды и Waterfall-команды.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.