가장 일반적인 애자일 메트릭을 사용한 경험

가장 일반적인 애자일 메트릭을 사용한 경험

 

by Kate Borisenko, BPO

 

팀의 생산성을 측정하기 위해 애자일 메트릭을 사용하는 것은 애자일 철학의 핵심 영역이다. 팀 관리자와 모든 구성원은 자신들의 작업 결과를 보고 작업 흐름을 개선하고 효율성을 증가시키는 데 이 데이터를 사용해야 한다.

 

최종 사용자와 고객 또한 제품의 결과를 평가하는 데 집중한 애자일 프로젝트 메트릭을 사용해 혜택을 얻을 수 있다. 스크럼 마스터, 개발자, 디자이너 그리고 테스터는 메트릭을 통해 애플리케이션의 성능을 측정하고 현재와 이전 작업으로 제품이 더 나아졌는지 추적할 수 있다.

 

우리는 이 기고에서 중요한 애자일 메트릭을 리뷰하고 이 애자일 메트릭 대시보드를 실제 프로젝트에 적용한 경험을 나누려고 한다. 팀을 성공으로 이끌고 성과를 내려면 어떤 메트릭을 적용할지 그리고 어떻게 적용할지 알아야 한다. 이제 우리가 어떻게 그 방법을 알아냈는지 공유하겠다.

 

 

일반적인 애자일 메트릭의 종류

 

애자일 메트릭의 분류는 고정되어 있지 않고 항상 변하며 재정립되고 있다. 10년이 지난 지금까지도 다양한 애자일 프레임워크에서 3가지 중요한 애자일 메트릭이 부상하고 있는 것이 확인된다.

 

1. 칸반 메트릭 - 이 메트릭은 투자 시간 (싸이클 타임), 결과 전달 (처리량) 그리고 그것의 비율을 측정하는 것에 기초한다.

2. 스크럼 메트릭 - 이 메트릭은 주어진 기간 안에 얼마나 많은 양의 작업을 수행했는지 보이면서 작업 흐름을 이해하고 계획하는 데 집중하는 메트릭이다.

3. 린 메트릭 - 기능을 테스팅하고 발생할 수 있는 에러를 확인하며 부정적인 효과를 예측하는 기술 평가를 통해 생산 효율성과 제품 품질을 계속 측정한다.

 

 

우리는 소프트웨어 개발 프로세스의 핵심적인 측면과 그 결과인 제품 품질, 팀의 생산성 그리고 팀의 건강성을 평가하기 위해 이 3가지 유형의 메트릭 모두를 사용했다.

 

애자일 품질 메트릭

 

당신이 팀의 속도와 효율성을 측정하기 전에 올바른 방향으로 자연스럽게 나아가고 있는지 알 필요가 있다. 만일 과업 그 자체가 잘못된 방향으로 설정되어 있다면 그 모든 개발 과제를 빠르게 전달한들 무슨 소용이 있을까? 각 소프트웨어 개발팀과 관리자는 모든 활동이 제품을 개선하는 것과 관련된 것인지 확인하는 데 우선 순위를 두어야 한다. 이것은 제품의 품질을 측정하고 부정적인 경향을 감지함으로써 달성할 수 있다.

 

놓친 결함

 

각각의 애자일 프로젝트는 스프린트나 작업 싸이클을 가지고 있고 그 마지막 단계에서 특정 과제를 전달한다. 작업이 완료된 후 팀의 관리자는 전환된 결과의 품질을 평가해야 한다. 모든 변경 사항과 수정 사항 그리고 해결되지 않은 버그는 놓친 결함에 해당하며 이는 개발자가 수정해야 했지만 그러지 못한 이슈를 말한다. 버그의 정확한 숫자와 속성을 기록해 무엇 때문에 개발자가 실수했는지 알아낸다.

 

 

놓친 결함에 대해 리포트를 작성하고 실질적인 통계를 수집한 뒤 당신의 팀과 결과를 두고 논의할 필요가 있다. 어떤 종류의 에러로 팀이 실수했는지 각각의 팀 구성원이 아는 게 중요하다. 만일 개인에게 제안할 것이 있다면 그것을 팀 구성원과 1대1로 이야기한다.

 

