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

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

Определение сквозного процесса

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

Добавление функций в журнал невыполненных работ

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

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

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

Совещание по согласованию объема работ

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

Добавление историй и раскадровки в журнал невыполненных работ

После собрания по согласованию объема работ любые проекты заголовков пользовательских историй могут быть добавлены в функцию. На этом этапе подробности не требуются, а статус пользовательской истории — «Новый». Вы можете просматривать истории либо в журнале невыполненных работ, либо в представлении доски.

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

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

Проверка интерфейса

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

Добавление сведений истории

Добавление типичной пользовательской истории может включать следующую информацию:

1. Заголовок : как <persona>, я могу <do something>, чтобы <impact/priority/value>
2. Описание: описание включает (но не ограничивается этим) определенные ключевые детали, такие как:
   • Краткое описание сценария, резюмирующего желаемый результат
   • Повествование — описывает действия, которые пользователи предпримут для навигации и выполнения сценария
   • Альтернативное повествование — описывает другие способы, которыми пользователи могут достичь того же результата
   • Примечания к разработке — записывают сущность, поля, представления, макеты экранов и бизнес-правила, связанные с пользовательской историей
   • Затронутые роли безопасности — список всех затронутых ролей безопасности или ролей, имеющих отношение к пользовательской истории

После добавления всех этих сведений вы измените состояние пользовательской истории на «Готово к рассмотрению». В большинстве случаев функциональная рабочая группа и бизнес-рабочая группа (если применимо) рассматривают пользовательские истории.

Обзор истории

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

Добавление задач и тестовых случаев

После просмотра историй члены рабочей группы создают задачи в Azure DevOps. Общий процесс добавления задач и тестовых случаев выглядит следующим образом:

1. Откройте журнал невыполненных работ спринта. Или создайте новый спринт.
2. Добавьте существующие рабочие элементы в спринт. Если вы уже добавили рабочие элементы, которые не отображаются в спринте, вам следует проверить их область и пути итерации. Не забудьте назначить любые задачи без родительских элементов соответствующим рабочим элементам.
3. Добавьте задачи в элементы невыполненной работы. Если у вас нет элементов невыполненной работы, назначенных вашему спринту, сделайте это сейчас. Также установите даты начала и окончания спринта.
4. Заполните форму задач. Как правило, задачи должны выполняться не более суток. Задачи, превышающие этот временной масштаб, должны быть разбиты на части.
5. Отслеживайте или интегрируйте любые задачи без родительских элементов. Вы можете отслеживать задачи без родительских элементов как и другие задачи, или перетаскивать их в существующий элемент невыполненной работы, чтобы задать им родительские элементы.

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

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

Подготовка решений

Важным аспектом успешной совместной разработки является структурированный процесс управления выпусками. Решения являются механизмом реализации управления жизненным циклом приложений (ALM); вы используете их для распределения компонентов по средам через экспорт и импорт. Компонент представляет собой артефакт, используемый в вашем приложении, и то, что вы потенциально можете настроить. Все, что может быть включено в решение, является компонентом, например таблицы, столбцы, приложения на основе холста и модели, потоки Power Automate, чат-боты, диаграммы и подключаемые модули.

Важно!

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

Развертывания

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

Среды Power Platform

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

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

Управление исходным кодом

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

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

Расширенный тема: проверка запросов на вытягивание (PR)

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

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

Примечание

Используйте инструмент проверки PR для автоматизации процесса проверки запросов на извлечение.

Шаблоны и стандартизация

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

Внедрение эффективной модели поддержки

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

Создание соглашения об уровнях обслуживания

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

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

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

Обеспечение поддержки приложения

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

1. Она способствует более качественной разработке, потому что те, кто создал приложение, знают, что им придется его поддерживать.
2. Создатели смогут находить и исправлять ошибки быстрее, чем сторонняя рабочая группа, просто потому, что они лучше знают приложение.
3. Передача исправления потенциально важного программного обеспечения другой группе может деморализовать и отнимать много времени у этой группы. Как и на других этапах создания, разработки и развертывания приложений, смешанная группа должна при необходимости сотрудничать с ИТ-отделом для получения помощи.

Мониторинг удовлетворенности приложением и удобства его использования

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

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

Сводка

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

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

Следующий шаг: попробуйте решения и инструменты, разработанные сообществом