누적 흐름, 리드 타임 및 주기 시간 지침

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

CFD(누적 흐름 다이어그램)를 사용하여 시스템을 통한 작업 흐름을 모니터링합니다. 추적할 두 가지 기본 메트릭, 주기 시간 및 리드 타임은 차트에서 추출할 수 있습니다. CFD 차트를 구성하거나 보려면 누적 흐름도 구성을 참조하세요.

또는 대시보드에 리드 타임 및 주기 시간 제어 차트 를 추가할 수 있습니다.

샘플 차트 및 기본 메트릭

연속 흐름 CFD는 린 프로세스를 따르는 팀이 가장 선호하는 차트를 제공합니다.

그러나 많은 팀이 스크럼 또는 다른 방법론과 린 관행을 결합하기 시작했습니다. 이는 반복 또는 스프린트의 범위 내에서 린 연습을 한다는 것을 의미합니다. 이 경우 다이어그램은 약간 다른 모양을 취하고 다음 차트에 표시된 것처럼 두 가지 추가 정보 및 매우 중요한 정보를 제공합니다.

연속 흐름

여기에 표시된 고정 기간 CFD는 완료된 스프린트를 위한 것입니다.

위쪽 줄은 스프린트에 대한 범위 집합을 나타냅니다. 또한 스프린트의 마지막 날까지 작업을 완료해야 하므로 닫힌 상태의 기울기는 팀이 스프린트를 완료하기 위해 궤도에 있는지 여부를 나타냅니다. 이 보기를 생각하는 가장 쉬운 방법은 번업 차트입니다.

데이터는 항상 프로세스의 첫 번째 단계를 왼쪽 위로 표시하고 프로세스의 마지막 단계를 오른쪽 아래로 표시합니다.

완료된 스프린트에 대한 고정 기간 CFD

차트 메트릭

CFD 차트는 시간에 따라 상태/Kanban 열별로 그룹화된 작업 항목 수를 표시합니다. 추적할 두 가지 기본 메트릭, 주기 시간 및 리드 타임은 차트에서 추출할 수 있습니다.

---

메트릭

정의

---

주기 시간¹

단일 프로세스 또는 워크플로 상태를 통해 작업을 이동하는 데 걸리는 시간을 측정합니다. 계산은 한 프로세스의 시작부터 다음 프로세스의 시작까지입니다.

리드 타임¹

연속 흐름 프로세스의 경우: 요청이 완료될 때까지(예: 제안된 사용자 스토리 추가) 요청이 완료될 때까지 걸리는 시간을 측정합니다(닫힘).

스프린트 또는 고정 기간 프로세스의 경우: 요청 작업이 시작되는 시점부터 작업이 완료될 때까지의 시간(예: 활성에서 닫힌 시간)을 측정합니다.

진행 중인 작업

현재 작업 중인 작업량 또는 작업 항목 수를 측정합니다.

범위

지정된 기간 동안 커밋된 작업의 양을 나타냅니다. 고정 기간 프로세스에만 적용됩니다.

---

¹ CFD 위젯(분석) 및 기본 제공 CFD 차트(작업 추적 데이터 저장소)는 리드 타임 및 주기 시간에 불연속 숫자를 제공하지 않습니다. 그러나 리드 타임 및 주기 시간 위젯 은 이러한 숫자를 제공합니다.

리드 타임/주기 시간과 WIP(진행 중인 작업 시간) 간에는 잘 정의된 상관 관계가 있습니다. WIP가 많을수록 주기 시간이 길어져 리드 타임이 길어집니다. 그 반대의 경우도 마찬가지입니다. WIP가 적을수록 주기와 리드 타임이 짧아집니다. 개발 팀은 더 적은 항목에 초점을 맞추면 주기 및 리드 타임을 줄입니다. 이 상관 관계는 Kanban 보드에서 진행 중인 작업 제한을 설정할 수 있고 설정해야 하는 주요 이유입니다.

작업 항목 수는 지정된 날짜의 총 작업량을 나타냅니다. 고정 기간 CFD에서 이 수의 변경은 지정된 기간의 범위 변경을 나타냅니다. 연속 흐름 CFD에서는 큐의 총 작업량을 나타내며 지정된 날짜 동안 완료되었습니다.

