Командная и Техническая Гибкость

Ниже представлен вольный пересказ статьи: Team and Technical Agility — Scaled Agile Framework.

Командная и Техническая Гибкость — одна из пяти Ключевых Компетенций Lean-организации.

Командная и Техническая Гибкость — компетенция, описывающая критические навыки и принципы и практики Lean-Agile, необходимые для создания высокопроизводительных Agile-команд, создающих качественные технические решения.

Зачем Командная и Техническая Гибкость?

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

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

Командная гибкость позволяет командам максимизировать поставляемую ценность. Небольшие кросс-функциональные команды, объединенные вокруг общей цели, применяют Lean-Agile, понимают свою роль во всей организации и в рамках Agile Release Train (ART), который представляет собой долгосрочное объединение Agile-команд с общей концепцией, вектором развития, пониманием результатов решения. Техническая гибкость подразумевает, что все члены команды обладают необходимыми навыками и знанием технических практик для создания наилучших решений. Это гарантирует, что разрабатываемые системы имеют подходящее архитектурное исполнение, высокое качество кода и всех компонентов, могут быть без труда модифицированы в будущем.

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

Командная Гибкость

Командная гибкость — первая составляющая компетенции. Работа Agile-команд основывается на взаимодействии Представителей Бизнеса (Business Owners), разработчиков и тестировщиков, что обеспечивает согласованность, общее понимание и быструю предсказуемую поставку ценности. Такие команды имеют полномочия и несут ответственность за результаты своей работы, повышение производительности и уменьшение времени поставки на рынок. Agile-команды выполняют работу небольшими порциями, сокращая циклы обратной связи и адаптируясь под изменяющиеся потребности.

Agile-команды — это двигатель ART, поэтому эффективность команд критически важна. В SAFe Agile-команда — это кросс-функциональная группа размером 5-11 человек, которая отвечает за сбор требований, разработку, тестирование и развертывание (при необходимости) некоторых элементов Решения за короткий временной интервал Итерации. Agile-команда включает такие роли как Команда Разработки (Dev Team), Scrum-мастер (Scrum Master) и Владелец Продукта (Product Owner).

Создание Высокопроизводительных Команд Lean-Agile

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

Работа в Процессе Lean-Agile

В SAFe Agile-команды берут на вооружение набор Agile-методов, включая Scrum и Kanban. Большинство команд используют Scrum, включая следующие Scrum-практики:

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

Для оптимизации работы команды визуализируют рабочий поток и управляют им при помощи Kanban-системы. Kanban позволяет командам идентифицировать так называемые бутылочные горлышки путем введения ограничений на количество одновременно выполняемых работ (WIP, Work In Progress). Такие ограничения предназначены для того, чтобы команда не брала в работу новые пользовательские истории пока не завершит уже начатые работы. Команды должны быть кросс-функциональными и иметь навыки, необходимые для реализации Фич или компонентов. Agile-команды не объединяются по функциональному принципу (команда тестировщиков, команда разработчиков и т.д.) или по принципу знания технической инфраструктуры, так как такие команды порождают зависимости, которые замедляют поставку ценности.

Работа в составе Agile Release Train

Ничто не может превзойти Agile-команду, разве что команда Agile-команд. Для поставки сложных решений, группа Agile-команд должна взаимодействовать под зонтиком ART. Такие поезда собирают вместе всех людей, необходимых для сбора требований, разработки, тестирования и развертывания решения для клиентов.

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

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

Техническая Гибкость

Техническая гибкость — вторая составляющая компетенции, определяющая Agile-принципы и практики программной инженерии (Software Engineering), которые команды используют для быстрой надежной поставки ценности. Программная инженерия — это «приложение систематического, дисциплинированного, измеримого подхода к разработке, функционированию и сопровождению программного обеспечения» (прим. ред. — IEEE STD 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, IEEE Computer Society, 1990). Программная инженерия по Agile привносит ценности и принципы Lean-Agile, практики экстремального программирования (eXtreme Programming, XP), Agile-моделирование и другие зарекомендовавшие себя подходы для проектирования программных решений.

