Поделиться через

Рекомендации по формализации практик управления разработкой программного обеспечения

  • Статья

Применимо к этой рекомендации Power Platform контрольного списка хорошо спроектированного операционного совершенства:

ОЭ:03 Формализуйте процесс разработки идей и планирования программного обеспечения, опираясь на установленные отраслевые и организационные стандарты. Используйте общий список невыполненных работ с четко расставленными приоритетами и достаточно подробные спецификации. Постоянно совершенствуйте процесс планирования на основе полученных результатов.

В этом руководстве описаны рекомендации по управлению методиками разработки рабочих нагрузок в соответствии с установленными стандартами. Способность вашей команды производить высококачественное программное обеспечение зависит от структурированного, совместного подхода к планированию разработки. Группы по управлению рабочей нагрузкой должны понимать и четко доносить до заинтересованных сторон суть выполняемой работы. Точнее говоря, рабочие группы должны иметь четкое представление о работе, которую необходимо выполнить в цикле разработки, и гарантировать, что все заинтересованные стороны согласны с тем, «зачем» эта работа. Установленные стандарты определяют, как следует выполнять методики разработки, и позволяют группе по рабочим нагрузкам эффективно сотрудничать, снижая риск путаницы в целях и ожиданиях.

Ключевые стратегии проектирования

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

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

Стандарты планирования разработки

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

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

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

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

  • Инструменты: используйте устоявшиеся, проверенные в отрасли инструменты и процессы, такие как Agile, Scrum и доски Kanban.

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

  • Развертывание: планируйте использовать частые небольшие итеративные развертывания вместо крупных и редких развертываний.

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

  • Коммуникация: Определите стандартные протоколы для владельцев продуктов и менеджеров проектов для предстоящих релизов повысить уровень.

  • Истории пользователей: стандартизируйте шаблон для историй пользователей. Хорошо написанные пользовательские истории должны соответствовать концепции INVEST:

    • I – Independent (Независимые): каждая пользовательская история должна быть независимой от других, что позволяет команде реализовывать ее небольшими постепенными шагами.
    • N – Negotiable (с возможностью переговоров): пользовательские истории должны быть предметом переговоров и открыты для обсуждения и изменения.
    • V–Ценность: пользовательские истории должны представлять ценность для клиента.
    • E–Estimable (с возможностью оценки): пользовательские истории должны быть пригодны для оценки и иметь четкое определение готовности.
    • S–Small (небольшие): пользовательские истории должны быть небольшими и сосредоточены на одной функции.
    • T-Testable (с возможностью тестирования): пользовательские истории должны быть пригодны для тестирования и иметь четкие критерии приемки.

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

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

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

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

    • Ежемесячный темп роста внедрения
    • Производительность
    • Время обучения
    • Частота инцидентов

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

Возможности в Power Platform

Хотя нет Power Platform продуктов, которые напрямую способствуют выполнению этой рекомендации, вы можете использовать другие инструменты в Microsoft стеке. Azure Boards — это веб-сервис, который позволяет командам планировать, отслеживать и обсуждать работу на протяжении всего процесса разработки.

GitHub Projects — это настраиваемый инструмент управления проектами для их организации и интеграции с вашими задачами и запросами на включение изменений в GitHub.

Следующие шаги

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