인기 있는 5가지 애자일 KPI 메트릭

요약: 애자일 메트릭은 소프트웨어 개발 수명 주기의 여러 단계를 통해 생산성에 대한 인사이트를 제공합니다. 제품의 품질을 평가하고 팀 성과를 추적할 수 있습니다.

메트릭은 민감한 주제입니다.

한편으로 우리는 어떤 종류의 데이터도 추적되지 않는 프로젝트를 진행해 왔으며, 우리가 릴리스할 수 있을지 아니면 점점 더 효율성이 늘어나는지 알기가 어려웠습니다. 반면에 대다수는 통계가 무기로 사용되거나 한 팀을 다른 팀과 대결시키거나 의무적인 주말 작업을 정당화하는 프로젝트에 참여하는 불행을 겪었습니다. 따라서 대부분의 팀이 메트릭과 애증의 관계를 맺고 있는 것도 놀라운 일은 아닙니다.

하지만 반드시 이럴 필요는 없습니다. 건전한 애자일 메트릭을 추적하고 공유하면 혼란을 줄이고 개발 주기 전반에 걸쳐 팀의 진행률 및 장애를 밝힐 수 있습니다. 방법은 다음과 같습니다.

"완료"는 스토리의 절반만 알려줍니다. 이것은 적절한 시장에 적절한 제품을 적시에 구축하는 것입니다. 프로그램 전반에 걸쳐 궤도를 유지한다는 것은 그 과정에서 관련 데이터를 수집하고 분석하는 것을 의미합니다. 모든 애자일 프로그램에서는 비즈니스 메트릭과 애자일 메트릭을 모두 추적하는 것이 중요합니다. 비즈니스 메트릭은 솔루션이 시장 요구를 충족하는지에 초점을 맞추고 애자일 메트릭은 개발 프로세스의 측면을 측정합니다.

로드맵의 각 이니셔티브에 대해 프로그램의 목표에 매핑되는 몇 가지 핵심 성과 지표(KPI)를 포함합니다. 또한 최종 사용자의 도입률 또는 자동화된 테스트에서 다루는 코드의 비율과 같은 각 제품 요구 사항에 대한 성공 기준을 포함합니다. 이 성공 기준은 프로그램의 애자일 메트릭에 입력됩니다. 팀은 더 많이 배울수록 더 잘 적응하고 발전할 수 있습니다.

스크럼 팀은 개발을 시간이 정해진 스프린트로 구성합니다. 스프린트가 처음 시작될 때 팀은 스프린트 중에 완료할 수 있는 작업의 양을 예측합니다. 그런 다음 스프린트 번다운 차트 보고서는 스프린트 전체에 걸쳐 작업 완료를 추적합니다. x축은 시간을 나타내고 y축은 스토리 포인트 또는 시간으로 측정된 완료까지 남은 작업량을 나타냅니다. 목표는 스프린트가 끝날 때까지 모든 예측 작업을 완료하는 것입니다.

지속적으로 예측을 충족하는 팀은 조직의 애자일에 대한 매력적인 광고입니다. 그러나 항목이 실제로 완료되기도 전에 완료되었다고 선언하여 숫자를 얼버무리려는 유혹에 넘어가지 마세요. 단기적으로는 좋아 보일 수 있지만 장기적으로는 학습과 개선을 방해할 뿐입니다.

Jira에서 번다운 차트를 사용하는 방법 알아보기

에픽 및 릴리스(또는 버전) 번다운 차트는 스프린트 번다운 차트보다 더 큰 작업에 대한 개발 진행률을 추적하고 스크럼 팀과 칸반 팀 모두의 개발을 안내합니다. 스크럼 팀의 경우 스프린트에는 여러 에픽 및 버전의 작업이 포함될 수 있으므로 개별 스프린트의 진행률과 에픽 및 버전을 모두 추적하는 것이 중요합니다.

"범위 초과"는 이전에 정의한 프로젝트에 더 많은 요구 사항을 주입하는 것입니다. 예를 들어 팀이 회사에 새 웹사이트를 제공하는 경우 범위 초과는 초기 요구 사항이 스케치된 후 새로운 기능을 요청합니다. 스프린트 중에 범위 초과를 허용하는 것은 나쁜 관행이지만 에픽 및 버전 내의 범위 변경은 애자일 개발의 자연스러운 결과입니다. 팀이 프로젝트를 진행하면서 제품 소유자는 학습 내용에 따라 작업을 진행하거나 제거하기로 결정할 수 있습니다. 에픽 및 릴리스 번다운 차트를 통해 모두가 에픽 및 버전 내에서 작업의 흐름을 알 수 있습니다.

