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

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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упрощение поддержки Azure

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

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

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

См. полный набор рекомендаций.

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