애자일 메트릭: 감독의 새로운 접근법

애자일 메트릭: 감독의 새로운 접근법

 

WILL HAYES

DECEMBER 18, 2017

 

최근 들어 정부 소프트웨어 인수 프로그램이 전통적인 폭포수 개발 방법론에서 애자일 접근법으로 광범위하게 이동되었다. 이러한 전환은 정부 소프트웨어 인수를 감독하는 종사자에게 애자일 방법론으로 개발된 시스템을 모니터링하는 데 쓰는 메트릭에 능숙해져야 할 필요성을 만들었다. 이 게시물에서는 애자일 메트릭에 대한 나의 이전 게시물에 이어 정부 프로그램과의 최근의 의견 교환을 바탕으로 개정된 우리의 애자일 메트릭 작업을 제시한다.

 

폭포수에서 애자일로의 전환에 따른 기회와 도전과제

 

애자일 방법론은 소프트웨어 제품이 운영되는 환경의 관행보다 더 적은 증감분으로 더 빠르게 프로그램 오피스가 소프트웨어 제품을 출시하도록 해준다. 애자일 개발 방법론은 정부 환경에서 점점 더 눈에 띄게 되고 새로운 기능을 빠르게 배포할 기회를 만든다. 하지만 애자일 방법론 역시 전통적인 정부 감사와 관리 관행에 도전과제를 제기한다. 예를 들어 정부의 인수자는 진행 상황을 평가하는 데 필요한 메트릭에 관해 경험이 부족하다. 따라서 필요한 통찰을 얻는 데 어려움을 겪는다. 특히 애자일 방법론을 사용해 성공하려는 팀에 필요한 행동을 방해하지 않으면서 거대 규모 프로그램 관리의 필요성을 만족해야 하는 도전과제가 존재한다.

 

애자일 환경에서 감독 방법이 바뀌는 것은 감독 조직이 과거에 경험하지 못했던 새로운 주기에 대해 다른 질문을 하는 것을 의미한다. 따라서 측정 방법과 보고 방법이 달라진다. 애자일 방법론은 소프트웨어에 대해 경험적인 접근법을 강조한다. 따라서 애자일 메트릭은 데모할 수 있는 결과물에 집중한다. 나는 이 주제에 대해 "애자일 메트릭: 애자일 계약자의 진척 모니터링"이라는 기고문을 공개했고, 이 기고의 기술 노트를 바탕으로 발견한 것을 이전 게시물에 요약했다. 우리는 그 기술 노트에서 애자일 팀 메트릭의 3가지 주요 관점인 속도 (velocity), 스프린트 번다운 차트 (sprint burn-down chart) 그리고 릴리즈 번업 차트 (release burn-up chart)를 언급했고 이것은 대부분의 팀 단위 애자일 구현에서 일반적이다.

 

우리는 이와 같은 이전 작업 결과를 통해 미국 국방성에서 쓰이는 규정 요구사항을 만족하게 도와주는 애자일 개발의 진척 감시 도구인 소프트웨어 크기, 공수와 인력 구성, 일정, 품질과 고객 만족, 비용과 예산, 요구사항 그리고 출시와 진척 항목을 확인할 수 있다. 대부분의 미 국방성 인수 프로그램과 협업한 우리의 작업 결과는 팀 단위가 아니라도 규모에 맞게 이런 이슈를 처리하는 데 집중할 수 있게 해주었다.

 

계획 달성 실패

 

대부분의 메트릭 접근법은 데이터를 수집하고 평가하는 "계획 합치성" 관점을 주로 사용한다. 소프트웨어 개발과 관련된 이해당사자는 당연히 다음과 같은 질문에 신경 쓴다.

 

• 산출물이 제때 도착하는가?
• 계획된 곳에 예산이 집행되었나?
• 요구사항에 명시된 대로 제품이 동작하나?
• ... 그리고 목록이 이어진다 ...