전달 실패

 

만일 제품을 전달했지만 출시하지 못하고 고객을 사로잡지 못했다면 이것을 전달 실패로 기록한다. 때때로 전달 실패는 이해관계자 중 한 사람의 결정이나 비즈니스 모델을 믿을 수 없다고 판명 난 경우 발생한다. 그러한 문제의 원인이 무엇이든 간에 당신은 해당 실패의 원인과 함께 모든 전달 실패를 기록해야 한다.

 

 

팀은 항상 신규 배포를 출시하기 전에 이전에 실패한 배포의 목록을 살펴보고 이번 것이 같은 과정을 겪는 건 아닌지 확인한다. 이전 버전의 실패 원인을 분석하면 장래의 이슈를 막을 수 있다.

 

출시 순고객추천지수 (Net Promoter Score_NPS)

 

순고객추천지수는 정량적으로 (숫자, 통계, 평점) 그리고 정성적으로 (리뷰, 직접 응답, 문자, 이메일, 전화) 사용자의 반응을 평가하는 것을 포함하는 메트릭이다. 팀이 그런 피드백을 수집해 분석한 뒤 각 팀 구성원이 얼마나 많은 사용자가 그 제품을 추천할 가능성이 있는지 평가하는 (대체로 1에서 10 사이의 숫자) 점수를 제안한다.

 

 

애자일 프로젝트 관리 메트릭

 

당신이 이전에 발생한 성공과 실패의 모든 역사를 확인한다면 현재의 모든 불완전한 프로젝트의 방향을 분석하고 과거 경험을 바탕으로 적절한 대안을 내놓을 수 있다. 당신이 제품에 대해 "무엇을 할 것인지"에 관한 개발 방향을 정했다면 그것을 "어떻게 하고 있는지의" 요소인 팀의 효율성을 평가할 필요가 있다. 당신은 팀 구성원이 당신의 기대를 만족시키고, 자신들의 과제를 이해하며, 일정을 관리하고 전체 프로세스가 예정대로 조율되고 있는지 알기 위해 애자일 프로젝트 메트릭을 사용할 수 있다.

 

리드 타임

 

리드 타임은 프로덕트 백로그 항목이 스프린트 마지막에 도달하는 데까지 걸리는 시간을 팀에게 알려주는 메트릭이다. 이것은 모든 개발 단계나 과업별로 제품을 추적하거나 아이디어 구상에서 출시까지 사용한 모든 시간을 평가하는 데 사용할 수 있다. 이것은 개발자가 장래의 작업을 계획하고 가격을 추정할 때 쓸 수 있는 장기적인 메트릭이다.

 

 

당신 프로젝트 모두의 리드 타임을 반드시 기록한다. 각 단계를 개별적으로 검토할 수 있는 체계적인 스프린트 메트릭과 전체 프로젝트를 다루는 큰 그림의 통계 양쪽을 모두 유지하는 것이 최상이다.

 

싸이클 타임

 

리드 타임이 팀의 장기적인 성과 메트릭 중 하나라면 싸이클 타임은 개별 과업에 집중한다. 이 메트릭은 하나의 과업인 단일 싸이클의 기간을 평가하고 프로젝트당 싸이클의 숫자를 계산한다. 그리고 그 제품이 이미 베타 테스트나 출시에 진입했다면 최종 사용자에게 얻은 결과를 측정한다.

 

팀이 싸이클 타임을 사용하면 하나의 과제에 너무나 긴 시간이 걸리지는 않는지 또는 어떤 팀 구성원이 종료 시점까지 완료하지 못했는지 즉시 알게 된다. 이런 단기 메트릭은 프로젝트 관리를 훨씬 수월하게 만들고 이슈가 발생했을 때 정확한 지점을 찾는 데 도움을 준다.

 

 

스프린트 번다운

 

