상대 추정

일정을 물을 때 오랫동안 쓰던 단위는 시간이었습니다. 이거 며칠 걸리느냐는 질문에 며칠이라고 답하는 방식입니다. 그 방식은 같은 일에 다른 답이 나오는 것을 설명하지 못합니다.

페이지덱의 주기 계획 자리에서 그 문제가 드러났습니다. 항목 다섯 개를 놓고 태오가 2·1·3·5·2일이라 적었는데, 같은 항목을 다른 개발자가 4·2·5·8·3일이라 적었습니다. 둘 다 정직한 숫자였습니다. 태오는 그 코드를 작년에 만들었고 다른 사람은 처음 열어 보는 자리였기 때문입니다. 합계는 13일과 22일로 갈렸고, 그러면 계획은 누가 맡느냐가 정해진 뒤에야 세울 수 있습니다.

사람의 판단에는 치우친 성질이 있습니다. 절대 시간은 잘 맞히지 못하는데 두 작업의 크기를 견주는 일은 꽤 잘합니다. 이 항목이 저 항목보다 두 배쯤 크다는 판단은 경력이 다른 두 사람이 비슷하게 내립니다. 상대 추정은 그 성질만 쓰기로 한 방식입니다. 작업의 크기를 절대 시간 대신 상대 기준으로 가늠하는 애자일 추정 아래에서 이 방식이 왜 성립하는지를 다루는 원리 갈래에 속합니다.

절차는 다섯입니다.

1. 기준 항목을 하나 못 박습니다. 팀 전원이 내용을 아는 작업이어야 하고 너무 크지 않아야 합니다. 로그인 화면 만들기를 3으로 하자고 정해 두는 식입니다. 이 하나가 흔들리면 나머지 전부가 함께 흔들립니다.
2. 새 항목을 기준과 견줍니다. 그보다 두 배쯤 크면 5, 절반이면 2를 줍니다. 여기서 묻는 질문은 며칠 걸리느냐가 아니라 기준보다 큰지 작은지입니다.
3. 눈금을 성글게 씁니다. 1·2·3·5·8처럼 띄엄띄엄한 값만 쓰는데, 값 사이를 벌려 둔 것은 6이냐 7이냐를 두고 다투는 시간을 없애기 위해서입니다. 큰 작업일수록 어차피 오차가 크니 눈금도 성글어야 맞습니다.
4. 13을 넘으면 쪼갭니다. 항목이 그만큼 크다는 것은 안에 아직 모르는 것이 섞여 있다는 신호입니다. 크기를 더 정확히 맞히려 애쓰는 대신 둘로 나눠 각각 다시 봅니다.
5. 시간으로 환산하지 않습니다. 3점이 3일이라는 표를 만들면 그 순간 시간 추정으로 되돌아갑니다.

이 방식이 통하는 까닭은 오차가 상쇄되기 때문입니다. 한 항목의 값은 자주 틀립니다. 5로 매긴 것이 실제로는 8만큼 걸리기도 합니다. 그런데 항목 스무 개를 더하면 높게 잡은 것과 낮게 잡은 것이 섞여 합계는 실제에 가까워집니다. 목표가 개별 항목의 정확도가 아니라 합계의 정확도라는 점이 열쇠입니다.

담당이 바뀌어도 값이 그대로라는 점도 같이 봅니다. 크기는 작업의 성질이고 걸리는 시간은 사람의 성질입니다. 크기로 적어 두면 태오가 맡든 다른 사람이 맡든 5는 5입니다. 시간으로 적어 두면 담당이 바뀔 때마다 전부 다시 매겨야 합니다. 그 크기를 적는 눈금의 이름이 스토리 포인트이고, 여러 사람의 숫자를 하나로 모을 때는 각자 카드를 고른 뒤 동시에 뒤집는 플래닝 포커를 씁니다.

