Posts [에센셜 스크럼] Chapter7 - 추정 및 속도
Post
Cancel

[에센셜 스크럼] Chapter7 - 추정 및 속도

개요

제품 개발을 계획하고 관리할 때 우리는 “얼마나 많은 제품 기능을 완성 시킬 것인가?” “언제 일을 마칠 것이며 비용은 얼마나 들 것인가?” 와 같은 중요한 질문에 답을 내야 한다.

스크럼에선 위 질문에 답을 내기 위해 우리가 만들고 있는 것의 크기 를 추정해야 하고 일을 할 수 있는 속도 혹은 비율 도 측정해야 한다. 이 정보를 가지고 우리는 제품 기능 목록의 크기를 팀의 속도로 나누어 가능한 예상 개발 기간을 얻을 수 있다.

image

  • 크기: 각 제품 백로그 항목의 크기를 추정 후 합한 값
  • 속도: 스프린트 기간 동안 완성된 모든 항목의 크기(추정치)를 합산한 값, 스프린트 마다 얼마나 많은 일을 하는지
    • 평균 속도: 위에서 말한 속도들의 중간 값
  • 예상 기간: 추정 크기 / 측정 속도 (스프린트 갯수)

위의 예시에선 200포인트(추정 크기)를 20포인트(속도)로 나눔으로써 10개의 스프린트라는 기간을 예측 할 수 있다.

하지만 여기서 속도 범위를 사용하는 것이 평균 속도를 사용하는 것보다 더 정확한지 후반부에서 설명하겠다. 여기선 임시로 평균 속도를 사용했다.

크기, 속도,기간의 관계는 변하지 않지만 개발 과정에서 어느 단계에 있느냐, 무엇을 측정하려고 하느냐,그리고 어떻게 그 데이터를 사용하려고 하느냐에 따라 일부 세부사항은 달라질 수 있다. 하고자 하는 일, 시기에 따라 추정과 속도가 어떻게 바뀌는지 더 자세히 살펴보자.

무엇을 언제 추정하는가

제품 개발 주기에 걸쳐 여러 가지 다양한 묶음을 추정해야 하고, 그에 따라 다른 추정 단위를 사용해야 한다.

대부분의 조직들은 세 가지 다른 수준의 세부 사항을 계획하기 위해 추정치를 만든다. 이 추정치들은 포트폴리오 백로그, 제품 백로그, 스프린트 백로그 에서 사용된다.

image

포트폴리오 백로그 항목 추정

포트폴리오 백로그 항목의 우선순위를 적절하게 정하기 위해선 각 항목의 대략적인 비용을 알아야 한다. 하지만 초기 단계에선 요구사항이 완전하지도 자세하지도 않으므로 표준 방식(각 항목의 추정치를 합산해 총 비용의 추정치를 내는 방식)은 사용할 수 없다.

대신 티셔츠 사이즈처럼(스몰, 미디움, 라지, 엑스라지) 대략적이고 상대적인 크기 추정치를 사용한다.

제품 백로그 추정 - 그루미 활동의 일부

제품 백로그 항목 우선순위가 만들어지고 더 자세하게 그루밍되었을 때, 대부분의 팀이 주로 스토리 포인트나 이상적인 날짜와 같은 숫자로 추정치를 나타내는 방식을 선호한다.

제품 백로그 항목을 추정하는 것은 전체 제품 백로그 그루밍 활동의 일부로서 새로운 제품 백로그 항목 추정치가 필요하면 PO가 스프린트 기간 동안 추가적인 추정 회의를 소집할 수도 있다.

하지만 모든 팀들이 제품 백로그 추정 활동이 필수적이라 생각하진 않는다. 이들의 경험에 따르면 충분히 좋은 스크럼팀은 제품 백로그 항목을 대략적으로 같은 크기로 작게 만들 수 있다. 이런 팀원들은 작고 크기가 비슷한 항목들의 추정치를 내는 것이 낭비라 결정을 내렸고, 대신에 제품 백로그 항목의 개수를 센다. 이들은 여전히 속도 개념을 사용한다. 하지만 속도는 한 스프린트 내에서 완성된 제품 백로그 항목 크기의 합이 아닌 한 스프린트에서 완성되는 제품 백로그 항목의 개수로 측정한다.