특정 Kanban 보드 열로 작업을 분해하면 작업이 처리 중인 위치를 볼 수 있습니다. 이 보기는 작업이 원활하게 진행되는 위치, 막힘이 있는 위치 및 작업이 전혀 수행되지 않는 위치에 대한 인사이트를 제공합니다. 데이터의 테이블 형식 보기를 해독하기는 어렵지만 시각적 CFD 차트는 특정 방식으로 어떤 일이 일어나고 있다는 증거를 제공합니다.

문제를 식별하고 적절한 조치를 취합니다.

CFD는 몇 가지 특정 질문에 답변하고 답변에 따라 시스템을 통해 작업을 이동하는 프로세스를 조정하기 위해 조치를 취할 수 있습니다. 여기에서 이러한 각 질문을 살펴보겠습니다.

팀이 정시에 작업을 완료할 수 있나요?

이 질문은 고정 기간 CFD에만 적용됩니다. Kanban 보드의 마지막 열에서 작업의 곡선(또는 진행률)을 확인하여 이해할 수 있습니다.

이 시나리오에서는 안정적인 속도로 작업이 충분히 빨리 완료되지 않는 것이 분명한 경우 반복 작업 범위를 줄이는 것이 적절할 수 있습니다. 작업이 과소 평가되었으며 다음 스프린트 계획에 고려되어야 함을 나타낼 수 있습니다.

그러나 차트에서 다른 데이터를 확인하여 확인할 수 있는 다른 이유가 있을 수 있습니다.

작업 흐름은 어떻게 진행되고 있나요?

팀이 꾸준한 속도로 작업을 완료하고 있습니까? 한 가지 방법은 차트에서 서로 다른 열 사이의 간격을 살펴보는 것입니다. 처음부터 끝까지 서로 비슷하거나 균일한 거리인가요? 열이 며칠에 걸쳐 평선으로 표시됩니까? 아니면 "부풀어 오른" 것 같습니까?

평평한 선과 부푼 것에 대한 마른 용어인 무라(Mura)는 고르지함을 의미하며 시스템의 폐기물(Muda)의 형태를 나타냅니다. 시스템의 고르지 못한 경우 CFD에 부푼 것이 나타납니다.

CFD에서 플랫 라인 및 부푼 부분을 모니터링하면 제약 조건 이론 프로젝트 관리 프로세스의 핵심 부분이 지원됩니다. 시스템의 가장 느린 영역을 보호하는 것은 드럼 버퍼 로프 프로세스라고하며 작업 계획 방법의 일부입니다.

두 가지 문제가 시각적으로 평면 선과 부푼 것으로 표시됩니다.

팀이 정기적인 주기로 작업을 업데이트하지 않으면 플랫 라인이 나타납니다. Kanban 보드는 작업을 한 열에서 다른 열로 전환하는 가장 빠른 방법을 제공합니다.
하나 이상의 프로세스에서 작업이 계획보다 오래 걸리는 경우에도 플랫 라인이 나타날 수 있습니다. 시스템의 한 부분이나 시스템의 두 부분만 문제가 있는 경우 부푼 부분이 표시되므로 시스템의 여러 부분에 플랫 라인이 나타납니다.

플랫 라인

작업이 시스템의 한 부분에서 빌드되고 프로세스를 거치지 않을 때 벌지가 발생합니다.
예를 들어 개발이 더 짧은 시간이 걸리는 동안 테스트에 오랜 시간이 걸리는 경우 부푼 것이 발생할 수 있습니다. 이로 인해 개발 상태에서 작업이 누적됩니다(부푼 단계는 반드시 부푼 단계가 아닌 문제가 있음을 나타낸다).

Bulges

흐름 문제를 해결하려면 어떻게 해야 하나요?

다음을 통해 시기 적절한 업데이트 부족 문제를 해결할 수 있습니다.

• 매일 스탠드업.
• 기타 정기 모임.
• 매일 팀 미리 알림 전자 메일을 예약합니다.

