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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Ценно. Работа должна явно приносить пользу пользователю.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Автоматизация сборки и интегрированное тестирование: Стандартизируйте автоматизированные сборки, которые выполняются при каждой отправке кода, и применяйте автоматизированное модульное и интеграционное тестирование с установленными порогами покрытия, где это возможно.

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

• Управление зависимостями: Непрерывно сканируйте зависимости для устаревших или уязвимых компонентов и интегрируйте сканирование безопасности, включая статическое тестирование безопасности приложений (SAST), динамическое тестирование безопасности приложений (DAST) и обнаружение секретов.

• Управление артефактами: Стандартизация версионирования пакетов и артефактов, а также политики хранения и хранения данных для обеспечения трассируемости и воспроизводимости.

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

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

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

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

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

Дополнительные ссылки

• Рекомендации по управлению проектами Agile
• Azure Boards

Ссылки на ресурсы сообщества

• Проекты GitHub

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

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