关于软件开发中度的把握。

在软件的开发过程中总是倾向于加入更多的功能，实现更多美妙的想法，而这往往又是使项目失败的一个很重要的因素。开发中的这个度该如何把握呢？

你的团队是否有足够的能力，你的团队是否有足够的时间，你的团队是否有足够的辅助资源（比如金钱、环境等）。

照XP的建议，划出足够细的用户故事，让用户排列优先级，始终只实现优先级最高的故事。

如何控制这个度，主要还是由系统整体基础架构的能力来衡量的，如果新增功能在基础架构的设计范围之内就可以放心增加，但是如果超出了原来的设计范围就必须很审慎，其实道理和建筑差不多。

更多的功能和更美妙的想法，如果是用户提出来的，你就给他估算一下要用多少成本，是否做由用户决定。如果是程序员提出来的，也要先和用户沟通，做不做也是用户说了算。

这种老套的说法以后就不必说了，差不多每一本和需求或软件工程相关的书籍都会有这种套话。

基本上，一个项目的真正需求只有到了beta测试阶段才会得到完整的补充，因为beta阶段之前的需求都是由高层用户代表确定下来的，因此并不能全面反映最终用户的实际需求，而只有到了beta测试阶段才会有最终用户参与进来试用以及评估，这个阶段的需求大多数是要求补充更具体更实用的功能，如果系统整体框架设计的比较完善，这种需求就很容易满足并且可以得到相当高的用户评介，但是如果框架设计的不周详，这种需求就有可能对系统造成不利影响。而这也是为什么XP一直要强调现场用户、持续集成以及小型发布（Small Release）的重要原因之一。

这个度由这个软件的主设计师把握就行了，呵呵，独裁一下

先砍

砍到不能再砍 就开始干

然后一个版本接一个版本的升级

楼上这招虽然很弱，确很实用
就看你们的市场人员是否能顶住压力了：）

哈哈 真是经典的问题阿
怎么大佬们都不出声呢
是懒的说了吧
奇怪呢

实际上这个问题 本质可以分解成两个更经典的问题
1.市场人员 与 开发人员的对抗
从本质上说市场人员倾向于在项目或产品中加入更多
功能，满足更多的需求。而开发人员一般占在反面，希望
需求更简单清楚，一旦确定了需求就不要改变。这个是
无法避免的事情，也不是坏事，比较市场人员和开发人员各司其职是比较好的现象。
我们解决的方法是一段时间后 将两方人员集中谈判，
容许谈清楚要或不要的原因
共同定出需求实现的优先级别，按照谈判结果决定。
当然期间我认为构架师是决定一票。
而且构架师应该倾向于比较保守的一边 为好。


2.可以分的另一个问题就是
系统（团队）对需求变更响应的能力
这个问题太经典 方法无数 请xd去查软件工程的书吧