애자일 메트릭: 7가지 카테고리

애자일 메트릭: 7가지 카테고리

 

WILL HAYES
SEPTEMBER 22, 2014

 

점점 더 많은 미 국방성 시스템의 소프트웨어 공급자가 애자일 방법론에 찬성하며 전통적인 폭포수 개발 관행에서 이동하고 있다. 이 블로그의 이전 포스트에서 작성했듯이 애자일 방법론은 출시 주기를 단축하고 비용을 관리하는 데 효과적이다. 하지만 애자일의 장점을 국방성에 효과적으로 실현하려면 소프트웨어 인수의 감독 권한이 있는 인력이 이러한 프로그램을 감시하는 데 쓰는 메트릭에 능숙해야 한다. 이 블로그 포스트는 애자일 방법론을 적용한 개발자가 만든 주요 시스템의 소프트웨어 개발 인수 감독자를 위한 참고 자료를 위해 카네기 멜런 대학 소프트웨어 연구소의 연구자들이 만든 노력의 결과를 강조한다. 또한 이 포스트는 애자일 메트릭을 추적하기 위한 7가지 카테고리도 보여준다.

 

소프트웨어에 대한 경험적 접근법

 

국방성과 정부 기관은 내부 리소스를 활용해 소프트웨어 집약적인 시스템을 만드는 대신 점점 더 조달에 의존한다. 하지만 인수 프로그램은 공격적인 비용, 일정 그리고 기술적인 목표를 달성하는데 자주 어려움을 겪는다. 이 블로그에서 보고한 조사는 국방성에 적용하는 인수 전문가를 돕고 애자일 소프트웨어 개발 방법론을 효과적으로 사용해 이러한 도전과제를 극복하기 위한 우리의 지속적인 작업의 일부분이다. 우리의 최근 조사는 진척 평가와 계약자에 집중하고 있고 이것은 정보 보증을 포함해 인수 관련 문제, 일부 국방성 관리 체계를 조사한 우리의 이전 조사를 확장하였다.

 

우리가 지원하는 정부와 군 기관의 많은 프로그램 오피스는 그들의 제공 업체와 계약자들이 애자일 방법론을 적용한다는 것을 확인하고 있다. 이러한 프로그램 오피스는 전통적인 방법이 아닌 더 적은 증분 방식으로 더 빠르게 소프트웨어 제품을 인도받는 새로운 방법을 발견한다. 하지만 프로그램 오피스는 이런 기술에 어려움을 겪고 있고 이것은 진척도에 관한 통찰을 얻는 데 필요한 메트릭에 경험이 부족한 것이 그 이유이다. 그런 환경에서 사용되는 측정값을 위한 잘 이해되는 정의와 정교한 체계가 존재한다.

 

우리가 애자일이란 용어에 대해 작성된 내용, 훈련된 내용, 논의한 내용을 살펴보면 자기 주도적으로 협력하는 5 ~9명의 개인으로 구성된 팀에 관심이 집중된다. 이 팀은 고객에게 가치를 전달하는 것에 매우 집중하고 경험적인 접근법을 적용하지만, 대부분의 논의는 작은 팀에 집중한다.

 

스크럼에서는 의사 결정이 사전에 상세하게 정의된 계획에 따라 이루어지기보다는 관찰과 실험을 기반으로 한다는 점에 유의하는 것이 중요하다. 경험적인 프로세스 통제는 투명성, 관찰 그리고 적응이라는 핵심 아이디어에 의존한다.

 

대다수 국방성 프로그램의 상황에서 애자일 방법론의 사용은 전례가 없다. 하지만 최근까지의 저작물과 훈련 과정은 개발팀의 아주 좁은 범위에만 집중되고 있다. 우리의 조사 결과를 보면 애자일 방법론을 적용한 조직이 소규모 팀 중심의 평가와 기업 또는 프로그램 수준의 평가 사이의 추상적인 영역을 잘 채우고 있는 것으로 보인다. 따라서 극복할 도전과제 중 하나는 애자일 방법론을 사용해 성공을 거두는 자기 주도적인 팀을 위해 필요한 환경을 위반하지 않으면서 큰 규모의 프로그램 관리에서 필요한 것을 충족하는 일이다.

 

중간 크기에서 거대 크기의 많은 조직에서 수행하는 평가란 대체로 한 조직이 다른 조직에 이익을 주기 위해 부여하는 의무이고 또 다른 개인에 의해 요청되어 실행된다. 너무나 빈번하게 사람들이 팀 리더나 프로젝트 관리자로부터 메트릭을 제출하라는 요구를 받을 때 방어적이 된다. 이러한 역학 관계는 소프트웨어에 대해 경험적인 접근법을 위한 근간을 제공하려는 의도를 가진 애자일 방법론의 가치를 제한할 수 있다.

 

