<!--QuoteBegin--><div class='quotetop'>QUOTE</div><div class='quotemain'><!--QuoteEBegin--><span style='font-family:Courier'><b>The 5 Pitfalls of Estimating a Software Project</b><br /><br /><br /><br />I am frequently asked why software projects are chronically late and/or over budget. Naturally, I always take that question as an opportunity to brag about not having gone more than 10% over any estimate since 1999. <!--emo&;)--><img src='style_emoticons/default/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo--><br /><br />It took me 6 years to learn how to produce an estimate that accurate, however, and along the way I&#39;ve noticed a set of behaviors that always lead to blown estimates and broken budgets. Avoiding these pitfalls will put any organization on the road to more accurate estimating, happier clients, and profitable projects.<br /><br />1) <b>Allowing non-technical staffers to give estimates</b>. I know, I know, you think I&#39;m about to launch into a typical software developer&#39;s tirade about how talentless the people on the &quot;business side&quot; of the house are - but I&#39;m not a typical software developer. I will say, however, that allowing a non-technical employee to provide an estimate for completing technical tasks makes about as much sense as allowing a hardcore C++ programmer to commit the company to a marketing plan of his own design. I&#39;ll even go so far as to say that NOBODY should be allowed to give an estimate for a piece of work except for the person who is actually going to perform the work.<br /><br />Remember Adam Smith? He wrote an obscure little book entitled The Wealth of Nations, maybe you&#39;ve heard of it. In it he argued for the specialization of labor, using a pin factory of the day as an example:<br /><br />&quot;...where each of a dozen workers engaged in only one part of the process of manufacture, so that together they produced far more pins than if each worker produced whole pins; the price of pins then fell, and more pins could be used by more people.&quot;<br />When businesses violate the principle of specialization of labor with regard to creating their product, trouble is soon to follow. It is far better to allow the specialists to do work that falls within their specialty than it is to placate a client by giving a totally fictional estimate.<br /><br />Because of the Iceberg Effect, a salesman out in the field is likely to think to himself, &quot;Well, that&#39;s just a couple of screens and buttons, it shouldn&#39;t take very long&quot;. So he gives the client a number, and the number may as well be 1 hour or 1 million hours, because it cannot possibly have any connection to reality unless it comes from the person who has to build the item being estimated.<br /><br />Let your salesmen sell, your marketers market, your executives execute, and your developers develop...estimates, that is.<br /><br />2) <b>Being afraid to look in the mirror</b>. Most development shops I&#39;ve interacted with do not do any &quot;post-mortem&quot; reviews at the end of an over-budget, past-due project (or even a successful project, for that matter). Therefore, they never learn what went wrong, never disseminate information that can help other teams to avoid what happened, and then promptly repeat the exact same mistakes. This causes the next project to be over-budget and past-due, and that project doesn&#39;t get reviewed either, so the same mistakes are made on the project after that, and so on. Even seasoned developers of whom you would expect sufficient experience to avoid common pitfalls fall into this trap.<br /><br /><br />Don&#39;t be afraid to take a look in the mirror and ask &quot;what did I do wrong?&quot; - this applies to everyday life as much as it does to software development. Always analyze your projects for both mistakes and best practices. Failure to do so is the equivalent of flying a 747 without visibility or instrumentation through the Himalayas; way too much risk for most client&#39;s tastes (and checkbook).<br /><br />3) <b>Underestimating design time and debugging time</b>. Most software developers are not in tune with The Business, they are in tune with The Thing - that is, they focus tightly on the act of construction and sometimes miss the other, equally vital, things that go into a successful project. Design is one of the most commonly underestimated things, I think. <br /><br />Figuring out how to build something takes time - sometimes more than it took to figure out what to build. On the other end of things, debugging and refining and polishing up the code takes more time than anyone ever anticipates - in fact, in my 11 years in this business, I have never seen an accurate debugging estimate. Never. Not once - except for my own, of course. <!--emo&;)--><img src='style_emoticons/default/wink.gif' border='0' style='vertical-align:middle' alt='wink.gif' /><!--endemo--> <br /><br />Budgeting 50% of total development time for debugging is absolutely reasonable, if not necessary. Any developer who fails to accept this is still in the Age of Unlimited Wisdom (more on that later).<br /><br />4) <b>Inadequate/unclear requirements</b>. Gathering requirements is difficult, gathering requirements well is rare, and gathering requirements correctly before asking a developer to start designing is just this side of miraculous. I would estimate that 90% of my pre-consultancy projects suffered from inadequate requirements. Ask any developer - they all have war stories about the unbelievably poorly-written spec that had more holes in it than Swiss Cheese when they got from the Business Analyst (to be fair, Business Analysts have war stories about OCD-affected developers who suffer from &quot;analysis paralysis&quot; and cannot do anything without every fact under the sun available to them first, but I digress), and most of those stories are true. <br /><br />It is tempting to rush the requirements gathering process. It is tempting to just assume the answer to questions that are not addressed in the requirements. Mapping a client&#39;s business process is hard, and very few people want to do it - those that actually relish the task are of a rare and strange breed. Uncovering and documenting every seemingly hidden nuance of how a company does business is hard. Going back and forth until everyone agrees that what is detailed in the requirements is an accurate representation of needs to be built is hard. There is a tremendous amount of room for inaccuracies to creep in, especially if you are in a rush. <br /><br />By slowing down just a little bit - and by little I&#39;m talking 10% - and making sure that the requirements gathering is done right before construction begins, everyone will end up happier and the project is infinitely more likely to be a success.<br /><br />5) <b>Taking too large a bite from the apple</b>. I cannot count the number of times I watched in horror as a project manager approached a junior programmer, asking &quot;How long will it take to do X?&quot;, only to hear &quot;Not very long - maybe Y hours&quot; in response from the snot-nosed young know-nothing. Now, whether X was &quot;re-write Microsoft Office from scratch in Assembler&quot; or &quot;change the color of this font on the home page&quot;, the only correct answer to that question is &quot;Let me see the requirements&quot;. And if you don&#39;t have requirements, you need to get some, even preliminary ones. Even then you cannot commit to anything better than a &quot;plus or minus 50%&quot; estimate until everyone has agreed that the requirements are complete. Even then you cannot give a good estimate until you break down the requirements into bite-sized chunks.<br /><br />That is the secret weapon of estimating - the more small chunks you can reduce the requirements to, the more accurate your resulting estimate will be. But most people are lazy. Analyzing requirements is almost as difficult as gathering them, and again - very few people want to do it. Those that do will consistently deliver more successful projects than those who do not.<br /><br />I&#39;m not saying anything here that people in the industry don&#39;t know. But I am saying a lot of things that people in the industry don&#39;t do. I wish that were not the case, but I can only control my own projects.</span><br /><!--QuoteEnd--></div><!--QuoteEEnd-->

