소프트웨어 개발 수명 주기 데이터 템플릿
소프트웨어 개발 수명 주기 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- 데이터 추출 안내
소프트웨어 개발 수명 주기 속성
| 이름 | 설명 | ||
|---|---|---|---|
|
개발 항목
DevelopmentItemId
|
기능, 버그 수정 또는 작업과 같이 개발 작업 한 건을 식별하는 고유한 ID입니다. 기본 케이스 식별자로 사용됩니다. | ||
|
설명
개발 항목 ID는 작업 항목이 생성된 시점부터 최종 배포까지 추적합니다. 브랜치 생성, 커밋, pull request, 리뷰, 배포 등 관련 활동을 하나의 프로세스 인스턴스로 연결합니다. 분석에서는 이 ID를 사용해 개발 작업의 엔드투엔드 사이클 타임을 계산합니다. 기능이나 버그 수정의 전체 진행 과정을 재구성해 개별 작업 항목의 병목, 재작업 반복, 프로세스 차이를 자세히 분석할 수 있습니다.
중요한 이유
process mining에서 관련된 모든 개발 이벤트를 하나의 케이스로 연결하는 데 필요한 식별자입니다. 이를 통해 소프트웨어 개발 수명 주기 전체를 정확하게 시각화하고 분석할 수 있습니다.
확보 방법
일반적으로 GitHub의 이슈 번호 또는 Pull Request 번호를 사용합니다. 이슈나 pull request 관련 웹훅 이벤트 또는 API 응답 페이로드의 'number' 필드에서 추출할 수 있습니다.
예시
101PR-2345TASK-812
|
|||
|
시작 시간
EventTimestamp
|
특정 개발 활동이나 이벤트가 발생한 정확한 날짜와 시간입니다. | ||
|
설명
이 타임스탬프는 활동이 시작된 시점을 나타냅니다. 개발 항목별 프로세스 흐름을 재구성하려면 이벤트를 시간순으로 정렬해야 합니다. 타임스탬프의 순서와 시간 차이를 사용해 프로세스 성과를 분석합니다. 분석에서는 사이클 타임, 처리 시간, 대기 시간 등 시간 기반 지표를 계산하는 데 이 속성이 필요합니다. 단계 사이의 지연을 파악하고 병목 분석 및 성과 모니터링 대시보드에 필요한 데이터를 제공합니다.
중요한 이유
이 타임스탬프는 이벤트를 올바른 순서로 정렬하고 사이클 타임과 병목 지속 시간 등 성과 지표를 계산하는 데 중요합니다.
확보 방법
일반적으로 GitHub API 및 웹훅이 이슈, pull request, 커밋 등의 객체에 대해 전송하는 JSON 페이로드의 'created_at' 또는 'updated_at' 필드에서 찾을 수 있습니다.
예시
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:25Z
|
|||
|
활동
ActivityName
|
소프트웨어 개발 수명 주기에서 발생한 특정 이벤트나 작업의 이름입니다. | ||
|
설명
활동 이름은 '이슈 생성', 'PR에 코드 푸시', 'Pull Request 승인', '배포 성공'과 같이 개발 프로세스의 한 단계를 나타냅니다. 이러한 이벤트가 모여 개발 항목의 엔드투엔드 프로세스를 구성합니다. 이 속성은 프로세스 맵을 구성하는 데 사용되므로 process mining의 기본 요소입니다. 활동의 순서, 빈도, 소요 시간을 분석하면 실제 프로세스 흐름과 일반적인 경로를 파악하고, 편차와 병목을 찾을 수 있습니다.
중요한 이유
이 속성을 바탕으로 프로세스 맵을 구성해 개발 수명 주기에서 이벤트가 발생한 순서를 시각화하고 분석할 수 있습니다.
확보 방법
웹훅 이벤트 페이로드의 'action' 필드(예: 이슈의 'opened', 'closed') 또는 이벤트 유형 자체(예: 'PushEvent', 'PullRequestReviewEvent')에서 가져옵니다.
예시
이슈 생성Pull Request 열기PR에 코드 푸시리뷰 요청Pull Request 병합
|
|||
|
개발 항목 유형
DevelopmentItemType
|
기능, 버그, 작업, 에픽 등 개발 작업 항목의 분류입니다. | ||
|
설명
이 속성은 수행 중인 작업의 성격을 분류합니다. 일반적으로 GitHub의 라벨이나 특정 이슈 템플릿으로 관리합니다. 작업 유형에 따라 적절한 성과 기대치를 설정하려면 이 정보를 파악해야 합니다. 버그 수정의 예상 사이클 타임은 새 기능 개발보다 훨씬 짧을 수 있습니다. 이 속성을 사용하면 작업 유형별로 비교 분석할 수 있습니다. 버그 수정이 새 기능보다 빠르게 처리되는지 분석하거나, 기술 부채와 신규 개발에 리소스가 어떻게 배분되는지 파악할 수 있습니다. '프로젝트 및 유형별 처리량' 대시보드의 주요 분석 기준입니다.
중요한 이유
작업 항목을 분류해 성과를 비교하고, 버그와 기능 등 작업 유형별로 프로세스가 어떻게 진행되는지 분석할 수 있습니다.
확보 방법
일반적으로 이슈나 pull request에 적용된 GitHub 라벨에서 가져옵니다. 'type:bug', 'type:feature'와 같이 일관된 라벨 규칙이 필요합니다.
예시
버그기능작업기술 부채
|
|||
|
담당 사용자
Assignee
|
개발 항목이나 pull request 리뷰와 같은 특정 작업을 맡은 사용자 또는 개발자입니다. | ||
|
설명
이 속성은 각 단계에서 작업을 담당하는 사람을 식별합니다. 이슈 담당자, pull request 작성자 또는 코드 리뷰 요청을 받은 리뷰어가 해당할 수 있습니다. 담당자를 추적하면 리소스 배분과 업무량을 파악할 수 있습니다. 분석 시 개발자별 업무량을 모니터링하고, 리소스 병목을 찾고, 팀원 간 인계 효율을 분석하는 데 사용합니다. 대시보드에서 담당자를 기준으로 필터링해 개인 또는 팀의 성과를 평가하고 업무가 균형 있게 배분되었는지 확인할 수 있습니다.
중요한 이유
개발자 업무량, 팀 성과, 팀원 간 인계 효율을 분석하는 데 중요합니다.
확보 방법
GitHub API의 이슈, pull request, 리뷰 이벤트 JSON 페이로드에 있는 'assignee' 또는 'user' 객체에서 확인할 수 있습니다.
예시
john.doejane.smithdev-team-lead
|
|||
|
우선순위
Priority
|
'높음', '보통', '낮음'과 같이 개발 항목에 지정된 우선순위 수준입니다. | ||
|
설명
우선순위는 작업 항목의 긴급성이나 업무상 중요도를 나타냅니다. GitHub에는 우선순위를 입력하는 기본 필드가 없으므로 일반적으로 라벨(예: 'P1-High', 'P2-Medium')을 사용해 관리합니다. 이 정보를 정확히 추출하려면 일관된 라벨 규칙을 정해야 합니다. 이 속성은 '우선순위별 흐름 분석'에 필수입니다. 분석가는 이를 통해 우선순위가 높은 항목이 낮은 항목보다 실제로 더 빠르게 처리되는지 확인하고, 우선순위에 따른 처리 시간 편차를 측정할 수 있습니다. 또한 우선순위 지정 프로세스가 효과적으로 운영되는지 평가하는 데 도움이 됩니다.
중요한 이유
우선순위가 높은 항목이 낮은 항목보다 빠르게 처리되는지 분석해 우선순위 지정 전략의 효과를 확인할 수 있습니다.
확보 방법
이슈나 pull request에 지정된 GitHub 라벨에서 가져옵니다. 우선순위 라벨에 표준 규칙을 적용해야 합니다.
예시
높음보통낮음긴급
|
|||
|
저장소
RepositoryName
|
개발 활동이 이루어지는 코드 저장소의 이름입니다. | ||
|
설명
저장소는 프로젝트나 제품을 식별하는 기준입니다. 특정 애플리케이션이나 구성 요소의 코드, 이슈, pull request가 저장됩니다. 저장소를 기준으로 제품이나 팀별 개발 프로세스를 구분하고 비교할 수 있습니다. 분석 시 이 속성을 사용해 프로젝트별 프로세스 성과를 필터링하고 비교할 수 있습니다. '사이클 타임이 가장 긴 프로젝트는 무엇인가요?', '프로젝트 A와 프로젝트 B의 버그 수정 프로세스는 어떻게 다른가요?'와 같은 질문에 답하는 데 도움이 됩니다. '프로젝트 및 유형별 처리량' 대시보드에도 필요합니다.
중요한 이유
프로젝트, 제품 또는 팀별로 개발 프로세스를 구분하고 비교해 분석 범위를 구체화할 수 있습니다.
확보 방법
거의 모든 GitHub 웹훅 및 API 페이로드의 'repository' 객체에서 확인할 수 있습니다. 해당 필드는 보통 'repository.full_name' 또는 'repository.name'입니다.
예시
my-org/web-appmy-org/api-servicemy-org/data-pipeline
|
|||
|
종료 시간
EndTimestamp
|
특정 개발 활동이나 이벤트가 완료된 정확한 날짜와 시간입니다. | ||
|
설명
종료 타임스탬프는 활동이 완료된 시점을 나타냅니다. GitHub의 많은 이벤트는 순간적으로 발생하지만(예: '이슈 생성'), CI 검사 실행처럼 소요 시간을 측정할 수 있는 활동도 있습니다. 종료 시간에서 시작 시간을 빼면 활동의 처리 시간을 구할 수 있습니다. 이 속성은 'ProcessingTime' 지표를 계산하는 데 사용됩니다. 코드 리뷰나 자동 검사와 같은 작업에 실제로 얼마나 많은 시간이 드는지 파악하는 데 중요합니다. 처리 시간을 분석하면 지나치게 많은 시간을 소모하는 비효율적인 활동을 찾을 수 있습니다.
중요한 이유
활동의 정확한 처리 시간을 계산해 실제 작업 시간과 대기 시간을 구분할 수 있습니다.
확보 방법
검사 실행 객체의 'completed_at' 필드에서 찾거나, 논리적으로 활동을 마무리하는 다음 이벤트의 타임스탬프를 사용해 계산할 수 있습니다.
예시
2023-10-26T10:05:15Z2023-10-27T18:00:00Z2023-10-28T09:10:30Z
|
|||
|
CI 검사 상태
CiCheckStatus
|
'통과' 또는 '실패'와 같은 자동화된 지속적 통합(CI) 검사의 상태입니다. | ||
|
설명
이 속성은 pull request의 코드 변경 사항을 대상으로 실행되는 자동 빌드, 테스트, 스캔의 결과를 나타냅니다. CI 검사는 현대적인 개발 워크플로에서 중요한 품질 게이트입니다. 이 속성을 분석하면 자동화된 테스트의 효과를 파악할 수 있습니다. 실패율이 높으면 코드 안정성, 테스트 모음 또는 개발 환경에 문제가 있을 수 있습니다. 'CI 검사 통과' 및 'CI 검사 실패' 활동을 지원하며, 빌드 오류로 인한 지연을 분석하는 데 도움이 됩니다.
중요한 이유
자동화된 품질 게이트의 통과 또는 실패 여부를 나타내므로 코드 품질과 CI 파이프라인의 효과를 파악할 수 있습니다.
확보 방법
GitHub Checks API 또는 Statuses API를 통해 check run이나 status 객체의 'state' 또는 'conclusion' 필드에서 가져옵니다.
예시
성공실패대기 중오류
|
|||
|
Pull Request 번호
PullRequestNumber
|
개발 항목과 연결된 pull request의 고유 식별자입니다. | ||
|
설명
pull request(PR)는 코드 변경 사항을 특정 브랜치에 병합하도록 제안하는 요청입니다. Pull Request 번호를 사용하면 코드 푸시와 리뷰 같은 개발 활동을 기본 개발 항목 또는 이슈와 연결할 수 있습니다. 이 ID는 전체 개발 수명 주기에서 코드 통합 및 리뷰 하위 프로세스를 추적하는 데 중요합니다. 리뷰 소요 시간, 리뷰 중 확인된 재작업 주기, 병합률 등 코드 리뷰 프로세스를 자세히 분석할 수 있습니다. 또한 계획 단계의 이슈와 구현 단계의 PR을 연결합니다.
중요한 이유
이슈를 관련 코드 변경 및 리뷰 프로세스와 연결해 코드 리뷰 주기와 전체 제공 시간에 미치는 영향을 자세히 분석할 수 있습니다.
확보 방법
여러 GitHub API 응답의 'pull_request' 객체에서 'number' 필드로 확인하거나 Pull Requests API의 기본 식별자로 확인할 수 있습니다.
예시
12345678910
|
|||
|
개발 주기 시간
DevelopmentCycleTime
|
개발 항목이 생성된 시점부터 최종 배포되거나 종료될 때까지 걸린 총시간입니다. | ||
|
설명
개발 항목 하나를 기준으로 첫 이벤트(예: '이슈 생성')와 마지막 이벤트(예: '배포 성공' 또는 '이슈 종료') 사이의 시간 차이를 계산하는 케이스 단위 지표입니다. 개발 프로세스의 전반적인 효율성을 측정하는 주요 KPI 중 하나입니다. '전체 개발 주기 시간' 대시보드와 '평균 개발 주기 시간' KPI에 직접 활용됩니다. 프로세스 개선 활동에서는 이 지표를 줄이는 것을 주요 목표로 삼는 경우가 많습니다.
중요한 이유
개발 항목의 시작부터 출시까지 걸리는 시간을 나타내므로 프로세스 전반의 속도와 효율성을 측정하는 주요 KPI입니다.
확보 방법
케이스별로 마지막 활동의 타임스탬프에서 첫 활동의 타임스탬프를 빼서 계산합니다.
예시
P5DT6H30MP14DT12HP1DT2H
|
|||
|
라벨
Labels
|
이슈나 pull request를 분류하기 위해 지정한 태그 또는 라벨 목록입니다. | ||
|
설명
GitHub 라벨은 이슈와 pull request에 메타데이터를 유연하게 추가하는 방법입니다. 우선순위, 작업 유형, 구성 요소, 팀 또는 상태를 표시하는 데 사용할 수 있습니다. 라벨 목록에는 구조화되지 않은 맥락 정보가 풍부하게 담겨 있습니다. 우선순위나 유형 같은 개별 속성은 라벨에서 추출하지만, 전체 라벨 목록을 보존하면 필요에 따른 분석을 수행하고 다른 프로세스 패턴을 찾는 데 유용합니다. 라벨을 조합해 케이스를 유연하게 필터링하고 세분화할 수 있습니다.
중요한 이유
작업 항목을 분류하는 데 활용할 수 있는 유연하고 풍부한 메타데이터를 제공해 다양한 차원에서 심층 분석할 수 있습니다.
확보 방법
GitHub API의 이슈 및 pull request JSON 페이로드에 있는 'labels' 배열에서 확인할 수 있습니다. 배열의 각 항목은 'name' 필드가 포함된 객체입니다.
예시
버그, UI, 높은 우선순위기능, 백엔드, 문서 필요기술 부채, 리팩터링
|
|||
|
리뷰 상태
ReviewState
|
pull request 코드 리뷰의 결과입니다. 예를 들어 '승인됨' 또는 '수정 요청'이 있습니다. | ||
|
설명
이 속성은 리뷰어의 결정을 나타냅니다. 일반적인 상태로는 코드를 병합할 준비가 되었음을 뜻하는 'APPROVED'와 재작업이 필요함을 뜻하는 'CHANGES_REQUESTED'가 있습니다. 그 밖에 'COMMENTED' 또는 'PENDING' 상태도 사용할 수 있습니다. 재작업과 품질을 분석하는 데 중요한 속성입니다. 'CHANGES_REQUESTED' 이벤트가 자주 발생하면 초기 코드 품질에 문제가 있거나 요구사항이 명확하지 않을 수 있습니다. 개발 항목이 수정 요청을 받아 되돌아간 시점을 식별해 '재작업 및 회귀 루프' 대시보드 분석을 지원합니다.
중요한 이유
코드 리뷰 프로세스에서 재작업 루프와 품질 게이트를 직접 보여 주므로 비효율과 품질 문제의 원인을 찾는 데 도움이 됩니다.
확보 방법
GitHub API의 pull request 리뷰 객체에서 'state' 필드로 확인할 수 있습니다. 예를 들어 'PullRequestReviewEvent' 페이로드에 포함됩니다.
예시
승인됨수정 요청의견 작성
|
|||
|
리뷰어
Reviewer
|
사용자가 pull request의 코드 리뷰를 요청받은 사람입니다. | ||
|
설명
리뷰어는 pull request의 코드 변경 사항이 품질과 정확성을 갖추고 표준을 준수하는지 검토하도록 지정된 개발자 또는 팀원입니다. 하나의 pull request에 여러 리뷰어를 지정할 수 있습니다. 이 속성은 코드 리뷰 프로세스 분석에 필수입니다. 특정 리뷰어와 관련된 병목을 찾고, 리뷰 업무 분배를 파악하며, 리뷰어가 요청에 응답하기까지 걸리는 시간을 측정할 수 있습니다. '평균 코드 리뷰 주기 시간' KPI를 계산하는 데도 사용됩니다.
중요한 이유
품질 보증에 참여한 사람을 식별해 리뷰 업무량, 지연, 코드 리뷰의 전반적인 효율성을 분석할 수 있습니다.
확보 방법
GitHub API의 pull request 리뷰 이벤트에서 'requested_reviewers' 배열 또는 'user' 객체를 통해 확인할 수 있습니다.
예시
alex.chenmaria.garciasenior-dev-team
|
|||
|
마지막 데이터 업데이트
LastDataUpdate
|
이 레코드의 데이터를 소스 시스템에서 마지막으로 새로 고친 시점을 나타내는 타임스탬프입니다. | ||
|
설명
이 속성은 가장 최근에 데이터를 추출하거나 업데이트한 날짜와 시간을 기록합니다. 분석에 사용되는 데이터의 최신성을 보여주는 메타데이터입니다. 비즈니스 이벤트가 발생한 시점을 기록하는 이벤트 타임스탬프와는 다릅니다. 분석 시 이 필드를 통해 프로세스 현황이 얼마나 최신인지 파악할 수 있습니다. 실시간 데이터를 보는지 특정 시점의 스냅샷을 보는지 사용자가 확인할 수 있어 운영 대시보드와 모니터링에 유용합니다.
중요한 이유
데이터가 최신 상태인지 보여줍니다. 분석과 대시보드가 최신 정보를 바탕으로 하는지 확인하는 데 중요합니다.
확보 방법
이 타임스탬프는 데이터 추출, 변환, 적재(ETL) 과정에서 생성되어 추가됩니다.
예시
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
배포 환경
DeploymentEnvironment
|
'스테이징' 또는 '프로덕션'과 같은 배포 대상 환경입니다. | ||
|
설명
이 속성은 코드가 배포되는 환경을 지정합니다. 개발부터 프로덕션 릴리스까지 전체 수명 주기를 파악하려면 환경별 배포를 추적해야 합니다. 이 속성을 활용해 배포 하위 프로세스를 분석할 수 있습니다. 스테이징에서 프로덕션으로 코드를 승격하는 데 걸리는 시간을 측정하고, 환경별 배포 성공률을 추적할 수 있습니다. 개발 항목이 실제로 완료되어 사용자에게 제공된 시점을 파악하는 데도 필요합니다.
중요한 이유
프로덕션 이전 릴리스와 프로덕션 릴리스를 구분합니다. 실제 출시 소요 시간을 측정하고 배포 패턴을 분석하는 데 중요합니다.
확보 방법
GitHub Deployments API에서 가져옵니다. 이 API는 CI/CD 파이프라인이나 다른 자동화 도구에서 호출되는 경우가 많습니다.
예시
개발스테이징프로덕션
|
|||
|
브랜치 이름
BranchName
|
개발 항목의 코드 변경이 이루어진 Git 브랜치의 이름입니다. | ||
|
설명
브랜치는 기본 코드베이스에 영향을 주지 않고 새 기능을 개발하거나 버그를 수정하기 위해 만든 독립적인 개발 경로입니다. 브랜치 이름에는 이슈 번호나 작업 내용을 요약한 설명 등 유용한 정보가 포함되는 경우가 많습니다. 브랜치 이름을 분석하면 브랜치 전략과 개발 규칙 준수 여부를 파악할 수 있습니다. 특정 코드 커밋을 개발 항목과 연결해 코딩 활동을 전체적으로 확인하는 데도 도움이 됩니다.
중요한 이유
개별 개발 경로에 대한 맥락을 제공하며, 브랜치 전략과 명명 규칙의 적용 및 분석에 도움이 됩니다.
확보 방법
push 이벤트의 'ref' 필드 또는 pull request API 응답의 'head' 및 'base' 객체에서 확인할 수 있습니다.
예시
feature/PROJ-123-new-loginbugfix/fix-payment-bughotfix/critical-security-patch
|
|||
|
소스 시스템
SourceSystem
|
개발 프로세스 데이터를 추출한 시스템입니다. | ||
|
설명
이 속성은 이벤트 데이터의 출처를 식별합니다. 이 프로세스에서는 값이 항상 'GitHub'입니다. 개발 활동이 여러 시스템에 걸쳐 있는 복잡한 환경에서는(예: 계획은 Jira, 코드는 GitHub, 배포는 Jenkins) 각 이벤트의 출처를 구분하는 데 사용합니다. 분석 시 데이터의 출처를 추적해 검증과 문제 해결에 활용할 수 있습니다. 여러 플랫폼에 걸친 프로세스도 분석할 수 있어 각 활동의 맥락을 명확히 파악할 수 있습니다.
중요한 이유
데이터 출처를 식별합니다. 데이터 검증과 여러 통합 시스템에 걸친 프로세스 분석에 필요합니다.
확보 방법
일반적으로 데이터 추출, 변환, 적재(ETL) 과정에서 레코드의 출처를 표시하기 위해 추가하는 고정값입니다.
예시
GitHubGitHub Enterprise
|
|||
|
인계 대기 시간
HandoffWaitingTime
|
서로 다른 사람이 수행하는 활동 사이에서 개발 항목이 대기한 시간을 계산한 값입니다. | ||
|
설명
한 활동이 완료된 시점부터 다음 활동이 시작될 때까지의 시간을 측정하되, 담당자가 바뀌는 경우만 포함합니다. 예를 들어 '리뷰 요청' 이벤트부터 다른 사용자가 '리뷰에서 수정 요청' 이벤트를 수행할 때까지의 시간입니다. 이 지표는 소통 공백과 조정 문제를 찾는 데 중요합니다. '주요 인계 효율성' 대시보드와 '평균 인계 대기 시간' KPI에 활용됩니다. 인계 시 대기 시간이 길면 리소스가 부족하거나 알림 프로세스가 비효율적일 수 있습니다.
중요한 이유
팀이나 역할 간 인계 과정에서 조정이 원활하지 않거나 리소스를 사용할 수 없어 발생하는 지연을 찾아냅니다. 이러한 지연은 비효율의 주요 원인인 경우가 많습니다.
확보 방법
'Assignee' 또는 'User' 속성이 바뀌는 연속 활동을 찾은 다음, 두 활동 사이의 시간 차이를 측정해 계산합니다.
예시
PT1H15MP2DT4HPT25M
|
|||
|
작성자
Author
|
이슈, pull request 또는 커밋을 생성한 사용자입니다. | ||
|
설명
작성자는 개발 프로세스에서 특정 산출물을 처음 만든 사람입니다. 예를 들어 이슈 작성자는 버그를 신고하거나 기능을 요청한 사람이고, pull request 작성자는 코드를 작성한 개발자입니다. 분석에서는 작성자 정보를 활용해 작업이 어디서 시작되는지 파악할 수 있습니다. 예를 들어 버그 신고 작성자를 분석하면 특정 팀이나 기능과 관련된 패턴을 찾을 수 있습니다. 담당자 정보와 함께 분석하면 업무 인계 패턴도 확인할 수 있습니다.
중요한 이유
작업 항목이나 코드 변경을 시작한 사람을 식별합니다. 재작업, 버그 신고 또는 기능 요청의 발생 경로를 분석할 때 유용합니다.
확보 방법
이슈, pull request, 커밋에 대한 API 응답의 기본 객체 안에 있는 'user' 객체에서 확인할 수 있습니다. 일반적으로 필드명은 'user.login'입니다.
예시
sara.jonesmike.leeautomation-bot
|
|||
|
재작업 여부
IsRework
|
활동이 이전 프로세스 단계로 되돌아가는 경우 true로 설정되는 불리언 플래그입니다. | ||
|
설명
개발 항목이 프로세스에서 이전 단계로 돌아가면 이 플래그가 true로 설정됩니다. 예를 들어 pull request 리뷰에서 '수정 요청'을 받거나 종료된 이슈가 다시 열리는 경우입니다. 활동 순서를 분석해 값을 도출합니다. 이 속성은 낭비와 비효율을 정량화하는 데 필요합니다. '재작업 및 회귀 루프' 대시보드와 '재작업률' KPI에 직접 활용됩니다. 'IsRework = true'로 필터링하면 재작업 원인을 분리해 조사할 수 있습니다.
중요한 이유
재작업에 해당하는 활동을 명시적으로 표시해 프로세스 비효율의 원인을 쉽게 정량화하고 시각화해 분석할 수 있습니다.
확보 방법
도출 속성입니다. 표준 프로세스 흐름을 정의한 다음, 이전의 논리적 단계로 되돌아가는 활동을 표시하는 방식으로 계산합니다.
예시
truefalse
|
|||
|
커밋 해시
CommitHash
|
특정 코드 커밋을 식별하는 고유 ID(SHA)입니다. | ||
|
설명
커밋 해시는 Git에서 커밋을 고유하게 식별하는 40자 SHA-1 해시입니다. 특정 코드 버전을 영구적으로 식별하는 ID 역할을 합니다. 커밋은 개발 프로세스에서 변경 사항을 구성하는 기본 단위입니다. 커밋 해시는 세밀한 수준까지 추적할 수 있게 해줍니다. 프로세스 이벤트를 실제 코드 변경 사항과 직접 연결할 수 있어 감사, 규정 준수 또는 프로덕션 장애의 근본 원인 분석에 유용합니다.
중요한 이유
프로세스 단계와 실제 코드 변경 사항을 가장 세밀하게 연결해 감사와 디버깅에 필요한 전체 추적성을 제공합니다.
확보 방법
push 이벤트 페이로드('head_commit.id') 또는 pull request나 브랜치의 Commits API에서 확인할 수 있습니다.
예시
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0f0e9d8c7b6a5f4e3d2c1b0a9f8e7d6c5b4a3f2e1
|
|||
|
항목 상태
State
|
'open', 'closed', 'merged'와 같은 이슈 또는 pull request의 현재 상태입니다. | ||
|
설명
이 속성은 개발 항목의 전반적인 상태를 나타냅니다. 이슈의 일반적인 상태는 'open'과 'closed'이며, pull request의 상태에는 'open', 'closed', 'merged'가 있습니다. 이를 통해 항목의 진행 상황을 확인할 수 있습니다. 분석에서는 진행 중인 작업과 완료된 작업을 구분하는 데 사용합니다. 진행 중인 작업을 모니터링하는 '활성 개발 진행 상황'과 같은 대시보드에 필요합니다. 프로세스의 종료 시점을 정의할 때도 사용합니다. 예를 들어 'merged' 또는 'closed' 상태를 케이스 완료로 간주할 수 있습니다.
중요한 이유
작업 항목이 진행 중인지 완료되었는지 명확히 보여줍니다. 수명 주기 분석과 진행 중인 작업 모니터링에 기본이 되는 정보입니다.
확보 방법
GitHub API가 이슈와 pull request의 JSON 페이로드에 제공하는 'state' 필드에서 바로 확인할 수 있습니다.
예시
열림닫힘병합됨
|
|||
소프트웨어 개발 수명 주기 활동
| 활동 | 설명 | ||
|---|---|---|---|
|
CI 검사 통과
|
Pull request의 코드를 대상으로 실행한 빌드, 단위 테스트, 정적 분석 등의 자동 검사가 성공적으로 완료되었음을 나타냅니다. GitHub Actions와 같은 시스템이 보고한 검사 상태를 바탕으로 추론합니다. | ||
|
중요한 이유
자동화된 품질 관문으로, 코드 안정성을 확보하는 데 중요합니다. 검사가 실패하거나 실행 시간이 길어지면 배포 파이프라인의 주요 병목이 될 수 있습니다.
확보 방법
GitHub Checks API 또는 Statuses API의 데이터를 바탕으로 추론합니다. 검사 실행 또는 상태 업데이트에서 'success'를 보고하거나, 'completed' 상태와 함께 'success' 결론을 보고합니다.
기록
Checks API를 모니터링해 관련 검사 모음의 결론이 'success'인지 확인합니다.
이벤트 유형
inferred
|
|||
|
Pull Request 병합
|
승인된 pull request의 코드 변경 사항이 main 또는 develop과 같은 대상 브랜치에 공식적으로 통합됩니다. 새 코드를 반영하는 pull request의 명시적인 최종 작업입니다. | ||
|
중요한 이유
개발과 리뷰가 완료되었음을 나타내는 중요한 이정표입니다. 많은 팀에서 자동 배포 직전의 마지막 단계입니다.
확보 방법
GitHub Pull Request API 이벤트 스트림 또는 웹훅에서 수집합니다. 이벤트 작업은 'closed'이며 pull request 페이로드의 'merged' 속성은 true입니다.
기록
Pull request의 'closed' 작업을 수신하고 'merged' 플래그가 true인지 확인합니다.
이벤트 유형
explicit
|
|||
|
Pull Request 승인
|
리뷰어가 pull request의 변경 사항을 공식적으로 승인했습니다. 이는 변경 사항이 품질 및 기능 기준을 충족한다는 뜻입니다. 리뷰어가 'approve' 상태로 리뷰를 제출하면 기록됩니다. | ||
|
중요한 이유
병합 전 중요한 품질 관문이자 주요 이정표입니다. PR 생성부터 이 상태에 도달하기까지 걸린 시간은 리뷰 프로세스의 효율을 측정하는 주요 KPI입니다.
확보 방법
리뷰가 'APPROVED' 상태로 제출되면 GitHub Pull Request API 또는 웹훅에서 수집합니다.
기록
'APPROVED' 상태인 pull request 리뷰 제출 이벤트를 필터링합니다.
이벤트 유형
explicit
|
|||
|
Pull Request 열기
|
초기 코드가 리뷰와 통합을 진행할 준비가 되었음을 나타냅니다. 개발자는 기능 브랜치의 변경 사항을 기본 브랜치에 반영해 달라고 제안하는 pull request(PR)를 만듭니다. GitHub에서 명시적으로 기록되는 이벤트입니다. | ||
|
중요한 이유
초기 개발 단계가 끝나고 리뷰 및 통합 절차가 시작되는 중요한 이정표입니다. 개발 시간과 리뷰 시간을 구분해 분석하는 데 필요합니다.
확보 방법
GitHub Pull Request API 이벤트 스트림 또는 웹훅에서 수집합니다. 이벤트 작업은 'opened'입니다.
기록
웹훅 또는 API 폴링을 통해 pull request의 'opened' 작업을 수신합니다.
이벤트 유형
explicit
|
|||
|
이슈 생성
|
개발 항목의 수명 주기가 시작되는 시점으로, 작업, 버그 또는 기능 요청이 공식적으로 생성된 것을 나타냅니다. 사용자가 GitHub 저장소에서 새 이슈를 만들면 이 이벤트가 명시적으로 기록됩니다. | ||
|
중요한 이유
이 프로세스의 주요 시작 활동입니다. 전체 개발 사이클 타임을 측정하고 초기 업무가 어디에서 발생하는지 파악하는 데 필요합니다.
확보 방법
GitHub Issues API 이벤트 스트림에서 명시적으로 수집되는 이벤트입니다. 특정 이슈 번호의 이벤트 유형은 보통 'opened'입니다.
기록
웹훅 또는 API 폴링을 통해 이슈의 'opened' 이벤트를 수신합니다.
이벤트 유형
explicit
|
|||
|
이슈 종료
|
개발 항목이 완료된 것으로 간주되어 해당 이슈가 공식적으로 종료됩니다. 연결된 pull request가 병합되면 자동으로 종료될 수 있으며, 팀원이 직접 종료할 수도 있습니다. | ||
|
중요한 이유
개발 항목의 프로세스가 끝나는 시점을 확정하는 활동입니다. 엔드투엔드 사이클 타임을 계산하는 데 필요합니다.
확보 방법
GitHub Issues API 이벤트 스트림에서 명시적으로 수집되는 이벤트입니다. 이벤트 유형은 'closed'입니다.
기록
웹훅 또는 API 폴링을 통해 이슈의 'closed' 이벤트를 수신합니다.
이벤트 유형
explicit
|
|||
|
CI 검사 실패
|
Pull request의 코드를 대상으로 실행한 빌드 오류나 단위 테스트 실패 등의 자동 검사가 실패했음을 나타냅니다. GitHub Actions와 같은 시스템이 보고한 실패 상태를 바탕으로 추론합니다. | ||
|
중요한 이유
이 활동은 개발자의 조치가 필요한 기술적 품질 문제와 재작업을 보여줍니다. 실패 빈도를 분석하면 로컬 테스트나 코드 품질을 개선할 방향을 찾을 수 있습니다.
확보 방법
GitHub Checks API 또는 Statuses API의 데이터를 바탕으로 추론합니다. 검사 실행 또는 상태 업데이트에서 'failure'를 보고하거나, 'completed' 상태와 함께 'failure' 결론을 보고합니다.
기록
Checks API를 모니터링해 관련 검사 모음의 결론이 'failure'인지 확인합니다.
이벤트 유형
inferred
|
|||
|
PR에 코드 푸시
|
리뷰를 위해 제출한 코드가 업데이트되었음을 나타냅니다. 최초 PR에 포함된 변경 사항일 수도 있고 리뷰 의견에 대한 수정일 수도 있습니다. 열린 pull request와 연결된 브랜치에 새 커밋이 푸시될 때마다 이 이벤트가 기록됩니다. | ||
|
중요한 이유
이 이벤트를 추적하면 재작업이 반복되는 구간을 파악할 수 있습니다. 리뷰 후 여러 차례 푸시가 발생했다면 수정이 필요했다는 뜻이며, 전체 사이클 타임에도 영향을 줍니다.
확보 방법
Pull Request 타임라인에서 커밋 추가로 표시되는 명시적 이벤트입니다. 'push' 웹훅을 사용하거나 PR에 연결된 커밋을 모니터링해 수집할 수 있습니다.
기록
열린 pull request와 연결된 브랜치의 'push' 이벤트를 추적합니다.
이벤트 유형
explicit
|
|||
|
리뷰 요청
|
Pull request 작성자가 특정 팀원이나 팀에 코드 리뷰를 공식적으로 요청합니다. GitHub UI 또는 API에서 실행하는 명시적 작업으로, 요청된 리뷰어에게 알림이 전송됩니다. | ||
|
중요한 이유
코드 리뷰를 위한 인계가 공식적으로 시작되는 활동입니다. 이 시점부터 리뷰 제출까지 걸린 시간을 측정하면 리뷰어의 응답 속도와 잠재적 병목을 파악할 수 있습니다.
확보 방법
GitHub Pull Request API 이벤트 스트림 또는 웹훅에서 수집합니다. 이벤트 작업은 'review_requested'입니다.
기록
Pull request의 'review_requested' 작업을 수신합니다.
이벤트 유형
explicit
|
|||
|
리뷰에서 수정 요청
|
리뷰어가 코드 리뷰를 마친 뒤 pull request를 승인하기 전에 수정이 필요하다고 판단했습니다. 리뷰어는 'request_changes' 상태로 리뷰를 공식 제출합니다. | ||
|
중요한 이유
이 이벤트는 재작업이 발생했음을 명확히 나타냅니다. 발생 빈도를 분석하면 품질 문제, 불명확한 요구 사항 또는 개발자 교육이 필요한 영역을 찾을 수 있습니다.
확보 방법
리뷰가 'CHANGES_REQUESTED' 상태로 제출되면 GitHub Pull Request API 또는 웹훅에서 수집합니다.
기록
'CHANGES_REQUESTED' 상태인 pull request 리뷰 제출 이벤트를 필터링합니다.
이벤트 유형
explicit
|
|||
|
배포 성공
|
스테이징이나 프로덕션과 같은 특정 환경에 코드 변경 사항이 성공적으로 배포되었습니다. 보통 GitHub Deployments API를 통해 기록하며, 병합 후 GitHub Action이 배포를 시작하는 경우가 많습니다. | ||
|
중요한 이유
코드가 저장소에서 실제 운영 환경으로 이동했음을 나타냅니다. 아이디어부터 프로덕션까지의 전체 리드 타임을 측정하려면 이 이벤트를 추적해야 합니다.
확보 방법
Deployments API를 통해 수집합니다. 외부 서비스나 GitHub Action이 배포를 생성한 뒤 상태를 'success'로 업데이트합니다.
기록
웹훅으로 배포 상태 이벤트를 모니터링해 상태가 'success'인지 확인합니다.
이벤트 유형
inferred
|
|||
|
브랜치 생성
|
이슈에 대한 실제 개발 작업이 시작되는 시점으로, 개발자가 기본 코드베이스에서 새 브랜치를 만듭니다. 저장소에 새 브랜치가 푸시될 때 명시적으로 기록되는 이벤트이며, 브랜치 이름에 이슈 번호가 포함되는 경우가 많습니다. | ||
|
중요한 이유
계획 단계에서 실제 코딩 단계로 전환되었음을 나타냅니다. 이슈 생성부터 이 이벤트까지 걸린 시간을 측정하면 개발자가 작업을 시작하기까지의 시간과 초기 백로그 지연을 분석할 수 있습니다.
확보 방법
GitHub Git API를 사용하거나 'branch' 유형의 'create' 이벤트를 수신하는 웹훅으로 기록합니다. 일반적으로 'feature/issue-123'과 같은 명명 규칙을 사용해 브랜치 이름을 이슈와 연결해야 합니다.
기록
새 브랜치의 'create' 웹훅 이벤트를 파싱해 해당 이슈와 연결합니다.
이벤트 유형
explicit
|
|||
|
이슈 재개
|
이전에 종료된 이슈가 다시 활성화됩니다. 보통 수정이 충분하지 않았거나 회귀 문제가 발견된 경우입니다. 개발 항목의 수명 주기를 다시 시작하는 명시적 이벤트입니다. | ||
|
중요한 이유
이는 상당한 재작업이 발생했음을 나타내며, 수정 사항이 프로덕션 결함을 막지 못했거나 불완전했을 가능성을 보여줍니다. 발생 빈도를 추적하면 전반적인 소프트웨어 품질을 측정할 수 있습니다.
확보 방법
GitHub Issues API 이벤트 스트림에서 명시적으로 수집되는 이벤트입니다. 이벤트 유형은 'reopened'입니다.
기록
웹훅 또는 API 폴링을 통해 이슈의 'reopened' 이벤트를 수신합니다.
이벤트 유형
explicit
|
|||
데이터 추출 가이드
시작할 준비가 되셨나요?
이 템플릿으로 데이터를 준비하고 소프트웨어 개발 수명 주기 개선을 시작하세요. 비효율을 찾아 릴리스 속도와 원활한 진행을 개선할 수 있습니다.
SDLC 비효율을 찾아 개선하세요
주기 시간을 30% 단축하고 GitHub 개발 프로세스를 효율화하세요.
신용카드 없이 몇 분 만에 설정할 수 있습니다.