10.15 추정과 예측
개요와 동기
모든 소프트웨어 팀은 같은 질문을 받습니다. 언제 끝나나요? 그 질문 뒤에는 소프트웨어 개발 노력 추정, 곧 어떤 일에 얼마나 많은 작업이 들지 해 보기 전에 예측하는 실천이 있습니다. 우리가 하는 가장 어려운 일 중 하나이면서 나쁘게 하기 가장 쉬운 일 중 하나입니다. 문제는 소프트웨어가 발견의 작업이라는 것입니다. 한 번도 존재한 적 없는 것을 만들고 있으며, 문제에 대해 배울 것의 많은 부분은 만드는 동안에야 보이게 됩니다. 학습의 노력을 예측하는 것은 알려진 과업을 반복하는 노력을 예측하는 것과 진정으로 다릅니다.
왜 이것을 프로젝트 관리(10.6장)의 한 귀퉁이가 아니라 별도의 규율로 다룰까요? 실패가 매우 일관되고 매우 비싸기 때문입니다. 팀은 근거 없는 단일 날짜를 상습적으로 약속하고, 현실이 그것을 반박한 지 한참 뒤까지 그 날짜를 방어합니다. 리더는 추정을 약속과 혼동합니다. 계약은 한나절에 나온 숫자를 얼리고 일 년 동안 사람들에게 그것을 지키게 합니다. 그 결과는 늦은 전달, 침식된 신뢰, 아무도 실제로 믿는 바를 말하지 않는 문화입니다. 이를 바로잡는 것은 더 나은 수학보다 정직에 가깝습니다. 아는 것과 바라는 것을 분리하고, 불확실성을 불확실성으로 전달하는 것입니다.
기업과 정부 환경에서 판돈은 급격히 오릅니다. 기업은 연간 예산에 맞춰 맞물린 이니셔티브의 포트폴리오에 자금을 대고 자본을 배분하려고 확고한 숫자를 기대합니다(10.1장). 정부는 세출 규칙 아래 공적 약속을 하고, 고정 가격 계약에 서명하며, 날짜가 미끄러지면 입법자에게 답해야 합니다. 두 세계 모두 자신 있는 단일 숫자를 내놓으라는 압박이 엄청나고, 그 숫자를 믿을 수 없게 만드는 깊은 불확실성은 중요한 누군가가 확실성을 원한다고 사라지지 않습니다. 이 장은 다른 자세를 주장합니다. 결정에 도움이 될 때 추정하고, 낙관이 아니라 증거로 예측하고, 범위에 대해 진실을 말하십시오.
핵심 원칙
- 추정은 예측이지 약속이 아닙니다. 목표와 약속에서 분리해 두십시오.
- 불확실성은 실재하므로 표현하십시오. 확률이 있는 범위가 거짓 단일 날짜보다 낫습니다.
- 과거가 낙관보다 미래를 더 잘 예측합니다. 새 짐작보다 측정된 이력을 선호하십시오.
- 이해하려고 분해하고, 약속하려고 예측하십시오. 작은 조각은 위험과 추정의 필요를 모두 줄입니다.
- 외부 시각을 취하십시오. 내부 이야기를 믿기 전에 비슷한 과거 노력과 비교하십시오.
- 지속적으로 다시 예측하십시오. 한 번 하고 갱신하지 않는 예측은 장식입니다.
- 답이 결정을 바꿀 때만 추정하십시오. 그렇지 않으면 낭비입니다.
권장 사항
추정, 목표, 약속을 분리한다
이 장 전체에서 가장 유용한 단일 움직임은 비용이 들지 않습니다. 세 개념을 구별해 두는 것입니다. 추정은 불확실성을 붙인 채 무언가가 얼마나 걸릴지에 대한 정직한 예측입니다. 목표는 무역 박람회 출시나 규제 기한처럼 달성하고 싶은 비즈니스 목적입니다. 약속은 지킬 생각으로 다른 누군가에게 하는 약정입니다. 이 셋은 서로 다른 것이며, 섞는 것이 프로젝트가 스스로에게 거짓말하기 시작하는 방식입니다. 리더가 “대략 3개월에서 5개월”을 듣고 “3개월”이라고 적고 영업팀이 고객에게 “12주”를 약속할 때, 아무도 위험을 받아들이기로 결정하지 않은 채 추정이 조용히 약속이 된 것입니다.
줄 때마다 어느 것을 주는지 말하십시오. 날짜를 요청받으면 범위로 표현한 추정으로 답하고, 비즈니스가 그것에 대해 목표를 정하고 무엇을 약속할지 의도적으로 결정하게 하십시오. 약속은 추정의 불확실성을 놓치는 비용에 대해 저울질해 눈을 뜨고 내리는 선택이어야 합니다. 이 규율은 조직이 결정을 내리고 기록하는 방식(1.5장)에 직결됩니다. 약속은 결정이며, 복도에서의 끄덕임이 아니라 결정의 엄밀함을 받을 자격이 있습니다.
추정이 왜, 어느 방향으로 틀리는지 이해한다
소프트웨어 추정은 무작위로 틀리지 않습니다. 예측 가능하고 체계적인 방식으로 틀리며, 그 패턴을 알면 보정할 수 있습니다. 어떤 노력이든 초기에는 불확실성의 원뿔 안에 있습니다. 시작 시점에는 추정이 어느 방향으로든 4배까지 쉽게 틀릴 수 있고, 범위는 만들고 배우면서만 좁아집니다. 원뿔의 넓은 입구에서 정밀한 숫자를 약속하는 것은 아직 뒷받침할 수 없는 수치를 약속하는 것입니다.
그 구조적 불확실성 위에 인간의 편향이 있습니다. 계획 오류는 최선의 경우를 상상하면서 자신의 계획에 드는 시간, 비용, 위험을 과소평가하는 우리의 믿을 만한 경향입니다. 우리는 행복한 경로를 그리고, 방해, 통합의 놀람, 병가를 잊고, 아무것도 잘못되지 않는다고 가정하는 숫자를 내놓습니다. 여유분을 더하는 것이 보통의 방어적 대응이지만, 감으로 더한 여유는 첫 짐작 위에 쌓은 두 번째 짐작일 뿐이고 일정이 빠듯해지는 순간 협상으로 사라집니다. 해법은 더 많은 의지력이 아니라 방법입니다. 이 일이 안에서 어떻게 느껴지는지가 아니라 비슷한 일이 실제로 얼마나 걸렸는지에 예측의 근거를 두십시오.
분해와 전문가 판단을 쓰되 그 한계를 안다
주력 기법은 알고 한계를 정해 둘 가치가 있습니다. 분해는 큰 산출물을 추론할 수 있는 더 작은 조각으로 나누고 조각을 합산합니다. 사람들은 크고 모호한 것보다 작고 익숙한 것을 훨씬 더 잘 추정하고, 많은 독립 항목을 합산하면 일부 과대 추정이 일부 과소 추정을 상쇄하기 때문에 도움이 됩니다. 한계는 분해가 상자 사이의 일, 곧 통합, 조율, 나열할 생각을 하지 못한 과업을 놓친다는 것입니다. 전문가 판단과 유추에 의한 추정(“이것은 작년에 만든 보고 모듈과 같고 두 달 걸렸다”)은 빠르고 놀랄 만큼 좋은 경우가 많지만, 추정자의 낙관과 맹점을 물려받습니다.
숫자를 붙여야 하는 일에는 낙관적, 가장 가능성 높은, 비관적 수치를 요청해 결합하는 3점 추정을 선호하십시오. 흔히 PERT 가중 평균(낙관 더하기 가장 가능성 높은 값의 4배 더하기 비관, 나누기 6)을 씁니다. 가치는 정확한 공식에 있지 않습니다. 3점 추정은 불확실성을 소리 내어 진술하게 하고 거짓 점 대신 범위를 낳는다는 데 있습니다. 스토리 포인트와 티셔츠 크기(작음, 중간, 큼, 매우 큼) 같은 상대 크기 산정 방법은 항목을 서로 비교함으로써 정확한 시간을 예측하는 덫을 피합니다. 순서 정하기와 대략적 역량에는 잘 맞지만, 통화가 아니라 예측의 입력으로 다루십시오. 포인트는 시간이 아니며, 속도에 포인트를 곱해 날짜를 만들면 상대 크기 산정이 피하려던 모든 문제를 되들여옵니다.
자체 흐름 데이터에서 확률적으로 예측한다
모든 것을 바꾸는 전환이 여기 있습니다. 사람들에게 일이 얼마나 걸릴지 짐작하라고 요청하기를 멈추고, 팀이 실제로 일을 얼마나 빨리 끝내는지 측정하기 시작하십시오. 전달 파이프라인(11.2장)이 이미 필요한 데이터를 만들어 냅니다. 팀이 주당 완료하는 항목 수인 처리량을 추적하면, 희망이 아니라 과거로 미래를 예측할 수 있습니다. 지난 3개월 동안 주당 6개에서 11개 항목을 닫은 팀은 남은 40개 항목을 끝내는 데 높은 확률로 대략 4주에서 7주가 걸릴 것입니다. 그 예측은 증거에 근거하고, 새 데이터가 도착함에 따라 매주 스스로 갱신됩니다.
엄밀한 버전은 몬테카를로 방법 시뮬레이션을 돌립니다. 과거 주간 처리량에서 수천 번 표본을 뽑아 가능한 종료 날짜의 분포를 만들고 답을 확률로 읽어 냅니다. “3월 14일까지 끝낼 확률이 85%이고 2월 28일까지는 50%입니다”는 “3월 1일에 끝납니다”보다 훨씬 더 유용하고 정직한 진술입니다. 이 접근은 대기열 이론(11.3장)에 직결됩니다. 리드 타임은 진행 중인 일을 처리량으로 나눈 것이므로, 일이 어떻게 움직이는지를 다스리는 같은 흐름 지표가 언제 도착할지도 다스립니다. 확률적 예측에는 이력과 합리적으로 안정적인 프로세스가 필요하며, 이것이 바로 일을 작게 유지하고 흐름을 안정적으로 하는 팀에 보답하는 이유입니다. 또한 묶음이 언제 닿을지 알기 위해 각 항목의 크기를 정할 필요가 없어지므로 추정 의례 대부분이 조용히 사라집니다.
큰 프로그램에는 외부 시각을 취한다
크고, 길고, 비싼 프로그램에서는 개별 추정과 심지어 흐름 예측도 오도할 수 있습니다. 새로운 프로그램에는 아직 처리량 이력이 없고 그 내부 이야기가 바로 계획 오류가 가장 세게 무는 곳이기 때문입니다. 해독제는 참조 클래스 예측입니다. 비슷한 완료된 노력의 참조 클래스를 찾고, 그것들이 실제로 얼마나 오래, 얼마나 많이 걸렸는지 보고, 자체 상향식 계획을 믿기 전에 프로그램을 그 분포에 위치시키십시오. 회사의 비슷한 플랫폼 교체가 평균 60% 초기 추정을 초과했다면, 그 숫자가 팀이 방금 조립한 깔끔한 계획보다 여러분의 것에 대한 더 나은 증거입니다. 외부 시각은 기운 빠지게 느껴지는데, 바로 그것이 가치입니다. 모든 새 계획이 지닌 낙관에 맞서기 때문입니다. 체계적 초과의 비용이 수백만과 신뢰로 측정되는 포트폴리오 자금과 초대형 프로그램 예산(10.1장)에 쓰십시오.
더 작게 나눠 덜 추정하고, 지연의 비용으로 순서를 정한다
때로 올바른 추정의 양은 거의 없음입니다. #NoEstimates 논증의 합리적 핵심은, 일을 각 조각이 하루나 이틀 걸릴 만큼 작게 나누면 어느 한 조각의 추정은 더 이상 중요하지 않다는 것입니다. 개수를 세고 그 수로 예측하면 됩니다. 조각이 균일하고 작을 때 정교한 크기 산정은 낭비입니다. 예측이 필요로 하지 않는 정밀을 만드느라 노력을 소비합니다. 이는 앞서 생각하는 것에 반대하는 논증이 아닙니다. 개별 조각을 작게 만들어 개별 예측을 싸게 만들자는 논증입니다.
여전히 결정이 필요한 것은 순서입니다. 모든 것을 한꺼번에 할 수 없을 때는 지연의 비용으로 순서를 정하십시오. 주어진 일이 늦을 때마다 단위 시간당 잃는 가치입니다. 다음 분기에 큰 계약을 여는 기능은 지연의 비용이 높아, 더 쉽더라도 지연의 비용이 없는 있으면 좋은 것보다 앞서야 합니다. 지연의 비용을 노력과 저울질하면(린 사고의 “가중 최단 작업 우선” 휴리스틱) 감으로 정렬한 백로그보다 훨씬 믿을 만하게 다음에 할 일을 알려 줍니다. 이것이 대화 전체를 재구성함에 주목하십시오. 거짓 정밀을 부르는 “언제 모든 것이 끝나는가” 대신, 실제로 답할 수 있는 “다음에 끝낼 가장 가치 있는 것은 무엇인가”를 묻게 됩니다.
장단점
| 접근 | 장점 | 단점 |
|---|---|---|
| 단일 날짜 추정 | 단순. 이해관계자가 요청하는 것 | 정밀하게 틀림. 위험을 숨김. 우발적 약속이 됨 |
| 3점 / PERT 추정 | 불확실성을 드러내게 함. 쌈 | 여전히 짐작. 공식이 거짓 엄밀함을 암시 |
| 스토리 포인트 / 티셔츠 크기 | 빠름. 순서 정하기와 대략적 역량에 좋음 | 시간이 아님. 속도 산수가 단일 날짜를 슬며시 되들여옴 |
| 확률적 흐름 예측 | 증거 기반. 스스로 갱신. 정직한 범위 | 이력과 안정적 흐름 필요. 덜 “확실해” 보임 |
| 참조 클래스 예측 | 큰 프로그램의 낙관을 교정 | 비교 가능한 과거 노력 필요. 듣기에 기운 빠짐 |
| #NoEstimates (작은 조각) | 낭비 제거. 세어서 예측 | 규율 있는 쪼개기 필요. 숫자를 원하는 자금 제공자에게 불안함 |
중심 긴장은 사람들이 원하는 확실성 대 일이 요구하는 정직입니다. 자금 제공자, 경영진, 계약, 입법자는 단일 날짜가 예산을 짜고, 약속하고, 방어하기 쉽기 때문에 확고한 단일 날짜를 요구합니다. 소프트웨어가 그것을 뒷받침하는 일은 드뭅니다. 확실성을 지어내서도, 답하기를 거부해서도 아니라 확률이라는 통화로 답하여 푸십시오. 신뢰도가 있는 범위를 증거가 도착함에 따라 다시 예측하는 것입니다. 이를 작은 조각과 짝지워, 이르고 실제인 전달이 멀고 상상 속인 전달을 사람들이 신뢰하는 대상으로 대체하게 하십시오. 시연된 증분이 어떤 추정보다 가치 있습니다.
팀과 논의할 질문
누군가 날짜를 물을 때 추정, 목표, 약속 중 무엇을 주고 있으며, 방의 모두가 어느 것인지 압니까? 이것이 가장 적은 노력으로 가장 많은 피해를 막는 질문입니다. 대부분의 조직에서 이 셋은 팀의 입을 떠나는 순간 하나의 숫자로 합쳐지고, 예측이 약속이 되는 위험을 받아들이기로 결정한 사람은 아무도 없습니다. 실제 예시를 가져오십시오. 마지막으로 약속한 마감을 처음 발화된 대화까지 거슬러 추적하고, 그것이 정장을 입은 희망적 짐작 말고 다른 것이었던 적이 있는지 물으십시오. 답은 언어를 영구히 바꿔야 합니다. 추정은 범위로 나가고, 목표는 비즈니스의 바람으로 이름 붙고, 약속은 불확실성을 저울질해 결정으로 기록하며 의도적으로 이루어집니다(1.5장). 팀이 약속이 의식적으로 수용된 곳을 지적할 수 없다면, 우연히 약속하고 있는 것입니다.
새로운 추정이 아니라 측정된 처리량으로 다음 릴리스를 예측할 수 있으며, 무엇이 막고 있습니까? 대부분의 팀은 일을 추적하는 도구에 쓰이지 않은 채 쌓여 있는 데이터로 “언제 끝나는가”에 경험적으로 답할 수 있습니다. 지난 분기에 팀이 주당 완료한 항목 수를 안다면, 종료 날짜 분포를 시뮬레이션하고 소망이 아니라 확률을 제시할 수 있습니다. 실제 처리량 이력과 남은 항목 수를 가져와 흐름 기반 예측을 팀이 감으로 추정한 날짜와 비교하십시오. 그 간극은 보통 시사적입니다. 막는 것이 항목 크기가 크게 다르거나 흐름이 불규칙한 것이라면 그 자체가 발견입니다. 불안정한 흐름은 어차피 고칠 가치가 있는 전달 문제이기 때문입니다(11.2장, 11.3장). 추정에서 측정으로 옮기는 것은 도구의 변경이라기보다 낙관보다 자신의 이력을 믿기로 하는 결정인 경우가 많습니다.
가장 큰 현재 프로그램에 대해 외부 시각을 취했습니까, 아니면 내부 계획만 세웠습니까? 큰 프로그램은 낙관이 비싼 초과로 복리 쌓이는 곳이며, 자신 있는 상향식 계획이 가장 유혹적이고 가장 믿을 수 없는 곳입니다. 규율은 조직 안팎의 비슷한 완료된 노력의 참조 클래스를 지명하고, 그것들이 실제로 얼마나 들고 얼마나 걸렸는지 찾고, 자체 숫자를 방어하기 전에 프로그램을 그 분포에 정직하게 위치시키는 것입니다. 데이터를 가져오십시오. 여기서 비교 가능한 이니셔티브는 첫 추정을 얼마나 초과했으며, 현재 계획은 그 모두를 이기리라고 조용히 가정하고 있습니까? 그렇다면 예외적이라는 데 걸고 있는 것이고, 기준율은 그 내기를 어김없이 집니다. 외부 시각은 예측을 덜 우쭐하게 하고, 여러분이 준 숫자를 기억할 자금 제공자와 감사자에게 훨씬 더 방어 가능하게 만듭니다(10.1장).
자금 제공자, 계약, 입법자가 하나의 고정된 날짜를 요구할 때, 거짓말도 거부도 하지 않고 어떻게 답합니까? 압박이 가장 심한 곳이며 정직한 팀이 가장 자주 굴복하는 곳입니다. 경쟁자의 자신 있는 “9월” 옆에서 “9월까지 70%“는 회피처럼 들리기 때문입니다. 큰 조직에서는 판돈이 곱해집니다. 하나의 고정된 날짜가 예산, 의존하는 프로그램, 공적 약속으로 번지므로, 편의를 위해 고른 숫자는 미끄러지는 순간 체계적 부채가 됩니다. 실제로 쓸 계획인 언어, 신뢰도가 있는 범위의 실제 예시, 확고하게 약속할 수 있는 작은 이른 증분을 두고 나중 범위는 자금이 배정된 범위로 두는 방법을 가져오십시오. 경쟁하는 고려는 실제입니다. 일부 마감(규제 전환, 무역 박람회 출시)은 정말 고정되어 있으며, 거기서 올바른 움직임은 노력이 확실한 척하지 않고 날짜를 고정하고 범위를 유연하게 하는 것입니다. 기업과 정부 환경에서는 이를 계약의 모양에 묶으십시오. 모듈식이고 증분 자금을 받는 계약은 가치 있는 핵심에 정직하게 약속하게 해 주는 반면, 먼 마일스톤에 닻을 내린 단일 고정 가격, 고정 범위 계약은 초과와 헤드라인을 낳는 바로 그 거짓 확실성을 강제합니다.
팀은 다음에 무엇을 만들지 어떻게 결정하며, 지연의 비용으로 명시적으로 순서를 정하면 순서가 바뀌겠습니까? 대부분의 백로그는 감, 가장 크게 외친 사람, 대략적 노력의 혼합으로 정렬되며, 이는 가치 있는 것이 아니라 쉬운 성과를 향해 조용히 최적화합니다. 일이 늦을 때마다 단위 시간당 잃는 가치인 지연의 비용은 질문을 “언제 모든 것이 끝나는가”에서 증거로 실제 답할 수 있는 “다음에 끝낼 가장 가치 있는 것은 무엇인가”로 재구성합니다. 실제 백로그 항목 서넛과, 각각이 여는 가치와 그 가치가 만료되는 때에 대한 정직한 추정을 가져와 노력에 대한 주당 잃는 가치로 순위를 매기고 그 순서를 현재 계획과 비교하십시오. 순서 변경은 대개 놀랍고 반박하기 어렵습니다. 경쟁하는 고려는 지연의 비용 자체가 추정이며 자기 항목이 먼저이길 원하는 누구든 조작할 수 있으므로, 숫자를 누가 소유하고 어떻게 이의를 제기하는지 정하라는 것입니다. 기업 포트폴리오나 정부 프로그램에서 이 규율은 각자 자기 이니셔티브가 먼저여야 한다고 믿는 이해관계자들에게 순서 결정을 변호하게 해 줍니다. 순서가 정치가 아니라 진술된 가치에 근거하기 때문입니다.
누가 다시 예측하고, 얼마나 자주이며, 예측이 움직일 때 행동할 책임은 누구에게 있습니까? 킥오프에서 한 번 하고 다시 보지 않는 예측은 장식이며, 가장 비싼 지연은 살아 있는 예측이 마감이 부정할 수 없게 되기 몇 달 전에 보여 주었을 것들입니다. 큰 팀에서 실패는 데이터의 부재가 아니라 상설 주기와 이름 붙은 소유자의 부재인 경우가 많습니다. 처리량이 표류하고, 종료 날짜 분포가 오른쪽으로 이동하는데, 알아챌 일이 직무인 사람은 아무도 보고 있지 않습니다. 실제 재예측 리듬(없다면 없다고 인정), 예측이 마지막으로 결정을 바꾼 때, 현재 약속이 정해진 이후 본 표류를 가져오십시오. 경쟁하는 고려는 예측 피로입니다. 너무 시끄럽게 다시 예측하면 요동을 부르고 신뢰를 침식하므로, 모든 흔들림에 반응하는 대신 합리적 간격과 에스컬레이션을 촉발하는 임계값을 합의하십시오. 기업과 정부 맥락에서는 이를 감독에 연결하십시오. 지연이 마일스톤에서 드러나는 놀람이 아니라 리더가 행동할 수 있는 관리되는 재예측으로 나타나도록 고정된 일정으로 거버넌스 기구에 갱신된 확률 범위를 보고하십시오.
분야별 관점
스타트업. 추정 의례는 거의 완전히 건너뛰십시오. 일을 하루나 이틀짜리 조각으로 나누고, 매주 끝낸 것을 세고, 창업자와 투자자에게 영웅적 단일 날짜 대신 좁혀지는 범위를 제시하십시오. 이력은 짧고 프로세스는 변동이 크니 불확실성의 원뿔을 변명이 아니라 정직한 설명으로 삼고, 그림이 선명해짐에 따라 매주 금요일 다시 예측하십시오.
소기업. 추정 전문가도 없고 크기 산정 회의를 할 의욕도 없으니, 이미 돌리는 도구가 일을 하게 하십시오. 대부분의 과업 추적기는 처리량을 공짜로 노출하고, 그것으로 한 가벼운 예측이 짐작한 마감보다 낫습니다. 인력을 둘 수 없는 무거운 계획 소프트웨어를 사고 싶은 충동을 억누르십시오. 완료된 항목의 단순한 주간 개수와 평이한 범위면 고객에게 실제로 하는 약속에 충분히 “언제 끝나는가”에 답합니다.
대기업. 문제는 연간 자본 주기(10.1장)에 맞춰 포트폴리오에 자금을 대는 많은 팀에 걸친 일관성입니다. 단일 날짜 대신 신뢰도가 있는 범위로 표준화하고, 큰 프로그램에는 참조 클래스 비교를 요구하고, 한 분기 안에 짐작이 처리량 기반 예측으로 대체되도록 흐름 지표를 세우십시오. 한 부서에서 나온 숫자가 이사회에 닿았을 때 같은 뜻이도록 추정, 목표, 약속의 분명한 정의를 갖춘 공유 실천으로 추정을 다스리십시오.
정부. 조달 규칙과 공적 책무가 모든 것을 형성합니다. 놓친 공적 날짜는 헤드라인이자 감사 지적 사항이 되므로, 먼 마일스톤에 닻을 내린 단일 고정 가격, 고정 범위 약속보다 모듈식이고 증분 자금을 받는 계약을 선호하십시오. 감독 기관에 확률적 예측과 참조 클래스 증거를 평이한 말로 보고하고, 신뢰도를 정직하게 공개하고, 계약자의 낙관적 계획 위의 서명이 아니라 시연된 동작하는 증분이 대중과 감사자가 신뢰하는 증거가 되게 하십시오.
사례
스타트업. 시리즈 A 시연을 준비하는 아홉 명의 스타트업이 핵심 통합이 준비될지 알아야 합니다. 창업자가 투자자에게 날짜를 약속하게 두는 대신, 리드가 추정을 범위로 제시하고 그 뒤의 불확실성의 원뿔을 설명합니다. 팀은 주당 백로그 항목 5개에서 9개를 닫아 왔으므로 남은 일에 빠른 몬테카를로 예측을 돌려 “분기 3주 차까지 80%, 한 주 일찍은 반반”이라고 보고합니다. 통합을 이틀짜리 조각으로 나눠 어느 한 추정도 크게 중요하지 않게 하고, 투자자에게 보이는 경로를 먼저 만들도록 지연의 비용으로 순서를 정하고, 매주 금요일 다시 예측합니다. 투자자는 미끄러졌을 자신 있는 숫자 대신 정직하고 좁혀지는 예측을 받습니다.
기업. 주문 관리 플랫폼을 교체하는 한 소매업체는 숫자를 요구하는 연간 자본 주기를 통해 프로그램에 자금을 대야 합니다. 프로그램 오피스는 깔끔한 상향식 계획을 방어하고 싶은 충동을 억누르고, 대신 비슷한 세 개의 플랫폼 교체(내부 둘, 공개 문서화된 하나)로 참조 클래스를 만듭니다. 이들은 초기 추정을 50%에서 80% 초과했습니다. 외부 시각의 수치에 맞춰 자금을 대고, 일정을 고정된 가동일이 아니라 확률 범위로 표현하고, 첫 전달 팀부터 흐름 지표를 세워 한 분기 안에 짐작이 매달 갱신되는 처리량 기반 예측으로 대체되게 합니다. 한 스트림이 과열되면 재예측이 일찍 보여, 리더십은 마감에서 지연을 발견하는 대신 재균형합니다.
정부. 급여 시스템을 현대화하는 한 기관은 놓친 공적 날짜가 헤드라인인 세출과 공적 정밀 조사 아래 운영됩니다. 하나의 먼 마일스톤에 닻을 내린 단일 고정 가격, 고정 범위 계약 대신 모듈식 증분을 조달하고, 일찍 전달되는 가치 있는 핵심에 공개적으로 약속하며 나중 범위는 약속이 아니라 자금이 배정된 범위로 표현합니다. 프로그램 리더는 확률적 예측과 참조 클래스 비교로 감독 기관에 보고하며 신뢰도를 쉬운 말로 설명해, “9월까지 70%“가 정확히 그 뜻으로 이해되게 합니다. 시연된 동작하는 증분이 대중이 신뢰하는 증거가 되며, 이는 계약자가 서명할 수 있는 어떤 추정보다 튼튼합니다.
비즈니스 사례: 동기, ROI, TCO
정직한 추정과 예측의 수익은 피한 재앙이 지배합니다. 대규모 소프트웨어 노력은 원래의 고정 계획에 맞을 가능성보다 초과하거나 실패할 가능성이 훨씬 높고, 손실은 복리로 쌓입니다. 매몰 비용, 늦은 전달로 포기된 가치, 회복을 위한 긴급 지출, 깨진 공적 약속 뒤에 따르는 신뢰의 침식입니다. 여기의 실천(추정을 약속과 분리, 실제 처리량으로 예측, 큰 프로그램에 외부 시각)이 프로그램을 그 실패 곡선에서 벗어나게 합니다. 더 정확한 수정 구슬을 사는 것이 아닙니다. 자신이 어디에 서 있는지에 대한 더 이르고 더 참된 정보를 사서, 교정이 아직 싼 동안 바로잡게 하는 것입니다.
총소유비용 측면에서 추정 의례에서 측정된 예측으로의 전환은 보통 비용을 올리지 않고 낮춥니다. 정교한 선행 추정은 만드는 데 비싸고 일이 시작되는 순간 퇴색하는 반면, 처리량 기반 예측은 전달 파이프라인이 데이터를 내보내면 거의 공짜입니다. 양 극단 모두 돈이 듭니다. 과추정(아무도 쓰지 않는 정밀을 만드는 끝없는 크기 산정 회의)과 과소 예측(눈을 감고 약속하고 나중에 초과로 값을 치름)입니다. 리더십을 설득하려면 마지막 주요 초과의 완전 부하 비용을 처리량을 추적하고 범위를 제시하는 거의 영에 가까운 비용 옆에 놓고, 외부 시각의 예측이 처음부터 자금을 댈 수 있는 기대를 어떻게 세웠을지 보이십시오.
안티패턴과 함정
- 단일 날짜 약속: 범위가 하나의 숫자로 무너진 뒤 증거를 넘어 방어되는 것.
- 추정 세탁: 희망적 짐작이 사슬을 타고 올라가 계약상 약속으로 굳는 것.
- 일정 엔진으로서의 속도: 스토리 포인트에 속도를 곱해 정밀한 날짜를 만들어 내는 것.
- 감으로 하는 여유분: 첫 짐작 위에 쌓은 두 번째 짐작이 압박 아래서 협상으로 사라지는 것.
- 내부 시각만: 비슷한 프로그램이 실제로 얼마나 걸렸는지 무시하고 새 상향식 계획을 믿는 것.
- 모든 것을 추정: 개별 추정이 어떤 결정도 바꾸지 않는 작고 균일한 조각의 크기를 산정하는 것.
- 얼어붙은 예측: 킥오프에서 한 번 하고 현실이 도착해도 갱신하지 않는 예측.
- 정밀 연극: 불확실성의 원뿔의 넓은 입구에서 소수점 둘째 자리까지 시간을 제시하는 것.
성숙도 모델
- 1단계, 시작: 추정은 감으로 만든 단일 날짜이며 약속으로 다뤄집니다. 추정, 목표, 약속의 구별이 없고, 예측은 반응적이고 임시적이며, 초과는 모두를 놀라게 하고 팀 탓이 됩니다.
- 2단계, 발전: 일부 구조화된 추정(분해, 스토리 포인트, 3점 수치)이 있지만 팀마다 실천이 다릅니다. 추정은 여전히 대부분 단일 숫자이고, 날짜를 투영하는 데 속도가 쓰이며, 예측은 킥오프에서 한 번 이루어지고 거의 다시 보지 않습니다.
- 3단계, 표준화: 문서화된 표준이 조직 전체에 시행됩니다. 추정은 진술된 불확실성이 있는 범위로 표현되고, 추정, 목표, 약속은 정의상 구별되며, 팀은 처리량을 추적하고 정해진 주기로 다시 예측하며, 큰 프로그램은 참조 클래스 비교를 쓰도록 요구됩니다.
- 4단계, 관리: 실천이 데이터로 측정되고 통제됩니다. 예측 정확도가 실제 결과에 대해 추적되고 보정이 점검되어, “80%까지” 날짜가 실제로 열 번 중 여덟 번 맞는지 말할 수 있습니다. 처리량과 사이클 타임 기준선이 유지되고, 지연의 비용이 수량화되며, 예측 표류가 임계값에 대해 모니터링되어 에스컬레이션을 촉발하고, 약속은 낙관이 아니라 증거에 대해 이루어집니다.
- 5단계, 오케스트레이션: 흐름 데이터에서의 확률적 예측이 지속적이고, 보정 이력이 그것이 정직함을 입증했기 때문에 신뢰받습니다. 약속은 신뢰도를 비용에 저울질하는 의도적 결정이고, 일은 추정이 최소한이 될 만큼 작게 나뉘며 지연의 비용이 순서를 이끌고, 추정은 포트폴리오 자금 및 위험 계획과 통합되어, 조직은 예측이 움직임에 따라 일상적으로 범위를 다시 정하고 재균형하며 원래 숫자를 방어하지 않고 증거에 계획을 적응시킵니다.
논의를 위한 아이디어
- 모든 추정이 신뢰도가 있는 범위로 팀을 떠나야 하고 단일 날짜가 금지된다면 조직에서 무엇이 바뀌겠습니까?
- 이미 세어서 예측할 수 있을 만큼 작고 균일한 일을 추정하는 데 노력을 쓰고 있는 곳은 어디입니까?
- 지난 두 분기의 처리량을 몬테카를로 시뮬레이션에 넣으면, 예측이 실제로 약속한 날짜와 일치하겠습니까?
- 가장 큰 프로그램의 정직한 참조 클래스는 무엇이며, 기준율이 현재 계획과 얼마나 심하게 모순됩니까?
- 오늘 팀은 순서를 어떻게 정하며, 지연의 비용으로 명시적으로 정렬하면 다음에 만들 것이 바뀌겠습니까?
- 조직에서 약속이 수용될 때 불확실성이 결정의 일부로 기록됩니까, 아니면 날짜가 적히는 순간 사라집니까?
핵심 요점
- 추정, 목표, 약속을 구별해 두십시오. 섞는 것이 프로젝트가 스스로에게 거짓말하기 시작하는 방식입니다.
- 추정은 알려진 방향으로 체계적으로 틀립니다. 불확실성의 원뿔은 초기 일을 넓히고 계획 오류는 낙관을 기본값으로 만듭니다.
- 새 짐작보다 측정된 처리량에서의 확률적 예측을 선호하십시오. 범위와 신뢰도를 제시하고 지속적으로 다시 예측하십시오.
- 낙관이 가장 비싼 큰 프로그램에는 참조 클래스 예측으로 외부 시각을 취하십시오(10.1장).
- 작게 나눠 개별 추정이 중요하지 않게 하고, 감이 아니라 지연의 비용으로 순서를 정하십시오.
- 결정을 바꿀 때만 추정하십시오. 그렇지 않으면 낭비입니다. 10.6장(프로젝트 관리), 11.2장(전달), 11.3장(대기열 이론), 1.5장(의사 결정과 거버넌스)을 보십시오.
참고 문헌과 더 읽을거리
- Steve McConnell, Software Estimation: Demystifying the Black Art.
- Daniel Vacanti, Actionable Agile Metrics for Predictability and When Will It Be Done? (probabilistic forecasting from flow data).
- Troy Magennis, Forecasting and Simulating Software Development Projects (Monte Carlo methods).
- Bent Flyvbjerg and Dan Gardner, How Big Things Get Done (reference class forecasting and megaprojects).
- Daniel Kahneman, Thinking, Fast and Slow (the planning fallacy and the outside view).
- Donald Reinertsen, The Principles of Product Development Flow (cost of delay and queue economics).
- Vasco Duarte, NoEstimates: How to Measure Project Progress Without Estimating.
- Frederick Brooks, The Mythical Man-Month (why software schedules go wrong).
- Todd Little, “Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty” (IEEE Software, 2006).