이러한 문제는 드물지만 전신 플랫 라인 문제는 더 어려운 문제를 나타냅니다. 플랫 라인은 시스템 전체의 작업이 중지되었음을 나타냅니다. 기본 원인은 다음과 같습니다.

• 프로세스 차원의 막힘.
• 시간이 오래 걸리는 프로세스입니다.
• 보드에 캡처되지 않은 다른 기회로 전환하는 작업.

시스템 플랫 라인의 한 가지 예는 CFD 기능으로 발생할 수 있습니다. 기능은 여러 스토리로 구성되므로 기능 작업은 사용자 스토리에서 작업하는 것보다 훨씬 더 오래 걸릴 수 있습니다. 이러한 상황에서는 위의 예제와 같이 기울기 또는 문제가 잘 알려져 있으며 팀에서 이미 문제로 제기되고 있습니다. 알려진 문제인 경우 문제 해결은 이 문서의 범위를 벗어납니다.

팀은 CFD 부푼 것으로 표시되는 문제를 사전에 해결할 수 있습니다. 팽창이 발생하는 위치에 따라 수정 사항이 다를 수 있습니다. 예를 들어 개발 프로세스에서 부푼 것이 발생한다고 가정해 보겠습니다. 테스트 실행이 코드 작성보다 훨씬 오래 걸리기 때문에 부푼 일이 발생할 수 있습니다. 테스터는 많은 수의 버그를 찾을 수도 있습니다. 지속적으로 작업을 개발자에게 다시 전환하면 개발자는 증가하는 활성 작업 목록을 상속합니다.

이 문제를 해결할 수 있는 두 가지 방법은 다음과 같습니다. 1) 개발자를 개발 프로세스에서 테스트 프로세스로 이동하거나 부푼 것이 제거될 때까지 또는 2) 신속하게 수행할 수 있는 작업 순서를 변경하면 작업이 더 오래 걸리는 작업과 결합됩니다. 부푼 것을 제거하는 간단한 솔루션을 찾습니다.

참고 항목

여러 시나리오가 발생하여 작업이 고르지 않게 진행될 수 있으므로 문제의 실제 분석을 수행하는 것이 중요합니다. CFD는 문제가 있고 대략적인 위치를 알려 주지만 근본 원인을 파악하려면 조사해야 합니다. 여기에 제공된 지침은 특정 문제를 해결하지만 상황에 적용되지 않을 수 있는 권장 작업을 나타냅니다.

범위가 변경했나요?

범위 변경은 고정 기간 CFD에만 적용됩니다. 차트의 위쪽 줄은 작업 범위를 나타냅니다. 스프린트는 첫 날에 수행할 작업과 함께 미리 로드됩니다. 위쪽 줄의 변경 내용은 작업이 추가되거나 제거되었음을 나타냅니다.

CFD를 사용하여 범위 변경을 추적할 수 없는 한 가지 시나리오는 같은 날 제거된 것과 동일한 수의 작업 항목이 추가될 때 발생합니다. 선은 계속 평평할 것입니다. 여러 차트를 서로 비교합니다. 특정 문제를 모니터링합니다. 보기/구성 스프린트 번다운을 사용하여 범위 변경 내용을 모니터링합니다.

WIP가 너무 많나요?

WIP 제한이 Kanban 보드에서 초과되었는지 여부를 쉽게 모니터링할 수 있습니다. CFD에서 모니터링할 수도 있습니다.

많은 양의 WIP는 일반적으로 수직 부푼 것으로 표시됩니다. WIP가 많을수록 팽창이 타원으로 확장됩니다. WIP가 주기 및 리드 타임에 부정적인 영향을 미치고 있음을 나타냅니다.

다음은 진행 중인 작업에 대한 좋은 엄지 손가락 규칙입니다. 지정된 시간에 팀 구성원당 진행 중인 항목이 두 개 이상 없어야 합니다. 두 항목과 엄격한 제한에 대한 기본 이유는 현실이 소프트웨어 개발 프로세스에 자주 침입하기 때문입니다.