이 메트릭은 단기와 장기에 모두 적용된다. 관리자는 현재 프로젝트에서 팀의 진척 사항을 실시간으로 추적하는 스프린트 번다운 스크럼 리포트를 생성할 수 있다. 이를 위해 전체 스프린트 숫자를 추정하고 예상 시간을 추정해야 한다. 또한 이것은 장기에도 적용될 수 있는데 관리자가 이전 프로젝트의 리포트를 분석해 예상 시간표를 맞추지 못한 단계를 파악해 지연의 원인을 분석할 수 있다.

 

가장 중요한 것은 스프린트 번다운이 팀의 작업 흐름이 가진 역동성을 추적한다는 점이다. 어떤 팀 구성원이 첫 단계에서 느리게 작업을 한다면 다른 구성원들이 프로젝트의 마지막에 이르러 번아웃 된다. 팀 리더가 스프린트 번다운을 통해 이런 경향성을 감지하고 근본 원인을 파악해 작업 배분과 시간 관리를 통해 팀 구성원을 도울 수 있다.

 

에픽과 릴리즈 번다운

 

이 메트릭은 스프린트 번다운과 유사하다. 유일한 차이는 이 메트릭이 릴리즈 이후 팀의 생산성에 집중한다는 점이다. 관리자는 새로운 요구사항을 추가하고 최종 사용자의 피드백에 기반한 과업을 통합할 수 있다. 이것은 스프린트 번다운의 개선 버전인데 이것이 프로젝트 릴리즈 이후에 발생한 과업도 통합하기 때문이다.

 

 

속도

 

이 메트릭은 특정 기간을 지나며 완료한 스토리 점수의 숫자를 평가한다. 당신은 지난 이력에 기초해 미래의 스토리 포인트에 드는 시간을 예상할 수 있다. 만일 특정 스프린트에서 팀의 속도가 감소하면 이것은 팀원이 잘못 이해하고 있거나 이전에 예상한 것보다 더 어려운 과제라는 걸 나타낸다.

 

 

추가적인 애자일 메트릭

 

애자일 메트릭은 팀이 제품 개발의 중요한 측면을 추적하고 프로젝트를 더 낫게 하는 방법을 알게 하는 데 도움을 준다. 또한 고위 임원이 팀의 건강성과 개발의 큰 그림을 살펴볼 수 있게 해주는 애자일 메트릭이 있다. 우리의 경험에 따르면 이런 추가적인 메트릭은 당신 과업의 모든 측면을 측정해준다. 하지만 우리는 최종 제품에 관해 가장 많이 알려주고 완전한 결과를 가져다주는 핵심 특성들을 정의했다.

 

누적식 흐름

 

이 메트릭의 이름은 그 의도를 명백하게 드러낸다. 즉 모든 프로젝트 흐름을 누적해서 그것을 하나의 다이어그램에서 평가한다. 당신이 이런 그래프를 가지면  큰 규모의 시각을 얻게 된다. 즉 애자일 리포트를 상세하게 분석할 시간이 없는 프로젝트 이해관계자들에게 보여줄 수 있다.

 

 

대체로 이 다이어그램은 아래의 프로세스를 설명한다.

 

• 백로그에 있는 과제: 주어진 시간 안에 팀원이 가지고 있는 백로그 과제의 숫자
• 승인된 작업: 누군가가 계획 대비 완료한 과제의 숫자. 팀 관리자는 즉시 계획 대비 완료된 활동 간의 차이를 확인한다.
• 버퍼 과제: 승인을 기다리는 모든 작업이 버퍼 구역에 존재하는 것으로 정의한다.
• 진행중: 당신은 현재의 작업 부하를 평가할 필요가 있다.

 

코드 이탈

 

이 메트릭은 출시 전에 코드 베이스가 변하는 경향을 보여준다. 이탈 다이어그램은 얼마나 많은 양의 코드가 순차적으로 추가되고 제거되고 변경되었는지를 나타낸다. 초기 단계의 스프린트에서 그래프상에 많은 수의 치솟음과 하락이 있을 것이다. 왜냐하면 그 코드가 여전히 불안하기 때문이다. 하지만 프로젝트가 진행되면서 코드 이탈 그래프는 심한 기복이 없이 안정된 상태가 되어야 한다.

 

