qileilove

　　關于ERP，關于BETA測試理論性的文章太多了，看多了就是兩種結果，經歷過的只當看過了，沒經歷過的還是不知道怎么做。最近產品要發(fā)版了，準備開展BETA測試，10余家的BETA測試項目，無奈新人太多，怎么才能讓大家了解到BETA測試的實戰(zhàn)經驗以及遇到困難的時候如何應對？今天加班“憤筆急書”寫了一個BETA測試攻略，在這里也拿來和大家分享一下，希望我的經驗能夠成為你開展BETA測試的錦囊妙計。文章中沒有太多講解BETA測試的理論，如果你還不明白的，可以先看一下BETA測試相關的理論知識，同時相信我這篇文章對于ERP項目實施也會有一些幫助，在此先感謝各位的拜讀！（相關文檔涉及公司資料，不便提供，敬請諒解）

ERP系統(tǒng) BETA測試攻略

　　首先恭喜你將代表公司參加ERP系統(tǒng)的BETA測試，你將被派駐“前線”開展BETA測試的艱巨任務。任務中你會直接面對客戶，和客戶進行溝通交流。你也許會聽到客戶的贊賞，友好的溝通，也許會聽到客戶的批評乃至抱怨，甚至是不信任。你需要通過這次BETA行動讓客戶的贊賞升級到對ERP系統(tǒng)的敬仰；你需要扭轉客戶的抱怨以及對產品的不信任，讓他們重新認識ERP系統(tǒng)，認可ERP系統(tǒng)這一款偉大的產品。你準備好接受這次挑戰(zhàn)了嗎？Let’go！黨和人民期待你的凱旋歸來！

　　（BETA測試流程）

　　（團隊與協(xié)作）

　　請確認你的BETA測試團隊的負責人以及成員。你的團隊中會有測試人員以及開發(fā)人員，還可能有部署、性能專家，也許還會有產品經理或者需求分析師。不管你的團隊有多少人，請記住一旦出發(fā)，你們這個團隊需要完成BETA測試的所有任務。在前方你需要和現場的實施顧問進行緊密協(xié)作，他們是你們在現場面對棘手問題的最有效的盟軍。不要嘗試自己解決所有的問題，遇到緊急情況可以與總部取得聯(lián)系，記住你所在BETA測試項目的內部接口人，你遇到的所有問題以及需要尋求總部支持的時候都可以和他取得聯(lián)系，他是你在前線唯一的接口人，你只需要在前線有條不紊的開展工作，不要被煩心事打亂你的計劃，否則你將功虧一簣。

當我們在接到一個需要測試的項目或任務時。我們通常往往思考的是在系統(tǒng)中出現的錯誤現象。如單擊某個按鈕出現了http500現象，或是其他錯誤頁面。這在我們測試中是無可非議的測試工作。大家有沒有想過當你接受這個軟件時，她就像一個你從未接觸過的汽車。每個檔位的轉換，每個功能按鈕的操作、及其作用都是陌生的。在這個時候你感覺麻煩的地方是最多的時候，有些問題當你接觸的時間長了你會有一些麻木感。往往這些麻木感就會變成了習慣。習慣的東西也就無所謂了，或許就是正確的。

　　很多項目或產品，當我們的系統(tǒng)軟件拿到用戶現場的時候。我們的用戶會提出一大堆問題。這個該怎么做，那個該怎么做。為什么會有這么多問題的反饋。項目還好說我們大不了給他們進行培訓。當我們做成產品的時候，批量生產發(fā)貨的時候，我們就沒有精力去照顧每個用戶。用戶最開始使用你的東西時，第一印象是非常重要的，用戶很少會花很長時間去試用你的推薦。用戶感覺這個軟件或系統(tǒng)好不好用，很大程度上是在他與機器之間的互通上。

　　我感覺有兩點值得我們測試人員關注的。

　　其一，系統(tǒng)本身的操作，其繁簡程度、流程規(guī)劃上。我們應該熟知業(yè)務的需求、規(guī)則。如出版業(yè)務都需要其三審，每一審我們展現的同樣的東西，他們也能工作。有時開發(fā)圖省事把所有的功能都整合一起，共同使用。必然會帶來很多沒必要的操作。他們的重點是不一樣，我們不應該把每一審都一樣，我們要展現給每一審的他們關注的重點，他們的需要的操作。每個人測試的行業(yè)都可能不一樣，這就需要我們去了解它，運用到我們的測試中。