때로는 이해 관계자로부터 정보를 얻는 데 시간이 걸리거나 필요한 소프트웨어를 획득하는 데 더 많은 시간이 걸립니다. 작업이 중단될 수 있는 여러 가지 이유가 있습니다. 피벗할 두 번째 작업 항목이 있으면 약간의 여유를 제공합니다. 두 항목이 모두 차단되면 다른 항목으로 전환하는 것이 아니라 차단 해제된 항목을 가져오기 위해 빨간색 플래그를 발생해야 합니다. 많은 수의 항목이 진행 중인 즉시 해당 항목에서 작업하는 사람은 컨텍스트 전환에 어려움을 겪게 됩니다. 그들이 하고 있던 일을 잊어버릴 가능성이 높으며 실수가 발생할 수 있습니다.

리드 타임 및 주기 시간

아래 다이어그램에서는 리드 타임이 주기 시간과 어떻게 다른지 보여 줍니다. 리드 타임은 작업 항목 만들기부터 완료됨 상태 입력까지 계산됩니다. 주기 시간은 진행 중 또는 해결됨 상태 범주를 처음 입력하는 것부터 완료된 상태 범주를 입력하는 것까지 계산됩니다.

리드 타임 및 주기 시간 그림

작업 항목이 완료됨 상태로 전환된 다음 다시 활성화되는 경우 제안된 상태, 진행 중 또는 해결됨 상태에서 소요되는 추가 시간은 완료된 상태 범주에 두 번째로 들어갈 때 리드/주기 시간에 영향을 줍니다.

팀에서 Kanban 보드를 사용하는 경우 Kanban 열이 워크플로 상태에 매핑되는 방식을 이해하려고 합니다. Kanban 보드를 구성하는 방법에 대한 자세한 내용은 열 추가를 참조 하세요.

시스템에서 상태 범주(제안됨, 진행 중, 해결됨 및 완료됨)를 사용하는 방법에 대한 자세한 내용은 워크플로 상태 및 상태 범주를 참조 하세요.

잠재 고객/주기 시간에 따라 예상 배달 시간 사용 계획

평균 잠재 고객/주기 시간 및 표준 편차를 사용하여 배달 시간을 예측할 수 있습니다.

작업 항목을 만들 때 팀의 평균 리드 타임을 사용하여 팀이 해당 작업 항목을 완료할 시기를 예측할 수 있습니다. 팀의 표준 편차는 예측값의 가변성을 알려줍니다. 마찬가지로, 주기 시간과 표준 편차를 사용하여 작업이 시작된 후 작업 항목의 완료를 예측할 수 있습니다.

다음 차트에서 평균 주기 시간은 8일입니다. 표준 편차는 +/- 6일입니다. 이 데이터를 사용하면 팀이 작업을 시작한 후 약 2~14일 후에 향후 사용자 스토리를 완료할 것으로 예상할 수 있습니다. 표준 편차가 좁을수록 예측 가능한 예측이 가능합니다.

주기 시간 위젯 예제

프로세스 문제 식별

이상값에 대한 팀의 컨트롤 차트를 검토합니다. 이상값은 종종 기본 프로세스 문제를 나타냅니다. 예를 들어 PR 검토를 완료하는 데 너무 오래 기다리거나 외부 종속성을 신속하게 해결하지 않습니다.

여러 이상값을 보여 있는 다음 차트에서 볼 수 있듯이 여러 버그가 팀 평균보다 완료하는 데 더 오래 걸렸습니다. 이러한 버그가 더 오래 걸린 이유를 조사하면 프로세스 문제를 파악하는 데 도움이 될 수 있습니다. 프로세스 문제를 해결하면 팀의 표준 편차를 줄이고 팀의 예측 가능성을 개선하는 데 도움이 될 수 있습니다.

여러 이상값을 보여 주는 예제 주기 시간 위젯

프로세스 변경이 잠재 고객 및 주기 시간에 미치는 영향을 확인할 수도 있습니다. 예를 들어 5월 15일에 팀은 WIP를 제한하고 부실 버그를 해결하기 위해 공동으로 노력했습니다. 표준 편차가 해당 날짜 이후의 범위를 좁혀 향상된 예측 가능성을 보여 주는 것을 볼 수 있습니다.

다음 단계

누적 흐름 차트 구성 또는 리드 타임 또는 주기 시간 차트 구성