출시 전에 이탈 추세가 꺾여야 한다. 즉 출시 전에 코드의 추가와 수정이 이뤄지는 것은 충분한 테스팅을 거치지 않았음을 의미한다. 대체로 애자일 차트에 불규칙성이 존재할 때마다 그 이유를 조사한다.

 

컨트롤 차트

 

컨트롤 차트는 팀이 자신의 싸이클 타임의 기간에 관한 정보를 볼 수 있는 차트이다. 최상의 결과는 시간이 지나며 그 차트상의 선이 꾸준히 내려가는 것이다. 이것은 팀의 속도가 증가하고 하나의 싸이클 당 필요한 기간이 짧아짐을 의미한다. 또 다른 중요한 측면은 일관성이며 이 경우 싸이클 타임은 과제의 유형과 관계 없이 일정할 필요가 있다. 이것은 과업 분배가 잘 되었다는 걸 의미한다.

 

 

건강성 메트릭

 

소프트웨어 개발팀은 팀원 간에 부드러운 의사소통을 유지하고 모든 사람이 만족하는지 점검하는 등 장기간의 우선순위에 집중해야 한다. 애자일은 유연한 방법론으로 다양한 팀원의 흥미에 맞출 수 있고 관리자는 무엇에 관심을 가져야 하는지 즉시 알 수 있다. 모든 팀원이 작업흐름에 만족하는지 알 방법은 다음과 같다.

 

행복감

 

당신에게 신뢰가 있고 팀 내에 비공식적인 관계를 유지하고 있다면 각 팀원과 열린 대화를 시작하기가 쉽다. 모든 이들에게 이 회사에서 경력에 대해 1에서 5까지 등급을 매기라고 요청한다. 당신은 다음과 같은 추가 질문을 할 수 있다. 자신이 맡은 일에서 최고의 측면과 최악의 측면은 무엇인가? 어떤 일에 개선이 필요하고 어떤 일이 행복감을 늘리는가? 만일 그 팀에게 친근하게 의사소통하는 습관이 결여되어 있다면 익명 설문 조사를 시행하면 좀 더 객관적인 결과를 얻을 것이다.

 

 

팀의 사기

 

팀의 사기와 행복감은 같은 것이 아니다. 행복감은 편안함과 관련이 있지만 팀 사기는 생산성, 자존감, 자신이 지닌 전문성의 정도에 대한 평가와 연결되어 있다. 다시 한 번 당신은 팀의 사기에 관해 1에서 5까지 등급을 매기라고 동료에게 요청할 수 있다. 그리고 다음의 질문을 던진다.

 

• 회사에서 일했던 것이 당신의 기술을 향상시키는데 도움이 되었나?
• 당신은 현재의 작업 부하에서 얼마나 많은 잠재력을 발휘하고 있나?
• 당신의 일을 즐기는가?
• 당신의 일에서 확실한 결과를 보고 있는가?
• 당신은 새로운 프로젝트에 열정적인가?

 

여기서 목표는 팀의 개발 흐름이 올바른 방향으로 가고 있는지 이해하는 것이다. 가끔은 소프트웨어 개발팀의 관리자가 팀원의 관심이 무시되고 따분한 과제지만 수익성이 있는 과제를 떠맡기도 한다. 이런 조사는 직원들이 자신들의 일에 열정적으로 도전하는지 아는 데 도움을 줄 것이다.

 

팀원 이직률

 

만일 팀 관리자가 빈번하게 팀원을 교체한다면 작업 환경이 건강하지 않을 가능성을 의미한다. 시간이 지나며 일정 수준의 이직률은 정상이다. 사실상 당신은 몇 년 동안 인력 충원을 하지 않는 것이 정체를 의미하므로 원하지 않을 것이다. 하지만 당신은 몇 달 만에 몇 명의 팀원이 팀을 떠나거나 많은 사람이 합류하는 등 갑작스럽게 튀는 것에 대해 주의해야 한다. 갑자기 신규 인력이 다수 유입되면 프로젝트 관련 작업에 바로 투입하기 전에 온보딩 절차에 관심을 가질 필요가 있다.

 

 