　　其二，用戶本身常用操作，使用習慣。這里也就是說用戶的習性了。如用戶等待時間等。及其軟件使用的一些“潛規(guī)則”。如按鈕的擺放，一些頁面的大小等。這就需要我們在平時的多加積累。之前剛開始測試遇見一個問題，就是在彈出頁面后讓選擇其多個目錄。我單擊一下選擇框沒選中，又單擊還是沒選中。之后又單擊的內容才勾選上前面的選擇框。這一個問題就凸現了我們的使用習慣。在用戶使用中一些規(guī)范的提示。圖標的運用、快捷鍵、提示的語義等問題，也是值得我們注意的。

　　剛接手的系統(tǒng)，它的安裝、配置、使用等，應該去記錄我們感覺有疑問的操作。在之后的測試工作中在詳細的去分析這些疑問。該增、改減、該修、該改，我們再去判定。

　　在之前的文章里，已經介紹了幾種不同的成長曲線的形式，知道了幾種曲線的趨勢情況。比如，指數曲線就是呈指數的不斷增長；S型曲線就是先增后趨于平穩(wěn)。然而，再進一步，怎么擬合出適合給定樣本數據的模型曲線呢？這回，我們介紹曲線的幾種擬合算法。

　　曲線擬合主要有3種算法：三點法、三和法和高斯-牛頓法。下面簡單介紹3種算法的原理。

　　1、三和法：

　　三和法是利用三個和值來進行計算。將數據平均分成三段，分別求這三段數據的和；隨后將三個和值依次做減法；通過求減法得出要預測的參數。也就是求解三元一次方程組，得到最終參數的值。

　　2、三點法：

　　三點法亦如它的名字，是利用三個點的值來進行計算。選擇數據的起點、中點和終點，得到三元一次方程組；解出方程組，得到參數值。

　　3、高斯-牛頓法：

　　高斯-牛頓法是用逐次逼近的方式來得到最佳參數值。高斯-牛頓法的計算過程是一個不斷迭代的過程。由于高斯-牛頓法的計算原理為尋找最優(yōu)值，因此得到的結果應該最接近實際情況，擬合度最高。然而，高斯-牛頓法對數據要求較高，會出現由于數據原因無法計算的情況。

　　由于算法公式較為復雜，暫時沒有發(fā)表在網站上，但我們會盡快整理。

　1、熟悉工作環(huán)境，認識新同事

　　2、制定學習計劃、跟進學習進度

　　（1）了解新人的情況，制定出盡量適合新人的學習計劃，計劃制定的要細致，包括各個階段要學習的內容、學習時間、學習資料、學習產出。

　　（2）找個機會和新人一起看下學習計劃，講解計劃內容以及認真聽取新人的意見，根據新人反饋的信息適當的調整計劃。和新人的溝通可以讓自已更能了解新人，制定盡量適合新人的計劃能讓新人帶著合理的目標去學習，而不會讓新人感到迷茫和困惑。

　　（3）跟進學習進度是讓自已了解前期制定的計劃是不是適合新人，并且可以通過這種方式了解新人的學習情況和遇到的問題，及時根據具體情況協(xié)助新人解決。在新人執(zhí)行計劃前，告訴新人以日報的形式反映學習進度、遇到的問題、心得。

　　3、講解概念性的問題，讓新人從整體上有個大概了解

　　（1）工作內容：新人一進來不知道自已所在的組是做什么測試的，自已的職責和任務是什么。所以師傅要主動介紹工作內容，測試的系統(tǒng)是什么，是通過哪種方式進行測試，以及她將來要做的工作是什么。

　　（2）發(fā)布流程方面：告訴新人發(fā)布流程的學習網址，告知流程平臺的作用。

　　（3）業(yè)務方面：

　　● 告訴新人業(yè)務的學習網址，告知業(yè)務學習是根本，雖然一進來是做接口測試，但是只有在了解業(yè)務的情況下才能更好的勝任測試的工作。

　　● 把自已以前整理好的主要業(yè)務流程圖和基本業(yè)務術語文檔給新人，先讓新人閱讀，第一遍看新人肯定會懵，所以師傅應該給予大概的講解，告訴新人遇到任何問題都可以問，不怕被打擾，只怕沒問題問，因為只有新人帶著問題問才知道新人需要什么幫助。

