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

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

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

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

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

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

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

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

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

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

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


 [florid.dong] 
 XP只是個理論，具體方法有很多，如Scrum等。XP不是將代碼轉(zhuǎn)向測試，要知道客戶付錢的是實(shí)際代碼，不是用你的測試代碼，更不會為你測試付錢的，你應(yīng)該對你的產(chǎn)品負(fù)責(zé)的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



自動測試的問題

[ florid.dong]

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

【G: 這種做法其實(shí)已經(jīng)不是xp了，xp中代碼測試是由開發(fā)人員完成的，需求測試是用戶完成的，體現(xiàn)了各自對各自工作的責(zé)任感。但是團(tuán)隊(duì)中能做到測試人員人數(shù)的待遇都超過開發(fā)人員，是相當(dāng)了不起的】

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

確實(shí)很累，要真正堅(jiān)持下去，團(tuán)隊(duì)領(lǐng)袖的意志力，技術(shù)力，判斷力都會變的很重要，這絕對是一個考驗(yàn)。

【G: 這其實(shí)是xp和其他方法的一個差別，xp希望做到的是大家自覺折騰產(chǎn)生1+1>2的效果， 而不是依賴于團(tuán)隊(duì)領(lǐng)袖的意志力和判斷能力】


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

沒有很好的辦法來保證，我的經(jīng)驗(yàn)是，一般來說，測試代碼只有遺漏，錯誤不多，因?yàn)椴恍枰噙壿嫞灰獎?chuàng)建數(shù)據(jù)，然后得到數(shù)據(jù)判斷是否是預(yù)期的，就好了。就是給個A，看出來的是不是B

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