需求的控制？
KingFish----2004/8/16
http://www.niufish.com/archives/2004/000161.html
这几天九九厉害了，尿布换了一条又一条，纸尿片关键时刻也充分的发挥了作用。我已经被同事们戏称为“巴巴手”。我劳动着的时候突然想到了，软件的需求变更……
First of all，客户要求改的话就要改！不改就是垃圾，改了就是软件。
Rule of thumb,大部分的需求都是来自于客户。需求的变更更是无时不存在的，如果非要把软件分解为若干阶段的话，从需求阶段、设计阶段到编码、测试、集成需求变更包含在各个阶段。这是为什么呢？
客户自己需求不明！没错，但这究竟是为什么呢？我们又使用了哪些方法去解决这些问题了呢？
因为：
1、客户确实对自己想做的东西确实不清楚
2、客户清楚自己的需求，但是与软件人员沟通时出现误区。以为软件人员明白，但看到自己想象的东西时已经为时已晚了。
3、原先客户明确的需求只是粗线条，当软件人员把细线条做出来发现已经不对了。
我们是这么解决的：
1、CMM：细化需求在需求阶段把所有的需求全部细化，让客户确认后。如果今后需求发生变化，运行需求变更流程，由SCCB（版本变更委员会）认可（大的需求变更）。
2、RUP：对需求逐步精化，一直持续到最后的阶段。参与各部分阶段的迭代，以保证需求是逐渐接近目标的。
3、XP：需求随时可改，使用用户卡片追踪需求。使用面向对象的方法控制变更成本。
解决问题了吗？
1、CMM：这家伙的解决方法很“应该”啊。需求如果不细化的话就不能指导生产，如果需求发生变化了的话导致变更成本加大，SCCB就可以决定哪些去修改、哪些不改。看上去很理所应当的事情在现实中有很多具体的问题:
1.1、细化需求这只是理想化的想法，这会直接受到客户需求不明的3个原因的影响。
1.2、SCCB中软件人员把需求变更所需要的成本告诉客户，客户会做出应该的决定。但是这个组织包含很多人，项目经理、开发人员、管理人员等。开发人员会说我们需要很多时间，项目经理会说我们已经没多少时间了，管理人员会说我们同时有好几个项目无法再加人了，客户一般为了项目进度只有妥协。
1.3、CMM具有学院气的流程方法很受中国的管理者喜爱，认为这能更好的“控制”。其实客户不管是什么原因的需求不明，都会经过需求变更流程。这好像就是要客户承认自己的错误，软件人员把所有的责任都推向客户。谁也没有犯什么错误，就像装修你能说原来设计师给你的图样就绝对能指导施工吗？你不也是一次一次的改吗？
1.4、你认真看过2/3百页的用户需求说明书吗？我遇到这么多页的东西的时候都不去看，你想想大学时考试之前都要画重点的，这本书可是全都是重点。这绝对会造成理解的偏差，如果开会沟通文档的话这又会造成浪费。
2、RUP：需求是精化的，从粗线条到细线条的。这种方法确定了需求的方向，并在需求变更到来时对项目变动成本影响不大。看上去很不错，但沟通所需要的资源成本也是很大的。
3、XP取决于面向对象的程度，强调沟通的重要。
为什么我会想起九九：
感觉CMM根本就不是控制需求的变更，而是控制客户。这只能造成垃圾的生成（说的比较严重）。换句话说，如果你无法控制需求你就需要拥抱它。如果我无法控制九九的拉尿，我就应该从心理上拥抱现在九九的这个特点。