Стратегии архитектуры для формализации методик разработки

Применяется к этой контрольной рекомендации по операционному превосходству в Azure Well-Architected Framework:

OE:03 Формализация процессов в течение всего жизненного цикла разработки программного обеспечения, от идеи до доставки и сделать их прозрачными для команды и заинтересованных лиц.

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

В этом руководстве содержатся рекомендации по запуску разработки программного обеспечения в структурированном, прогнозируемом и совместном режиме.

Создание стандартов для управления изменениями

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

При инициировании работы с запрошенным изменением следуйте следующим аспектам:

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

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

  • Общаться. Стандартизируйте, как команда передаёт информацию о релизах, как внутри компании, так и снаружи. Определите, какие сведения следует предоставлять внешним аудиториям (например, клиентам), соответствующий уровень детализации, необходимую документацию по подключению или поддержке, а также временную шкалу связи. Например, уведомите заинтересованных лиц за две недели до выпуска и отправьте напоминание за 24 часа до развертывания.

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

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

  • Отчеты. Стандартизируйте отчеты о том, как изменяется продукт. Сохраняйте отчеты, ориентированные на рост продуктов, а не на производительность отдельных разработчиков. Например, это хорошо для заинтересованных лиц, чтобы отслеживать:

    • Рост внедрения
    • Улучшения производительности
    • Время адаптации
    • Частота инцидентов

Выбор проверенных в отрасли инструментов

Вместо того чтобы придумывать собственный процесс, используйте проверенные, такие как Agile, Scrum и Kanban-доски.

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

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

Стандартизировать процесс записи работы по разработке

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

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

Замечание

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

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

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

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

Стандартизация методик программирования

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

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

  • Соглашения о кодировании. Определите и задокументируйте стандарты программирования, охватывающие соглашения об именовании, структуру кода, форматирование. Рекомендуется применять стандарты в блоках кода, обрабатывающих исключения и выполняющие инструментирование. Четкие соглашения упрощают чтение, понимание и обслуживание кода, а также помогают командам согласованно работать между функциями и компонентами. Убедитесь, что эти рекомендации доступны всем разработчикам и регулярно обновляются по мере развития базы кода. Например, можно использовать EditorConfig в среде Visual Studio для применения стилей написания кода.

  • Репозиторий кода. Установить и применять стандартные стратегии ветвления, такие как Gitflow, GitHub Flow или разработка на основе основного ствола, во всех репозиториях, чтобы обеспечить согласованную интеграцию кода и практики выпуска.

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

  • Шаблоны для распространенных артефактов. Описания PR, сообщения о коммитах и модульные тесты — это классические примеры, которые можно шаблонизировать. Убедитесь, что документация содержит цели, контекст, шаги тестирования.

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

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

Такие инструменты, как SonarQube или Copilot Labs, могут автоматически определять отклонения от стандартов кодирования, отсутствующие тестовые покрытия и распространенные антишаблоны. Автоматизация этих повторяющихся задач проверки на ИИ позволяет командам сосредоточиться на более ценной работе. Однако проверка человека остается важной, так как методики разработки критически важны для правильной реализации бизнес-логики и общего качества рабочей нагрузки.

Стандартизация методик интеграции

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

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

  • Автоматизация сборки и интегрированное тестирование: Стандартизируйте автоматизированные сборки, которые выполняются при каждой отправке кода, и применяйте автоматизированное модульное и интеграционное тестирование с установленными порогами покрытия, где это возможно.
  • Анализ качества кода: Примените статический анализ кода и шлюзы качества с помощью утвержденных средств, чтобы обеспечить соответствие кода определенным стандартам качества перед повышением уровня.
  • Управление зависимостями: Непрерывно сканируйте зависимости для устаревших или уязвимых компонентов и интегрируйте сканирование безопасности, в том числе SAST, DAST и обнаружение секретов.
  • Управление артефактами: Стандартизация версионирования пакетов и артефактов, а также политики хранения и хранения данных для обеспечения трассируемости и воспроизводимости.
  • Мониторинг и отчеты: Соберите и отслеживайте метрики сборки и конвейера для отслеживания качества, производительности и соответствия требованиям.

Возможность искусственного интеллекта. Рассмотрим рабочие процессы на основе ИИ для автоматизации повторяющихся задач интеграции, таких как создание конфигураций конвейера CI/CD, создание шаблонов тестирования и обнаружение проблем сборки или тестирования, таких как отсутствующие тесты или проблемы зависимостей. Хотя ИИ ускоряет настройку конвейера, убедитесь, что анализ человека сохраняется для проверки критически важных решений.

Упрощение функций Azure

Azure Boards — это веб-служба, которая позволяет командам планировать, отслеживать и обсуждать работу по всему процессу разработки. Он хорошо подходит для практик разработки на основе гибкой разработки.

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

Контрольный список операционного превосходства

Ознакомьтесь с полным набором рекомендаций.

Контрольный список операционного совершенства

  • Last updated on