Внедрение архитектурных стандартов и следование им — не самый простой элемент agile-разработки для руководителей и участников команд. Стандартов, относящихся к практикам и данным, придерживаться непросто, так как agile-группы работают в режиме спринтов длительностью по две-четыре недели, а владельцы продуктов обычно заполняют журнал пожеланий приоритетными функциями. Ведь дополнительное время требуется как на разработку стандартов, так и на то, чтобы продумать технические особенности их внедрения.
Если работать по схеме, при которой после завершения очередного спринта составляются планы только на следующий, на планирование долгосрочной разработки с соблюдением стандартов не остается времени. При этом если задокументированным стандартам трудно следовать или нет возможности с ними сверяться, новых разработчиков будет сложно заставить усвоить рекомендации, касающиеся архитектуры и данных, а это все равно что блуждать группой по лесу без карты и GPS; вы, возможно, набредете на тропу, но не будете знать, лучший ли это путь к «цивилизации».
Какие проблемы данных и архитектуры требуют внимания
Полезным будет разделить стандарты в области данных и архитектуры на две категории.
- Стандарты архитектуры, например, модели данных, конвейеры данных, базовые технологии микросервисной архитектуры, стандартные конвейеры непрерывной интеграции и доставки программных решений (continuous integration/continuous delivery, CI/CD), проверки концепций для новых технологий. Внедрение таких стандартов требует подготовительной работы.
- Стандарты для практик, в том числе соглашения об именовании, требования к тестированию, стандарты интерфейсов микросервисов и шаблоны удобства использования (usability) — все это будет служить для участников группы руководством при реализации функций и устранении технического долга. Кроме того, в данную категорию можно включить стандарты процессов, определяющие принципы расширения моделей данных, проверки усовершенствований конвейера CI/CD, составления документации по новым конечным точкам микросервисов и т. д.
| Считаете, что Agile без DevOps — деньги на ветер? Ждем вас на конференции «Корпоративный DevOps 2019»! |
Когда стандарт требует инженерной работы, ее лучше оформить в качестве ситуаций (epic), функций и историй (story) в журнале пожеланий и назначить соответствующей группе. Для этой группы другие команды разработки становятся клиентами, соответственно, она должна сформулировать условия приемки своей работы. Владельцем продукта при этом может быть архитектор данных, приложения или решения. Его задача — выпустить компонент, которым легко смогут воспользоваться agile-команды и который будет полезен бизнесу.
В то же время, если группы разработки пользуются стандартами архитектуры и данных, эти же стандарты должны применяться при реализации пользовательских историй. Соответственно, участникам группы нужно потребуется практическое владение такими стандартами, в связи с чем полезно завести простую в использовании базу знаний по ним.
Agile-разработка требует систематического планирования
Многие agile-группы проводят совещания по планированию в начале каждого спринта. В ходе таких совещаний обсуждаются и выбираются для реализации пользовательские истории.
Этот подход эффективен, когда приоритет группы — мелкие доработки существующих приложений. Но если речь идет о новой функциональности, которую нужно создавать в соответствии со стандартами в области данных и архитектуры, оперативного планирования недостаточно. Краткого совещания непосредственно перед началом спринта просто не хватит, чтобы обсудить пользовательские истории и согласовать их реализацию в соответствии со стандартами.
Поэтому если следование стандартам – ваш приоритет, нужно проводить соответствующее планирование на более ранних этапах. Помимо совещания по ближайшим задачам, проводимого перед началом спринта, следует также организовать одно или более собраний, посвященных планированию реализации пользовательских историй.
В идеале следует внедрить agile-процесс непрерывного планирования, обеспечивающий систематический анализ ситуаций, функций и пользовательских историй. Совещания по сложным рабочим элементам, для планирования которых нужно больше времени, проводятся за несколько спринтов до реализации, а небольшие можно планировать непосредственно перед нею. Когда совещание проводится на более раннем этапе, группе не приходится работать в условиях сжатых сроков и участники с большей вероятностью будут придерживаться стандартов благодаря наличию достаточного времени на планирование.
Разработка эталонных архитектур и моделей данных
Один из элементов координации работы agile-групп состоит в разработке эталонных архитектур и моделей данных, отражающих текущее состояние проекта, состояние в ближайшем будущем и долгосрочные цели. Такие схемы будут служить «дорожной картой» для разработчиков, помогающей обеспечивать оптимальное соответствие реализации стандартам архитектуры и данных.
Эталонная архитектура представляет собой схему с цветовой маркировкой и символами, при помощи которых изображаются текущее и будущие состояния системы. Схему следует уместить на одной странице, определив набор связанных компонентов и изобразив все сервисы одного или более приложений.
Эталонная модель данных может состоять из нескольких схем в зависимости от особенностей использования данных в организации. Обычно эталонная модель описывается следующими схемами:
— концептуальная модель данных, изображающая бизнес-объекты, связи и основные транзакции;
— аналитическая модель, отражающую централизованное размещение данных в озерах или хранилищах и их использование для аналитики, экспериментов с искусственным интеллектом и визуализаций;
— модель интеграции данных, на которой показаны источники данных, операции преобразования и базы данных;
— сервисная модель, показывающая, каким образом микросервисы и другие компоненты соединяются с базами данных.
Такие схемы служат разработчикам в качестве отправной точки при освоении стандартов и планировании на будущее. Архитектору следует дополнить их вспомогательными сведениями — документацией по API, словарями данных и перечнем профильных специалистов по каждому компоненту архитектуры и модели данных.
Составьте согласованные со стандартами условия приемки нового кода
Пользовательские истории должны описывать суть требований и причину их появления, а также содержать пояснение о том, кому конкретно нужна их реализация. В идеале документировать принципы реализации истории должен не владелец продукта, а архитекторы, разработчики и инженеры по тестированию. При этом группы разработки должны нести ответственность за выпуск функциональности и соответствие реализации стандартам в области архитектуры, данных, безопасности, DevOps и другим.
При этом только документирования стандартов и эталонных архитектур недостаточно. Когда команды разработки стеснены обязательствами быстрого написания кода и выпуска очередных релизов, доработка стандартов обычно не в приоритете. Архитекторы должны брать на себя ответственность за анализ пользовательских историй и организацию собраний с членами команд для обмена знаниями, а также за согласование реализаций с необходимыми стандартами путем дополнения историй условиями приемки.
При этом и условия приемки, и стандарты должны обсуждаться руководителями разработки с членами группы — это поможет им придерживаться в работе оптимальных методов и обеспечивать долгосрочное соответствие реализаций стандартам.
В организациях большого размера придется рассмотреть и другие принципы соблюдения стандартов в области данных и архитектуры. Но в любом случае, основные практики, которые помогут группам разработки выпускать новые функции, отвечающие единой архитектуре, — это подготовка стандартов, планирование за несколько итераций до спринта, составление условий приемки с опорой на архитектурные особенности и распределение ответственности.
.jpg)
.jpg)