최종 사용자에게 주는 혜택 측정하기

 

애자일 팀은 제품이 최종 사용자와 비즈니스 오너의 필요에 얼마나 잘 들어맞는지 알아야 한다. 이것은 종합적인 코드 분석을 통해 코드의 품질, 최종 사용자가 느끼는 사용성, 발생 가능한 유지 보수 문제를 확인해서 수행할 수 있다.

 

정적 코드 분석

 

이것은 소프트웨어가 동작 중이지 않은 상태에서 수행하는 단순한 유형의 코드 분석이다. 그냥 오픈 소스 도구를 가지고 자동으로 코드를 모니터링하면 보안 이슈를 확인하며 기술 부채나 버그를 찾아내어 문제 있는 코드 조각을 가비지 수집기로 보낼 수 있다.

 

 

동적 코드 분석

 

당신의 팀은 최종 사용자가 경험하는 바를 평가하기 위해 동적 코드 분석을 통해 소프트웨어를 구동한다. 우리는 개발자와 테스터가 항상 사용자의 신발을 신고 대부분의 일반적인 시나리오를 탐색하도록 장려한다. 예를 들어 계약상 금지되지 않는다면 동료와 가족 구성원을 해당 솔루션에 초대해 피드백을 요청할 수 있다. 가장 중요한 것은 우리는 동적인 코드 분석의 완전한 책임을 진 QA 전문가팀을 보유하고 있는 점인데 애자일에서 더 많은 사람이 테스팅 메트릭에 기여할수록 최종 제품의 품질이 더 나아진다고 믿기 때문이다.

 

 

최상의 애자일 메트릭을 어떻게 적용하나

 

당신은 사용할 수 있는 다양한 애자일 메트릭 중에서 당신의 팀과 장기간의 프로젝트에 적합할 것을 선정해야 한다. 이런 메트릭의 핵심 특성을 계속 추적하는 것이 습관이 되어야 하지만 시급한 업무에서 주의를 뺏길 만큼은 아니어야 한다. 우리는 다음과 같은 방법으로 작업 흐름에 애자일 메트릭을 자연스럽게 통합할 수 있다.

 

성능, 예산 그리고 품질에 집중하기

 

당신은 모든 메트릭을 선택한 뒤에 작업물의 품질, 부하, 시간 비용 그리고 예산에 관한 명확한 그림을 얻을 수 있을지 확인해야 한다. 최초에 우리는 애자일 성과 평가를 위한 싸이클 타임과 속도, 코드 품질 평가를 위한 코드 분석 그리고 전체 개발 프로세스와 그것의 비용을 추적하기 위한 누적 흐름 같은 현재 진행 중인 프로젝트에 관한 단기 메트릭을 수립한다.

 

첫 번째 스프린트를 진행하면서 다음의 일을 하는지 확인한다.

 

• 해당 프로젝트에 포함되는 스프린트와 싸이클의 숫자를 정의한다.
• 고객의 요구를 참고해 전체 프로젝트에 소요되는 시간 비용을 추정한다.
• 최종 제품의 복잡도 수준을 알기 위해 경쟁 솔루션을 평가한다.
• 해당 프로젝트의 가장 흥미롭고 도전적이며 어려운 측면에 관한 팀원의 기대를 수집한다.

 

 

우리는 이런 방식으로 프로젝트를 완료하는 데 시간이 얼마나 들지 알 수 있으며, 유사 솔루션에 근거해 품질 표준을 수립하고 우리 팀이 과제를 작업하는데 동기부여 되어 있는지 아닌지 (이것은 생산성에 큰 영향을 끼친다) 알게 된다.

 

첫 번째 스프린트 이후의 메트릭

 