이러한 경험적인 접근법이 담고 있는 것은 에드워드 데밍의 계획-실행-점검-보완 주기를 즉시 개인적인 수준에 집중해 실행하게 만든다. 소프트웨어에 대한 이런 접근법은 개발자들 사이에 더 자주 논의되는 방향으로 진화한다. 이러한 접근법의 또 다른 특징은 그러한 논의가 제품 그 자체에 매우 집중한다는 점이다.

 

애자일 헌장과 그 안에 담긴 12가지 원리의 문맥을 살펴보면 진척을 증명하는 최상의 방법은 기능을 데모하는 것으로 종이에 담긴 추상물을 대신해 실제 작동하는 제품을 보이는 것이다. 당연히 추상물 없이 제품이 만들어지지 않았을 것이지만 애자일 방법론의 맥락에서는 데모할 수 있는 결과물과 팀이 스스로 사용하기 위해 수집한 데이터에 집중한다.

 

애자일 메트릭

 

애자일 소프트웨어 개발에서 중요한 메트릭 중 하나는 비즈니스 가치를 전달하는 것이다. 이런 진척의 평가는 관찰을 기반으로 하면서도 팀 조직력을 해치지 않는다. 이런 작업에 대한 우리의 핵심 목표는 프로그램 관리자가 진척을 더욱 효과적으로 측정하는 데 도움을 주는 것이다. 동시에 우리는 팀이 프로그램 수준에서 쓰이는 메트릭과는 차별화되면서도 팀에게 고유한 메트릭을 사용해 자신만의 환경에서 일하기를 원한다.

 

이런 주제에 관해 우리가 출간한 기술 보고서인 "애자일 메트릭: 애자일 계약자의 진척 모니터링"은 애자일 방법론의 구현에서 일반적인 3가지 핵심 측면을 자세히 설명한다.

 

속도. 간단히 말해 해당 팀에서 구체적인 시간 안에 달성한 작업의 양이다. 대체로 이것은 스프린트 당 달성한 스토리 점수로 측정한다. 가끔 애자일 실무자들은 이런 측정값을 "어제의 날씨"로 부르는데 이것은 계절적 경향뿐만 아니라 지역적 상황에 대한 민감도를 나타내는 것과 유사하다. 실제로 대부분의 전문가는 속도를 "팀마다 고유한 값"으로 설명하며 이 측정값을 추정 모델에 실수가 있다는 걸 나타내는 한 가지 파라미터로 간주한다. 그 팀은 즉시 작업에 대한 자신만의 속도를 구축해야 한다.

 

스프린트 번다운 차트. 우리 기술 보고서에 기술된 바와 같이 이 그래픽 기술은 하나의 스프린트 동안에 개발팀의 진척을 나타내는 수단을 제공한다. 작업 백로그에 있는 하나의 아이템이 완료되면 차트가 진행 상황의 비율과 양을 표시한다. 일반적으로 이와 같은 차트는 팀에 있는 일반적인 벽이나 전자적인 대시보드에 표시된다.

 

릴리즈 번업 차트. 일반적으로 스프린트 번다운의 보완적인 그래픽 기법으로 릴리즈 번다운 차트가 사용된다. 많은 이들은 이 두 가지 차트를 사용하는 수학적 원리는 없지만 스프린트 번다운과 릴리즈 번다운에 집착한다. 각각의 스프린트가 완료되면 출시할 기능이 늘어나고 릴리즈 번다운 차트는 직관적이고 논리적인 형태로 진척 사항을 표현한다. 이 개념은 작업흐름 관리 도구로 이용되고 또 다른 개념 확장으로 이어진다.

 

우리 연구에는 국방성 인수 프로그램에서 애자일 공급자와 성공적으로 작업했던 현업 전문가의 통찰을 우리에게 전해준 애자일 계약 관리 담당자와의 인터뷰도 포함되어 있다.

 

우리의 보고서는 애자일 계약을 관리하는 인력과의 인터뷰를 바탕으로 프로그램이 국방성의 일반적인 규정 요구사항을 준수하는 데 도움이 되는 성공적인 진척 관리의 7가지 방법을 확인했다.

 

일반적으로 애자일 방법론을 사용할 때 소프트웨어의 크기는 스토리 점수로 표현한다. 이 방법은 사용자의 관점에서 기능을 분해하는 사용자 스토리의 지지를 받는다. 이런 사용자 스토리로 시스템 기능을 추적하면 작업의 계층 관계를 의미 있게 소통할 수 있으며 전달된 기능에 기반한 진척 관리 모니터링은 코드 라인 수나 기능 점수와 같은 대체물이 아닌 유용성과 기능에 집중할 것이다.

 

