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

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

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

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

【G按:問(wèn)題是軟件業(yè)從來(lái)就沒(méi)有出現(xiàn)過(guò)福特汽車式的流水線大生產(chǎn)模式，印度的軟件工廠只是個(gè)案，并未解決所有的問(wèn)題域空間，又怎么提生產(chǎn)模式的改進(jìn)？ xp從精益制造的思路吸取很多優(yōu)秀思想的這個(gè)說(shuō)法是臆造的。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%符合文檔。

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

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

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

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


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

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

【G：這位把xp和agile 弄混了，對(duì)測(cè)試工作的理解不錯(cuò)】

需求的變動(dòng)與來(lái)回折騰的問(wèn)題。

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

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

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

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

* [florid.dong] 需求的獲取問(wèn)題

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

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

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

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

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

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

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



自動(dòng)測(cè)試的問(wèn)題

[ florid.dong]

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

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

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

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

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


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

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

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