공동 개발 거버넌스

효과적인 공동 개발 거버넌스 프레임워크를 설정하는 것은 제작자가 정의한 프로젝트와 Fusion Teams에서 일관성과 반복성을 보장하는 중요한 부분입니다. 이 문서에서는 거버넌스 순서도를 정의하는 접근 방식을 설명합니다.

엔드투엔드 프로세스 정의

다음 프로세스를 예로 사용하여 조직의 모범 사례에 맞게 사용자 지정할 수 있습니다. 필요한 결과를 얻는 한 모든 단일 단계를 완료할 필요는 없습니다.

백로그에 기능 추가

백로그를 사용하면 전반적인 경험을 주도하는 기능을 추가하여 프로젝트를 계획할 수 있습니다. 백로그는 또한 팀이 제공하려는 전체 로드맵을 제공합니다.

백로그에 새 기능을 추가할 때 목표는 일반적인 범위를 설명하는 것입니다. 그런 다음 각 기능은 비즈니스 가치, 초안 스토리 제목, 범위 및 코드 개발 노력을 주도하는 데이터 모델 변경 사항을 정의합니다.

또한 비즈니스 크리티컬 기능을 추가할 때 테스트를 자동화하기 위해 중요한 시나리오를 식별하는 것이 좋습니다. 기능을 추가한 후 범위 조정 회의를 예약할 수 있습니다.

범위 조정 회의

이 회의의 초점은 제안된 각각의 새로운 기능을 검토한 다음 중복 작업을 피하기 위해 이미 이 기능을 제공하는 기존 앱, 시나리오 또는 데이터 모델을 확인하는 것으로 제한되어야 합니다. 이 회의는 또한 다른 앱에 미치는 영향에 대해 논의할 기회를 제공합니다. 마지막으로 이 기능에 경험 검토가 필요한지 확인해야 합니다.

백로그에 스토리 및 스토리보드 추가

범위 조정 회의 후에는 사용자 스토리 초안 제목을 기능 아래에 추가할 수 있습니다. 이 시점에서 세부 사항은 필요하지 않으며 사용자 스토리의 상태는 "신규"입니다. 백로그 또는 게시판 보기에서 스토리를 볼 수 있습니다.

다음 그림은 백로그에 추가된 샘플 사용자 스토리를 보여줍니다.

이때 작업 흐름과 애플리케이션별로 작업을 정리하여 품질을 유지하는 것이 중요합니다. 이 접근 방식은 관련 작업 항목을 함께 유지하는 데 도움이 되며 각 작업 흐름의 전문가가 각 앱 내의 기능 및 데이터 사용에 대한 깊은 이해를 개발하고 유지할 수 있도록 합니다.

경험 리뷰

경험 리뷰는 최종 사용자 경험에 중점을 두고 팀이 조직의 모범 사례를 따르도록 해야 합니다. 이러한 일관성을 통해 모든 앱은 최종 사용자와 지원 팀에게 신뢰할 수 있고 반복 가능한 경험을 제공할 수 있습니다.

스토리 세부 정보 추가

일반적인 사용자 스토리를 추가하면 다음 정보가 포함될 수 있습니다.

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을 생성해야 합니다. Azure Boards에서 팀을 위한 스크럼 구현 사례에 명시된 스프린트 및 개발 지침에 따라 솔루션 버전 관리가 정확한지 확인해야 합니다. PR의 테스트 결과는 구축 중인 기능을 설명하는 스크린샷이나 비디오가 될 수 있습니다.

PR 거버넌스 프로세스를 자동화하면 솔루션 버전과 같은 기본 검사를 수동으로 검토하지 않고도 코드 품질을 보장할 수 있습니다.

참고

PR 검사기 도구를 사용하여 끌어오기 요청 검사 프로세스를 자동화하십시오.

템플릿 및 표준화

템플릿 및 표준화는 팀 내에서 일관성을 촉진하여 효율성을 제공합니다. 온보딩 작업, 스토리 검토 프레젠테이션 또는 사용자 스토리, 기능, 버그 또는 작업을 정의할 때 팀에 지침을 제공하고 시간을 절약하는 데 도움이 되는 작업 항목 템플릿 등 팀 운영의 모든 측면은 표준화 및 단순화의 이점을 얻습니다.