source here: <br /><a href='http://www.christopherhawkins.com/06-01-2004.htm#11' target='_blank'>http://www.christopherhawkins.com/06-01-2004.htm#11</a>

控制时间与保持产品功能很重要

有时候追求精益求精，或者说随着开发的深入，产生新的想法有助于产品的完善，但有时候也会陷入误区，导致开发周期的延长，而且不断的增删功能，导致最初的结构被破坏，很难维护。

<!--QuoteBegin-carol+2004-10-27 21:14:20--><div class='quotetop'>QUOTE(carol @ 2004-10-27 21:14:20)</div><div class='quotemain'><!--QuoteEBegin-->有时候追求精益求精，或者说随着开发的深入，产生新的想法有助于产品的完善，但有时候也会陷入误区，导致开发周期的延长，而且不断的增删功能，导致最初的结构被破坏，很难维护。<br />[right][snapback]404628[/snapback][/right]<br /><!--QuoteEnd--></div><!--QuoteEEnd--><br /><br />我很赞同你的观点, 目前的很多团队都存在这样的问题.<br />我想这样种问题可以通过螺旋式模型进行控制, 定期的评估和版本控制; <br />还要对设计和编码阶段进行严格控制, 会避免增删功能的随意性;

<!--QuoteBegin-newzyx86+2004-11-03 11:48:19--><div class='quotetop'>QUOTE(newzyx86 @ 2004-11-03 11:48:19)</div><div class='quotemain'><!--QuoteEBegin-->我很赞同你的观点, 目前的很多团队都存在这样的问题.<br />我想这样种问题可以通过螺旋式模型进行控制, 定期的评估和版本控制; <br />还要对设计和编码阶段进行严格控制, 会避免增删功能的随意性;<br />[right][snapback]407348[/snapback][/right]<br /><!--QuoteEnd--></div><!--QuoteEEnd--><br /><br />很多时候这不是一个部门的事情<br />一切都要以marketing的要求来做，而marketing总是尽可能的来满足客户的需求。<br />俺们的老大的宗旨就是，客户是上帝，他要变态，你就得陪着他变态。 <!--emo&:fire:--><img src='style_emoticons/default/fire.gif' border='0' style='vertical-align:middle' alt='fire.gif' /><!--endemo--> <br /><br />很多时候，就只能未雨绸缪，在进行软件的结构设计时，多考虑一些可能性，以备客户随时可能提出的要求，既然遇到了变态的客户，那就让我们比他们更早变态吧 <!--emo&:fire:--><img src='style_emoticons/default/fire.gif' border='0' style='vertical-align:middle' alt='fire.gif' /><!--endemo-->