위의 모든 질문은 기준 요구사항, 예산 그리고 일정 (그리고 남은 기간)이 그 프로그램에 맞는 올바른 목표라고 가정한다. 미 국방성 포트폴리오에 있는 대부분의 인수 프로그램을 살펴보면 그 프로그램의 생애주기 전체를 통틀어 요구사항, 예산 그리고 일정에 대한 주기적인 기준선 재조정이 발견된다. 진화하는 사용자의 요구로 (그리고 기술 혁신) 대체된 요구사항을 오래된 계획으로 강제 준수하는 방식으로 프로그램을 관리하는 것은 현명해 보이지 않는다. 그러나 우리가 일반적으로 사용하는 메트릭은 바로 그 방향으로 우리를 인도한다!

 

성공적인 애자일 프로그램은 그 계획을 목표 그 자체로 취급하기보다는 원래의 계획이 달성하려고 했던 결과에 집중을 유지하면서 적법한 이해관계자들의 질문을 만족한다. 동작하는 소프트웨어의 증감식의 출시를 기반으로 경험적인 프로세스를 적용하면 최종 결과의 단기적인 상태를 알 수 있다. 이런 반복적인 접근법은 전통적인 폭포수 접근법에서 일반적인 장기간의 목표 대비 진행 상황을 대리인에게만 의존하는 것과 극명하게 대비된다. 애자일 조직에 유용한 메트릭은 그 프로그램의 장기적인 로드맵과 성과 목표의 큰 그림을 처리하면서도 결과물을 개선하는 단기와 지역적인 행동을 불러일으키는 전술적인 집중력을 가진다.

 

활용률이 아닌 흐름에 집중

 

대규모 인수 프로그램에서 일해보면 "계획 준수"에 대한 강조가 애자일 성공을 저해하는 걸 볼 수 있다. 예를 들어 10억 달러 프로그램의 일정이 늦어졌을 때, 프로그램 관리자의 본능은 각각의 과제가 제시간에 끝났는지 (계획 대비) 그리고 리소스의 100퍼센트를 활용하는지 (심지어 원래 용량 이상으로 사람들을 압박해) 확인하며 상세에 집중한다.

 

하지만 상세 수준에서 변동성을 제한하려는 의도된 개입은 지식 집약 작업에 포함된 불확실성을 과도하게 정정할 가능성이 있다. 대규모 프로그램은 많은 움직이는 부분의 총합이며 어떤 과업은 예측 대비 빨리 완료되고 다른 것은 늦게 완료된다. 프로그램 수준에서 계획과의 일치성은 가장 낮은 수준에서 계획과의 일치성의 밀도를 높인다고 해서 달성할 수 없다. 프로그램이 문제에 빠지면 우리의 본능은 작은 과제를 마이크로 매니징하면서 전체 프로그램이 제 궤도에 오르기를 희망한다. 하지만 실제로는 우리가 아무리 계획을 잘 세운다고 해도 각각 매 15분짜리 과업이 계획에 적힌 대로 완료되는 것을 기대하는 것은 비현실적이다.

 

본질적으로 변동성 높은 프로세스에 이런 결정론적 취급을 하는 것은 소프트웨어 프로젝트 관리를 어떻게 할지 설명하기 위해 제조업의 사례에 의존하던 유물일 수 있다. 우리는 기술적 과업 사이의 연관성이나 (무엇보다도) 인력들 사이에 넓게 퍼져 있는 공학적 재능에 대한 인정 없이 마이크로와 매크로 사이에 엄격한 대수 관계가 (algebraic relationship) 있는 것처럼 행동한다. 직원들의 일정을 빡빡하게 조정해 압박한 상태에서 다중 업무를 수행하라고 요구하는 것은 그 프로그램의 속도를 높이는 결과로 이어지지 않는다. 아래 그림이 묘사하는 개입을 생각해 보자.

 