　　● 新人有一定的經驗后可以給予新人整理某塊業(yè)務的機會，這樣有助于她對這塊業(yè)務更深層次的了解。由于我?guī)У男氯怂峙涞墓ぷ魅蝿帐亲鼋涌跍y試和偶爾做功能測試，其實在做功能測試的時候她已經了解了一些業(yè)務，所以我會整理出相關業(yè)務的一級業(yè)務點和底層對應的接口，然后讓新人查找知識沉淀或者功能基線用例庫把該業(yè)務的所有業(yè)務點畫出mm圖，讓她試著根據閱讀接口的實現代碼進行完善mm圖。

　　（4）測試流程方面：測試流程是新人需要掌握的，這樣可以讓新人知道整個測試各個階段需要做哪些工作，包括：什么時候了解需求、什么時候測試用例評審、什么時候開始測試、什么時候接口測試完成進入功能測試、什么時候daily測試，什么時候預發(fā)測試。

　　（5）測試技術方面：

　　● 給新人分享所測系統(tǒng)的架構以及如何搭建接口測試環(huán)境，這個分享是很有必要的，新人不僅要知其然而且要知其所以然，所以講解的時候要通俗易懂，目的只想讓新人知道被測系統(tǒng)是怎樣的架構，我們又是如何進行接口測試的，直到新人能真正理解為止。

　　● 給個簡單的接口讓新人第一次與接口測試親密接觸，我是以一個業(yè)務邏輯非常簡單的接口讓新人做的，因為第1次做接口測試，我會告訴她如何去設計正常流和異常流測試用例，如何寫測試腳本和驗證點到位。同時，我會寫好第1個測試腳本，然后讓她完成其他腳本的編寫，并且給予review。

　　● 給新人找個稍微有點業(yè)務邏輯的接口讓她測試，這樣她可能通過對這個接口測試了解到相關的業(yè)務，也可以了解更復雜點的開發(fā)代碼

　　● 告訴新人如何提bug

　　● 告訴新人測試過程中的重點是什么，以及測試時間的把握

　　4、善于聽取新人的問題并給予回復

　　（1）新人問問題是一件非常正常的事情，反而沒有問題可以問這才叫人干著急，所以當新人問問題的時候，尤其前幾次問師傅問題時，師傅態(tài)度要誠懇，要有耐心，要是一個很好的聽眾。這點是從我?guī)煾邓稳焙臀睦誓菍W到的，我覺得做好一個師傅，要善于聽取新人的問題和意見，這樣新人才敢拋出問題，不會把問題爛到肚子里，從而才能解決問題，這樣也可以提升以后的工作效率。

　　（2）幫新人解決問題時最好告訴新人自已怎么解決的，解決的思路和方法是什么，這樣在你幫她解決問題的同時也在教她知識，下次同樣的問題她就會解決了。

　　5、信任和鼓勵對方、讓新人更加自信

　　（1）第1次讓新人整理mm圖時，我會給予一些指導，同時自已也會整理同一個業(yè)務的mm圖，然后對比新人產出的mm圖和新人一起討論，這樣可以知道她的思路是什么，思路對不對，以及表達我自已的觀點。互相討論交換思考可以讓新人覺得你尊重她，同時她也會很愿意很主動的表達自已的觀點。

　　（2）新人來到新的環(huán)境工作，心里或多或少會有點壓力，在工作中偶爾問問新人工作和生活情況，關心下新人，會讓她感覺到新環(huán)境的溫暖，也許可以讓她更輕松更快樂的工作。

　　（3）多鼓勵別人是一種美德，因為這是你對新人的認可，會讓新人更有信心和激情去勝任手頭上繁忙的工作。

　　（4）當新人成長了，達到自已的預估目標時，我覺得要讓新人獨立的去承擔一些工作，可能新人會很有壓力，心里會擔心萬一業(yè)務理解的有偏差遺漏了問題怎么辦，萬一在發(fā)布之前測不完怎么辦。其實這種心態(tài)是很正常的，所以師傅要把握好這個度，要做好review工作，要在適當的時候問問新人進展過程中有什么風險需不需要幫助。當新人獨立的完成了測試工作，體會到整個測試并沒有延期，并沒有遺漏的問題時，新人會更自信的面對以后的工作。因為信任，所以簡單。

　　*建立起一個全局目標后，再開始測試

　　探索式測試的幾個目標：

　　1、理解應用程序如何工作、它的接口看起來怎樣、它實現了哪些功能

　　2、強迫軟件展示全部能力：

　　*目的是讓軟件努力運行，證明軟件確實實現了設計時所要求達到的功能

　　3、找到缺陷，并有目的的使缺陷數量降為零

　　把軟件特性劃分成幾個相互重疊的“區(qū)域”，具體區(qū)域和測試方法如下：

