업무의 우선순위 정하기

개발팀은 항상 개발범위보다 많은 일을 가지고 있습니다. 그렇다면 어떤 일을 먼저해야 하는 것일까요?

이 글은 SAFe(https://www.scaledagileframework.com/)와 The DSDM Agile Project Framework Handbook(karen) 을 참고하여 작성되었습니다.

개발 업무 우선순위 왜 필요할까?

 

  업무 우선순위를 정하는 것은 애자일에서 매우 중요한 부분입니다. 제품을 만들때 모든 요구사항에 대한 약속을 이행하는 것이 아닌 우선순위가 높은 범위를 먼저 개발하기 때문입니다. 또한 업무 우선순위는 애자일 프로젝트가 아니더라도 중요합니다. 실패한 프로젝트의 경우 우선순위 없이 개발을 진행하다 중요도가 낮은 일만 잔득 완성하고 중요한 몇가지 일을 뒤로 미루다 결국 개발 기간 안에 완성하지 못하게 되는 경우도 있습니다. 중요한 기능이 개발되어 있다면 어떻게든 사용자에게 전달할수 있겠지만 그렇지 않다면 낭패가 아닐수 없습니다. PO와 개발팀이 밀접하게 일한다면 이러한 일이 일어나더라도 바로 잡을 기회가 생기겠지만 PO와 밀접하게 일하지 않거나 PO가 다른 업무로 바쁘다면 언제든 발생할수 있는 일입니다.

 

  개발자는 합의된 우선순위가 없다면 자신의 선택권을 활용하여 합법적인 방식으로 자신이 선호하는 업무를 먼저 진행할수 있습니다. 기술적으로 도전적인 업무를 하거나 스스로의 우선순위를 만들어 진행하게 되는 것이죠.

 

  업무 우선순위는 비즈니스 특성에 따라 그리고 개발 방식에 따라 상황에 따라 달라질수 있습니다. 그래서 어떤 특정한 방식을 도입하여 모두에게 강제시키는 것은 자칫 잘못하면 문제를 일으킬 수도 있는 위험성이 있습니다. 상황은 항상 바뀌기 마련이고 이전에는 고려하지 못했던 요소가 나타날 수도 있기 때문입니다. 따라서 저는 업무 우선순위는 PO의 능력에 의존하는 업무이며 동시에 경험과 직관이 중요하게 고려되어야 한다고 생각합니다. 특정 방식을 모든 상황에 적용하는 것을 경계해야할 이유입니다.

 

  그럼에도 업무 우선순위에 대한 동일한 기준이 있다면 개발팀의 모든 사람에게 쉽게 받아들여질수 있습니다. 또한 공통리소스를 위해서 여러팀이 경쟁할 경우와 같이 이해관계가 다를 경우 수월하게 논의를 진행할수 있는 기준을 마련해 주기도 합니다.

 

  이번에는 Scaled Agile Framework(이하 SAFe)와 DSDM(Dynamic System Development Method)에서 소개하는 우선순위 선정 방식에 대해서 소개하겠습니다.

---

SAFe의 업무 우선순위 산정 방식 WSJF

 

  SAFe에서는 WSJF라는 모델을 사용합니다. WSJF는 Weighted Shortest Job First 의 줄임말이며 일반적인 용어로는 중요하고 개발기간이 짧은 일을 먼저 한다는 의미입니다. SAFe에서 사용하는 용어로는 지연 비용(Cost of Delay)를 기간(Job Duration)으로 나눈 값입니다.

 

WSJF = Cost of Delay / Job Duration

 

이 방식을 통해 SAFe에서는 아래의 관점을 유지하려 합니다.

 

• 경제적 관점
• 매몰 비용에 대한 고려 제외
• 지속적으로 재정적인 관점을 유지
• 의사결정과 통제 방식의 분산화 
• 지연 비용의 정량화

SAFe는 이를 통해서 최고의 경제성을 유지하길 기대합니다.

 

지연 비용(Cost of Delay)는 어떻게 결정되나요?

  SAFe에서 업무를 나타내는 단위는 Feature, Capability 그리고 Epic입니다.(Feature의 묶음으로 가장 큰 업무 단위, Feature는 한개 모듈에서 개발하는 기능 단위, Capabliity는 여러 팀에서 개발하는 기능 단위로 이해하시면 됩니다.) 그리고 각각의 업무 단위는 아래 세가지 요소들의 합으로 계산합니다.

 

• 사용자 비즈니스 가치
• 시기의 적절성(Time Ciriticality)
• 리스크 해결 가능성

지연 비용 = 사용자 비즈니스 가치 + 시기 적절성 +  리스크 해결 가능성

그래서 WSJF는 아래와 같아집니다.

WSJF =  (사용자 비즈니스 가치 + 시기 적절성 +  리스크 해결 가능성) / 개발 기간

 

더 중요한 업무의 크기가 더 크다면?

  아무리 중요한 업무라도 개발 기간이 길다면 WSJF가 충분히 커지지 않기 때문에 업무 우선 순위에서 뒤로 밀릴 가능성이 있습니다. 이를 해결하기 위해서는 PO는 업무를 충분히 작게 나눌 수 있어야 합니다. 그런 방식으로 충분히 높은 우선순위를 달성할 수 있게 됩니다.

  또한 애자일에서 업무를 작게 나누는 것은 쉽지 않지만 중요한 일입니다. 협업을 촉진하고 업무의 진척의 확인을 수월하게 만들기 때문입니다. SAFe의 이러한 업무 우선 순위 모델은 업무를 작게 나누게 만드는 압력을 제공하여 업무를 가시화하고 효율적으로 관리할수 있는 바탕이 되기도 합니다.

 

---

DSDM의 우선순위 모델, MoSCoW

DSDM의 우선순위 모델을  MoSCoW라고 부릅니다. 이 방식은 SAFe의 그것보다 더 대중적으로 알려져 있는데요.

계산식이 없는 단순한 방식이기도 하고 국가의 수도를 연상시키는 이름 때문이기도 합니다.

 

DSDM의 4단계 업무 우선순위 

 

• Must Have - 해당 기간 동안 꼭 해야할 업무 리스트입니다.
• Should Have - 되도록 해야하는 업무 리스트입니다. 일반적으로 완수될 것으로 기대되는 업무 범위입니다.
• Could Have - 시간이 허락한다면 완수할 수 있는 업무 리스트입니다. 약속하는 업무 범위는 아닙니다.
• Won't Have this time - 해당 기간동안 배제할 업무 리스트입니다.

그럼 각 항목을 간단히 살펴보겠습니다.

 

Must Have

  Must Have에서 정의하는 업무리스트는 아래와 같은 속성을 가지며 DSDM에서는 MUST(Minimal Usable SubseT) 요구사항이라고도 표현을 합니다.

  이 항목이 일감들은 아래와 같은 기준으로 선정될 수 있습니다.

• 이 기능 없다면 목표일에 제공하는 것이 의미가 없다.
• 관련 법령에 의해서 꼭 충족해야 하는 것
• 이 기능이 없다면 안전하지 않다.
• 이 기능이 없다면 솔루션이 실행가능하지 않다.

Should Have

 Should Have에 포함되는 업무리스트의 속성은 아래와 같습니다.

• 중요하지만 필수적이지는 않다.
• 제거하는 것은 마음이 아프지만 솔루션은 여전히 가치가 있다.
• 다른 해결책(일시적인 방법이라도...)이 존재한다.

일반적으로 Must Have와 Should Have에 속하는 업무 리스트는 해당 기간동안 개발되길 기대하는 업무의 범위입니다.

그리고 Should Have와 Could Have를 나누는 기준은 미묘하긴 하지만 구현이 되지 않았을 경우에 달성할 수 없는 비즈니스 가치의 크기 또는 영향을 받는 사람의 수로 측정을 한다. 

 

Could Have

Could Have 업무 리스트의 속성은 아래와 같습니다.

• 원하거나 요구가 있지만 덜 중요하다.
• 영향도가 낮다.

Could Have의 업무 리스트는 최상의 개발 퍼포먼스를 통해서 제공할 것으로 생각되는 업무리스트입니다. 문제가 발생하거나 예측이 잘못될 경우에 Could Have의 업무 리스트들은 개발 범위에서 제외될수 있는 후보들이 됩니다. 이 업무리스트은 다른 기능들을 달성할 수 있도록 하는 버퍼가 됩니다.

 

Won't Have this time

 해당 기간동안 구현하지 않기도 합의한 업무 리스트입니다. 프로젝트 범위를 명확히 하는데 도움이 되는 영역이고 이를 통해 비공식적으로 업무리스트에 포함되는 것을 방지하는 효과가 있습니다. 이를 통해 개발팀은 Must/Should/Could Have 리스트에 집중하게 됩니다.

 

DSDM의 권장사항

  Must Have에 해당하는 업무리스트의 양은 개발팀의 자신감의 표현이라고 생각할 수 있습니다. 아니면 고객이나 PO의 압박일 수도 있겠네요. 하지만 DSDM은 Must Have리스트가 해당 기간 업무 리스트의 60%가 넘지 않도록 하는 것을 권장합니다. 만약 60% 이상을 Must Have 업무리스트가 차지하고 있다면 실패의 위험도가 판단될 수 있습니다.

 

  더불어 Could Have의 업무리스트는 20% 정도 유지하길 권장합니다. Must/Should Have 의 업무리스트가 약속할 수는 없지만 일반적으로 기대되는 업무량이라는 것을 감안하면 20%정도의 버퍼를 만들어 Must/Should Have를 집중하여 이해관계자들의 기대를 완수하기 위함입니다.

---

정리하며... 

 

  SAFe와 DSDM에서 소개하는 업무 우선 방식을 소개해드렸습니다. 읽어보시면 아시겠지만 이 것만으로는 기계적으로 업무 우선순위를 만든 다는 것을 불가능합니다. 여전히 PO 또는 PM의 추가적인 노력과 고민이 필요합니다. 다만 이러한 방식이 기존의 노력과 함께 이루어진다면 더 합리적인 방식으로 결정을 내리고 협의하는데 도움이 되리라 생각이 됩니다. 

 

  그리고 되도록 특정 방식만을 고수하기 보다는 상황에 따라 몇가지 방식을 함께 사용하거나 응용하시길 추천합니다. 프로젝트/프러덕트 상황에 맞는 방식을 찾아 적용하셔서 개발 주기가 완료되었을 때 모두를 만족시킬수 있기를 기대합니다.

 

감사합니다.

 

- CHAD -