우리는 이 시점에서 고객과 전체 팀원에게 피드백을 얻는 데 집중한다. 첫 번째 스프린트 이후 우리는 작업 흐름에 참여한 모든 구성원이 그 프로세스를 이해하는지 그리고 편안함을 느끼는지 알기 원한다. 또한 우리는 코드 품질을 평가하는 일을 강조해서 다음 스프린트의 코드 분석과 기술 부채 평가를 계획하기도 한다. 코드 첫 줄이 작성되자마자 코드의 품질을 유지하는 것은 우리의 중요 우선순위이다.

 

속도는 나중이다

 

속도는 우리 프로젝트의 중요한 메트릭 중 하나지만 핵심은 아니다. 우리는 초기 단계에서 속도를 나타내는 숫자를 근거로 판단하지 않는다. 첫 단계를 통해 얻은 급한 전략은 재난의 약속이다. 그 팀이 계획을 생략했을 수도 있고 고객에게 몇 가지 중요한 질문을 하지 못했을 수도 있다. 우리는 제품의 첫 단계에 급하게 뛰어들지 않고 고객과 팀원이 자신들의 속도를 발견하도록 허용한다.

 

우리가 실행 단계에 있을 때 팀의 속도를 증가시키는 것이 우선순위 중 하나이다. 우리는 모든 피쳐와 디자인을 내놓자마자 가능한 한 빨리 모든 과제를 마치고 시간을 최소화하려고 노력한다.

 

개인 메트릭

 

적용한 메트릭은 전체 팀과 개인 구성원 모두가 사용할 수 있어야 한다. 개발자, 테스터, 디자이너는 팀 전체가 아닌 자기의 작업 속도와 결과를 확인할 수 있어야 한다. 우리는 이를 위해 Jira와 Hubstaff와 같은 생산성 도구와 시간 추적기를 사용한다. 모든 일반 리포트는 개인의 리포트와 동기화 되어 구성원은 자신의 시간이 전체 생산성에 몇 퍼센트를 차지하는지 알 수 있다.

 

 

자주 물어보는 질문들

 

애자일에서 KPI는 무엇인가?

 

애자일에서 KPI(Key Performance Indicator)는 측정할 수 있는 값으로 비즈니스 목표를 달성하는 데 팀의 효율성을 나타낸다. 높은 수준의 KPI는 수많은 요인이 기여한 장기적인 결과에 집중한다. 즉, 최종 제품에 얼마나 많은 수의 사용자가 매료되었는지, 변환율은 어떠한지, 피드백 품질은 어떠한지가 포함된다. 낮은 수준의 KPI는 단기적인 값으로 다수의 연결된 요인인 그 프로젝트에 든 시간 (대체로 시간 단위로 측정한다), 프로젝트 예산 (과제 당 투자금) 등에 영향받지 않는다.

 

애자일은 지속적인 개선에 기반한 개발 방법론으로 데이터를 분석하고 적용하는 소프트웨어 개발이다. 팀은 애자일 KPI의 성과와 작업 품질을 분석해 다음번 스프린트에 적절한 변화를 적용한다.

 

스프린트 메트릭은 무엇인가?

 

스프린트 메트릭은 소프트웨어 개발팀의 산출물을 평가해서 각 단계의 스프린트 종료 후 최종 사용자에게 얼마나 많은 가치를 전달했는지 점검한다. 이런 가치는 신규 기능, 디자인 개선 또는 버그 삭제를 통해 평가할 수 있다.

 

스프린트 메트릭의 다음 목표는 팀의 효과성을 비즈니스 용어로 측정하는 것이다. 그 솔루션이 얼마나 빨리 시장에 출시되었는지, 고객의 피드백과 전환 수준은 어떠한지 확인한다. 마지막으로 메트릭은 프로젝트에 참여한 개발자의 만족감을 나타내고 팀이 전반적으로 나아가는 방향을 보여주어야 한다.

 

애자일 프로젝트에서 메트릭이 왜 그렇게 중요한가?

 