이렇게 활용률에 잘못 집중하면 거의 확실하게 더 긴 주기 시간을 낳게 되어 원치 않는 지연을 도입한다. 많은 소프트웨어 개발 인력은 줄어들기보다는 늘어나는 요구사항을 맞추려는 노력으로 자신들의 시간을 좀 더 작은 주기로 나눈다. 우리는 이런 새로운 형태의 그리드락 (gridlock)에서 과거의 긴 죽음의 행진 프로그램을 우리가 스프린트라고 부르는 연속적인 2주 단위의 지구력 경기로 변환한다. 즉 깨어 있는 모든 시간은 상세한 예측을 맞추는데 과격하게 집중하는 마라톤과 같다.

 

가장 붐비는 고속도로의 진입로에 있는 교통 신호를 보게 되면 차들 사이에 약간의 간격을 도입해 차량 흐름을 개선하는 걸 볼 수 있다. 어느 시점 이후에는 활용률이 흐름에 반한다. 유료 주차장 관리인이 주차장을 100퍼센트 활용하려고 노력하면 고속도로 예시와는 다른 목표를 가진다. 상세 예측을 얼마나 완수했는지만 보고 개발 조직을 평가하면 개발 중인 기능을 성공적으로 생산했는지가 아닌 프로젝트 계획 그 자체를 목표로 하게 된다.

 

프로젝트 관리가 아닌 결과에 집중

 

우리는 애자일 프로그램을 감독하는 정부 인력이 자신들의 초점을 해당 소프트웨어 시스템을 사용해서 얻을 수 있는 결과에 집중하는 걸 보게 된다. 개발팀이 시연하는 최소 기능 제품은 (minimum viable products) 강력한 미션 집중력을 요구한다. 시스템 성과의 평가는 (예를 들면 핵심 성과 파라미터) 그 평가가 가끔은 후행적으로 검토되는 주요 이정표로 강등되기는 하지만 정부 인수자에게 항상 중요하다. 

 

개발자의 우선순위를 관리하는 로드맵에 맞춰 우선순위가 지정된 기능을 적시에 출시하는 것이 강조되어야 한다. 비용이나 일정과 같은 프로젝트 관리 성과를 나타내는 대리 지표는 중요하다. 하지만 그것을 강조하는 정도는 운영상의 요구를 맞춰야 하는 중요성에 비할 바는 아니다.

 

성공적인 애자일 조직이 프로젝트 계획에 나온 파라미터만 맞추려고 집중하기보다는 명확한 단기 우선순위를 제공하고 그 작업의 인수 기준에 집중해 팀을 관리하면 소프트웨어 개발 전문가들이 자신의 직무를 추구한다는 사실을 알 수 있다. 애자일의 의도는 개발자가 피벗을 할 수 있게 짧은 배움 주기를 가능하게 해서 필요한 경우 시스템을 운영하는 사용자의 필요에 더 이익이 되는 방향으로 이동하는 데 있다.

 

해당 솔루션에서 무엇이 필요한지를 더 자세히 알려면 그 시스템에서 정부가 얻고자 하는 이익에 대한 날카로운 감지가 필요하다. 정부 인수 관리자가 차례대로 이 목표를 달성하려면 제품 품질에 관한 흔들림 없는 집중과 미션 요구사항에 대한 강조와 더불어 소프트웨어 개발 공수로 얻을 수 있는 것에 대한 다양한 질문을 던져야 한다. 정부 인수자가 애자일 개발의 장점을 충분히 얻기 위해서는 예산과 일정이 아닌 미션 요구사항에 따라 평가되는 소규모 배치 작업의 반복적인 출시에 맞게 감독해야 한다.

 

마무리와 전망

 

우리는 애자일 방법론으로 전환하는데 애쓰는 국방부 직원들을 계속 지원하면서 이 블로그 같은 매체를 통해 그들이 제공하는 교훈과 통찰을 보고할 것이다. 단기적으로는 특히 오픈 시스템과 관련한 개념이 들어간 아키텍쳐의 득세가 애자일 방법론을 최적화하기에 더 중요해지기 시작할 것이다. 장기적으로는 소프트웨어를 넘어 하드웨어와 프로그램의 다른 측면을 시스템 수준에서 반복적이고 증감식의 방식으로 통합하는 데 집중할 필요가 있다고 보인다. 
  

EOD.