　　商業(yè)區(qū)：

　　*含義：用戶所要使用的軟件特性和功能，你的軟件包裝盒上描述的特性和掩飾的特性及代碼

　　測試方法：

　　1、指南測試法：根據用戶說明書來測試

　　2、賣點測試法：觀摩哪些銷售演示，測試演示過程，并且可以加上質疑測試法

　　3、地標測試法：提前確定關鍵的軟件特性，確定他們的前后順序

　　4、極限測試法：向軟件提出最困難的問題

　　5、快遞測試法：關注于數據，找到每個和數據有接觸的軟件特性

　　6、遍歷測試法：通過選定一個目標（例如所有菜單項、所有錯誤消息或所有對話框），然后使用可以發(fā)現的最短路徑來訪問目標包含的所有對象

　　歷史區(qū)：

　　*含義：從前版本遺留下的代碼，還有那些曾經出現較多缺陷的特性和功能

　　測試方法：

　　1、惡鄰測試法：反復測試缺陷特別多的地方

　　2、博物館測試法：關注被接受重新修改的老代碼，或者是沒被改動就放到新環(huán)境中運行的老代碼

　　3、上一版測試法：回歸測試，關注新版本中無法再運行的測試用例

　　娛樂區(qū)：

　　*含義：軟件的輔助特性，而不是主線特性

　　測試方法：

　　1、配角測試法：關注和主要的特性非常鄰近的特性，例如和主要的特性一同出現在顯示器上，容易被用戶注意

　　2、深巷測試法：軟件中最不可能被用到的或者最不吸引用戶的特性，有助于提高代碼覆蓋率

　　*注：多個特性混合在一起測試時，比如重要的和不重要的混在一起時，可以考慮：

　　**有關輸入的問題：這兩個特性會不會處理同一輸入

　　**有關輸出的問題：這兩個特性功能是否在可見的用戶界面上操作同一塊區(qū)域？他們會產生同一個輸出嗎？

　　**有關數據的問題：這兩個特性會操作其共享的一些內部數據？是讀取共享數據、還是修改共享數據

　　3、通宵測試法：性能測試和壓力測試，永遠不關閉程序，連續(xù)不斷的使用某些特性來測試軟件

【導讀】教你維護SQL Server數據庫日志。

　　交易日志(即oracle中的事務)（Transaction logs）是數據庫結構中非常重要但又經常被忽略的部分。由于它并不像數據庫中的schema那樣活躍，因此很少有人關注交易日志。

　　交易日志是針對數據庫改變所做的記錄，它可以記錄針對數據庫的任何操作，并將記錄結果保存在獨立的文件中。對于任何每一個交易過程，交易日志都有非常全面的記錄，根據這些記錄可以將數據文件恢復成交易前的狀態(tài)。從交易動作開始，交易日志就處于記錄狀態(tài)，交易過程中對數據庫的任何操作都在記錄范圍，直到用戶點擊提交或后退后才結束記錄。每個數據庫都擁有至少一個交易日志以及一個數據文件。

　　出于性能上的考慮，SQL Server將用戶的改動存入緩存中，這些改變會立即寫入交易日志，但不會立即寫入數據文件。交易日志會通過一個標記點來確定某個交易是否已將緩存中的數據寫入數據文件。當SQL Server重啟后，它會查看日志中最新的標記點，并將這個標記點后面的交易記錄抹去，因為這些交易記錄并沒有真正的將緩存中的數據寫入數據文件。這可以防止那些中斷的交易修改數據文件。

　　維護交易日志

　　因為很多人經常遺忘交易日志，因此它也會給系統(tǒng)帶來一些問題。隨著系統(tǒng)的不斷運行，日志記錄的內容會越來越多，日志文件的體積也會越來越大，最終導致可用磁盤空間不足。除非日常工作中經常對日志進行清理，否則日志文件最終會侵占分區(qū)內的全部可用空間。日志的默認配置為不限容量，如果以這種配置工作，它就會不斷膨脹，最終也會占據全部可用空間。這兩種情況都會導致數據庫停止工作。

　　對交易日志的日常備份工作可以有效的防止日志文件過分消耗磁盤空間。備份過程會將日志中不再需要的部分截除。截除的方法是首先把舊記錄標記為非活動狀態(tài)，然后將新日志覆蓋到舊日志的位置上，這樣就可以防止交易日志的體積不斷膨脹。如果無法對日志進行經常性的備份工作，最好將數據庫設置為“簡單恢復模式”。在這種模式下，系統(tǒng)會強制交易日志在每次記錄標記點時，自動進行截除操作，以新日志覆蓋舊日志。