하지만 필자는 몇 가지 이유로 인해 제품 백로그 항목의 추정을 선호한다.

  • 모든 제품 백로그 항목이 같은 시기에 같은 크기가 되진 않기 때문이다.
  • 팀이 제품 백로그 항목을 대략 같은 크기로 나누는 기술을 얻는데에는 어느 정도 시간이 필요하다.
  • 스토리의 크기를 같게 만들기 위해 부자연스런 부분에서도 스토리를 나누게 된다.
  • 가장 중요한 것은 추정의 가장 중요한 가치 중 하나가 추정치에 대한 대화도중에 발생하는 학습이라는 점이다. 어떠한 의견 충돌이라도 즉각적으로 표면화되고 짐작만 하고 있던 것들을 강제로 드러낸다.

작업 추정

이상적 시간(ideal hour)으로 작업의 크기를 정하는데, 이상적인 시간은 또한 노력 시간, 맨 아워, 한 사람이 한 시간에 하는 일이라고도 한다.

위 이미지의 팀은 사용자 인터페이스 작업을 완성하기 위해 다섯 시간의 일을 해야한다고 추정하고 있다.

하지만 이는 실제 다섯 시간의 경과 시간을 의미하는 것이 아니다. 추정치는 단순히 팀이 그 작업을 위해 얼마나 많은 노력을 기울이기를 기대하는지 서술한 것이다.

제품 백로그 항목 추정 개념

위의 세 가지 수준의 세부 사항이 중요하긴 하지만 이번 포스팅에서 중점을 두는 것은 제품 백로그 수준의 추정 이다. 제품 백로그 항목을 추정할 때 스크럼 팀이 사용하는 몇 가지 중요한 개념이 있따.

  • 팀으로서 추정
  • 추정치는 약속이 아니다
  • 정밀도가 아닌 정확도에 초점을 맞춤
  • 상대적 vs 절대적 크기 사용

팀으로서 추정

개인적으로 가장 핵심적인 부분이지 않을까 싶다. 스크럼에선 한 가지 단순한 규칙을 따른다. 함께 협력해서 일을 하는 사람들이 추정을 한다.

명확히 말하면 일하는 사람들이란 직접 제품 백로그 항목을 설계하고 제작하며 테스트 할 개발팀이다. 제품 책임자와 스크럼 마스터는 추정치를 내지 않는다. 그렇다면 제품 책임자와 스크럼 마스터는 무엇을 하느냐?

  • 제품 책임자: 제품 백로그 항목을 설명하고 팀이 항목에 대한 질문이 있을 때, 요구 사항을 분명하게 해주는 역할
  • 스크럼 마스터: 추정 활동을 코칭하거나 퍼실리테이팅하는 역할

개발 팀 의 목표는 협력적인 시각 에서 제품 백로그 항목의 크기를 정하는 것이다. 모두 스토리를 다른 시점에서 보기 때문에 개발 팀의 각 전문 분야를 대표하는 팀원 모두 참여하는 것이 중요하다.

추정치는 약속이 아니다

추정치를 약속으로 다루지 않는 것 이 중요하다. 왜 그럴까?

추정치를 약속으로 다루게 되면 모두가 원래 맞다고 생각한 것보다 훨씬 더 큰 추정치를 낼 것이다. 추정은 반드시 무언가가 얼마나 큰지에 대한 현실적인 측정 이어야 한다.

정확도 대 정밀도

추정은 정확해야 하지만 지나치게 정밀해선 안된다. 왜 그럴까?

  • 자세한 추정치를 내는데에는 상당한 노력이 들 수 있으며, 이 노력이 낭비가 될 수 있다
  • 착각을 기반으로 중요하고 비용이 많이 드는 비즈니스 결정을 잘못 내릴 때 낭비가 생긴다. 이해하지 못한 것을 이해했다고 스스로를 속일 때 이런 일이 발생할 수 있다.

그럼 어느 정도로 해야되는가? 우리는 대략적인 추정치를 얻는데에 적정한 노력을 투자해야 한다.

image

추정을 하다보면 항상 들어가는 노력에 비해 정확도(accuracy)가 향상되지 않기 시작하는 지점이 있다. 이 지점을 넘어가면 가치가 낮은 데이터가 점점 늘어나 추정치의 정확도에 악영향을 미치고, 시간이 낭비된다.

상대적 크기 추정

절대적인 크기가 아닌 상대적 크기로 추정을 해야한다. A는 2이고 B는 A의 2배정도라면 4로 잡는 듯이 말이다.

