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


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

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

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

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

Основные стратегии проектирования

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

Создание стандартов совместной работы и коммуникации

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

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

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

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

    • Ежемесячный темп роста внедрения.

    • Производительность.

    • Время обучения.

    • Частота инцидентов.

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

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

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

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

Внедрение стандарта для отслеживания сценариев конечных пользователей

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

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

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

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

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

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

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

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

Стандартные методики развертывания

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

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

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

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

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

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

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

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