呵呵,思归说话了,那我就把问题的相关内容都转贴过来吧,不过,会做一些删减,不必要的内容,就不转贴了:
************************************转贴内容开始***************************************
作者：zidoing
时间: 2005-2-24 09:03:56 标题: 关于软件开发中度的把握。
--------------------------------------------------------------------------------
在软件的开发过程中总是倾向于加入更多的功能，实现更多美妙的想法，而这往往又是使项目失败的一个很重要的因素。开发中的这个度该如何把握呢？
回复：
作者：凤舞凰扬
你的团队是否有足够的能力，你的团队是否有足够的时间，你的团队是否有足够的辅助资源（比如金钱、环境等）。
回复：
作者：gigix
照XP的建议，划出足够细的用户故事，让用户排列优先级，始终只实现优先级最高的故事。
回复：
作者：age0
如何控制这个度，主要还是由系统整体基础架构的能力来衡量的，如果新增功能在基础架构的设计范围之内就可以放心增加，但是如果超出了原来的设计范围就必须很审慎，其实道理和建筑差不多。
回复：
作者：Archie
zidoing 写道:
在软件的开发过程中总是倾向于加入更多的功能，实现更多美妙的想法，而这往往又是使项目失败的一个很重要的因素。开发中的这个度该如何把握呢？
更多的功能和更美妙的想法，如果是用户提出来的，你就给他估算一下要用多少成本，是否做由用户决定。如果是程序员提出来的，也要先和用户沟通，做不做也是用户说了算。
Archie 写道:
更多的功能和更美妙的想法，如果是用户提出来的，你就给他估算一下要用多少成本，是否做由用户决定。如果是程序员提出来的，也要先和用户沟通，做不做也是用户说了算。
这种老套的说法以后就不必说了，差不多每一本和需求或软件工程相关的书籍都会有这种套话。
基本上，一个项目的真正需求只有到了beta测试阶段才会得到完整的补充，因为beta阶段之前的需求都是由高层用户代表确定下来的，因此并不能全面反映最终用户的实际需求，而只有到了beta测试阶段才会有最终用户参与进来试用以及评估，这个阶段的需求大多数是要求补充更具体更实用的功能，如果系统整体框架设计的比较完善，这种需求就很容易满足并且可以得到相当高的用户评介，但是如果框架设计的不周详，这种需求就有可能对系统造成不利影响。而这也是为什么XP一直要强调现场用户、持续集成以及小型发布（Small Release）的重要原因之一。
回复：
作者：notyy
这个度由这个软件的主设计师把握就行了，呵呵，独裁一下
回复：
作者：winterwolf
先砍
砍到不能再砍 就开始干
然后一个版本接一个版本的升级
回复：
作者：flyingbug
楼上这招虽然很弱，确很实用
就看你们的市场人员是否能顶住压力了：）
************************************转贴内容结束***************************************
