方法論的問題
 [zhenyue]
軟件工程作為工程學的一個分支而存在， 其目的和制藥工程、生物工程、金融工程等其他工程學領域的區(qū)別不大。
最關鍵的部分是區(qū)分不同的方法論所對應的問題空間。

只有確定了問題空間才能找出正確的方法論和正確的工程學工具。
目前對于軟件工程學最感無奈的地方就是 “手里是錘子，眼里都是釘子” 這種現象。
重量級的軟件工程方法論  CMM RUP
輕量級的軟件工程方法論 XP 等 敏捷方法思想
都有各自的問題領域， 跨過各自領域后方法論并非不起作用， 而是成本和風險的急劇上升。
對于xp 等敏捷思想來說， 比較流行的說法是請參照“精益生產"思想的應用領域。
它就是軟件行業(yè)的精益生產
【G按: 其實agile運動有一個提法，就是反對把軟件當作工程學的來看待，軟件不能等同于大規(guī)模生產過程，不過其他領域的研發(fā)管理應該也有可以借鑒的部分,這個問題爭論很大。問題空間這個提法很有益，不同的開發(fā)方法都有特定的問題空間約束，另外把cmm和rup并列也是不對滴，打個比方，k大就專門有人寫過文章如何使用xp玩cmm，cmm和組織使用的具體軟件開發(fā)方法理論上無關】

[ zhenyue]
二戰(zhàn)后的美國，以福特公司為首的汽車制造公司在大肆提倡規(guī)模制造（Mass Prodution）的同時，東方的日本，豐田英二等人在考察了美國的制造思路之后，認為美國的制造方式不適合日本，提出了自己的精益制造（Lean Production）的思路，精益制造成就了一代霸主－豐田公司，豐田的制造方式被人稱為TPS（Toyota Production System）。豐田公司的豐田英二和大野耐一等人進行了一系列的探索和實驗，根據日本的國情，提出了一系列改進生產的方法：及時制生產、全面質量管理、并行工程，逐步創(chuàng)立了獨特的多品種、小批量、高質量、低消耗的生產方式。這些方法經過30多年的實踐，形成了完整的"豐田生產方式"，幫助汽車工業(yè)的后來者日本超過了汽車強國美國，產量達到1300萬輛，占到世界汽車總量的30％以上。

　　回顧這段歷史，和軟件開發(fā)的歷史何其相似。大規(guī)模制造理論認為，一定程度的浪費，一定程度的廢品是正常的，允許的。而在軟件開發(fā)中，浪費、成本居高不下也同樣成為阻止軟件開發(fā)邁向工程化的一大障礙。像XP這樣的敏捷方法從精益制造的思路中吸取了很多的優(yōu)秀思想，例如，不斷改進質量，設計決策應該交給最貼近生產的人員，根據客戶的需求來推動生產。雖然我們一直在強調軟件開發(fā)和制造行業(yè)截然不同，但是，處于變革的十字路口的軟件開發(fā)行業(yè)，總是不斷的從其它的行業(yè)中尋找可借鑒的理論。這種借鑒來的思路就被稱為精益編程（Lean Programming）。

【G按:問題是軟件業(yè)從來就沒有出現過福特汽車式的流水線大生產模式，印度的軟件工廠只是個案，并未解決所有的問題域空間，又怎么提生產模式的改進？ xp從精益制造的思路吸取很多優(yōu)秀思想的這個說法是臆造的。xp起始于c3項目，大部分關鍵實踐在xp出現之前就已經出現，并在很多項目中使用，而c3項目的發(fā)生地。。。。】

[ zhenyue]
在管理軟件領域， 抱怨客戶需求變更的情況及其普遍， 而且這條路已經走死。
【G：這也是xp的出發(fā)點】
試想

就算 客戶的業(yè)務流程與工程文檔100%同步且需求分析100%正確，代碼100%符合文檔。

就一定保障客戶會滿意嗎， 客戶馬上會發(fā)現自己的業(yè)務流程有問題，而要求你修改文檔和程序。

而這一過程僅僅是用程序來驗證客戶的業(yè)務流程而已， 并沒有同時起到優(yōu)化客戶的業(yè)務流程的作用。

最好的思想還是SAP的行業(yè)最佳業(yè)務實踐。

管理軟件的開發(fā)上，一定要管理理論優(yōu)先。
【G:貌似在絕大部分問題域，理論永遠是落后于實踐的，而且信息系統(tǒng)的建設一定是對現有業(yè)務模式的重組過程】


 [florid.dong] 
 XP只是個理論，具體方法有很多，如Scrum等。XP不是將代碼轉向測試，要知道客戶付錢的是實際代碼，不是用你的測試代碼，更不會為你測試付錢的，你應該對你的產品負責的。

測試細分又有很多，大類有static testing, Dynamic testing, 功能分有Unit Testing, Iteration Testing, Acceptance Testing等，要按模塊分又有UI Testing, DB Testing等等，還有很多支持手段貫穿各個階段，如Daily Build, Code Coverage, Duplicate Analysis等，太細了

【G：這位把xp和agile 弄混了，對測試工作的理解不錯】

需求的變動與來回折騰的問題。

[ florid.dong]
主要要原因是技術人員對業(yè)務的不了解而產生的誤解。以前的開發(fā)模式是先花大量時間分析，然后寫代碼寫出個完整的版本再讓用戶看。而XP方法是開發(fā)出不同的小版本來來逐步確認。

打個比方，路很好走，也知道方向，你會走的很快，而且一直走，但如果你不熟悉的路還大步走，不問人肯定出問題，而大多數開發(fā)人員過于自信了。所以現在要求，小步走，走的慢些，而且見一個人問一個人來保證方向正確。

