http://coding.abel.nu/2012/06/programmer-time-translation-table/
프로그래머가 30초짜리 일이라고 말한다면 그건 실제로는 1시간짜리 일이란 얘기다. (혹은 그 이상). 나도 비슷한 경험을 많이 했기 때문에 더 와닿는 글이다. (간단한 일이라고 말하고 하루종일 보고 있기..).
팀에서도 agile 을 진행하고 매 scrum 마다 backlog 에 대한 estimation 을 하지만, 항상 주먹구구식이며 review 때도 작업 시간에 대한 얘기는 하지 않는다. (완료 여부가 더 중요하게 생각되므로..)
ariticle 에서 저자는 esitmation 을 하고 후에 작업 완료 후에 실제 작업 시간과 비교해 보고 차이점을 생각해 봐야 배울 수 있는 게 있다고 얘기하고 있다.
estimation 에서 뭘 놓치고 있었는지 알게 된다면, 다음번 estimation에서는 더 정확한 작업 시간을 예상할 수 있을 것이다.
다음번 review 시간에는 estimation time 을 review 해 볼 수 있도록 분위기를 만들어야 겠다.
<<프로그래머의 작업 시간 변환표>>
| Estimate | The Programmer Thinks | What the Programmer Forgot | Actual Time |
|---|---|---|---|
| 30 seconds | There’s just a small change to the code to be done. I know exactly what to type and where. It takes 30 seconds to type. | Time for starting the computer, the development environment and getting the right source. The time to build, test, check in and document the fix | 1 hour |
| 5 minutes | It’s a minor thing, I just have to look up the exact syntax on google and fix it. | It’s quite rare to find exactly the right information on the first try. Even if it is found, it probably needs some adjustments before it works. Add time for building, testing etc. | 2 hours |
| 1 hour | I know how to do it, but it’s some code to write so it will take some time. | 1 hour is too tight to have any margin for unforeseen problems. Something always fails. | 2 hours |
| 4 hours | It’s some code to write, but I roughly know the step. I know the Wizzabanga module of our standard framework can do it, but I have to check the documentation on exactly how to call it. | This is probably the only realistic estimation. It is large enough to have some margin for unexpected problems, while the task is still small enough to grasp. | 4 hours |
| 8 hours | I first have to refactor the Balunga class into two, then I’ll add a call to the Wizzabanga code and finally add the new fields to the GUI | There’s a lot of dependencies on the Balunga class from different parts of the system. About 40 different files have to be adjusted. The newly added field in the GUI has to be added in the database as well. 8 hours is too large to grasp completely. There will be more steps than the programmer thought of when estimating. | 12-16 hours |
| 2 days | It’s really quite a lot to code. I have to add some new tables to the database, a GUI for those and then the logic to read and write data to the tables. | 2 days of work is too large to overview for most developers. There will surely be things that are missed. Not just small things, but entire major pieces of functionality required will be forgotten during the estimation. | 5 days |
| 1 week | Ouch… that’s a HUGE task. I don’t have a clue on how to do it, but I can’t say I don’t know. One week should be enough, I hope, I really hope, but I can’t ask for more or they’ll think I’m not competent enough. | The task is way too large to get an understanding of for most programmers. It has to be sent back to an architect that can help splitting it in smaller parts and provide some direction how it should be solved. The architect might find a simple way to do it – or find that there’s a lot more work than expected. | 2-20 days |
