|
|
|
|
|
by fayyazkl
4586 days ago
|
|
That's a very interesting sort of analogy. Among most of the discussed issues, a) For one, giving enough time to come up with a project estimate is often rare. Usually people try to ask for those upfront. b) Usually we try to add a general buffer for any unseen issues. However, the deeper you go and list tasks against time, the closer to realistic is the total. c) Often it is just a customer giving a requirement needed at date x, or a management guy setting goal for a date y. When all you can do is to cut features but have to deliver by a given date. d) No matter what we say, but at the back of our minds, we are not enough prepared to defend a timeline when giving it in the first place. Implementing feature x needs a week? gosh boss would say it should take a day. Latter it turns out the assumption was based upon a library which for just internal implementation reason (that you only discover upon learning it enough through actual code) is completely useless and it should actually be planned for 3 weeks at least. |
|