애자일 방법론의 핵심은 개발자가 각각의 스프린트를 마친 후 항상 프로세스의 수정을 가한다는 점이다. 개발자는 실질적인 데이터, 통계 그리고 그래프를 통해 다음번 스프린트에 어떤 변화를 가할지 이해하게 되어 최종 제품의 품질을 평가할 수 있다. 그렇지 않다면 이것은 기술이나 조직적인 상세에 매몰되기 쉽다.

 

애자일에서 스프린트란 무엇인가?

 

한 개의 스프린트는 몇 가지 과제를 완료하려고 팀을 구성하고 시작과 끝 날짜가 명확하게 정의된 기간이다. 스프린트는 스크럼, 애자일 그리고 데브옵스의 기초가 되며 작업을 팀이 다룰 수 있는 크기만큼의 조각으로 나누고 각 스프린트의 결과를 추적한다. 이런 개별 기간은 사전 계획, 리스크 평가, 책임 할당 그리고 스프린트 사후 분석을 가진 소규모 프로젝트처럼 취급된다.

 

각각의 프로젝트는 일련의 스프린트로 구성된다. 모든 스프린트를 평가하기 때문에 이슈를 초기에 파악하고 다음번 스프린트에 제거하기 쉽다. 따라서 작업 흐름이 계속 최적화된다.

 

 

소프트웨어 개발을 위한 메트릭은 무엇이 있을까?

 

소프트웨어 개발 메트릭은 소프트웨어 개발 프로젝트의 품질, 성능 그리고 팀의 건강성을 측정해 주는 수량적인 값이다. 이것은 프로젝트를 진행하면서 개발 프로세스를 개선하는 데 도움을 주고 조직 구성과 계획을 개선하기 위해 팀의 미래의 작업에 쓰일 수도 있다.

 

6가지 유형의 대표적인 소프트웨어 개발 메트릭이 존재한다.

 

• 공식적인 코드 메트릭: 코드 라인 수 (number of the lines of code), 명령어 경로 길이 (Instruction Path Length) 등의 숫자를 결정해 수행한 작업의 양을 계산하는 객관적이고 정성적인 값.
• 개발자 효율성 메트릭: 팀은 할당된 코드, 활성일수(active days) 그리고 과제에 소모한 시간을 계산할 수 있다.
• 애자일 프로세스 메트릭: 팀이 프로젝트를 스프린트 단위로 쪼개면 프로젝트의 작은 부분이 가진 효율성을 측정할 수 있다. 즉, 리드 타임 (다수의 스프린트를 포함하는 특정 개발 단계에서 소모한 시간의 양은 얼마인가), 싸이클 타임 (대체로 한 개의 스프린트는 하나의 싸이클에 속한다), 속도 (특정 시간표 안에서 얼마나 많은 수의 과제가 완료되었나)가 그것이다.
• 운영 메트릭: 이 메트릭은 소프트웨어의 동작 특성을 점검하고 회사 인력이 제삼자의 도움 없이 얼마나 효과적으로 도구를 유지보수하는지를 나타낸다. 평균 장애 간격(Mean Time Between Failures) 및 평균 복구 시간(Mean Time to Recover)은 소프트웨어가 실제 환경에서 어떻게 실행될지, 사내 팀이 부하를 처리하는 데 얼마나 준비되어 있는지 확인한다.
• 테스트 메트릭: 이 메트릭은 코드 커버리지를 평가한다. 즉, 얼마나 많은 수의 코드를 테스트 했는지, 버그의 수는 얼마나 되는지 그리고 기술 부채의 비율은 얼마인지 평가한다.
• 고객 만족: 팀은 순수 추천 고객지수, 고객 만족 점수, 고객 노력 지수를 측정해 제품에 대한 최종 사용자의 반응에 대한 통찰을 얻는다. 이 메트릭은 사용자가 제품을 추천하는지 여부와 결과에 만족하는지 모두에 대해 평가한다.

 

