소프트웨어 개발 수명 주기 데이터 템플릿
소프트웨어 개발 수명 주기 데이터 템플릿
- 수집 권장 속성
- SDLC에서 추적할 주요 활동
- Azure DevOps 데이터 추출 안내
소프트웨어 개발 수명 주기 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
개발 항목
DevelopmentItem
|
기능, 버그 또는 사용자 스토리와 같은 개별 작업 단위를 식별하는 고유 ID입니다. 프로세스의 케이스 식별자로 사용됩니다. | ||
|
설명
Development Item은 Azure DevOps에서 추적하는 개별 작업 단위를 나타냅니다. 고유 ID로 식별되는 각 항목은 생성과 계획부터 개발, 테스트, 배포까지 모든 프로세스 활동의 기준이 됩니다. process mining 분석에서는 이 속성을 사용해 관련 이벤트를 하나의 케이스 여정으로 연결합니다. 이를 통해 각 작업 항목의 종단 간 수명 주기를 재구성하고 항목별 주기 시간, 프로세스 이탈, 재작업 경로를 분석할 수 있습니다.
중요한 이유
이 식별자는 모든 프로세스 단계를 하나의 케이스로 연결하므로 소프트웨어 개발 수명 주기를 처음부터 끝까지 분석할 수 있습니다.
확보 방법
Azure DevOps Boards의 작업 항목에 있는 'ID' 필드에 해당합니다. Azure DevOps REST API의 Work Item Tracking을 통해 확인할 수 있습니다.
예시
10234102351023610237
|
|||
|
이벤트 시각
EventTime
|
개발 항목에서 특정 활동이나 이벤트가 발생한 시점을 나타내는 정확한 타임스탬프입니다. | ||
|
설명
이벤트 시각은 개발 수명 주기의 각 활동이 발생한 날짜와 시간을 기록합니다. 이 타임스탬프를 기준으로 이벤트를 시간순으로 정렬하고 이벤트 간 소요 시간을 계산합니다. 분석에서는 주기 시간, 처리 시간, 대기 시간을 포함한 모든 시간 기반 지표를 계산하는 데 이 속성이 필요합니다. 시간순 이벤트 로그를 구성할 수 있어 process mining 분석의 필수 입력 데이터로 활용됩니다. 지연 원인을 진단하고 SLA 대비 성과를 측정하며 시간에 따른 추세를 추적하는 데도 사용합니다.
중요한 이유
이 타임스탬프를 기준으로 이벤트 순서를 정렬합니다. 시간 기반 KPI를 계산하고 프로세스 흐름과 병목을 파악하는 데 필요합니다.
확보 방법
작업 항목 이력에서 각 업데이트에 기록된 'Changed Date'입니다. 빌드나 배포 같은 외부 이벤트의 경우 해당 이벤트가 완료된 시각을 사용합니다.
예시
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
|
|||
|
활동명
ActivityName
|
개발 수명 주기에서 특정 작업 항목에 대해 특정 시점에 발생한 이벤트 또는 작업의 이름입니다. | ||
|
설명
활동명은 'Development Started', 'Pull Request Created', 'Deployed to Production'과 같은 프로세스의 특정 단계나 주요 시점을 나타냅니다. 작업 항목 상태 변경, 빌드나 pull request 같은 연결 이벤트 또는 사용자 지정 이벤트를 바탕으로 생성합니다. 이 속성은 워크플로를 시각적으로 나타내는 프로세스 맵을 구성하는 데 필요합니다. 분석가는 이를 통해 이벤트 순서와 일반적인 진행 경로를 파악하고, 특정 활동 사이의 병목을 찾으며, 각 단계의 발생 빈도를 분석할 수 있습니다.
중요한 이유
프로세스의 단계를 정의해 프로세스 맵의 뼈대를 구성하며, 워크플로와 병목, 이탈을 분석할 수 있게 합니다.
확보 방법
일반적으로 작업 항목의 'State' 필드 변경이나 빌드, 커밋, pull request와 같은 연결 이벤트에서 도출합니다. Work Item History에 이러한 이벤트의 원시 데이터가 기록됩니다.
예시
개발 시작Pull Request 완료QA 테스트 실패운영 환경에 배포작업 항목 종료
|
|||
|
원천 시스템
SourceSystem
|
프로세스 데이터를 추출한 시스템입니다. 여기서는 Azure DevOps를 의미합니다. | ||
|
설명
이 속성은 데이터가 생성된 시스템을 식별합니다. 여러 시스템의 데이터를 결합해 프로세스 전반을 분석하는 환경에서 특히 유용합니다. 이 모델에서는 값이 항상 Azure DevOps입니다. 단일 시스템 분석에서는 값이 고정되어 보일 수 있지만, 데이터 거버넌스와 문제 해결, ServiceNow나 SAP 같은 다른 시스템과의 향후 연동을 위해 데이터 출처를 확인하는 데 필요합니다.
중요한 이유
데이터 출처를 확인할 수 있어 데이터 거버넌스, 검증, 여러 시스템을 아우르는 프로세스 분석에 필요한 맥락을 제공합니다.
확보 방법
데이터 추출 및 변환 과정에서 데이터셋을 식별할 수 있도록 추가하는 고정값입니다.
예시
Azure DevOps
|
|||
|
최종 데이터 업데이트 시각
LastDataUpdate
|
원천 시스템에서 프로세스 데이터를 마지막으로 새로 고친 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성은 Azure DevOps에서 데이터셋을 마지막으로 추출하고 업데이트한 시점을 기록합니다. 데이터의 최신 여부와 분석 대상 기간을 확인할 수 있습니다. 프로세스를 분석할 때 데이터가 얼마나 최근 정보인지 알아야 적절한 판단을 내릴 수 있습니다. 이 타임스탬프를 통해 실시간 정보인지 과거 시점의 데이터인지 파악할 수 있으며, 이는 분석 결과의 활용도에 영향을 줍니다.
중요한 이유
데이터의 최신 여부를 알려 분석과 의사결정의 기준이 되는 기간을 명확히 파악할 수 있습니다.
확보 방법
데이터 추출, 변환, 적재(ETL) 과정에서 생성해 저장하는 메타데이터 타임스탬프입니다.
예시
2024-05-20T08:00:00Z
|
|||
|
담당자
AssignedTo
|
개발 항목을 현재 담당하는 사용자 또는 팀원입니다. | ||
|
설명
이 속성은 프로세스의 각 단계에서 작업 항목을 담당하는 사람을 식별합니다. 항목의 수명 주기 동안 개발자에서 테스터로, 다시 릴리스 관리자로 담당자가 여러 번 바뀔 수 있습니다. 'Assigned To'를 기준으로 분석하면 Developer and Tester Workload Overview 대시보드에 필요한 정보를 얻을 수 있습니다. 리소스 배분을 파악하고 업무가 과도하게 집중된 팀원을 찾으며 개인이나 팀 간 성과 차이를 분석하는 데 도움이 됩니다.
중요한 이유
리소스별 분석을 통해 업무량 분포와 리소스별 병목을 파악하고 팀의 업무 처리 역량을 관리할 수 있습니다.
확보 방법
Azure DevOps 작업 항목의 'Assigned To' 필드에 해당합니다. 각 이벤트의 값은 작업 항목 이력에서 가져옵니다.
예시
jane.doe@example.comjohn.smith@example.com미할당
|
|||
|
상태
State
|
워크플로에서 개발 항목의 현재 상태를 나타냅니다. 예: '신규', '진행 중', '해결됨', '닫힘'. | ||
|
설명
State 속성은 프로젝트의 프로세스 템플릿에 정의된 작업 항목의 공식 상태를 나타냅니다. 상태가 변경될 때마다 이벤트 로그에 활동을 생성하는 데 필요한 주요 정보가 기록됩니다. 'Activity' 속성은 상태 변경을 더 구체적으로 설명하는 경우가 많지만, 원본 'State' 속성도 필터링과 분석에 유용합니다. 이를 통해 항목이 특정 상태에 머무는 시간을 파악할 수 있으며, 단계별 소요 시간 대시보드를 만들고 인계 과정을 분석하는 데도 활용됩니다.
중요한 이유
항목의 수명 주기상 상태를 나타내며, 프로세스 흐름을 파악하고 각 단계에 걸린 시간을 계산하는 데 필요한 정보입니다.
확보 방법
Azure DevOps의 작업 항목에 있는 'State' 필드에 해당합니다.
예시
신규진행 중QA 진행 중해결됨닫힘
|
|||
|
우선순위
Priority
|
다른 항목과 비교해 개발 항목의 중요도를 숫자나 설명으로 나타낸 순위입니다. | ||
|
설명
우선순위는 작업 항목의 일정상 중요도를 나타냅니다. 우선순위가 높을수록 낮은 항목보다 먼저 처리해야 합니다. 일반적으로 1, 2, 3, 4와 같은 숫자를 사용하며, 1이 가장 높은 순위입니다. 이 속성은 우선순위별 처리량 및 주기 시간 대시보드에 필요합니다. 데이터를 분석하면 우선순위 체계가 효과적인지, 즉 우선순위가 높은 항목이 낮은 항목보다 실제로 더 빠르게 프로세스를 통과하는지 확인할 수 있습니다.
중요한 이유
우선순위가 높은 항목을 프로세스에서 더 빠르게 처리하는지 분석할 수 있어, 우선순위 전략의 효과를 평가하는 데 도움이 됩니다.
확보 방법
Azure DevOps의 작업 항목에 있는 'Priority' 필드에 해당합니다.
예시
1234
|
|||
|
작업 항목 유형
WorkItemType
|
Bug, Feature, User Story 또는 Task와 같은 개발 항목의 분류입니다. | ||
|
설명
작업 항목 유형은 수행하는 업무의 성격을 분류합니다. 유형에 따라 프로세스 경로와 성과 기대치 또는 SLA가 다를 수 있습니다. 예를 들어 'Bug'는 'Feature'보다 빠른 경로로 처리될 수 있습니다. 이 속성은 유형별 비교 분석에 필요합니다. 작업 유형별로 프로세스 맵이나 KPI를 필터링해 버그와 기능 개발 중 어느 쪽의 프로세스가 더 효율적인지 확인하거나, 업무 범주별 과거 주기 시간 추세를 추적할 수 있습니다.
중요한 이유
프로세스 분석을 업무 범주별로 나누어 버그와 기능 등 서로 다른 작업의 워크플로와 성과를 비교할 수 있습니다.
확보 방법
Azure DevOps 작업 항목의 'Work Item Type' 필드에 해당합니다.
예시
버그기능사용자 스토리작업
|
|||
|
재작업 여부
IsRework
|
개발 항목이 수명 주기의 이전 단계로 되돌아갔는지를 나타내는 불리언 값입니다. | ||
|
설명
작업 항목에서 재작업 루프가 확인되면 이 값은 true로 설정됩니다. 예를 들어 'QA 테스트 완료'에서 '개발 시작'으로 되돌아가는 경우입니다. 케이스별 활동 순서를 분석해 정상적인 선형 흐름에서 벗어나는지 확인하여 계산합니다. 이 속성은 재작업 및 재테스트 빈도 대시보드와 재작업 루프 빈도 KPI에 필요합니다. 재작업을 쉽게 필터링하고 수치화해 비효율을 초래하는 품질 문제, 소통 단절 또는 불충분한 테스트를 찾을 수 있습니다.
중요한 이유
재작업을 직접 식별하고 수치화해 주기 시간을 늘리는 품질 문제와 프로세스 비효율을 파악할 수 있습니다.
확보 방법
케이스별 이벤트 로그의 활동 순서를 분석해 계산하는 속성입니다.
예시
truefalse
|
|||
|
종료 시각
EndTime
|
활동이 완료된 시점을 나타내는 타임스탬프입니다. 활동의 처리 시간을 계산하는 데 사용합니다. | ||
|
설명
종료 시각은 활동이 끝난 시점을 나타냅니다. 많은 이벤트 로그에서는 다음 활동의 시작 시각을 이전 활동의 종료 시각으로 사용합니다. 다만 종료 시각을 별도로 기록하면 활동 처리 시간과 활동 간 유휴 시간을 더 정확하게 계산할 수 있습니다. 이 속성은 ProcessingTime KPI 계산과 상세한 병목 분석에 필요합니다. 작업을 실제로 수행한 시간과 다음 단계가 시작되기를 기다린 시간을 구분할 수 있어 Stage Handoff Analysis 대시보드에 활용됩니다.
중요한 이유
활동 처리 시간과 유휴 시간을 정확하게 계산할 수 있어 병목 분석과 효율성 개선에 필요한 정보를 제공합니다.
확보 방법
대개 다른 데이터에서 도출합니다. 같은 케이스의 다음 이벤트 시작 시각을 사용할 수 있으며, 원천 시스템이 작업의 시작과 종료 시각을 모두 기록하는 경우에는 해당 값을 직접 사용할 수 있습니다.
예시
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
|
|||
|
팀 이름
TeamName
|
작업 항목을 담당하는 개발팀의 이름입니다. | ||
|
설명
팀 이름은 작업 항목이 배정된 팀을 나타냅니다. Azure DevOps에서는 대규모 프로젝트의 일부 팀을 포함해 팀 단위로 작업을 구성하는 경우가 많습니다. 이 속성을 사용하면 팀별로 프로세스를 나누어 분석할 수 있습니다. 팀 간 프로세스와 성과를 비교하고, 성과가 높은 팀의 모범 사례를 찾으며, 지원이나 프로세스 개선이 필요한 팀을 파악하는 데 유용합니다.
중요한 이유
팀별 성과를 비교해 차이를 파악하고 조직 전체에 모범 사례를 공유할 수 있습니다.
확보 방법
Azure DevOps에서 팀을 특정 영역 경로에 연결하는 경우가 많으므로, 일반적으로 작업 항목의 'Area Path'에서 가져옵니다.
예시
피닉스 팀오메가 스쿼드플랫폼 코어프런트엔드 팀
|
|||
|
단계 간 인계 대기 시간
StageHandoffTime
|
주요 단계 하나가 끝난 뒤 다음 단계가 시작될 때까지 작업이 대기한 시간입니다. | ||
|
설명
단계 간 인계 대기 시간은 순차적으로 진행되는 프로세스 단계 사이의 대기 시간을 측정합니다. 예를 들어 '개발 완료'부터 'QA 테스트 시작'까지 걸린 시간입니다. 주요 전환을 식별한 뒤 첫 번째 활동이 끝난 시점과 두 번째 활동이 시작된 시점 사이의 간격을 계산합니다. 이 지표는 단계별 소요 시간 및 인계 분석 대시보드에서 중점적으로 다룹니다. 인계 대기 시간을 분리해 측정하면 리소스 부족, 소통 지연 또는 비효율적인 프로세스로 인해 작업이 멈춰 있는 숨은 병목을 찾을 수 있습니다.
중요한 이유
프로세스 단계 사이의 대기 시간을 수치화해 실제 작업 시간이 아닌 숨은 병목과 지연을 드러냅니다.
확보 방법
계산 속성입니다. 인계를 나타내는 연속 활동 쌍을 식별한 다음 두 활동 사이의 시간 차이를 계산해야 합니다.
예시
2시간 15분1일 4시간30분
|
|||
|
반복 경로
IterationPath
|
작업 항목이 배정된 개발 스프린트 또는 기간입니다. | ||
|
설명
반복 경로 또는 스프린트는 정해진 기간 동안 진행되는 개발 주기를 나타냅니다. 작업 항목은 해당 기간 안에 완료하도록 반복에 배정됩니다. 반복 경로별로 분석하면 스프린트마다 프로세스 성과를 파악할 수 있습니다. 스프린트가 거듭될수록 주기 시간이 개선되는지 추적하고, 다음 스프린트로 이월되는 작업을 분석하며, 스프린트 계획의 예측 가능성을 평가할 수 있습니다.
중요한 이유
스프린트별로 성과를 분석해 시간에 따른 변화를 평가하고 애자일 방식을 개선할 수 있습니다.
확보 방법
Azure DevOps의 작업 항목에 있는 'Iteration Path' 필드에 해당합니다.
예시
전자상거래 플랫폼\스프린트 12전자상거래 플랫폼\스프린트 13모바일 앱 재출시\2단계\스프린트 4
|
|||
|
승인 대기 시간
ApprovalWaitingTime
|
승인 요청 후 개발 항목이 승인을 기다리는 시간입니다. | ||
|
설명
이 지표는 작업 항목이 승인을 기다리는 특정 기간의 길이를 측정합니다. 예를 들어 'UAT 시작'부터 'UAT 승인'까지 걸린 시간입니다. 해당 케이스에서 두 활동 사이의 시간을 계산합니다. 계산된 이 속성은 승인 대기 시간 분석 대시보드와 관련 KPI에 직접 활용됩니다. 이러한 지연을 구분해 살펴보면 팀은 소통과 의사결정 절차를 개선해 유휴 시간을 줄이고 전체 수명 주기를 단축할 수 있습니다.
중요한 이유
의사결정이나 승인을 기다리며 발생하는 지연을 측정해 소통 및 의사결정 절차를 개선할 기회를 보여줍니다.
확보 방법
이벤트 로그에서 승인 시작 및 완료 활동(예: 'UAT 시작'과 'UAT 승인')을 찾아 두 활동 사이의 시간 차이를 계산합니다.
예시
3일 2시간1일 8시간 30분4시간
|
|||
|
심각도
Severity
|
버그나 문제가 시스템 또는 최종 사용자에게 미치는 영향을 나타냅니다. | ||
|
설명
심각도는 시스템 중단과 같은 치명적인 문제부터 사소한 외관상의 문제까지 버그의 영향을 분류하는 데 사용합니다. 작업 순서를 정하는 우선순위와는 다른 개념입니다. 해결 방법이 쉽게 마련된 경우에는 심각도가 높은 버그라도 우선순위가 낮을 수 있습니다. 이 속성을 활용하면 우선순위별 처리량 및 주기 시간 대시보드에서 분석 범위를 넓힐 수 있습니다. '가장 심각한 버그부터 수정하고 있는가?'와 같은 질문을 살펴보고, 처리 중인 작업의 위험 수준을 파악할 수 있습니다.
중요한 이유
작업 항목을 비즈니스 영향에 따라 분류하므로, 팀이 영향이 큰 문제를 얼마나 효과적으로 처리하는지 분석할 수 있습니다.
확보 방법
Azure DevOps의 작업 항목, 일반적으로 버그에 있는 'Severity' 필드에 해당합니다.
예시
1 - 치명적2 - 높음3 - 보통4 - 낮음
|
|||
|
풀 리퀘스트 ID
PullRequestId
|
개발 항목과 연결된 풀 리퀘스트의 식별자입니다. | ||
|
설명
이 속성은 작업 항목을 코드 변경 제출 및 검토 절차인 특정 풀 리퀘스트와 연결합니다. 하나의 작업 항목에 여러 풀 리퀘스트가 연결될 수 있습니다. 풀 리퀘스트 ID를 사용하면 수명 주기 중 코드 검토와 통합 단계를 세부적으로 분석할 수 있습니다. 풀 리퀘스트 생성부터 완료까지 걸린 시간을 측정하고, 풀 리퀘스트가 거부되거나 큰 폭의 수정이 필요한 빈도를 분석할 수 있습니다. 이는 코드 품질이나 요구사항의 명확성을 보여주는 지표가 될 수 있습니다.
중요한 이유
개발 작업을 구체적인 코드 검토 활동과 연결해 코드 통합 및 품질 보증 과정을 자세히 분석할 수 있습니다.
확보 방법
이 정보는 Azure DevOps 작업 항목의 'Links' 또는 'Development' 섹션에서 확인할 수 있습니다.
예시
452145334589
|
|||
|
프로젝트 이름
ProjectName
|
개발 항목이 속한 Azure DevOps 프로젝트의 이름입니다. | ||
|
설명
이 속성은 작업 항목이 있는 Azure DevOps 조직 내 프로젝트를 나타냅니다. 프로젝트가 많은 조직에서 전체적인 맥락을 파악하는 데 도움이 됩니다. 프로젝트 이름은 필터링과 비교 분석에 중요한 기준입니다. 프로젝트별로 분석을 나누어 과거 주기 시간 추이 대시보드를 살펴볼 수 있습니다. 이를 통해 프로젝트별 효율성 차이를 확인하고, 한 프로젝트의 프로세스 개선이 긍정적인 영향을 미쳤는지 파악할 수 있습니다.
중요한 이유
분석 데이터를 프로젝트별로 묶어 성과를 비교하고 프로젝트 간 추이를 살펴볼 수 있습니다.
확보 방법
Azure DevOps의 작업 항목에 있는 'Team Project' 필드에 해당합니다.
예시
전자상거래 플랫폼모바일 앱 재출시데이터 웨어하우스 현대화
|
|||
소프트웨어 개발 수명 주기 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
Pull Request 생성
|
개발자가 초기 코딩을 마치고 검토를 위해 pull request로 변경 사항을 제출했음을 나타냅니다. 이 이벤트를 통해 작업 항목과 Azure Repos의 특정 코드 변경을 연결할 수 있습니다. | ||
|
중요한 이유
개발에서 코드 검토로 넘어가는 주요 인계 시점입니다. 이를 추적하면 코딩에 걸린 시간을 측정하고 코드가 동료 검토를 받을 준비가 된 시점을 파악할 수 있습니다.
확보 방법
Azure Repos 데이터에서 pull request 생성 이벤트를 관련 작업 항목과 연결해 포착합니다. 개발자가 명시적으로 연결하는 경우가 많습니다.
기록
작업 항목과 연결된 Azure Repos pull request 생성 이벤트에서 포착합니다.
이벤트 유형
explicit
|
|||
|
Pull Request 완료
|
코드 검토가 승인되고 대상 브랜치에 코드가 병합되어 검토 절차가 성공적으로 끝났음을 나타냅니다. 이 이벤트는 Azure Repos에 명시적으로 기록됩니다. | ||
|
중요한 이유
일반적인 병목인 코드 검토 단계의 종료를 나타냅니다. PR 생성부터 완료까지 걸린 시간을 분석하면 검토 주기의 효율성을 파악할 수 있습니다.
확보 방법
작업 항목과 연결된 Azure Repos pull request의 완료 또는 병합 이벤트에서 포착합니다.
기록
작업 항목과 연결된 pull request 병합 이벤트에서 포착합니다.
이벤트 유형
explicit
|
|||
|
QA 테스트 시작
|
정식 품질 보증 테스트 단계의 시작을 나타냅니다. 작업 항목 상태가 'In QA', 'Testing' 또는 이에 해당하는 값으로 변경된 경우 추론합니다. | ||
|
중요한 이유
QA 주기의 시작을 나타냅니다. 이 단계의 소요 시간을 분석하면 테스트 병목과 효율성을 파악할 수 있습니다.
확보 방법
작업 항목 이력에서 System.State 필드가 'In QA' 또는 지정된 다른 테스트 상태로 변경된 것을 추적해 추론합니다.
기록
State 필드가 'In QA' 또는 'Testing'으로 변경된 것을 기준으로 추론합니다.
이벤트 유형
inferred
|
|||
|
UAT 승인
|
사용자 인수 테스트 후 비즈니스 이해관계자가 변경 사항을 승인했음을 나타냅니다. 일반적으로 상태가 'In UAT'에서 'UAT Approved' 또는 'Ready for Release'로 변경된 것을 기준으로 추론합니다. | ||
|
중요한 이유
작업 항목이 비즈니스 요구사항을 충족하고 운영 환경에 배포할 준비가 되었음을 확인하는 중요한 승인 단계입니다.
확보 방법
작업 항목 이력에서 System.State 필드가 UAT 상태에서 승인 또는 릴리스 준비 상태로 변경된 것을 감지해 추론합니다.
기록
State 필드가 'In UAT'에서 'Ready for Release'로 변경된 것을 기준으로 추론합니다.
이벤트 유형
inferred
|
|||
|
개발 시작
|
개발자가 해당 항목에 실제로 착수했음을 나타냅니다. 작업 항목 상태가 'Active', 'In Progress' 또는 'Committed'로 변경된 것을 기준으로 추론합니다. | ||
|
중요한 이유
실제 개발 단계의 시작을 나타냅니다. 'Created'부터 'Development Started'까지의 시간을 분석하면 백로그 대기 시간을 파악할 수 있습니다.
확보 방법
작업 항목 이력에서 System.State 필드가 'New' 또는 'Approved' 상태에서 'In Progress' 상태로 변경된 것을 기준으로 추론합니다.
기록
State 필드가 'Active' 또는 'In Progress'로 변경된 것을 기준으로 추론합니다.
이벤트 유형
inferred
|
|||
|
운영 환경에 배포
|
작업 항목과 연결된 코드가 운영 환경에 성공적으로 배포되었음을 나타냅니다. Azure Pipelines 릴리스 로그에서 명시적으로 포착하는 이벤트입니다. | ||
|
중요한 이유
가치가 실제로 전달된 시점을 나타내는 중요한 단계입니다. 리드 타임과 주기를 계산할 때 종료점으로 사용합니다.
확보 방법
Azure Pipelines 릴리스 파이프라인 데이터에서 포착합니다. 특히 작업 항목과 연결된 'Production' 단계 배포의 완료 이벤트를 사용합니다.
기록
릴리스 파이프라인의 배포 완료 이벤트에서 포착합니다.
이벤트 유형
explicit
|
|||
|
작업 항목 생성
|
이 활동은 개발 수명 주기의 시작을 나타내며, User Story, Bug 또는 Task와 같은 새 작업 항목이 생성되었음을 의미합니다. Azure DevOps Boards에 새 레코드가 저장될 때 명시적으로 기록됩니다. | ||
|
중요한 이유
이 이벤트는 프로세스의 주요 시작 이벤트입니다. 종단 간 개발 주기를 측정하고 업무가 처음 발생한 경로를 파악하는 데 필요합니다.
확보 방법
작업 항목의 'Created Date'에서 포착합니다. 작업 항목 이력 테이블에도 최초 상태 전환이 기록됩니다.
기록
작업 항목의 'Created Date' 필드에서 포착합니다.
이벤트 유형
explicit
|
|||
|
QA 테스트 실패
|
작업 항목이 QA 테스트를 통과하지 못해 개발 단계로 돌아갔음을 나타냅니다. 테스트 상태에서 'In Progress' 또는 'Active' 상태로 변경된 것을 기준으로 포착합니다. | ||
|
중요한 이유
재작업이 반복되는 경로를 파악하는 데 필요한 활동입니다. 이 이벤트가 자주 발생하면 코드 품질, 요구사항 또는 테스트 절차에 문제가 있을 수 있습니다.
확보 방법
작업 항목 이력에서 'In QA'와 같은 상태가 'Active' 또는 'In Progress'와 같은 상태로 되돌아간 것을 감지해 추론합니다.
기록
State 필드가 'In QA'에서 'Active'로 되돌아간 것을 기준으로 추론합니다.
이벤트 유형
inferred
|
|||
|
QA 테스트 완료
|
품질 보증 단계가 성공적으로 끝났음을 나타냅니다. 작업 항목 상태가 테스트 상태에서 'Ready for UAT' 또는 'QA Approved'와 같은 상태로 변경된 경우 추론합니다. | ||
|
중요한 이유
항목이 사용자 인수 테스트 또는 릴리스를 진행할 준비가 되었음을 나타내는 주요 품질 게이트입니다. 이 시점 이후의 지연은 UAT 또는 릴리스 계획 단계의 병목을 나타낼 수 있습니다.
확보 방법
작업 항목 이력에서 System.State 필드가 'In QA'에서 'Ready for UAT' 또는 'Done'과 같은 다음 상태로 변경된 것을 기준으로 추론합니다.
기록
State 필드가 'In QA'에서 'Ready for UAT'로 변경된 것을 기준으로 추론합니다.
이벤트 유형
inferred
|
|||
|
UAT 시작
|
비즈니스 이해관계자가 기능을 검증하는 사용자 인수 테스트의 시작을 나타냅니다. 일반적으로 상태가 'In UAT' 또는 이에 해당하는 값으로 변경된 것을 기준으로 추론합니다. | ||
|
중요한 이유
릴리스 전 최종 검증의 시작 시점을 측정합니다. 프로세스를 개선하려면 UAT 소요 시간과 승인 대기 시간을 분석해야 합니다.
확보 방법
작업 항목 이력에서 System.State 필드가 'In UAT'와 같이 UAT를 나타내는 사용자 지정 상태로 변경된 것을 기준으로 추론합니다.
기록
State 필드가 'In UAT'로 변경된 것을 기준으로 추론합니다.
이벤트 유형
inferred
|
|||
|
개발 완료
|
개발과 단위 테스트가 모두 끝나 정식 테스트를 시작할 준비가 되었음을 나타냅니다. 일반적으로 작업 항목 상태가 'Resolved' 또는 'Ready for Test'로 변경된 것을 기준으로 추론합니다. | ||
|
중요한 이유
개발팀에서 QA팀으로 넘어가는 주요 인계 시점입니다. 'QA Testing Started'까지 걸린 시간을 측정하면 인계 지연을 파악할 수 있습니다.
확보 방법
작업 항목 이력에서 System.State 필드가 'Resolved' 또는 QA 준비 완료를 나타내는 사용자 지정 상태로 변경된 것을 기준으로 추론합니다.
기록
State 필드가 'Resolved'로 변경된 것을 기준으로 추론합니다.
이벤트 유형
inferred
|
|||
|
빌드 성공
|
새 변경 사항을 포함한 소스 코드가 빌드 파이프라인에서 성공적으로 컴파일되고 패키징되었음을 확인하는 활동입니다. Azure Pipelines에 명시적으로 기록되는 이벤트입니다. | ||
|
중요한 이유
새 코드가 기존 코드와 올바르게 통합되어 빌드가 정상적으로 완료되는지 확인하는 중요한 품질 게이트입니다. 이 단계의 실패는 통합 문제를 나타낼 수 있습니다.
확보 방법
Azure Pipelines의 빌드 완료 이벤트에서 포착합니다. 빌드를 작업 항목에 직접 연결하거나 관련 pull request를 통해 연결해야 합니다.
기록
Azure Pipelines의 빌드 완료 이벤트에서 포착합니다.
이벤트 유형
explicit
|
|||
|
작업 항목 승인
|
작업 항목이 공식적으로 승인되어 내용이 구체화되고 개발을 시작할 준비가 되었음을 나타냅니다. 일반적으로 'State' 필드가 'Approved' 또는 'Ready for Dev'와 같은 값으로 변경된 것을 기준으로 추론합니다. | ||
|
중요한 이유
승인 시점을 추적하면 아이디어 제출부터 개발 착수 결정까지 걸리는 시간을 분석할 수 있습니다. 계획 수립과 백로그 정리 단계에서 발생하는 지연도 확인할 수 있습니다.
확보 방법
작업 항목 이력에서 System.State 필드가 'Approved' 또는 이에 해당하는 사용자 지정 상태로 변경된 것을 감지해 추론합니다.
기록
State 필드가 'Approved'로 변경된 것을 기준으로 추론합니다.
이벤트 유형
inferred
|
|||
|
작업 항목 종료
|
배포 및 배포 후 검증이 끝난 뒤 작업 항목을 최종 종료하는 것을 나타냅니다. 상태가 'Closed' 또는 'Done'으로 변경된 것을 기준으로 포착합니다. | ||
|
중요한 이유
작업 항목에 대한 전체 프로세스가 성공적으로 완료되었음을 나타내는 마지막 활동입니다. 수명 주기의 최종 종료점입니다.
확보 방법
작업 항목 이력에서 System.State 필드가 'Closed' 또는 'Completed' 범주의 유사한 최종 상태로 변경된 것을 기준으로 추론합니다.
기록
State 필드가 'Closed'로 변경된 것을 기준으로 추론합니다.
이벤트 유형
inferred
|
|||
|
작업 항목 취소
|
작업 항목이 취소되어 완료되거나 배포되지 않음을 나타냅니다. 상태가 'Removed', 'Cancelled' 또는 이에 해당하는 값으로 변경된 것을 기준으로 포착합니다. | ||
|
중요한 이유
프로세스가 성공적으로 완료되지 않고 끝나는 경우를 나타냅니다. 취소된 항목을 분석하면 계획, 우선순위 지정 또는 요구사항 정의의 문제를 파악할 수 있습니다.
확보 방법
작업 항목 이력에서 System.State 필드가 'Removed' 범주의 최종 상태로 변경된 것을 기준으로 추론합니다.
기록
State 필드가 'Removed' 또는 'Cancelled'로 변경된 것을 기준으로 추론합니다.
이벤트 유형
inferred
|
|||
데이터 추출 안내
시작할 준비가 되셨나요?
오늘부터 소프트웨어 개발 수명 주기 개선을 시작하세요. 이 템플릿을 활용해 프로세스에 관한 유용한 인사이트를 얻을 수 있습니다.
오늘부터 Azure DevOps에서 SDLC를 개선하세요!
주기 시간을 30% 줄이고 SDLC 워크플로의 병목을 없애세요.
신용카드 없이 몇 분 만에 시작할 수 있습니다.