한 강의실의 학생들에게 실제 벽의 거리가 정확히 몇 미터인지 물어볼땐 학생들은 각각 색다른 답을 내놓는다. 하지만 중간쯤 위치한 프로젝터의 상대적 위치를 물었을땐 거의 대부분이 “중간” 이라는 상대적 수치를 내놓는다.

절대적인 크기보다 상대적인 크기를 실제로 더 잘 판단할 수 있다는데 대부분의 사람들이 빠르게 동의한다. 요점은 사람들에게 추정치를 내라고 할 때 사람들이 잘 못하는 것(절대저거 크기 추정)이 아닌, 잘 하는 것(상대적 크기 추정)을 바탕으로 해야 한다는 것이다.

제품 백로그 항목 추정 단위

제품 백로그 항목 크기를 추정하는 표준화된 단위는 없지만, 지금까지 스토리 포인트이상적 날짜가 가장 흔하게 사용된다. 필자가 일한 70%의 조직은 스토리 포인트, 30%의 조직은 이상적 날짜를 사용했다.

스토리 포인트

스토리 포인트는 제품 백로그 항목의 크기 혹은 규모를 측정한다.

스토리 포인트는 복잡성, 물리적 크기와 같은 요소를 하나의 상대적 크기로 합친다. 스토리 포인트의 목표는 스토리 크기를 비교하는 것이다. 그러면 “티켓 스토리 제작이 2포인트면, 티켓 스토리 검색은 8포인트이다.” 같은 표현을 사용할 수 있게 된다. 이는 검색 스토리가 제작 스토리보다 대략 4배가 크다는 의미를 내포한다.

스토리 포인트 같은 크기 측정치는 결국 기간을 계산하는데 사용되기 때문에 반드시 스토리를 개발하기 위한 노력에 대한 개발 팀의 관점을 반영해야 한다.

이상적 날짜

이상적 날짜는 스토리를 완성하는데 필요한 노력 일자(effort-days) 혹은 맨 아워(man-hours)를 나타낸다.

하지만 책의 예시처럼 이상적 날짜와 실제 달력의 날짜를 오해하면 안된다. 특정 제품 백로그 항목이 2일이라고해서 꼭 달력의 2일 동안 완료해야 되는 것은 아니란 얘기다.

사람들이 이상적 시간을 오해할 것이라 생각한다면 스토리 포인트를 사용하는 것이 나을 것이다.

플래닝 포커

플래닝 포커는 제품 백로그 항목 크기를 정하는 방법으로 제임스 그레닝에 의해 처음 설명되었고, 마이크 콘에 의해 인기를 얻었다. 아래 이미지처럼 플래닝 포커는 몇 가지 중요한 개념을 바탕으로 한다.

image

플래닝 포커는 합의를 바탕으로 추정 하기 위한 기술이다. 제품 백로그 항목을 작업하기 위해 선발된 지식인들이 가정을 드러내고 공통의 이해를 얻으며 제품 백로그 항목의 크기를 재기 위해 강도 높은 논의에 참여한다. 플래닝 포커는 정확한 그루핑이나 비슷한 크기의 아이템들을 한 곳에 모아 상대적 크기를 산출한다. 팀은 이미 추정한 제품 백로그 항목의 추정 이력을 이용해 더 쉽게 다음 제품 백로그 항목을 추정할 수 있다.

추정 등급

팀은 플래닝 포커를 실행하기 위해 어떤 등급이나 수열을 추정에 사용할지 결정해야 한다. 우리가 추정하는 목적이 정밀보단 정확하게 추정하려는 것이다보니 모든 숫자를 사용하지 않는다. 대신에 범위가 작으면 더 많은 숫자를 사용하여 등급을 세분하고, 범위가 넓으면 더 넓은 간격의 숫자를 사용하는 것을 선호한다.

가장 자주 사용되는 등급은 마이크 콘이 제안한 것으로 1, 2, 3, 5, 8, 13, 20, 40, 100 처럼 변형된 피보나치 수열을 사용한다. 어떤 팀들은 1, 2, 4, 8, 16, 32처럼 2의 제곱을 대안적 방법으로 사용한다.

이런 종류의 등급을 사용할 때 비슷한 크기의 제품 백로그 항목을 그룹 혹은 조로 나누고, 같은 등급에 잇는 항목들에 같은 숫자를 부여한다.

image