세 자리에 들어갑니다. 주기 계획에서 담을 항목을 고를 때, 백로그를 훑어 크기를 붙여 둘 때, 분기 계획처럼 항목이 아직 굵을 때입니다. 마지막 자리에서는 숫자 대신 S·M·L 같은 등급으로 거칠게 나누는 티셔츠 사이징을 쓰기도 합니다.

합계를 계획으로 바꾸는 자리가 이 방식의 목적지입니다. 최근 몇 주기에 실제로 끝낸 포인트의 평균인 벨로시티가 있으면 이번에 몇 점을 담을지 근거가 생깁니다. 다음 주기에 실제로 소화할 수 있는 양을 세는 캐파시티 플래닝과 짝을 이룹니다. 40점어치를 골라 놓고도 다음 주기에 휴가가 3일 잡혀 있다는 사실을 모르면 그 40점은 숫자로만 남습니다.

맞지 않는 자리도 분명합니다. 외부에 날짜를 약속해야 하는 자리입니다. 고객사가 언제 되느냐고 물을 때 8점이라는 답은 아무 뜻이 없습니다. 그때는 최근 벨로시티로 환산해 2주에서 3주 사이라는 범위로 답합니다. 환산은 합계에만 적용하고 답은 날짜 하나가 아니라 범위로 냅니다. 같은 항목이라도 언제 추정했는지에 따라 오차 폭이 달라진다는 불확실성의 원뿔이 그 범위의 너비를 정해 줍니다.

"이거 로그인 화면보다 큰가요 작은가요? 며칠인지는 안 물어볼게요."

질문을 시간에서 크기로 바꾸는 말입니다.

"8이랑 13 사이면 13으로 올리지 말고 두 개로 쪼개죠."

값이 커진 것을 쪼개라는 신호로 읽는 경우입니다.

"3점이 3일이라는 표는 만들지 말아요. 그러면 상대 추정을 하는 이유가 없어져요."

환산표가 이 방식을 무너뜨린다는 지적입니다.

페이지덱의 주기 계획에서 지현이 항목을 읽고 개발팀이 카드를 냅니다. 태오와 다른 개발자의 숫자가 3과 8로 갈리는 일이 자주 있고, 그때 오가는 대화가 이 자리의 실제 소득입니다. 대개 한쪽이 모르던 사실이 튀어나옵니다. 결제 연동이 함께 붙는다거나, 그 화면이 이미 다른 팀에서 고쳐 두었다는 것입니다.

숫자를 맞추는 일은 그다음입니다. 대화가 끝나면 두 사람의 값이 대개 5 근처로 모입니다.

포인트를 시간으로 바꿀 수 있다고 보는 경우가 가장 많습니다. 계획을 날짜로 말해야 하는 사람에게는 환산표가 꼭 필요해 보입니다. 하지만 1점이 하루라는 표를 만들어 두면 그다음부터 팀은 시간으로 생각하면서 포인트로 적기 시작합니다. 담당이 바뀌면 값이 흔들리고, 흔들리는 값의 합계는 계획의 근거가 되지 못합니다. 날짜가 필요할 때는 표가 아니라 벨로시티를 씁니다. 표는 한 항목에 붙는 환산이고 벨로시티는 지난 실적에서 나온 값이라, 뒤쪽만 사람에 따라 달라지지 않습니다.

팀끼리 숫자를 비교할 수 있다고 여기는 것도 흔합니다. 같은 눈금을 쓰니 같은 의미일 것처럼 보입니다. 그런데 기준 항목은 팀 안에서만 통하는 약속입니다. A 팀이 로그인 화면을 3으로 잡고 B 팀이 같은 화면을 8로 잡았다면 B 팀 숫자가 항상 두 배 넘게 나오는데, B 팀이 두 배 일하는 것은 아닙니다. 두 팀의 합계를 나란히 놓고 생산성을 따지기 시작하면 팀은 같은 일에 더 높은 값을 매기는 쪽으로 움직이고, 반년 뒤에는 숫자만 오른 채 나가는 결과물은 그대로입니다.