　　截除過程發(fā)生在備份或將舊標記點標為非活動狀態(tài)時，它使得舊的交易記錄可以被覆蓋，但這并不會減少交易日志實際占用的磁盤空間。就算不再使用日志，它依然會占據一定的空間。因此在維護時，還需要對交易日志進行壓縮。壓縮交易日志的方法是刪除非活動記錄，從而減少日志文件所占用的物理硬盤空間。

　　通過使用DBCC SHRINKDATABASE語句可以壓縮當前數據庫的交易日志文件，DBCC SHRINKFILE語句用來壓縮指定的交易日志文件，另外也可以在數據庫中激活自動壓縮操作。當壓縮日志時，首先會將舊記錄標記為非活動狀態(tài)，然后將帶有非活動標記的記錄徹底刪除。根據所使用的壓縮方式的不同，你可能不會立即看到結果。在理想情況下，壓縮工作應該選在系統(tǒng)不是非常繁忙的時段進行，否則有可能影響數據庫性能。

　　恢復數據庫

　　交易記錄備份可以用來將數據庫恢復到某一指定狀態(tài)，但交易記錄備份本身不足以完成恢復數據庫的任務，還需要備份的數據文件參與恢復工作。恢復數據庫時，首先進行的是數據文件的恢復工作。在整個數據文件恢復完成前，不要將其設為完成狀態(tài)，否則交易日志就不會被恢復。當數據文件恢復完成，系統(tǒng)會通過交易日志的備份將數據庫恢復成用戶希望的狀態(tài)。如果在數據庫最后一次備份后，存在多個日志文件的備份，備份程序會按照它們建立的時間依次將其恢復。

　　另一種被稱為log shipping的過程可以提供更強的數據庫備份能力。當log shipping配置好后，它可以將數據庫整個復制到另一臺服務器上。在這種情況下，交易日志也會定期發(fā)送到備份服務器上供恢復數據使用。這使得服務器一直處于熱備份狀態(tài)，當數據發(fā)生改變時它也隨之更新。另一個服務器被稱作監(jiān)視（monitor）服務器，可以用來監(jiān)視按規(guī)定時間間隔發(fā)送的shipping信號。如果在規(guī)定時間內沒有收到信號，監(jiān)視服務器會將這一事件記錄到事件日志。這種機制使得log shipping經常成為災難恢復計劃中使用的方案。

　下面的分析，米盧教練說了，內容不重要，重要的是態(tài)度。就像韓局長對待日記的態(tài)度那樣，嚴謹而細致。

　　只要你使用這樣的態(tài)度開始分析內核，那么無論你選擇內核的哪個部分作為切入點，比如USB，比如進程管理，在花費相對不算很多的時間之后，你就會發(fā)現你對內核的理解會上升到另外一個高度，一個抱著情景分析，抱著0.1內核完全注釋，抱著各種各樣的內核書籍翻來覆去的看很多遍又忘很多遍都無法達到的高度。請相信我！

　　讓我們在Linux社區(qū)里發(fā)出號召：學習內核源碼，從學習韓局長開始！

　　態(tài)度決定一切：從初始化函數開始

　　任小強們說房價高漲從現在開始，股評家們說牛市從5000點開始。他們的開始需要我們的錢袋，我們的開始只需要一臺電腦，最好再有一杯茶，伴著幾支小曲兒，不盯著錢總是會比較愜意的。生容易，活容易，生活不容易，因為總要盯著錢。

　　有了地圖Kconfig和Makefile，我們可以在龐大復雜的內核代碼中定位以及縮小了目標代碼的范圍。那么現在，為了研究內核對USB子系統(tǒng)的實現，我們還需要在目標代碼中找到一個突破口，這個突破口就是USB子系統(tǒng)的初始化代碼。

　　針對某個子系統(tǒng)或某個驅動，內核使用subsys_initcall或module_init宏指定初始化函數。在drivers/usb/core/usb.c文件中，我們可以發(fā)現下面的代碼。

　　我們看到一個subsys_initcall，它也是一個宏，我們可以把它理解為module_init，只不過因為這部分代碼比較核心，開發(fā)者們把它看作一個子系統(tǒng)，而不僅僅是一個模塊。這也很好理解，usbcore這個模塊它代表的不是某一個設備，而是所有USB設備賴以生存的模塊，Linux中，像這樣一個類別的設備驅動被歸結為一個子系統(tǒng)。比如PCI子系統(tǒng)，比如SCSI子系統(tǒng)，基本上，drivers/目錄下面第一層的每個目錄都算一個子系統(tǒng)，因為它們代表了一類設備。

