RSS feed [root] /weblog /software_engineering



title search:


Tue Apr 10 10:27:33 HKT 2018


Here is one way of how people estimate percent of completion -

I believe the general practice in my company is to take your estimate and triple it. Noone EVER complains that a project was completed too quickly. -[..]iscussTopicParent=15151&ixDiscussGroup=3

McConnell: 25% isn't necessarily a bad number. What's bad about it is that the average project is something like 100% late and 100% over budget at the time it's shut down. With better development approaches, a lot of those projects would get shut down when they've used 20% of their budgets rather than 200% of their budgets.

Schedule chicken , someone leave the responsiblity to other sliencely -[..]ion=edetail&ObjectType=COL&ObjectId=7923

If you need to deliver software in 9 months, you could make a plan to deliver software in 9 months and hope it works. Or you could start delivering software every week. Maybe in the first week you aren't so good at it but after four weeks you and the rest of your team will be better. I call it the reduce risk by practicing technique. I can't believe how many people line up against me on this, even quality experts. - Ward Cunningham

Estimate via experience -[..]mating-software-feature-development.html

Explain what is Velocity in scrum -[..]2008/01/understanding-your-velocity.html

Concern about estimation -

Test Effort Estimation -[..]mation_approch-bid-00oQI1TW93593159.html

Reducing focus on estimation, I think it is good move, as estimate always inaccurate -[..]se-for-reducing-focus-on-estimation.html[..]ng-budget-instead-of-estimates-in-agile/

Discussion about noestimates-software-contractors -[..]2016/01/noestimates-software-contractors[..]2015/12/noestimates-software-contractors

(google search) (amazon search)
download zip of files only