https://jacobian.org/2021/may/25/my-estimation-technique/
나의 소프트웨어 추정 노하우
일단 가장 중요한 점 하나: 내 추정 시스템에선 시간과 불확실성을 동시에 잡는다. 즉 15일 남은 프로젝트가 있을 때 "그 작업은 14일 걸려요" 라고 말하는 대신 "그 작업은 10일에서 15일 정도 걸려요"라고 말한다. 이렇게 말함으로써 지금 상황이 여유롭지 않다는 것을 표현하는 것이다.
1. 일을 덜 복잡한 태스크들로 쪼개라
예를 들면 나는 이런 계산법을 쓴다:
| 복잡도 | 소요시간 |
|---|---|
| 간단함 | 1일 |
| 중간 | 3일 |
| 복잡함 | 5일 (1주) |
| 엄청 복잡함 | 10일 (2주) |
- 실제 시간 단위를 사용해서 복잡성을 표현하라
- 이상적인 상황을 상정하지 마라. 위 표의 "간단함" 태스크는 8시간 코딩을 해야 완료할 수 있는 작업을 말하는게 아니라, 4시간짜리 작업을 말하는 것이다. 나머지 4시간은 엔지니어로서 매일매일 해야 하는 다른 업무들을 해야한다.
- 지나치게 낙관적이지도, 지나치게 비관적이지도 않도록 복잡성을 가늠하라.
2. 불확실성을 추정하라
불확실성을 최대한 좁혀보자. 내가 해보니 best-case, worst-case 를 잡는건 별로 도움이 안됐다. 대신 나는 expected-case, worst-case 를 사용한다. best-case 같은 상황이 거의 없었다는 소리다.
1에서 말한 방법으로 예상치 (expected-case)를 찾고 다음과 같이 "만약 일이 잘 안될 경우"를 위한 곱셈법을 사용한다:
| 불확실성 정도(level) | 곱하기 |
|---|---|
| 낮음 | 1.1 |
| 중간 | 1.5 |
| 높음 | 2.0 |
| 극도로 높음 | 5.0 |
1과 2에 공통적으로 해당되는 사항: 복잡함/높음 이상의 태스크가 많다면 제대로 추정하지 못하고 있다는 소리. 4를 참고하시오.
3. 수학적으로 접근하라
이제 1과 2에 산수를 얹으면 된다:
(ex) 이번 태스크가 중간 복잡도에 불확실성이 높을 때: "3일에서 6일 정도 걸립니다"
4. (불확실성을) 다듬어라. 필요할 경우.
시간을 아끼는 방법은 일을 많이 처리하는 것이 아니라 불확실성을 줄이는 것이다 (de-risk). 불확실성이 낮아지면 아주 많은 시간을 버는 셈이다:
- 조사하기: AWS에서 GCP로 마이그레이션 하는 방법을 찾는대신 그런 경험이 있는 사람과 대화해보기
- 스파이크 (애자일 방법론 일부): POC 를 만들어보기
- JFDI (Just Fucking Do It): 닥치고 부딪히기
5. 회고하라.
실제 걸린 시간을 기록해라.
원 블로그에 보니 이게 4부작 글이더군요. 전체 내용을 (위에 적은 부분 빼고) 아래와 같이 요약해 보았습니다.
전체 글 요약
1부. Just do it
호프스태터의 법칙은 이렇게 말한다.
“모든 일은 항상 예상했던 것보다 오래 걸린다. 심지어 호프스태터의 법칙을 고려해서 계획을 세웠다 해도 말이다."
견적을 내는 (제품 출시 날짜를 고지하는) 일을 피하지 마라. 정확성을 올려라. estimation 은 배울 수 있는 스킬이다.
2부. How i did
- '복잡도'가 낮아지도록 쪼개라
- '불확실성'을 가늠하라
- 기대시간 (1를 사용) / 최악시간을 계산하라 (1, 2 를 공식에 넣고 계산)
- 다듬어라
- 피드백 해라.
(자세한 방법은 위에..)
3부. 즉각적인 추정(SWAG)을 하는 법
상당히 과거 경험이 많은 경우에만 가능. 단순히 추측 (때려맞추기)와는 다르다.
복잡한 문제는 이렇게 접근하지 말라 (즉각적 추정 X)
"빠른 견적 요청"은 개발자를 불안하게 한다. 이는 그 일이 복잡하다는 것을 당신 스스로 잘 알고 있는 것이다
복잡한 일이란 예를 들면,
- complicated authorization schemes
- high availability or performance requirements
- increasing scale (traffic, data storage, etc) of more than a couple of orders of magnitude
- complex technical transitions (e.g. switching programming languages or cloud providers)
- complex re-architectures (e.g. moving from a monolith to microservices)프로젝트 관리 삼각형 에 대해서도 생각해보라: "Good, Fast, Cheap - 오직 두개만 고르세요 (PM님)"
주의: 현실에선 두개조차 사치일수도.
4부. 추정하고 얘기한 다음엔?
얘기한 10주 중 5주가 지났는데 절반도 못했다면? :thinking:
정기적으로 상태를 알려서 늦었음을 알려라. 자신의 실패는 인정하기 어렵기 때문에, 아예 그런 시간을 정기적으로 잡는 것이 좋다.
또한 초/노/빨 세가지 컬러로 현재 state 를 표현하는 것도 괜찮다. 대신 초록색을 아주 좁게 잡고, 노란색으로 가자마자 순식간에 팔로업해야 한다.
"내가 틀렸을리가 없어. 이 GPS 는 엄청 비싸다구. 지도가 잘못된 것 아닐까?" 라는 생각을 하지 않도록 조심하라.
늦은 프로젝트는 실제로 더 늦게 끝난다. 10주짜리 계획의 절반을 6주에 끝냈다면 앞으로 5주만에 나머지 절반을 할 수 없고 6주가 필요할 것이다. 야근으로 늦은 프로젝트를 따라잡으려고 생각하지 마라. (추정이 잘못된거다)
잘못되었다고 생각하면 그 즉시 추정을 새로 하면 된다. 겁먹지 마라.