효과적인 지원 모델 구현

지원 매트릭스 생성에 대한 이전 섹션에서 강조한 것처럼 효과적인 지원 모델은 배포 후 애플리케이션의 장기적인 성공에 필수적입니다. 버그와 가동 중단은 불가피하므로 팀이 이러한 발생을 처리하기 위한 구조화된 접근 방식을 갖는 것이 중요하며 지원 매트릭스가 필요한 프레임워크를 제공합니다.

서비스 수준 약정 생성

모든 지원 모델의 핵심 요소는 SLA(서비스 수준 약정)의 정의입니다. SLA는 다음 항목을 다루는 섹션을 포함하는 팀이 작성하는 공식 문서여야 합니다.

• 정전 – 허용 가능한 서비스 중단 수준, 알려야 할 대상, 취해야 할 조치, 서비스 재개 확인 및 반복 방지 조치입니다. 팀에서 사용하는 모든 자동화된 테스트 절차는 예상되는 중단 허용 범위 및 해당 SLA와 일치해야 합니다.
• 버그 – 통지할 수 있는 사람, 심각도 수준 할당, 분류, 탐지 시 조치, 해결 및 승인을 담당하는 사람입니다.
• 에스컬레이션 – 에스컬레이션 수준, 수준별 직원 할당, 각 수준의 책임, 각 수준의 배포 목록 등 입니다.

SLA는 팀의 문서 포털에 저장하고 필요에 따라 업데이트해야 합니다.

애플리케이션 지원 제공

SLA에 지정된 애플리케이션 지원을 제공하는 가장 좋은 방법은 솔루션을 만든 팀이 솔루션을 지원하는 역할도 하는 것입니다. 이 시스템의 장점은 다음과 같습니다.

1. 앱을 만든 사람들은 앱을 지원해야 한다는 것을 알고 있기 때문에 더 나은 품질의 개발을 장려합니다.
2. 제작자는 앱을 더 잘 알고 있기 때문에 타사 팀보다 더 빨리 버그를 찾고 수정할 수 있습니다.
3. 잠재적으로 업무상 중요한 소프트웨어의 수정을 다른 그룹에 위임하는 것은 해당 그룹의 사기를 저하시키고 시간이 많이 소요될 수 있습니다. 애플리케이션 생성, 개발 및 배포의 다른 단계와 마찬가지로 Fusion Teams은 필요할 때 IT와 협력하여 지원을 받아야 합니다.

애플리케이션 만족도 및 사용성 모니터링

지원 노력의 마지막 부분은 배포된 앱의 만족도와 사용성을 모니터링하고 평가하는 것입니다. 메트릭은 설문조사 및 설문지와 같은 보다 전통적인 방법과 함께 여기에서 유용합니다. 앱 사용 모니터링에 대한 자세한 내용은 Power Apps용 관리 분석을 참조하십시오.

궁극적으로 고객이 게시된 앱을 사용하지 않는다면 해당 앱은 목적을 달성하지 못하는 것입니다. 정기적인 검토 회의는 이러한 만족도 및 사용성 지표를 확인하여 백로그에 스토리를 변경하거나 추가하여 업데이트된 버전의 앱을 생성하고 배포할 수 있는 긍정적인 피드백 루프를 생성할 수 있습니다.

요약

Power Apps와 같은 노코드 및 로우코드 도구의 개발은 비즈니스 기술자 또는 제작자가 앱을 생성, 개발 및 배포할 수 있는 옵션을 확장했습니다. 이 개발은 제품 담당자, 도메인 전문가, 전문 개발자 및 관리자로 구성된 Fusion Teams 환경에서 가장 잘 작동하며 이 팀은 필요에 따라 다른 리소스를 가져옵니다.

Fusion Teams 내에서 민첩성 및 스크럼 개발 접근 방식을 통합하면 비즈니스에 상당한 차이를 만드는 기능 세트로 더 빠른 앱 개발과 성공적인 배포 가능성이 높아집니다. 이러한 모범 사례, 지침 및 권장 사항을 적용함으로써 Fusion Teams은 Power Apps를 사용하여 조직의 디지털 혁신 과제를 해결할 수 있습니다.

다음 단계: 커뮤니티 솔루션 및 도구 사용해 보기