Настройка Потока

Необходимость разрабатывать и выпускать высококачественные бизнес-возможности создает для Agile-команд условия динамичной и потоковой среды. Вместо выполнения большей части тестирования по окончании разработки, Agile-команды создают и регулярно выполняют тесты на ранних этапах разработки на различных уровнях. Для изменений в программном коде определяются тесты (Test-Driven-Development, TDD) (прим. ред. — Beck, Kent. Test-driven Development: By Example. Addison-Wesley. 2003), а критерии приемки Историй (Behaviour-Driven Development (BDD) (прим. ред. — Pugh, Ken, Lean-Agile Acceptance Test-Driven Development: Better Software Through Collaboration. Addison-Wesley. 2010) и гипотезы о выгодах Фич (Lean-UX) (Gothelf, Jeff and Josh Seiden. Lean UX: Designing Great Products with Agile Teams. O’Reilly Media. 2016) обеспечивают встроенное качество. Встраивание качества гарантирует, что частые изменения в рамках Agile не будут приводить к новым ошибкам. Таким образом, Agile-команды создают и развивают решения, способные отвечать текущим и будущим бизнес-потребностям.

Рисунок 1. Agile Software Engineering

В традиционных проектах успех определяется полным выполнением инициативы в отведенный срок и в рамках бюджета. Lean-Agile стремится к быстрым и регулярным релизам минимального коммерчески ценного функционала (Minimal Marketable Feature, MMF), а также быстрому обучению и адаптации. MMF определяет минимальный функционал, представляющий ценность бизнесу и рынку. Согласно Lean-UX, каждая Фича и каждое требование представляет собой гипотезу, которая должна быть проверена. На последнем шаге Lean-UX проверяется гипотеза и делается вывод о том, насколько Фича обеспечивает ожидаемую ценность. Для каждой Фичи команды используют телеметрию, которая позволяет проверить гипотезу о выгоде MMF и определить, была ли достигнута выгода.

Неоптимальная архитектура решения может влиять на поток и препятствовать возможности команды независимо выпускать продукт небольшими порциями, в то время как компонентная или сервисно-ориентированная архитектура с качественно спроектированными интерфейсами позволяет командам независимо разрабатывать, тестировать, разворачивать и выпускать системные компоненты и сервисы. Такая целеориентированная архитектура образует архитектурную тропинку (architectural runway), состоящую из enabler для будущих MMF. Также не стоит забывать про важность сотрудничества между архитектором и командой, работающей с архитектурой.

Мышление “Сначала Тест”

Скорость процесса поставки зависит от того, насколько хорошо среда разработки поддерживает встроенное качество через тестирование на разных уровнях. Ошибки сильно влияют на процесс, задерживают выпуск и делают неопределенным время ожидания. Чтобы исключить ошибки создаются тесты всего — Фич, Историй и программного кода. В идеальном случае тесты пишутся перед тем, как компонент будет разработан. Такой подход называется Сначала Тест (Test-first). Test-first применяется как к функциональным требованиям (Фичи и истории), так и к нефункциональным (Non-Functional Requirements, NFRs) требованиям к производительности, надежности и т.п. На рисунке 2 представлено как раннее создание тестов в подходе Test-first сжимает классическую «V-модель».

Рисунок 2. Shift testing left посредством BDD и TDD

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

Рисунок 3. Баланс набора тестов с большим количеством быстрых, автоматизированных тестов

Написание Историй в концепции Behavior-Driven Development

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

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

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

Моделирование Историй

Для демонстрации дизайна и поведения системы команды используют упрощенные модели. Модели могут быть:

• Статичные (или структурные) — показывают назначение компонентов и взаимосвязи между ними.
• Динамичные (поведенческие) — показывают взаимодействие между компонентами для понимания того, как функционирует система.

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

Качество в Дизайне

Качественный код и дизайн решения влияют на способность команды быстро и эффективно поставлять новый функционал. Например, практики экстремального программирования (прим. ред. — Beck, Kent. Extreme Programming Explained. Addison-Wesley. 1999), как и некоторые другие практики, побуждают к хорошему дизайну:

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

По мере развития системных требований дизайн системы должен также эволюционировать. Низкокачественный дизайн труден для понимания и приводит к низкой скорости поставки с большим количеством дефектов. Использование coupling/cohesion (прим. ред. — подразумевается низкая степень зацепления между компонентами и высокая степень внутрикомпонентной связности), а также подходящей абстракции и инкапсуляции способствуют созданию систем более простых для понимания и модификации. Принципы SOLID (прим. ред. — Martin, Robert. Design Principles and Patterns. 2000) делают системы гибкими, поддерживают возможность реализации новых требований:

• Принцип одной ответственности (Single Responsibility Principle) — компоненты должны выполнять одну функцию. Части, которые меняются по одной и той же причине должны быть объединены, а части, меняющиеся по разным причинам — разъединены.
• Принцип открытости/закрытости (Open/Closed Principle) — компоненты должны быть открыты для расширения и закрыты для изменения. При расширении компонентов не нужно их модифицировать с целью обеспечить новое поведение.
• Принцип подстановки Барбары Лисков (Liskov Substitutuon Principle) — клиенты не должны зависеть от способа реализации, а должны быть способны работать с любой реализацией незаметно для себя.
• Принцип разделения интерфейса (Interface Separation Principle) — множественные клиентоориентированные интерфейсы предпочтительнее одного интерфейса общего пользования.
• Принцип инверсии зависимостей (Dependency Inversion Principle) — высокоуровневые модули не должны зависеть от низкоуровневых модулей, а должны зависеть от абстракций/интерфейсов.

Шаблоны проектирования (прим. ред. — Gama, Erich, et al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. 1994) описывают хорошо известные способы поддерживать эти принципы. Один из них — использование названий, которые легко описывают назначение компонентов как части большой системы, например «Фабрика» (Factory) или «Сервис» (Service). Другой пример — использование на этапе проектирования нескольких вариантов дизайна и последующий выбор наиболее оптимального.

Качество в Реализации

Agile-команды непрерывно реализуют решения, используя такие практики повышения качества как TDD, рефакторинг, эволюционное проектирование. TDD — это подход к разработке, при котором разработчик непрерывно создает минимальные наборы тестов, после чего в рамках быстрого цикла разработки (в идеале, минуты) пишет программный код под эти тесты. Для быстрого выполнения тестов используются дублеры (test doubles/mocks), они запускаются для компонентов с наименьшей скоростью работы или имеющих ограниченную доступность.

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

Качество в Непрерывной Интеграции и Развертывании

Масштабирование Agile-практик приводит к тому, что разработчики вносят большое количество изменений, которые должны непрерывно проверяться на предмет конфликтов и ошибок. Непрерывная интеграция (Continuous Integration, CI) позволяет разработчикам работать с последней версией продукта при помощи частого (каждые несколько часов) применения изменений. Непрерывное Развертывание (Continuous Deployment, CD) обеспечивает быструю обратную связь, что способствует исключению ошибок, соответствию стандартам качества и правильной работе в приближенной к продуктивной среде. Изображение 4 демонстрирует что каждое изменение программиста (commit) автоматически инициирует процесс сборки, тестирования и установки изменений в рамках Конвейера Непрерывной Поставки (Continuous Delivery Pipeline). «Маски», представляющие собой тестовые дублеры (test doubles) для элементов, необходимых для работы тестируемой системы, позволяют снизить время и стоимость тестирования.

Рисунок 4. Непрерывная интеграция и развертывание

Также SAFe предоставляет инструмент для самооценки и улучшения командной работы и технических навыков.

Резюме

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