이 개념을 설명하기 위해, 우리가 우체국에서 일한다 가정하고 비슷한 크기의 소포를 같은 바구니에 담아야 한다고 생각해보자. 바구니에 들어올 소포가 물리적 모양, 크기, 무게가 모두 똑같진 않다. 하지만 현재 추정하고 있는 소포에 가장 적합한 바구니를 찾아야 한다. 바구니에 담긴 소포가 많을수록 들어올 소포의 크기와 비교할 수 있는 대상이 많아져 크기를 가늠하고 분류해서 바구니에 담는 일은 쉬워질 것이다.

지나치게 정밀해지는 것을 “바구니 4”는 사용하지 않는다.(피보나치 수열을 바탕으로 적용한다면) 따라서 2보다 크고 8보다 작은 것 같은 소포가 있으면 “바구니3” 또는 “바구니5”에 넣어야 한다.

플래닝 포커 방법

플래닝 포커를 실행할 때는 스크럼 팀원 모두가 참여한다.

  • 제품 책임자: 제품 백로그 항목을 제시하고, 설명하고, 명확하게 한다.
  • 스크럼 마스터: 팀이 플래닝 포커를 더 잘 적용하도록 돕기 위해 코칭한다. 또한 계속해서 바디랭귀지나 침묵을 통해 동의하지 않는 것 같은 낌새를 보이는 사람들을 찾아 참여하도록 돕는다.
  • 개발 팀: 협동적으로 추정치를 생성한다.

각 개발 팀원들은 플래닝 포커 카드 세트를 제공받으며 구체적인 실행 과정은 아래 이미지를 참고하자.

image

image

플래닝 포커에서 우리는 평균치를 받아들이거나 등급/카드에 없는 숫자를 사용하지 않는다. 목표는 타협이 아니라 개발 팀이 팀의 관점에서 스토리의 전반적인 크기에 대한 추정치를 합의하는 것이다.

이익

플래닝 포커를 이용하면 다양한 사람들로 구성된 팀이 합의를 통해 보다 정확한 추정치를 얻을 수 있는데, 이 추정치는 보통 어떤 개인이 만들어 낼 수 있는 것보다 훨씬 낫다.

플래닝 포커의 가장 큰 가치는 이와 같은 열띤 토론과 PBI에 대해 팀원들이 더 잘 이해하고 서로 공유하는 것에 있다. 팀이 제품 백로그 항목의 크기 추정치를 얻는 것도 바라지만, 제품 백로그 항목에 대해 배우는 거을 더 중시한다. 만일 그렇다면 팀은 투자대비 좋은 수익을 얻은 것이다.

속도란 무엇인가?

속도는 각 스프린트마다 마무리된 일의 양이다. 각 스프린트 끝에 완성된 제품 백로그 항목의 크기를 합치는 것으로 속도를 측정한다. 부분적으로 완성된 제품 백로그 항목의 크기는 포함하지 않는다.

속도는 결과(전달된 것의 가치) 아닌 생산량(전달된 것의 크기) 측정한다. 크기가 8인 항목을 완성하는 것이 크기가 3인 항목보다 반드시 더 많은 비즈니스 가치를 전달하진 않는다.

속도는 두 가지 중요한 목적을 위해 사용된다.

  • 1)먼저 속도는 스크럼 계획의 핵심적인 개념이다. 스프린트의 수를 계산하기 위한 목적으로 사용한다.
    • 추가적으로 스프린트 계획에서 팀의 속도는 앞으로 있을 스프린트에서 약속할 수 있는 작업 능력치를 결정하는 정보 중 하나로 사용된다.
  • 2)속도는 진단을 위한 측정 기준이다. 팀은 고객 가치를 전달하기 위해 스크럼 사용을 평가하고 개선하는데 속도를 사용할 수 있다.
    • 특정 프로세스의 변화가 고객 가치를 전달하는데 어떤 영향을 미치는지에 대한 통찰력을 얻을 수 있다.

속도 범위 계산

계획이 목적이라면 속도를 범위로 표현하는 것이 가장 유용하다. 예를 들면, “팀은 보통 각 스프린트마다 25포인트에서 30포인트를 완성할 수 있다” 라고 하는 것이다. 범위를 사용하면 우리는 지나치게 정밀하지 않으면서도 정확하게 속도를 계산할 수 있다.

image

속도 예측

새로운 팀이라 속도 이력 데이터가 없는 상황이라면 속도를 예측할 수 밖에 없다. 어떻게 예측하느냐?

