软件开发难，恐怕大家都觉得最难的是搞清楚需求；但是其实更难的是管理需求。今天在北京.NET俱乐部上又有人提出了这样的问题，主要的难点是他的开发团队是为了自己的领导们服务的，几个领导都有自己的想法，而且不停的在开发过程中提各种个样的问题；开发进度无法保证，开发的结果总是满足不了要求……
其实这样的问题大家都遇到过，而对于普通的开发人员来说我们往往不去关心，认为这是项目经理的事情，但是其实不然，这样的问题涉及软件开发的各个环节，就算你是出于最底层的开发人员，一样需要控制项目经理交给你的任务。其实这里最重需要把握的一点就是：把任务控制在你能控制的范围之内。总结一下，我的经验如下：
第一：无论你的客户是谁，我们永远需要一个中介来接受需求；你首先需要和客户有个协议，需要他们制定某一个人来提所有的需求，这个人不需要是很高职位的人，而且往往最好的选择是中层的技术管理人员；用户的所有需求必须通过这个人的认可，就算是对方老总提出的要求，如果没有这个人的认可我们也不执行。这点非常重要，可是替我们减少许多麻烦。
第二：无论是什么样的软件开发过程理论现在都承认一个问题，那就是软件开发需要迭代。而且我们一定要面对一个现实，就是软件开发的过程是在不断的变化中寻找平衡的过程，我们的需求永远不会结束，我们的软件永远都在被修改；修改不是坏事，但是我们必须要保证在一定的时候可以拿出成果。
所以，控制迭代的增量就是非常重要的。一般我们公司的做法是，以两周为一个周期最为一个Release，一旦这个Release开始以后，任何用户的新需求就都需要放到后面的Release；我们不会决绝客户的需求，但是我们必须管理我们可以承受的进度。这样做的最大好处在于，在两周的时间内，我们一定可以为客户提供一个更好的版本，这可能不是客户现在心目中的最终结果（因为很多新需求都在后面的Release中），但是我们至少完成了我们在两周前所承诺的结果，客户得到他们想要的东西（当然不是全部），我们也可以很明确的告诉客户，我们完成什么样的需求。
而且在这样一个迭代的过程中，我们会发现很多需求中的不完善之处，每两周的时间我们都可以针对开发方向作相应调整。最终的结果是保证了客户的满意度，同时也保证了产品的按期交付。
在这里，我们需要明确的区分修改bug的需求和新功能的需求，bug应该是那些对软件主要功能造成决定性影响的缺陷，这些东西无论是我们开发人员自己发现的还是客户反馈的，都必须在当前的Release处理完；而新需求则必须放到后面的Release中去。明确区分这两种不同需求对软件项目的成功起到决定性作用。
第三：我们需要学会管理客户。可能有人觉得我在胡扯，客户怎么可能被管理，他们是上帝啊？？！！其实上帝也是人，而且是通事理的人。我们对客户永远不应该是100%的服从，正确的方式是控制用户对开发进度的期望值，尽量使他们一致。当然有些时候我们需要更强硬一点点，比如我就经常很直接的告诉我的老板，这个需求属于新功能，必须放到后面的Release中去。
下一篇：新一代的功能点规模估算方法:COSMIC-FFP[2]
2 COSMIC-FFP方法的基本原理
COSMIC-FFP方法假设功能规模是通过“数据移动”的个数来度量，一个数据移动是一个数据组的传输，一个数据组是一个有区别的、非空的、没有顺序且没有冗余的数据属性的集合。有4种类型的数据移动：输入、输出、读和写。输入是从用户穿越被度量系统的边界传输数据到系统内部，这里提到的用户既包括系统的使用人员，也包括其他软件或者硬件系统；输出是一个数据组从一个功能处理通过边界移动到需要它的用户；写是存储数据到永久性的存储设备；读是从...[查看详情]
