Роль архитектора в гибкой разработке


Вы архитектор?

Вступление

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

Вам также может понравиться: Краткое введение в архитектуру программного обеспечения

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

Проблемы в гибкой разработке

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

  1. Видимость, бесконечная видимость на долгосрочной клиентской дорожной карте (технической и предметной).
  2. Сопротивление, для любых предложений и изменений в существующих процессах, приемлемость очень низкая или почти нулевая со стороны Заказчика.
  3. Многочисленные команды, работающие над различными функциями и разными частями базы кода, приводят к размыванию структуры основы архитектуры и перекрытию кода между модулями.
  4. Отсутствие внимания к атрибутам качества обслуживания (QoS).
  5. Изменчивость требований, как правило, требования определяются из нескольких источников, а не только Business Analyst. Поэтому всякий раз, когда кто-то выражает «желание», которое необходимо добавить в отставание.
  6. Time Crunch, это всегда был компромисс между технологией, NFR и временем. Обычно мы не контролируем время. Чтобы сделать клиента счастливым, нам нужно выполнить все бизнес-требования за это время. Таким образом, единственное место, где мы можем пойти на компромисс, это технология и NFR.
  7. Подход, основанный на новейших технологиях, заключается в том, чтобы сначала расставить приоритеты для всех «видимых» требований, а затем перейти к другим. При этом мы упускаем возможности для внедрения новейших технологий.
  8. Техническая задолженность, технические соображения приобретают более низкий приоритет по сравнению с бизнес-функциями. Это накапливает технические долги, которые требуют доработки.

Как архитектор, являющийся частью многих программ, мы столкнулись со следующими несколькими сценариями:

Сценарий 1

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

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

Принятое решение для данного спринта, задачи,

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

Сценарий 2

Низкий приоритет технических соображений.

Архитектура, созданная во время начальных итераций до начала реализации итерации. Любые выявленные изменения будут представлены в планировании PI, и попытаться получить истории пользователей для этого. Как правило, нам нужно представить все проблемы в событии планирования PI, нужно выиграть время для внедрения архитектур или передовых практик. Любое событие, которое не учитывается при планировании PI / Sprint, является большой проблемой. Любые изменения дизайна, выявленные в середине итерации, переносятся на следующую итерацию.

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

Сценарий 3

Управление навыками.

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

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

Продемонстрируйте результаты спринта для бизнеса, чтобы узнать отзывы клиентов и учесть необходимые изменения. Во-вторых, команде необходим правильный состав опытных и более свежих инженеров.

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

Сценарий 4

Управление требованиями.

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

Объем спринта определяется совместно владельцем продукта и командой. Архитектор; вмешиваться только в случае проблем во время определения объема или изменений, внесенных в последний момент.

Много раз тестирование проводилось на фиктивных данных, но мы используем его для решения многих проблем и задач безопасности на этапе SIT / UAT. Поскольку бизнес использует, чтобы понять, что то, что они думали, решило бы их проблему полностью, решает это только частично.

Роль архитектора в гибкой разработке

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

Скриншот сотового телефона

Описание автоматически сгенерировано

На этапе создания портфеля резервных копий Архитектор будет сотрудничать с Управлением проектами, Epic Owner и руководителями предприятий для выполнения следующих действий:

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

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

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

Во время планирования приращения программы (PI) архитектор поможет команде поделиться техническим и архитектурным видением и выполнит следующие действия:

  1. Оцените пользователя и технические истории.
  2. Помогите с расстановкой приоритетов в истории.
  3. Помогите с планированием спринта.

Как проворный архитектор, продвигайте гибкий подход на предприятии. Действует как слуга лидер, фасилитатор. Это помогает команде в гладком исполнении и устраняет любые препятствия. Гибкий архитектор – лучший владелец продукта для продукта архитектуры предприятия.

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

  • Преднамеренная архитектура. Архитектура – это сотрудничество.
  • Участвуйте во всех гибких церемониях, которые включают разработку, планирование, ретроспективу и постоянные встречи.
  • Создайте простейшую архитектуру, которая может работать (установленные принципы проектирования).
  • Определите второстепенные / основные дизайнерские решения на основе требований.
  • Не под архитектором и не переусердствуйте.
  • Изолируйте быстро меняющиеся детали / компоненты от более стабильных.
  • Кодируйте это или моделируйте это (шипы, прототип, область и модели варианта использования).
  • Построй, протестируй (дизайн для тестируемости).
  • Реализовать Architectural Flow (архитектурная эпопея и портфолио Канбан).
  • Руководство командой на техническом фронте и руководство командой к достижению качественного результата в срок.
  • Нужно оставаться вложенным в команду повсюду. Начните участие в проекте прямо с точки зрения функциональных спецификаций. Совместно рассмотрите функциональные спецификации с бизнесом, чтобы понять ожидания и убедиться, что написанное соответствует ожидаемому.
  • Постоянно проверяйте с командой, чтобы удостовериться, что они не отклоняются от заявленного проекта. Много раз, как архитектору приходилось защищать время от нежелательной бюрократии.

Резюме

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

Архитекторы предприятия должны организовать себя и взять на себя ответственность за реализацию проекта архитектуры.

Ссылки

https://www.scaledagileframework.com

Дальнейшее чтение

Как стать архитектором программного обеспечения Java

Архитектура программного обеспечения: 5 шаблонов, которые нужно знать

Вы архитектор?