속도는 스크럼 팀이 스프린트 중에 완료하는 평균 작업량으로, 스토리 포인트 또는 시간 단위로 측정되며 예측에 매우 유용합니다. 제품 소유자는 속도를 사용하여 팀이 백로그를 얼마나 빨리 처리할 수 있는지 예측할 수 있습니다. 보고서는 여러 반복에 걸쳐 예측 및 완료된 작업을 추적하므로 반복 횟수가 많을수록 예측이 더 정확해집니다.

제품 소유자가 백로그에서 500개의 스토리포인트를 완료하려고 한다고 가정해 봅시다. 개발 팀은 일반적으로 반복당 50개의 스토리 포인트를 완료한다는 것을 알고 있습니다. 제품 소유자는 팀이 필요한 작업을 완료하는 데 10번의 반복(주기 또는 받기)이 필요하다고 합리적으로 가정할 수 있습니다.

시간이 지나면서 속도가 어떻게 진화하는지 모니터링하는 것이 중요합니다. 팀이 관계와 작업 프로세스를 최적화하면 새로운 팀은 속도가 빨라질 것으로 기대할 수 있습니다. 기존 팀은 속도를 추적하여 시간이 지나면서 일관된 성과를 보장하고 특정 프로세스 변경으로 인한 개선 여부를 확인할 수 있습니다. 평균 속도 감소는 일반적으로 팀 개발 프로세스의 일부가 비효율적이므로 다음 회고에서 검토해야 한다는 신호입니다.

각 팀의 속도는 고유합니다. 팀 A의 속도가 50이고 팀 B의 속도가 75라고 해서 팀 B의 처리량이 더 높다는 의미는 아닙니다. 각 팀의 추정 문화는 고유하기 때문에 속도도 마찬가지입니다. 팀 간 속도를 비교하려는 유혹에 저항하세요. 각 팀의 고유한 스토리 포인트 해석을 기반으로 노력 수준과 작업 결과를 측정합니다.

컨트롤 차트는 개별 이슈의 사이클 타임, 즉 "진행 중"부터 "완료"까지의 총 시간에 중점을 둡니다. 사이클 타임이 짧은 팀은 처리량이 더 많을 가능성이 크며 많은 이슈에서 일관된 사이클 타임을 가진 팀은 작업 제공에 있어 예측 가능성이 더 높습니다. 사이클 타임은 칸반 팀의 기본 메트릭이지만 스크럼 팀도 최적화된 사이클 타임의 장점을 누릴 수 있습니다.

사이클 타임 측정은 변경 결과를 거의 즉시 식별할 수 있기 때문에 즉시 추가 조정을 수행할 수 있으므로 팀의 프로세스를 개선하는 효율적이고 유연한 방법입니다. 최종 목표는 작업 유형(새로운 기능, 기술적 부채 등)과 관계없이 일관되고 짧은 사이클 타임을 갖는 것입니다.

누적 흐름 다이어그램은 왼쪽에서 오른쪽으로 갈수록 부드러워 보일 것입니다. 한 색상의 거품이나 격차는 부족과 병목 현상을 나타내므로 하나가 보이면 차트에서 색상 밴드를 매끄럽게 만들 방법을 찾으세요.

좋은 메트릭은 위에서 논의한 보고서에만 국한되지 않습니다. 예를 들어 품질은 애자일 팀에 중요한 메트릭이며 애자일 개발에 적용할 수 있는 기존 메트릭은 여러 가지가 있습니다.

• 발견된 결함 수:
  • 개발 중에?
  • 고객에게 릴리스한 후에?
  • 팀 외부 인력에 의해?
• 향후 릴리스로 연기되는 결함은 몇 개입니까?
• 얼마나 많은 고객 지원 요청이 들어오고 있습니까?
• 자동 테스트 커버리지의 비율은 얼마입니까?

애자일 팀은 릴리스 빈도와 제공 속도도 고려해야 합니다. 각 스프린트가 끝날 때마다 팀은 소프트웨어를 프로덕션으로 릴리스해야 합니다. 실제로 얼마나 자주 일어납니까? 대부분의 릴리스 빌드가 제공됩니까? 같은 맥락에서 팀이 긴급 수정 사항을 프로덕션에 릴리스하는 데 얼마나 걸립니까? 팀에 릴리스는 쉽습니까, 아니면 투지가 필요합니까?