애자일 메트릭은 애자일 프로젝트 팀의 진행 상황과 성공을 추적하는 데 사용되는 측정입니다.
올바른 방식으로 정의된 메트릭은 팀의 성능, 품질, 테스트 효율성 또는 전반적인 효율성과 시간이 지남에 따라 어떻게 발전하는지에 대한 통찰력을 제공합니다.
민첩한 지표의 궁극적인 목표는 팀이 개선할 영역을 식별하고 팀이 진행됨에 따라 더 나은 제품으로 이어질 데이터 기반 의사 결정을 내리는 데 도움을 주는 것입니다.
대부분의 경우 회사는 왼쪽에서 오른쪽으로 멋지게 증가하는 허영 메트릭 또는 원시 숫자인 메트릭을 정의합니다. 일부 대시보드에서는 멋지게 보일 수 있지만 일반적으로 팀 자체에는 쓸모가 없습니다.
그들의 목적은 어떤 식으로든 팀을 돕는 것이 아니라 리더십을 위해 보고서를 작성하고 몇 가지 전략적 결정으로 결론을 내리는 것입니다. 불행히도 이 특정 결정이 존재하는 이유를 이해하지 못하는 것은 팀입니다.
이러한 잘못된 메트릭을 이행하기 위한 울타리에서 팀은 메트릭이 좋아 보이도록 자체 프로세스를 속입니다. 그러나 팀의 성과는 전혀 개선되지 않고 있습니다.
목차
기본 메트릭
메트릭을 분리하는 방법에는 여러 가지가 있습니다. 아마도 가장 기본적인 것은 하향식과 상향식일 것입니다.
➡️ 하향식 의미: 우리 리더십은 여러분 모두가 충족하기를 원하는 메트릭을 생성할 것이며 궁극적인 목표는 이러한 녹색 영역에 맞추는 것입니다. 우리는 당신이 팀을 좋아하든 그렇지 않든 상관하지 않습니다. 이것이 우리가 추적하려는 것입니다.
➡️ 상향식 의미: 우리 팀은 이러한 영역에서 개선해야 하며 이를 위해 이러한 사항에 집중해야 합니다. 따라서 우리는 목표를 향한 팀의 진행 상황을 추적할 수 있는 측정 기준을 정의하고 시간이 지남에 따라 작업이 얼마나 정확히 개선되었는지 리더십에 보여줄 수 있습니다.
좋은 지표의 정의
그렇다면 좋은 지표에는 무엇이 포함되어야 하며 어떻게 설명해야 할까요?
가장 중요한 속성은 행동 변화입니다. 즉, 메트릭의 결과를 볼 때마다 개선을 위해 팀 내부에서 변경해야 하는 사항이 분명합니다.
그렇다면 단순해야 합니다. 관련된 모든 청취자가 이해할 수 있도록 몇 개의 간단한 문장으로 설명할 수 없다면 정말 좋지 않은 것입니다.
좋은 메트릭은 시간이 지남에 따라 비교할 수 있습니다. 한 번에 결과 스냅샷을 찍은 다음 나중에 다시 수행하십시오. 나란히 놓으십시오. 두 결과를 서로 비교할 수 없다면 이 메트릭을 다시 생각해야 합니다.
마지막으로 순수한 숫자보다 가능한 한 비율이나 백분율로 만드는 것이 좋습니다. “스프린트 동안 10개의 새로운 공개 결함”은 많은 것을 말해주지 않습니다. 보통 1개냐 100개냐에 따라 다릅니다.
다음은 이러한 모든 정의 기준을 충족한다고 생각되는 메트릭의 몇 가지 예입니다. 그들은 특별히 애자일 팀을 염두에 두고 있습니다. 성능, 품질 및 사기의 세 가지 주요 범주가 있습니다.
메트릭 범주
성능 지표
목표는 팀이 스프린트 내에서 커밋된 스토리를 얼마나 잘 따라잡는지 이해하는 것입니다. 과도한 헌신이 평소와 같은 비즈니스가 아닌지 또는 이월 사례가 스프린트에서 스프린트로의 표준인지 평가합니다.
민첩한 성능 관점에서 팀은 스프린트 시작 시 팀이 커밋한 계획된 스프린트 콘텐츠를 제공하기 위해 노력해야 합니다.
스프린트 중에 이야기를 교환할 때 유연하지 않다는 의미는 아닙니다. 그러나 추가가 아니라 항상 교환으로 이어지는 협상이어야 합니다. 누군가가 스프린트 안에 새로운 이야기를 추가했다고 해서 팀의 역량이 늘어나는 것은 아니다.
우리는 이러한 사례를 살펴보고 팀의 모든 사람이 스프린트에 대한 역량을 보호하도록 안내하기 위해 이 메트릭을 사용합니다.
이것은 팀의 신뢰성과 예측 가능성을 구축합니다.
#1. 스프린트 용량 대 전달된 스토리 포인트
스프린트에 대한 스프린트 용량 대 전달된 스토리 포인트(SP) 콘텐츠의 내역을 확인하십시오.
- 스프린트에서 스프린트로의 작은 편차는 괜찮습니다. 어떤 방향으로든 크게 점프하면 뭔가 꺼져 있다는 신호입니다.
- 총 스프린트 용량 – 한 팀원의 가용일은 총 용량에 1을 더합니다. 예를 들어, 팀에 10명이 있고 그들 모두가 전체 스프린트에서 사용할 수 있는 경우 스프린트의 총 용량은 100입니다.
스프린트에서 스프린트까지 스프린트 용량과 완료된 SP를 확인하십시오. 팀이 (계획하는 동안) 팀이 일반적으로 완료할 수 있는 것보다 훨씬 더 많은 양의 SP를 커밋하는 경우 이 위험을 팀에 높입니다.
목표는 계획된 총 SP가 스프린트당 완료된 총 SP보다 작거나 같아야 합니다.
팀이 계획된 모든 스토리를 완료하고(스프린트가 끝날 무렵) 팀이 여전히 추가 스토리를 수행할 수 있는 용량이 있는 경우 계획보다 더 많은 SP를 완료할 수 있습니다.
- 팀이 계획보다 적은 SP를 반복적으로 제공하는 경우 팀은 계획을 수정하고 다음 스프린트에 더 적은 SP를 가져와야 합니다.
monday.com, Atlassian Jira 또는 Asana와 같은 도구는 모두 스프린트의 각 스토리당 스토리 포인트를 저장하고 추출하는 간단한 방법을 제공합니다. 각 스프린트 계획 후 자동으로 생성할 수도 있습니다.
#2. 번다운 차트
이것은 아마도 대부분의 스크럼 팀이 대시보드 어딘가에 숨긴 지표 중 하나일 것입니다. 나는 이것이 쓸모없는 것으로 보일 수도 있다는 데 동의합니다. 팀에서는 거의 고려하지 않습니다. 오히려 관리자는 높은 수준에서 스토리가 어떻게 보이는지, 그리고 스토리가 어떻게 잘 진행되지 않는지(전체 스프린트에서 모두 공개되기 때문에) 지적하는 것을 좋아합니다.
제가 강조하고 싶은 것은 그럼에도 불구하고 여러분이 팀으로서 번다운 차트를 확인해야 한다는 것입니다. 모든 스토리가 전체 스프린트에서 공개되고 스프린트 마지막 날에만 종료되는 경우 팀 내부와 스프린트 목표 완료에 대한 불확실성이 발생합니다.
- 완성된 스토리에 대한 스프린트 보드를 검토합니다.
- 팀과 함께 작은 이야기가 스프린트 시작 부분에 시작되었음에도 불구하고 여전히 열려 있는 이유를 확인하십시오.
- 이야기를 필요 이상으로 길게 열어 두지 말고 팀과 협력하여 사고 방식을 구축하십시오.
- 이상적인 번다운 차트는 일반적으로 이론적 상태입니다. 그러나 우리가 그것에 가까워질수록 더 효과적인 스토리 처리가 가능해집니다.
Asana와 같은 민첩한 관리 도구는 각 스프린트에 대해 자동으로 번다운 차트를 생성할 수 있습니다.
출처: asana.com
#삼. 스프린트 목표 완료
각 스프린트 동안 완료한 스프린트 목표의 백분율을 추적합니다.
각 스프린트에 대해 Confluence 페이지/Jira와 같이 스프린트 목표를 별도로 문서화합니다. 상태는 스프린트 내에서 충족되었는지 여부에 관계없이 할당됩니다.
팀이 스프린트 내에서 모든 스토리를 완료하지 않았더라도 여전히 스프린트 목표를 달성할 수 있습니다(예: 사이드 스토리만 누락).
우리는 매 스프린트마다 100% 스프린트 목표 달성을 목표로 할 것입니다. 그렇지 않은 경우 팀이 무엇을 방지하고 있는지 알아보십시오.
- 각 스프린트에서 병렬 주제가 너무 많으면 그 양을 줄이십시오.
- 스프린트 중에 임시 스토리가 너무 많이 추가되면 원래 스프린트 목표에 영향을 미치지 않도록 줄이십시오.
- 스프린트 목표가 너무 크거나 도전적이라면 더 간단하게 만드십시오. 어쨌든 스프린트가 끝날 때까지 목표를 달성하지 못한 채 큰 스프린트 목표를 갖는 것은 의미가 없습니다.
코드 품질 지표
이것은 시간이 지남에 따라 코드가 얼마나 좋은지 추적합니다. 건전한 개발 프로세스를 유지하고 문제 해결에 소요되는 시간을 줄이는 데 도움이 됩니다. 또는 개발 및 테스트 활동 중에 코드 실행 대기로 인해 발생하는 개발자의 유휴 시간.
출처: azuredevopslabs.com
#1. 자동화된 테스트
개발자가 수행하는 각 변경 사항에 대해 자동화된 단위 테스트를 만듭니다.
- 자동화된 테스트로 코드 커버리지 측정 – Azure Pipelines 또는 SonarCloud를 사용하여 테스트를 실행합니다. 85% 커버리지를 목표로 합니다. 90% 이상은 실제로 효율적이지 않습니다.
- 자동화된 단위 테스트 생성이 새 스토리에 대한 완료 정의의 일부인지 확인하십시오.
- 백로그에서 기술 부채 이야기의 일부로 이전 코드 테스트 범위를 따라잡으십시오.
#2. 코드 복잡성
시간이 지남에 따라 코드가 얻는 불필요한 합병증을 평가하고 기술 부채 사례를 통해 적극적으로 수정합니다. 또는 가능하면 발생하지 않도록 하십시오.
코드 표준 및 지침을 정의하여 개발자가 이를 따르도록 교육합니다. 코드 복잡성의 비합리적인 증가를 최소화하기 위해 코딩 규칙을 준수하는지 확인하십시오. 팀의 경험을 바탕으로 가이드라인을 정기적으로 업데이트했습니다.
Code Smell 식별 – 중복 코드, 긴 메서드 및 사용되지 않는 변수와 같은 코드의 잠재적인 문제를 나타내는 지표입니다.
피어 리뷰는 코드 표준이 새로 생성된 코드에 적용되도록 해야 합니다.
Azure Ado 또는 SonarCloud 대시보드 및 보고서와 같은 도구를 사용하여 코드 문제를 발견합니다.
#삼. 배포의 수동 단계
테스트 또는 프로덕션 환경에 코드를 릴리스하기 위해 팀이 수행해야 하는 수동 단계를 추적합니다.
- 우리의 목표는 시간이 지남에 따라 여기에서 0을 달성하는 것입니다.
- 자동화 로드맵까지 배포/릴리스 파이프라인을 가져오는 데 필요한 경우 기술 부채 스토리를 생성합니다. 스프린트에서 스프린트로의 프로세스에서 나머지 수동 단계를 점차 낮추십시오.
사기 지표
이것은 팀이 자신의 작업과 매일 처리하는 프로세스에 대해 어떻게 느끼는지 추적하는 메트릭입니다.
#1. 스프린트 소급 이행
다음 스프린트에서 실제로 완료한 작업 항목 수를 추적할 수 있습니다.
- 스크럼 마스터는 회고 회의 결과를 팀 페이지에 수집하여 합의된 작업 항목을 추적합니다.
- 그런 다음 팀은 진행 상황을 추적합니다.
- 그런 다음 프로젝트 관리는 작업 항목이 진행되고 있는지 또는 팀이 작업 항목을 완료하지 못하는 이유를 검토할 수 있습니다. 그런 다음 팀이 합의된 작업 항목을 진행할 수 있도록 환경을 수정합니다.
이전 스프린트의 작업 항목 중 최소 33% 또는 1개(높은 것에 따라 다름)가 다음 스프린트에 채택됩니다.
그보다 적으면 팀이 합의한 개선 사항을 구현할 수 있도록 변경이 필요합니다.
프로젝트 관리 도구에는 스프린트 회고 활동을 위해 바로 사용할 수 있는 템플릿이 포함되어 있습니다. 다음은 monday.com의 예입니다.
출처: monday.com
#2. 팀 협업
트랙 페어 프로그래밍.
- 스토리별로 자연스러운 커플을 형성하여 함께 작업하고 관찰, 지식 및 성공을 공유합니다. 다른 팀 구성원이 소유한 스토리 아래에 하위 작업을 만듭니다.
동료의 이니셔티브에서 코드 검토를 추적합니다.
- 동료는 다른 사람의 스토리 출력을 검토하도록 요청하거나 능동적으로 조치를 취합니다.
메트릭은 하위 작업의 monday.com/Asana/Jira 보드에서 추출할 수 있습니다.
스프린트 스토리의 최소 50%는 팀원이 공유해야 합니다. 적다면 이유를 조사하고 합당한 조치를 취하십시오.
자발적 동료 검토를 위해 전용 하위 작업으로 스토리를 추적합니다. 처음에는 이런 방식으로 검토된 코드 스토리의 20%가 좋은 시작입니다. 스프린트를 통해 점진적으로 팀이 더 협력적으로 작업하도록 격려하고 동기를 부여하고 스프린트당 코드 스토리의 50%를 목표로 늘려야 합니다.
#삼. 기술 부채 대 새로운 기능 이야기
출처: atlassian.com
팀에게 자신의 부채 이야기를 해결할 수 있는 기회를 제공하면 작업에 대한 팀의 만족도가 높아질 것입니다.
- 반대로 점진적으로 해결할 계획 없이 기술 부채 문제가 누적되면 시간이 지남에 따라 팀의 사기가 저하됩니다. 그리고 솔루션은 더욱 불안정해지고 복잡해지며 실질적인 재작업 없이는 해결하기 어려워질 것입니다.
팀은 이해 관계자나 최종 사용자가 보지 못하더라도 솔루션과 잘 작동하지 않는 것이 무엇인지 가장 잘 압니다. 이러한 이야기는 개발팀 자체에 가장 큰 영향을 미칩니다. 이해 관계자에게는 보이지 않을 수 있습니다. 그렇기 때문에 팀이 개발 활동을 정리하는 데 도움이 되는 스토리 작업을 할 수 있는 기회를 팀에 제공하는 것이 중요합니다.
목표는 시간이 지남에 따라 제기된 기술 부채 사례가 얼마나 많이 해결되었는지, 이러한 사례의 백로그가 증가하는지 여부를 추적하는 것입니다.
팀은 스토리를 백로그에서 TechDebt로 레이블을 지정하고 팀에서 우선 순위를 부여하여 스프린트에서 맨 위로 이동하여 선택할 수 있습니다.
프로젝트의 상태와 백로그에서 식별된 기술 부채의 수에 따라 TechDebt 백로그가 스프린트마다 10% 이상 증가하지 않도록 할 수 있습니다.
기술 부채 이야기의 우선순위를 정하고 스프린트에 포함하여 기술 부채 백로그 증가를 억제하여 팀이 각 스프린트 시간의 10-20% 시간 동안 기술 부채 이야기를 작업할 수 있도록 합니다.
마지막 말
모든 프로젝트에는 경영진이 원하거나 팀이 자체 성공을 측정하기로 결정하기 때문에 결국 몇 가지 메트릭이 필요합니다.
당신이 할 수 있는 최선은 선택하고 사용할 준비가 된 지표 라이브러리 구축을 시작하는 것입니다. 빠를수록 좋다. 그리고 그렇게 하는 동안 무엇보다도 항상 행동을 변화시키는 지표를 찾으십시오.
다음으로 스프린트를 망칠 수 있는 비정상 프로세스를 확인하십시오.