지식 집약적인 작업에서 공수와 인력 구성이 주요 비용 요인이기 때문에 추적해야 한다. 애자일 방법론을 사용해도 이런 기본적인 사실은 변하지 않으며 진척을 모니터링하는 데 쓰이는 메커니즘을 크게 바꾸기 때문에 이런 추적은 필수적이다. 하지만 인력 활용 형태의 변화가 나타난다. 애자일 방법론을 사용할 때 통합 개발팀이 꾸준한 운율을 유지하며 전문적으로 구성된 인력의 노동력이 들고 나는 경향이 덜하다. 일반적으로 애자일 팀은 비록 몇 가지 특화된 기술은 임시직으로 포함하더라도 개발팀 내부에 필요한 기술을 전부 채워 넣는 것을 볼 수 있다. 따라서 계약자의 이러한 성과 요소를 모니터링하는데 적용되는 법칙의 개정이 필요하다. 개발 공수의 초기 단계에서 인력 구성이 느리게 진행되면 문제가 될 수 있다. 그리고 그 개발 프로그램의 마지막 절반에 (전통적으로 테스팅 활동이 접수하는) 개발 인력의 활용이 감소하는 계획도 재조정되어야 한다. 조직에서는 개발팀의 영역 바깥에 시스템 테스팅이나 리그레션 테스팅을 수행할 테스트 팀을 만들 수도 있다.

 

전통적으로 일정을 작업 속도의 결과로 간주한다. 애자일 개발은 이런 변수를 고정할 의도로 잘 정의된 시간 단위로 개발팀의 작업 성과를 최대화하려고 노력한다. 이와 같은 이유로 요구사항을 전달해야 하며 수행 작업의 우선순위를 조정해야 하는 이해관계자에게 중요한 요구가 발생한다.

 

애자일 방법론은 품질과 고객 만족의 영역에서 전통적인 개발 방법론이 제공하는 것보다 더 많은 통찰력 제공의 기회를 제공한다. 작동하는 소프트웨어의 빈번한 전달에 집중하게 되면 고객이 요구사항 스펙이나 디자인 문서와 같은 중간 작업 결과보다 제품 그 자체를 살펴보게 만든다. 검증 기준에 강하게 집중하면 (주로 "완료의 정의"로 부른다) 필요한 기능과 고객에게 중요한 제품의 속성에 대한 이해가 더 강화된다.

 

비용과 자금 지원 구조는 애자일 방법론의 반복적인 속성을 최대한 활용하는 방향으로 맞춰질 수 있다. 선별적인 계약 자금지원 라인 또는 무기한 납기 무기한 수량 (indefinite delivery indefinite quantity_IDIQ) 계약 구조는 개발 조직의 작업을 계획하고 관리하는데 유연성을 줄 수 있다. 이를 위한 계약 구조를 고려하는 더욱 상세한 논의는 이어지는 간행물의 주제이다.

 

애자일 개발 맥락에서는 전통적이고 거대규모인 폭포수 개발 방법론과는 반대로 요구사항이 아주 다르게 표현된다. 대체로 애자일 방법론이 적용될 때 (국방성 말투로 정의된) 완전하고 상세한 요구명세를 개발 활동 시작의 사전조건으로 간주하지 않는다. 하지만 사용자 스토리에서 나타난 것처럼 요구사항의 명확화, 정교화 그리고 우선순위 재조정의 유연성은 많은 거대 규모 프로그램에게 이익인 것으로 증명될 수 있다. 전통적인 방법론에서는 요구사항 변경의 비용이 유지보수가 되어야 하는 일련의 중간 작업 결과 전체에 자주 파급 효과를 보인다. 애자일 개발에서 자주 보이는 빠른 속도의 증분식 방법론은 재작업의 수준을 낮추는 데 도움이 될 수 있다.

 

전달과 진척 모니터링은 전통적인 접근법에 비해 애자일 개발이 가장 다르게 보이는 영역일 것이다. 자주 작업 중인 소프트웨어 제품을 전달하면 (잠재적으로는 출시할 수 있는 형태로) 일반적인 중간 산출물의 검사를 통한 것보다 더 직접적인 진척 관찰이 가능하게 된다.  시스템 기능을 데모로 보이면 예산이나 일정 내에 개발팀이 완성할 수 있는지 묻지 않고도 최종 제품을 재조정하고 개발팀이 원하는 기술적 성능으로 옮겨갈 빠른 기회를 얻는다.

 

전망

 

우리는 애자일 구현자로부터 성과 진단과 진척을 데모로 보이는 새롭고 창의적인 방법을 계속 배우고 있다. 이런 접근 방법의 가치는 이것이 실세계의 경험에서 나온 서사를 표현한다는 점이다.

 

우리는 이 연구를 통해 애자일 팀이 데이터를 분석할 때까지 기다리지 않는다는 것을 목격했다. 향후의 연구는 데이터 흐름에 대한 초기 분석에 집중할 필요가 있다. 이러한 데이터 흐름을 분석하는 데 필요한 시각적 표현은 우리가 보아온 전통적인 것이 아니다. 이런 맥락에서 적용이 필요한 분석 기법과 사용 할 수 있는 기준선은 좀 더 단기적이고 좀 더 즉각적인 피드백, 역사적인 기준선의 지능적인 사용과 같이 다른 형태를 띤다.

 

EOD.