팀의 속도를 예측하는데 흔히 사용하는 방법은 팀이 스프린트 계획을 할 때, 한 번의 스프린트 동안 전달할 수 있다고 약속하는 제품 백로그 항목을 저하는 거싱다. 약속이 합리적으로 보이면 약속한 제품 백로그 항목 크기를 단순히 더해서 팀의 예측 속도로 사용한다. 대안적으로 다른 팀의 속도 이력 데이터를 바탕으로 직관적으로 속도 추정치를 만들고, 이를 두 개의 추정칠 범위로 변환할 수 있다.

Note: 팀이 스프린트를 시행하여 실제 속도 측정값을 얻게 되면, 즉시 예상치를 버리고 실제 수치를 사용해야 한다. 그리고 팀이 실제 속도 이력을 쌓아감에 따라 데이터의 평균값 혹은 다른 통계를 적용해 속도 범위를 추출해야 한다.

속도에 영향을 미치는 것

image

팀의 속도가 수평을 이룬다고 해서 더 이상 올라갈 가능성이 없는 것은 아니다. 스크럼 팀과 관리자가 속도를 다음 평행선으로 가져가기 위해 도울 수 있느느 여러 방법이 있다.

  • 새로운 도구를 소개하거나 훈련량을 늘리는 것
  • 관리자가 전체적으로 더 높은 속도를 이끌기를 바라면서 전략적으로 팀의 구성을 바꾸는 것
    • 물론 무턱대고 사람들을 움직이고 팀을 해체하는 것은 속도 하락을 일으킬 수 있기 때문에 조심해야 한다.

속도를 증가시키기 위해 초과 근무를 할 수 있다. 연속적으로 초과 근무를 많이 하면 초반에는 속도가 증가할 수 있다. 하지만 초과 근무로 속도가 증가하면 반드시 품질이 떨어지고 이후로는 속도도 급격히 감소한다.

초과 근무 기간이 끝난 후에도 팀이 합리적인 기본 속도로 돌아가기까지는 어느 정도 시간이 필요할 것이다.

결과적으로 초과 근무를 많이 해서 단기적인 이익을 얻을 수 있을진 몰라도, 보통 장기적인 손해가 단기적인 이익보다 훨씬 크다.

image

속도의 잘못된 사용

속도는 계획의 도구이자 팀을 진단하는 측정 기준으로 사용된다. 팀의 생산성을 판단하기 위해 성과 측정치로 사용해선 안 된다. 이렇게 잘 못 사용하면 속도는 낭비적이고 위험한 행동을 낳는다.

예를 들어, 속도가 가장 높은 팀에게 성과급을 제일 많이 주기로 결정했다고 해보자. 이는 합리적이지 않다. 만일 제품 백로그 항목의 크기를 측정할 때 서로 다른 기준치를 사용한 팀들을 비교하려 한다면, 숫자를 비교하는 것은 말이 되지 않는다. A팀이 한 제품 백로그 항목에 5포인트를 부여하고 B팀은 같은 항목에 50 포인트를 부여했다고 해보자. A팀은 자신들의 속도를 B팀의 속도와 비교하고 싶지 않을 것이다. 실제로 양 팀이 각 스프린트 동안 같은 양의 일을 마쳤음에도 B팀의 속도는 A팀의 10배가 될 것이다.

일단 A팀이 이런 문제를 발견하면 같은 항목의 크기를 500으로 할 것이다. 이런 행동을 포인트 인플레이션(point inflation) 이라 부른다. 이는 팀의 행동을 잘못된 측정 시스템에 맞추는 것 외에는 아무런 목적에도 도움이 되지 않는다. 이렇게 해선 안된다.

의도된 인플레이션보다 더 심각한 것이 있다. 욕심나는 대로 더 빠른 속도로 더 많은 완료를 달성하기 위해 타입을 하는 것이다. 이는 기술적 채무를 느릴수 있다.

결국 속도가 정확한 계획을 짜는데 얼마나 도움이 되는지 팀 스스로 내부적 개선을 하는데 속도가 얼마나 도움이 되는지에 따라 속도를 평가해야 한다. 다른 사용법은 잘못된 행동을 촉진할 가능성이 크다.

마무리

This post is licensed under CC BY 4.0 by the author.

[자바 ORM 표준 JPA 프로그래밍-기본편] 필드와 컬럼 매핑

[자바 ORM 표준 JPA 프로그래밍-기본편] 기본키 매핑