애자일 지표는 애자일 프로젝트 팀의 진행 상황과 성공 여부를 평가하는 데 사용되는 중요한 척도입니다. 이러한 지표를 올바르게 설정하면 팀의 성과, 품질, 테스트 효율성, 전반적인 운영 효율성이 시간이 지남에 따라 어떻게 변화하는지 파악할 수 있습니다.
애자일 지표의 주된 목적은 팀이 개선해야 할 부분을 명확히 하고, 데이터에 기반한 의사 결정을 통해 더 나은 결과물을 만들 수 있도록 지원하는 데 있습니다. 하지만 많은 경우 기업들은 단순히 보기 좋게 꾸며진 허영 지표나 원시 수치를 사용하는 경향이 있습니다. 이러한 지표들은 대시보드에서는 멋져 보일 수 있지만, 실제로는 팀에게 거의 도움이 되지 않습니다.
이러한 지표들은 팀을 지원하기보다는 경영진에게 보고서를 제출하고 몇 가지 전략적 결정을 내리는 데 사용됩니다. 그러나 안타깝게도 이러한 결정이 왜 내려졌는지에 대한 이해는 팀에게 전달되지 않는 경우가 많습니다. 잘못된 지표를 사용할 경우, 팀은 지표가 좋아 보이도록 자신들의 프로세스를 왜곡하게 되고, 결과적으로 실제 성과는 개선되지 않는 문제가 발생합니다.
메트릭의 기본 접근 방식
메트릭을 분류하는 방법은 다양하지만, 가장 기본적인 구분은 하향식(Top-Down)과 상향식(Bottom-Up) 방식입니다.
- 하향식 (Top-Down): 경영진이 팀에게 달성해야 할 목표를 설정하고, 그 목표에 맞추도록 강요하는 방식입니다. 팀의 의견이나 상황은 고려되지 않고, 정해진 목표를 달성하는 데만 집중하게 됩니다.
- 상향식 (Bottom-Up): 팀 스스로 개선이 필요한 부분을 파악하고, 이를 위해 집중해야 할 영역을 설정하는 방식입니다. 팀은 목표 달성 과정을 측정할 수 있는 지표를 정의하고, 그 결과를 경영진에 보여줄 수 있습니다.
좋은 메트릭의 특징
그렇다면 좋은 메트릭은 어떻게 정의해야 할까요? 다음은 좋은 메트릭이 갖추어야 할 몇 가지 핵심 특징입니다.
- 행동 변화 유도: 가장 중요한 것은 메트릭 결과를 볼 때마다 개선을 위해 팀 내부에서 어떤 변화가 필요한지 명확하게 알 수 있어야 한다는 점입니다.
- 간결하고 명확: 메트릭은 관련된 모든 사람이 이해할 수 있도록 몇 문장으로 간단하게 설명할 수 있어야 합니다.
- 시간 경과에 따른 비교 가능: 메트릭은 주기적으로 측정하여 결과를 비교할 수 있어야 합니다. 이전 결과와 비교하여 개선 여부를 판단할 수 있어야 합니다.
- 비율 또는 백분율: 단순한 수치보다는 비율이나 백분율로 표현하는 것이 좋습니다. 예를 들어, “스프린트 동안 10개의 새로운 오류가 발견되었다”는 정보만으로는 부족하며, 전체 개발량이나 기존 오류 수와 비교해야 의미 있는 정보를 얻을 수 있습니다.
애자일 팀을 위한 몇 가지 메트릭 예시를 통해 이러한 정의를 충족하는지 살펴보겠습니다. 메트릭은 크게 성과, 품질, 사기라는 세 가지 범주로 나눌 수 있습니다.
메트릭 범주
성능 지표
성능 지표는 팀이 스프린트 내에서 계획한 작업을 얼마나 잘 수행하는지 파악하는 데 사용됩니다. 과도하게 많은 작업을 계획하는지, 아니면 스프린트에서 스프린트로 작업이 계속 이월되는지 등을 평가합니다.
애자일 환경에서는 팀이 스프린트 시작 시 계획했던 내용을 최대한 완료하는 것이 중요합니다. 물론 스프린트 중에 작업 내용이 변경될 수도 있지만, 이러한 변경은 단순히 추가되는 것이 아니라 기존 작업과 교환되는 형태여야 합니다. 스프린트 중에 새로운 작업이 추가된다고 해서 팀의 처리 능력이 갑자기 늘어나는 것은 아닙니다.
이러한 지표를 통해 팀은 스프린트 계획에 대한 책임감을 갖고, 신뢰성과 예측 가능성을 높일 수 있습니다.
#1. 스프린트 용량 대비 완료된 스토리 포인트
각 스프린트에서 계획된 스토리 포인트(SP)와 실제로 완료된 SP를 비교합니다. 작은 편차는 괜찮지만, 큰 변화는 문제가 있다는 신호일 수 있습니다.
- 총 스프린트 용량은 팀 구성원의 가용 일수를 합산하여 계산합니다. 예를 들어, 팀원 10명이 모두 스프린트 전체에 참여할 수 있다면 총 용량은 100이 됩니다.
만약 팀이 계획한 SP가 일반적으로 완료할 수 있는 SP보다 훨씬 많다면, 이는 위험 신호입니다. 목표는 계획한 SP가 실제 완료한 SP보다 적거나 같도록 유지하는 것입니다.
팀이 계획한 모든 스토리를 완료하고 남는 시간이 있다면 추가 스토리를 처리할 수 있습니다. 반대로 계획보다 적은 SP를 반복적으로 완료한다면, 계획을 수정하여 다음 스프린트에 더 적은 SP를 가져와야 합니다.
monday.com, Atlassian Jira, Asana와 같은 도구는 스토리 포인트를 쉽게 기록하고 추출할 수 있는 기능을 제공합니다. 또한 스프린트 계획 후 자동으로 생성할 수도 있습니다.
#2. 번다운 차트
번다운 차트는 많은 스크럼 팀에서 대시보드에 포함하지만, 실제로 잘 활용하지 않는 지표 중 하나입니다. 관리자들은 전체적인 작업 진행 상황을 파악하기 위해 이 차트를 활용하지만, 팀 구성원들은 중요하게 생각하지 않는 경향이 있습니다.
- 팀은 번다운 차트를 통해 스프린트 동안 스토리가 어떻게 완료되는지 확인해야 합니다. 만약 모든 스토리가 스프린트 마지막 날에만 완료된다면, 스프린트 목표 달성에 대한 불확실성이 커집니다.
- 스프린트 보드를 검토하고, 작은 이야기가 스프린트 초기에 시작되었음에도 불구하고 여전히 완료되지 않은 이유를 찾아야 합니다.
- 이야기를 필요 이상으로 길게 열어두지 않고, 팀과 협력하여 효율적인 스토리 처리 방법을 찾아야 합니다.
- 이상적인 번다운 차트는 직선으로 내려오는 형태이지만, 실제로는 그렇지 않습니다. 하지만 그에 가까워질수록 스토리 처리가 효율적이라고 할 수 있습니다.
Asana와 같은 애자일 관리 도구는 각 스프린트마다 번다운 차트를 자동으로 생성하는 기능을 제공합니다.
출처: asana.com
#3. 스프린트 목표 달성률
각 스프린트 동안 팀이 설정한 스프린트 목표의 달성률을 추적합니다. 스프린트 목표는 Confluence 페이지나 Jira 등에 별도로 문서화하고, 달성 여부를 기록합니다. 팀이 모든 스토리를 완료하지 못했더라도 스프린트 목표를 달성할 수도 있습니다. (예: 사이드 스토리만 누락)
매 스프린트마다 100% 목표 달성을 목표로 해야 합니다. 그렇지 않은 경우에는 그 원인을 분석해야 합니다.
- 만약 여러 개의 주제를 동시에 진행하고 있다면, 그 수를 줄여야 합니다.
- 스프린트 중에 너무 많은 임시 작업이 추가된다면, 원래 스프린트 목표에 영향을 미치지 않도록 줄여야 합니다.
- 만약 스프린트 목표가 너무 크거나 어렵다면, 더 작고 달성 가능한 목표로 조정해야 합니다. 어차피 스프린트가 끝날 때까지 목표를 달성하지 못한다면, 큰 목표를 세우는 것은 의미가 없습니다.
코드 품질 지표
코드 품질 지표는 시간이 지남에 따라 코드의 품질이 어떻게 변화하는지 추적하는 데 사용됩니다. 건전한 개발 프로세스를 유지하고 문제 해결에 소요되는 시간을 줄이는 데 도움이 됩니다. 또한 개발 및 테스트 활동 중 코드 실행 대기로 인해 발생하는 개발자의 유휴 시간을 줄이는 데도 도움이 됩니다.
출처: azuredevopslabs.com
#1. 자동화된 테스트
개발자가 수행하는 각 변경 사항에 대해 자동화된 단위 테스트를 생성해야 합니다.
- 자동화된 테스트로 코드 커버리지를 측정해야 합니다. Azure Pipelines 또는 SonarCloud와 같은 도구를 사용하여 테스트를 실행하고, 85% 이상의 커버리지를 목표로 해야 합니다. 90% 이상은 효율성이 떨어질 수 있습니다.
- 자동화된 단위 테스트 생성은 새로운 스토리에 대한 완료 조건에 포함되어야 합니다.
- 백로그에 기술 부채 스토리로 이전 코드 테스트 범위를 따라잡아야 합니다.
#2. 코드 복잡성
시간이 지남에 따라 코드가 불필요하게 복잡해지는 것을 평가하고, 기술 부채를 통해 적극적으로 수정해야 합니다. 가능하면 처음부터 코드가 복잡해지지 않도록 해야 합니다. 코드 표준 및 지침을 정의하여 개발자들이 이를 준수하도록 교육해야 합니다. 또한 팀의 경험을 바탕으로 가이드라인을 정기적으로 업데이트해야 합니다.
코드 스멜을 식별하여 잠재적인 문제 (중복 코드, 긴 메서드, 사용하지 않는 변수 등)를 찾아야 합니다. 피어 리뷰를 통해 코드 표준이 잘 적용되고 있는지 확인해야 합니다. Azure Ado 또는 SonarCloud 대시보드 및 보고서와 같은 도구를 사용하여 코드 문제를 발견할 수 있습니다.
#3. 배포의 수동 단계
테스트 또는 프로덕션 환경에 코드를 배포하기 위해 팀이 수행해야 하는 수동 단계를 추적합니다. 목표는 시간이 지남에 따라 수동 단계를 0으로 만드는 것입니다. 필요한 경우 기술 부채 스토리를 생성하여 배포/릴리스 파이프라인을 자동화해야 합니다. 스프린트마다 수동 단계를 점진적으로 줄여나가야 합니다.
사기 지표
사기 지표는 팀 구성원이 자신의 업무와 일상적인 프로세스에 대해 어떻게 느끼는지 파악하는 데 사용됩니다.
#1. 스프린트 회고 결과 이행
팀이 회고 회의에서 도출한 개선 사항을 실제로 얼마나 이행했는지 추적합니다. 스크럼 마스터는 회고 회의 결과를 팀 페이지에 정리하고, 합의된 작업 항목을 추적합니다. 팀은 작업 진행 상황을 확인하고, 프로젝트 관리자는 작업 항목이 진행되는지 또는 완료하지 못하는 이유를 검토합니다.
이전 스프린트에서 합의된 작업 항목 중 최소 33% 또는 1개 이상 (더 높은 값)을 다음 스프린트에서 채택해야 합니다. 그렇지 않다면, 팀이 개선 사항을 실행할 수 있도록 환경을 바꿔야 합니다.
프로젝트 관리 도구에는 스프린트 회고 활동을 위한 템플릿이 포함되어 있습니다. 예를 들어, monday.com은 다음과 같은 템플릿을 제공합니다.
출처: monday.com
#2. 팀 협업
페어 프로그래밍을 통해 팀원 간의 협업을 장려합니다. 스토리에 따라 자연스럽게 팀을 구성하여 지식과 경험을 공유하고, 하위 작업을 만들어 다른 팀 구성원이 담당하는 스토리에 참여하도록 합니다.
코드 리뷰를 통해 다른 팀원의 작업물을 적극적으로 확인하고, 피드백을 주고받도록 합니다. 메트릭은 monday.com/Asana/Jira 보드의 하위 작업에서 추출할 수 있습니다.
스프린트 스토리의 최소 50%를 팀원들이 공유해야 합니다. 그렇지 않은 경우 그 이유를 조사하고 적절한 조치를 취해야 합니다. 코드 리뷰를 위해 스토리를 하위 작업으로 추적하고, 처음에는 20% 정도의 코드 스토리부터 시작하여 점차 50%까지 늘려나가야 합니다.
#3. 기술 부채 대비 신규 기능 스토리
팀에게 기술 부채 문제를 해결할 기회를 제공하면 업무 만족도가 높아질 수 있습니다. 반대로 기술 부채 문제를 해결하지 않고 누적하면 팀의 사기가 저하될 수 있습니다. 기술 부채는 프로젝트 이해 관계자에게는 보이지 않을 수 있지만, 개발팀에 큰 영향을 미칩니다. 따라서 팀이 기술 부채를 해결하고 개발 환경을 개선할 수 있도록 지원해야 합니다.
출처: atlassian.com
목표는 시간이 지남에 따라 제기된 기술 부채 사례가 얼마나 많이 해결되었는지, 백로그가 증가하고 있는지 여부를 추적하는 것입니다. 팀은 기술 부채 스토리를 백로그에서 별도로 표시하고, 우선순위를 정하여 스프린트에 포함시킬 수 있습니다.
프로젝트 상태와 백로그에 쌓인 기술 부채 수에 따라 백로그가 스프린트마다 10% 이상 증가하지 않도록 관리할 수 있습니다. 기술 부채 스토리를 스프린트에 포함하여 팀이 각 스프린트에서 10-20%의 시간을 기술 부채 문제를 해결하는 데 사용할 수 있도록 해야 합니다.
마지막으로
모든 프로젝트는 경영진의 요구 또는 팀 자체의 필요에 따라 몇 가지 지표를 사용하게 됩니다. 중요한 것은 팀과 프로젝트에 적합한 지표를 선택하고, 이를 통해 지속적으로 개선을 이끌어내는 것입니다. 처음부터 지표 라이브러리를 구축하여 필요에 따라 선택하고 사용할 수 있도록 준비하는 것이 좋습니다. 또한, 무엇보다도 행동 변화를 유도하는 지표를 찾아야 합니다. 마지막으로 스프린트 운영에 부정적인 영향을 미치는 비정상적인 프로세스를 확인하고 개선해야 합니다.