需求變動可以看做來回折騰的前兆。原因都是一點，雙方都不了解到底要干嗎

【G按：道理講的蠻清楚，例子也舉得蠻好，不過有一點有問題，需求理解差異并非單純是技術人員的問題，而是雙方的問題，xp的一個核心就是希望解決用戶和技術人員的雙向溝通問題，小步迭代并非xp特有的，在rup這種重量級方法里也是核心。】

* [florid.dong] 需求的獲取問題

想讓用戶為把他們的單據可以輸入，就付你錢，你就從一開始就玩完了。你跟著他們走，遲早被變化的需求拖死。

但憑心而論，并不是需求變化了，而是用戶沒說清，或你沒有引導用戶說清，還有用戶自己也說不清。所有國內的管理軟件做的都像單據輸入一樣，可問題在于，你一旦這么一做，每個用戶的單據都不一樣，就像一個立方體，每個人看的面都不一樣，如果你只按看到一個面的用戶的要求做，你做不出立方體。要響應變化了，你的產品就要分叉了，時間一長，你就要維護N個版本，頭就大了。

必須知道用戶在想什么，并且要超過用戶才行，而現在的分析員，或開發(fā)員都太缺乏相應的業(yè)務背景了。

【G按：這個問題的根已經脫離了xp的范疇了，信息系統(tǒng)的建設本質都是對用戶業(yè)務管理模式的一次重構，試圖將現有手工處理模式簡單的copy為計算機模式本身就是錯誤的。對業(yè)務的理解，要超過用戶比較困難，各種顧問公司的存在并非因為他們真正的超過了用戶，更多是提供一種不同角度的思考借鑒和內部矛盾轉移。xp的做法其實相反，xp讓用戶來選擇，主導自己的需求，把責任推給用戶，這和傳統(tǒng)的開發(fā)模式是相背的。另外所謂n個版本的問題，其實架構方面可以解決】

 業(yè)務人員很少有人能了解公司里的所有業(yè)務與聯系，每個人都是只知道自己的工作內容。高層知道業(yè)務聯系，但完全不了解細節(jié)。很絕望是不是？但這是現實。

好的分析員，就像膠水，能把每個不同立方體聯系起來。差的分析員不但不能把每個立方體拼起來，自己還被立方體尖角扎死了。分析員的價值就在這里。

【G按：xp的做法好像是讓用戶去做這個膠水，呵呵】



自動測試的問題

[ florid.dong]

1）到什么地步，取決于你肯投入多少物力，人力。在我的TEAM中連UI測試都是自動進行的。測試人員是多于開發(fā)人員的，而且測試員的工作量要顯著多于開發(fā)人員，相應待遇也要高，能力最高的一般是測試人員。測試人員也是寫代碼的。
2）自動測試只是一種機制，在某個特定時刻自動執(zhí)行你寫的測試用例。我們的標準是，后臺，每三十分鐘檢查一次代碼庫，對一個Solution只要有一點變動，就靜態(tài)，動態(tài)，相關測試全跑一遍。還有每天晚上定時至少跑一次。前臺代碼，每天晚上至少跑一次，其它手工啟動。我們還沒辦法使不同的前臺測試同時運行，因為我們是直接通過Win32 API處理的。
測試取決于你的軟件開發(fā)模式，越模塊化的越好測試，在我的TEAM中，后臺開發(fā)與前臺開發(fā)是分離的，前后臺是單獨測試的。如果模塊切分的不好，測試就會很復雜。像蓋房子，一般都是一堵墻一測的，你整個房子蓋好的，當然測的東西要多。

【G: 這種做法其實已經不是xp了，xp中代碼測試是由開發(fā)人員完成的，需求測試是用戶完成的，體現了各自對各自工作的責任感。但是團隊中能做到測試人員人數的待遇都超過開發(fā)人員，是相當了不起的】

測試數據是否直接創(chuàng)建，取決于你是測那一塊。說說我們的做法
引用的基本數據先創(chuàng)建一部分，這樣，在引用這些數據的頁面里只要引用就好了。
如果是輸入等測試，要通過測試輸入數據，如果是查詢，就事先創(chuàng)建數據。
Test Case是很多的，五種不同屬性的供應商，三種結算方式，如果是關聯的，至少十五個Test case，如果不關聯，至少八個。如果再考慮錯誤，邊界，那就更多了。
換個角度想一想，如果不寫測試代碼，人走一遍，基本是不可能的，你稍微改動一下代碼，如果不全測，說不定，就影響其它部分了，三周后才發(fā)現，早就不知道什么原因造成的了。代碼再累也只寫一次，反正是機器，讓它跑去好了，一臺服務器，便宜的才幾千塊。那怕改一行，跑一天也沒多少成本，如果是人測，漏了一個，都頭痛。長期來看，成本反而會降低。沒苦那有甜

確實很累，要真正堅持下去，團隊領袖的意志力，技術力，判斷力都會變的很重要，這絕對是一個考驗。

【G: 這其實是xp和其他方法的一個差別，xp希望做到的是大家自覺折騰產生1+1>2的效果， 而不是依賴于團隊領袖的意志力和判斷能力】


我們的做法是，1. 測試用例是有重疊的，2. 靜態(tài)測試 3. 盡量將測試寫進我們的測試引擎，然后創(chuàng)建不同的場景，以測試 測試引擎。

沒有很好的辦法來保證，我的經驗是，一般來說，測試代碼只有遺漏，錯誤不多，因為不需要太多邏輯，只要創(chuàng)建數據，然后得到數據判斷是否是預期的，就好了。就是給個A，看出來的是不是B

【G: xp中對這個問題的處理一度程度上是依賴PP來解決的，也就是加強review】