一、介紹
這是一篇英文的文獻，昨天把他翻譯出來了。覺得還是比較有用，是以決定在這裡把它貼出來。
二、摘要
三、名詞解析（自己添加的）
3.1 面向傳遞的項目管理是一種項目管理方法，測試驅動開發是一種開發方法。
3.2 面向傳遞的項目管理：就是本文說的，把任務分下去，總體任務代表一個總的傳遞，然後各個子任務代表子傳遞。項目根據各個傳遞任務來進行管理。
3.3 疊代的開發方法：就是先完成部分主要的功能，形成一個版本。然後再逐漸添加新的功能，形成新的版本。
3.5 測試驅動開發：表示總的程式需要什麼功能，各個子子產品需要什麼功能。指定好測試用例，程式完成了測試用例的功能，就表示開發完成了。将測試用例用于開發過程中，而不是說先把程式寫好了，最後再測試。
3.6 可傳遞性（deliverable）：可以了解為可以傳遞的工作産品，就是具備獨立功能的一段代碼。
四、可傳遞性的定義
所有的工程項目，原則上都具有可傳遞性。如果采用疊代的開發途徑，為了制定一個疊代的、基于裡程碑節點的傳遞方案，需要将主傳遞性可以分成多個小的子傳遞性。（比如一個應用程式可以分成多個子產品、函數或者使用者開發實作）。
五、wbs和項目計劃
工作分解結構（wbs）是一個大家熟悉的而且非常有用的工具，用來将一個項目分解成容易管理的（也有人說可以消化的，或者可以咀嚼的）多個任務。在一定程度上，你配置設定wbs任務給單獨的開發組成員，（某些時候，是一小群開發成員），然後要求他們産生一個具體的可傳遞産品。
工作分解結構（wbs）往往是跟項目計劃緊密相連。這裡，對于工作分解結構（wbs），工作需要細化到每個任務對應一個可傳遞性的條款，然後配置設定到具體的小組成員。将具體的傳遞工作分給具體的小組成員，可以讓開發者将開發活動上聚焦在具體的、短期的目标上，同時也可以培養開發者的buy-in能力和責任感。
六、測試用例
自然，我們也為每個傳遞要寫一組測試用例。這些測試用例代表了每個子產品可以被接受的标準。可以有很多方法來做測試計劃和測試用例。大部分會包含某種形式的，一系列的執行動作和步驟，伴随着特定的結果。在我們的用例中，對于每一個可傳遞的子產品，我們将對應的測試用例填到excel電子表格中，并加注額外的資訊以便容易使用。下面就是excel表格的表項。
● 一個獨一無二的測試用例号
● 顯示id
● 顯示區域
● 執行的動作
● 期望的結果
● 得到的結果
→ 結果：通過，失敗，還沒有測試
→ 描述任何非期望的行為
→ 相關的缺陷追蹤問題
根據我們的經驗，一組好的測試用例能夠很完美的訓示産品是否準備好傳遞。理想的情況，是測試用例和産品的功能定義一同交給開發者，盡管在實際中，測試用例一般要晚一點點。分析文檔和測試用例為每一個子產品提供了具體的有形的目标，使得開發者能夠關注于代碼的編寫。
七、用測試來衡量進度
7.1 衡量測試結果
基于測試的進度報告能夠用一種容易了解的、客觀的觀點來審視項目進度。在我們的項目中，對每個子產品需要報告下面的測試狀态：
● 全部的測試用例
● 通過的測試
● 失敗的測試
● 還未進行的測試
我們從下面三個主要方面來進行度量：
● 一個子產品當所有的測試用例都由qa執行過，并測試成功，這個子產品就算完成了。qa包括内部測試組和使用者測試人員。
● 測試一個子產品需要的測試用例的數目反映了子產品的複雜度。雖然不總是這樣，但常常如此。
● 開發是疊代的：新版本被頻繁的傳遞，測試也需要不停的進行，而不是僅僅在項目的最後才進行測試。
在這些條件下，各個子產品的全部進度都可以通過各個子產品的測試用例通過的數目來衡量。如果你能可靠的在特定的時間點（裡程碑節點），獲得各個子產品通過的測試用例數、失敗的測試用例數和未測試的用例數，就可以把它制成如圖一所示的表格。
圖一：測試狀态表
7.2 子產品進度狀态
我從不相信一個開發者說他的一個子產品快要完成了。在我的書中，隻有所有的測試用例都通過了，一個子產品才算完成了。然而，有些被普遍接受的原則認為，如果一個程式，85%的測試用例通過了，就可以進行beta版測試了。盡管你理論上認為必須100%的測試用例通過，才能說産品準備好了，但是我們的使用者通常會接受産品，盡管産品還存在一些不嚴重的問題，并且這些問題在将來能夠被修補。是以，我們把子產品的“預産品”狀态定義為至少95%的測試用例通過并且沒有嚴重的問題。最後，我把子產品開發過程的階段劃分原則制定出來。
我們劃分成五個狀态來表示五個開發階段，通過測試成功的測試用例的數目來客觀的衡量。
● 計劃階段：還沒有開始編碼
● 開發階段：開始編碼
● beta版本階段：85%測試用例通過。
● 預産品階段：95%的測試用例通過，沒有發現嚴重的問題
● 産品準備好階段：100%的測試用例通過
一旦你有了測試用例通過的百分數，你就對子產品的開發進度和穩定性有了一個很好的評價。我們将這些資料用圖形來表示，寫在每周的進度報告中。
可以将進度表示成紫色的條圖，用來訓示子產品的工作進展。這能夠鼓勵開發者自發主動的清楚工作的進度。如圖2所示。
圖2 進度顔色條碼圖
八、基于測試的進度總覽
我們從更高的層次上，通過測試用過的資料來看項目的進度。如圖四所示。這圖對外行人很容易看懂，在項目的進展報告中，放在在執行總結情況這部分特别有用。
圖3 基于測試的項目進展總覽圖
九、缺陷資料
我們使用的疊代的開發周期，提供了友善的追蹤缺陷資料的基礎。（譯者注：因為疊代是周期性的送出版本，可以周期性的對每個版本測試，發現版本的缺陷）。我們一般一到兩周會送出一個面向使用者傳遞的版本，每周或者幾天就會送出一個内部版本。新版本的整潔性比增加的子產品數目或者修正的bug數目更重要。然而，qa人員在接受一個新版本之前，必須對上一個版本進行一個合理長的時間測試。傳遞的日期就必須一起商量決定。在期望的傳遞日期前，我們要考慮傳遞是否可行（能否修正嚴重的問題），要考慮哪些新子產品以及哪些bug能夠對使用者聲明。
為了實作這個，我們把缺陷資料放在缺陷資料庫，從資料庫中提取出缺陷資料來衡量産品的品質可可靠性。全局缺陷狀态圖表示了各個缺陷狀态（open, to-be-deployed,pending validation等）的缺陷數目。
我們對每次傳遞，都要衡量缺陷的狀态——記錄公開的問題數目和總的問題數。這對于傳遞規劃是非常重要的。
十、曆史資料
對于跟蹤随時間變化的測試的結果也是很重要。它能告訴你軟體的可傳遞性和穩定性的速度（多長時間可以産生一個傳遞版本，多長時間可以達到某種穩定程度）。如圖6和圖7所示。
圖6 曆史資料：随時間的測試完整性
圖7 曆史資料：随時間的測試完整性
十一、這個方法不能做的
（譯者注：這個方法指基于測試的項目進度管理）
這種方法不完備，也不是要取代傳統的項目進度跟蹤和彙報。這種方法的特别之處在于它是純粹面向傳遞的。是以它能夠幸運的忽略哪些諸如延時、開銷、資源消耗、關鍵途徑等等術語。這些術語能夠而且應該被諸如gantt圖，pert圖等代替。實際上，這種方法能夠給上層管理人員、小組成員和項目投資人等一個項目進度的直覺表示方法。基于測試的傳遞狀态是一個重要的而且容易了解的項目彙報方式。但是延遲、花費和面向任務的觀點同樣重要。
十二、對這種方法的評價（自己添加的評論）
測試用例的設計非常重要，要完備，系統。要有機制對測試用例的優先級進行設定，哪些優先級高，先實作；哪些沒那麼重要，後實作。 對各個測試用例要歸屬各個版本，哪個版本應該實作哪些測試用例。要設計好。
====================================分割線================================
最新内容請見作者的github頁：http://qaseven.github.io/