요약: 애자일 메트릭은 소프트웨어 개발 수명 주기의 여러 단계를 통해 생산성에 대한 인사이트를 제공합니다. 제품의 품질을 평가하고 팀 성과를 추적할 수 있습니다.
메트릭은 민감한 주제입니다.
한편으로 우리는 어떤 종류의 데이터도 추적되지 않는 프로젝트를 진행해 왔으며, 우리가 릴리스할 수 있을지 아니면 점점 더 효율성이 늘어나는지 알기가 어려웠습니다. 반면에 대다수는 통계가 무기로 사용되거나 한 팀을 다른 팀과 대결시키거나 의무적인 주말 작업을 정당화하는 프로젝트에 참여하는 불행을 겪었습니다. 따라서 대부분의 팀이 메트릭과 애증의 관계를 맺고 있는 것도 놀라운 일은 아닙니다.
하지만 반드시 이럴 필요는 없습니다. 건전한 애자일 메트릭을 추적하고 공유하면 혼란을 줄이고 개발 주기 전반에 걸쳐 팀의 진행률 및 장애를 밝힐 수 있습니다. 그 방법을 소개합니다.
비즈니스 파악
"완료"는 스토리의 절반만 알려줍니다. 이것은 적절한 시장에 적절한 제품을 적시에 구축하는 것입니다. 프로그램 전반에 걸쳐 궤도를 유지한다는 것은 그 과정에서 관련 데이터를 수집하고 분석하는 것을 의미합니다. 모든 애자일 프로그램에서는 비즈니스 메트릭과 애자일 메트릭을 모두 추적하는 것이 중요합니다. 비즈니스 메트릭은 솔루션이 시장 요구를 충족하는지에 초점을 맞추고 애자일 메트릭은 개발 프로세스의 측면을 측정합니다.
"프로그램의 비즈니스 메트릭은 로드맵에 뿌리를 두어야 합니다."
로드맵의 각 이니셔티브에 대해 프로그램의 목표에 매핑되는 몇 가지 핵심 성과 지표(KPI)를 포함합니다. 또한 최종 사용자의 도입률 또는 자동화된 테스트에서 다루는 코드의 비율과 같은 각 제품 요구 사항에 대한 성공 기준을 포함합니다. 이 성공 기준은 프로그램의 애자일 메트릭에 입력됩니다. 팀은 더 많이 배울수록 더 잘 적응하고 발전할 수 있습니다.
애자일 KPI 메트릭을 사용하여 제공을 최적화하는 방법
스프린트 번다운 차트
스크럼 팀은 개발을 시간이 정해진 스프린트로 구성합니다. 스프린트가 처음 시작될 때 팀은 스프린트 중에 완료할 수 있는 작업의 양을 예측합니다. 그런 다음 스프린트 번다운 차트 보고서는 스프린트 전체에 걸쳐 작업 완료를 추적합니다. x축은 시간을 나타내고 y축은 스토리 포인트 또는 시간으로 측정된 완료까지 남은 작업량을 나타냅니다. 목표는 스프린트가 끝날 때까지 모든 예측 작업을 완료하는 것입니다.
지속적으로 예측을 충족하는 팀은 조직의 애자일에 대한 매력적인 광고입니다. 그러나 항목이 실제로 완료되기도 전에 완료되었다고 선언하여 숫자를 얼버무리려는 유혹에 넘어가지 마세요. 단기적으로는 좋아 보일 수 있지만 장기적으로는 학습과 개선을 방해할 뿐입니다.
- 팀은 충분한 작업에 커밋하지 않기 때문에 스프린트 후 초기 스프린트를 완료합니다.
- 팀은 너무 많은 작업에 커밋하기 때문에 스프린트 후 예측 스프린트를 놓치고 있습니다.
- 번다운 차트 라인은 작업이 세부적인 작업으로 분할되지 않았기 때문에 점진적인 번다운 차트가 아닌 가파른 하락으로 이어집니다.
- 제품 소유자가 스프린트 중에 범위를 추가하거나 변경합니다.
에픽 및 릴리스 번다운
에픽 및 릴리스(또는 버전) 번다운 차트는 스프린트 번다운 차트보다 더 큰 작업에 대한 개발 진행률을 추적하고 스크럼 팀과 칸반 팀 모두의 개발을 안내합니다. 스크럼 팀의 경우 스프린트에는 여러 에픽 및 버전의 작업이 포함될 수 있으므로 개별 스프린트의 진행률과 에픽 및 버전을 모두 추적하는 것이 중요합니다.
"범위 초과"는 이전에 정의한 프로젝트에 더 많은 요구 사항을 주입하는 것입니다. 예를 들어 팀이 회사에 새 웹사이트를 제공하는 경우 범위 초과는 초기 요구 사항이 스케치된 후 새로운 기능을 요청합니다. 스프린트 중에 범위 초과를 허용하는 것은 나쁜 관행이지만 에픽 및 버전 내의 범위 변경은 애자일 개발의 자연스러운 결과입니다. 팀이 프로젝트를 진행하면서 제품 소유자는 학습 내용에 따라 작업을 진행하거나 제거하기로 결정할 수 있습니다. 에픽 및 릴리스 번다운 차트를 통해 모두가 에픽 및 버전 내에서 작업의 흐름을 알 수 있습니다.
- 팀이 작업을 진행하는 동안 에픽 또는 릴리스 예측은 업데이트되지 않습니다.
- 여러 번 반복된 기간에 진행이 이루어지지 않습니다.
- 만성 범위 초과는 제품 소유자가 작업을 통해 해결하려는 문제를 완전히 이해하지 못한다는 신호일 수 있습니다.
- 범위는 팀이 흡수할 수 있는 것보다 빠르게 증가합니다.
- 팀은 에픽 개발 전반에 걸쳐 증분 릴리스를 제공하지 않습니다.
속도
속도는 스크럼 팀이 스프린트 중에 완료하는 평균 작업량으로, 스토리 포인트 또는 시간 단위로 측정되며 예측에 매우 유용합니다. 제품 소유자는 속도를 사용하여 팀이 백로그를 얼마나 빨리 처리할 수 있는지 예측할 수 있습니다. 보고서는 여러 반복에 걸쳐 예측 및 완료된 작업을 추적하므로 반복 횟수가 많을수록 예측이 더 정확해집니다.
제품 소유자가 백로그에서 500개의 스토리포인트를 완료하려고 한다고 가정해 봅시다. 개발 팀은 일반적으로 반복당 50개의 스토리 포인트를 완료한다는 것을 알고 있습니다. 제품 소유자는 팀이 필요한 작업을 완료하는 데 10번의 반복(주기 또는 받기)이 필요하다고 합리적으로 가정할 수 있습니다.
시간이 지나면서 속도가 어떻게 진화하는지 모니터링하는 것이 중요합니다. 팀이 관계와 작업 프로세스를 최적화하면 새로운 팀은 속도가 빨라질 것으로 기대할 수 있습니다. 기존 팀은 속도를 추적하여 시간이 지나면서 일관된 성과를 보장하고 특정 프로세스 변경으로 인한 개선 여부를 확인할 수 있습니다. 평균 속도 감소는 일반적으로 팀 개발 프로세스의 일부가 비효율적이므로 다음 회고에서 검토해야 한다는 신호입니다.
속도가 장기간에 걸쳐 불규칙할 경우 항상 팀의 추정 관행을 다시 확인하세요. 팀의 회고를 진행하는 동안 다음과 같이 질문합니다.
- 이 작업을 추정할 때 설명하지 않은 예상치 못한 개발 과제가 있습니까? 작업을 어떻게 더 잘 분할하면 이 과제 중 일부를 발견할 수 있습니까?
- 팀이 한계를 넘어서게 하는 외부 비즈니스 압박이 있습니까? 결과적으로 개발 모범 사례를 준수하는 데 어려움을 겪고 있습니까?
- 팀으로서 우리가 스프린트 예측에 지나치게 열성적입니까?
각 팀의 속도는 고유합니다. 팀 A의 속도가 50이고 팀 B의 속도가 75라고 해서 팀 B의 처리량이 더 높다는 의미는 아닙니다. 각 팀의 추정 문화는 고유하기 때문에 속도도 마찬가지입니다. 팀 간 속도를 비교하려는 유혹에 저항하세요. 각 팀의 고유한 스토리 포인트 해석을 기반으로 노력 수준과 작업 결과를 측정합니다.
컨트롤 차트
컨트롤 차트는 개별 이슈의 사이클 타임, 즉 "진행 중"부터 "완료"까지의 총 시간에 중점을 둡니다. 사이클 타임이 짧은 팀은 처리량이 더 많을 가능성이 크며 많은 이슈에서 일관된 사이클 타임을 가진 팀은 작업 제공에 있어 예측 가능성이 더 높습니다. 사이클 타임은 칸반 팀의 기본 메트릭이지만 스크럼 팀도 최적화된 사이클 타임의 장점을 누릴 수 있습니다.
사이클 타임 측정은 변경 결과를 거의 즉시 식별할 수 있기 때문에 즉시 추가 조정을 수행할 수 있으므로 팀의 프로세스를 개선하는 효율적이고 유연한 방법입니다. 최종 목표는 작업 유형(새로운 기능, 기술적 부채 등)과 관계없이 일관되고 짧은 사이클 타임을 갖는 것입니다.
컨트롤 차트는 처음에는 변덕스러워 보일 수 있습니다. 모든 이상값에 너무 신경 쓰지 마세요. 추세를 찾아보세요. 조심해야 할 두 가지 영역은 다음과 같습니다.
- 사이클 타임 증가 - 사이클 타임을 늘리면 팀이 힘들게 얻은 민첩성이 약해집니다. 팀 회고에서 시간을 내어 사이클 타임 증가를 이해하세요. 단, 예외적으로 팀의 완료 정의가 확장되면 사이클 타임도 확장됩니다.
- 불규칙한 사이클 타임 — 목표는 유사한 스토리 포인트 값을 가진 작업 항목에 대해 일관된 사이클 타임을 유지하는 것입니다. 각 스토리 포인트 값에 대한 컨트롤 차트를 필터링하여 일관성을 확인합니다. 크고 작은 스토리 포인트 값에서 사이클 타임이 불규칙한 경우 회고에서 누락을 조사하고 향후 추정치를 개선하는 데 시간을 할애하세요.
누적 흐름도
누적 흐름 다이어그램은 왼쪽에서 오른쪽으로 갈수록 부드러워 보일 것입니다. 한 색상의 거품이나 격차는 부족과 병목 현상을 나타내므로 하나가 보이면 차트에서 색상 밴드를 매끄럽게 만들 방법을 찾으세요.
- 차단 이슈로 인해 프로세스의 일부 부분에서는 대규모 백업이 만들어지고 다른 부분에서는 극도로 부족한 현상이 발생합니다.
- 시간 경과에 따른 백로그 증가를 확인하지 않았습니다. 제품 소유자가 더 이상 사용되지 않거나 우선 순위가 너무 낮아서 가져올 수 없는 이슈를 종료하지 않았기 때문입니다.
더 많은 메트릭
좋은 메트릭은 위에서 논의한 보고서에만 국한되지 않습니다. 예를 들어 품질은 애자일 팀에 중요한 메트릭이며 애자일 개발에 적용할 수 있는 기존 메트릭은 여러 가지가 있습니다.
- 발견된 결함 수:
- 개발 중에?
- 고객에게 릴리스한 후에?
- 팀 외부 인력에 의해?
- 향후 릴리스로 연기되는 결함은 몇 개입니까?
- 얼마나 많은 고객 지원 요청이 들어오고 있습니까?
- 자동 테스트 커버리지의 비율은 얼마입니까?
애자일 팀은 릴리스 빈도와 제공 속도도 고려해야 합니다. 각 스프린트가 끝날 때마다 팀은 소프트웨어를 프로덕션으로 릴리스해야 합니다. 실제로 얼마나 자주 일어납니까? 대부분의 릴리스 빌드가 제공됩니까? 같은 맥락에서 팀이 긴급 수정 사항을 프로덕션에 릴리스하는 데 얼마나 걸립니까? 팀에 릴리스는 쉽습니까, 아니면 투지가 필요합니까?
컨텍스트에서 인사이트 찾기
Insight는 팀이 필요할 때 메트릭에 액세스할 수 있는 유용한 도구입니다. 스프린트 계획, 일일 스탠드업 시 체크인 또는 제공 최적화 중에 메트릭에 액세스할 수 있습니다. Jira 보드, 백로그 및 배포 보기의 오른쪽 상단에서 Insight를 찾을 수 있습니다.
인사이트는 다음 메트릭의 시각적 스냅샷을 제공합니다.
- 스프린트 진행률
- 이슈 유형 분석
- 스프린트 이행 약속
- 배포 빈도
- 사이클 타임
이 메트릭을 사용하여 팀 성과를 지속적으로 최적화합니다. Insight에 대해 자세히 알아봅니다.
결론...
애자일 메트릭 및 KPI는 팀 문화 구축의 일부일 뿐입니다. 팀의 성과에 대한 정량적 인사이트를 제공하고 팀에 측정 가능한 목표를 제공합니다. 메트릭은 중요하지만 집착하지는 마세요. 회고 중에 팀의 피드백을 경청하는 것은 팀 전체의 신뢰, 제품의 품질 및 릴리스 프로세스를 통한 개발 속도를 높이는 데 똑같이 중요합니다. 양적 피드백 및 질적 피드백을 모두 사용하여 변화를 주도하세요.
관련 리소스