* 고객 노력 지수: 고객이 해당 브랜드와 소통하기 위해, 얼마나 많은 노력을 했는지에 대해 묻는 만족도 조사의 값.

 

애자일 메트릭은 소프트웨어 네트워크의 일부분이며 우리의 가이드를 통해 당신도 눈치챘겠지만, 다른 카테고리와 합칠 수 있다.

 

SDLC 메트릭은 무엇인가?

 

SDLC는 소프트웨어 개발 생애주기이다. 즉 컨셉 잡기, 실행, 종료 과정에서 겪는 전형적인 기술 단계의 집합이다. 평균적인 SDLC는 다음의 단계로 구성된다.

 

• 기존 시스템을 평가하고 그것의 기능, 장점, 문제점을 정의한다.
• 신규 프로젝트의 기능성, 디자인, 목표 고객 등에 관한 요구사항을 정의한다.
• 시스템을 설계하고 전형적인 사용자 경로를 고려한다.
• 소프트웨어를 개발한다. 이것은 코드를 작성하고 하드웨어를 준비하며 기능을 만드는 것을 의미한다.
• 소프트웨어의 성능, 기능성, 보안성, 인터페이스 등을 테스팅한다.
• 그 기술이 장기간 운용될 일상적인 환경에 소프트웨어를 배포한다. 
• 코드를 업데이트 하고 특정 조각을 교체하거나 수정하며 버그를 제거해 시스템을 유지보수한다.

 

SDLC의 각 단계는 다음의 특성을 통해 측정할 수 있다.

 

• 요구사항: 팀은 프로젝트를 위한 모든 요구사항을 수집하고 시간과 비용의 관점으로 각각의 요구사항 구현을 판단해야 한다.
• 소프트웨어 품질: SDLC의 개발 단계에서 모든 애자일 품질 메트릭을 사용할 수 있다.
• 테스트 케이스: 팀은 수행된 테스트 활동의 숫자, 그 활동의 속도 그리고 최종적인 코드 커버리지를 계산해야 한다.
• 결함: 작업의 효율성을 평가하기 위해 개발자와 테스터는 개발 기간 동안 발생한 문제의 정확한 숫자를 인지할 필요가 있다.
• 과업: 과업당 소모한 시간과 비용을 측정하면 전체 팀 구성원이 생산적이었는지 아닌지 평가할 수 있다.

 

우리의 가이드에 언급된 모든 메트릭은 소프트웨어 개발 생애주기의 서로 다른 단계에 사용할 수 있다.  이슈가 쌓일 수 있고 제품에 치명적인 결함을 놓치기가 쉽기 때문에 프로젝트의 출시가 가까워져 올수록 모니터링의 필요성이 최고로 증가한다.

 

애자일 메트릭의 처리량은 무엇인가?

 

이것은 스프린트 당 완성된 스토리의 숫자를 계산하는 메트릭이다. 스크럼을 기준으로 보면 유사한 메트릭은 스프린트 속도이다.

 

결론

 

애자일 메트릭은 소프트웨어 개발 프로젝트를 통해 정보에 근거한 의사 결정을 내리기 위한 단단한 기초를 제공한다. 개발자는 다음번 스프린트의 효율성을 높이기 위해 이런 통찰을 활용할 수 있고 제품의 품질을 계속 개선할 수 있다. 하지만 개발 메트릭이 소프트웨어 개발 프로젝트 내에서 절대적인 우선순위를 가져서는 안 된다. 개발자는 무엇보다도 프로젝트의 요구와 대상자의 선호를 고려해야 한다.

 

 

Jelvix는 프로젝트에 메트릭을 적용하는 개별 맞춤식의 접근법을 사용한다. 먼저 우리는 고객, 프로젝트의 MVP와 논의하고 목표 대상을 조사한 뒤 경쟁 솔루션을 분석해 그 프로젝트에 가장 잘 들어맞는 메트릭만 선정한다. 우리는 모든 단일 KPI를 적용하려고 애쓰지 않으며 프로젝트의 요구를 가장 잘 반영하는 것만을 선정한다.

 

EOD.