需求的控制？
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根本就不是控制需求的變更，而是控制客戶。這隻能造成垃圾的生成（說的比較嚴重）。換句話說，如果你無法控制需求你就需要擁抱它。如果我無法控制九九的拉尿，我就應該從心理上擁抱現在九九的這個特點。