　　subsys_initcall(usb_init)的意思就是告訴我們usb_init是USB子系統(tǒng)真正的初始化函數，而usb_exit()將是整個USB子系統(tǒng)的結束時的清理函數。于是為了研究USB子系統(tǒng)在內核中的實現，我們需要從usb_init函數開始看起。

　　導讀：作者陳皓在微博上說過這樣一段話：“聰明的程序員使用50%-70%的時間用來思考，嘗試和權衡各種設計和實現，而用30%–50%的時間是在忙碌著編碼，調試和測試。聰明的老板也會讓團隊這樣做。而愚蠢的老板，愚蠢的程序員會拿出來100%-150%的時間來忙著趕進度，返工，重構，fix大量的bug…所以，越差的團隊一般會越忙，而且還忙不完。”文中作者就此觀點進行闡述。

　　文章內容如下：

　　在現在這個浮躁的時期，再加上敏捷咨詢師們念的歪經，他們讓人感覺上就像是軟件產品是可以在很短的時間內高質量的完成的，這令那些管理者們很興奮，就像巴甫洛夫的條件反射實驗中的狗看到了肉就像流口水那樣興奮。他們使用TDD，快速迭代，不斷重構，持續(xù)集成直至持續(xù)部署的方法在進行軟件開發(fā)。

　　軟件開發(fā)真是這樣的嗎？難道不需要花時間去思考嗎？對此，有些觀點在Todd的《“品質在于構建過程”嗎？》以及《Bob大叔和Jim Coplien對TDD的論戰(zhàn)》中談到過了。我只想想表達下面的觀點：

　　● 軟件的精髓在于設計，設計是一件很費大腦的事件。對于軟件來說，設計沒有完美的，它總是一件需要取舍需要權衡的事，比如：時間換空間，空間換時間，TCP或UDP，同步還是異步，數據冗余還不冗余等等。那怕是一個小小的observers模式是pull方式還是push方式都需要仔細討論。這些的東西需要時間和做前期嘗試。

　　● TDD、快速原型和迭代可能會對軟件和團隊產生負面影響。在一開始，你需要花很大的精力來讓你的軟件從無到有（做過軟件的人都知道，從零開始寫代碼是很痛苦的事），但是因為你沒有想好，先做再說，所以，后期你會面臨更多的質量問題而讓你需要花更多的時間精力。當然，那些咨詢師會讓你用持續(xù)集成和持續(xù)部署這樣的方法。但我想告訴你，這并不解決你軟件設計的缺陷。舉個例子——TDD、迭代、原型只關注功能性需求，其不會關注非功能性需求，比如性能問題，高可用性問題，系統(tǒng)維護問題（模塊的耦合問題），等等。而這些問題往往都可以讓你的軟件設計重新來過。

　　● 重構是惡夢，重構應該越少越好。當你維護一個復雜的系統(tǒng)時你會知道重構是一件多么恐怖的事情（參看《重構代碼的7個階段》）。如果一開始沒有想好，你要面臨的不單單是re-design， re-architect，還要面對時間和人力成本的增加，最難的是你還要面對的是團隊士氣因為不斷的rework而逐漸低落并產生厭倦和懈怠情緒。

　　所以，如果你能有多一些時間去和客戶討論一下需求和未來可能的變化，去調查一下實現的技術難點和細節(jié)，去和其他有經驗的人討論并推敲一下架構和設計，去思考設計上的缺陷，那么，你的coding會變得非常地直，直到你一眼就看到盡頭，你的測試案例也會寫得非常地好，你會幾乎不需要重構，于是，你會在未來少寫很多代碼，從而你的軟件開發(fā)會越來越輕松，直到技術開始換代。

　　我現在在做的項目，花了幾乎4個月的時間來做設計，在這個過程中，我們反復思考、討論和權衡若干種實現方法，并盡可能地窮舉所有的場景和細節(jié)以及未來可能的變化（那怕是那些簡單的模塊），有個模塊被重寫了至少三次，每次都是寫到一半就被推翻重寫，我們整個團隊不斷地在和其它團隊討論，并在對系統(tǒng)不斷地認識中對系統(tǒng)進行簡化和優(yōu)化，并力求達到完美。現在看來，沒有貿然使用Scrum是明智的。