【文章內(nèi)容簡介】 的 “ 故事 ” 。 ?每個故事由客戶書寫并臵于一張索引卡上，客戶根據(jù)對應特征或功能的全局業(yè)務價值度標明權值（故事優(yōu)先級）； ?評估每個故事給出開發(fā)周數(shù)為單位的成本； ?客戶和團隊共同決定故事分組； ?團隊對待開發(fā)故事進行排序 ?團隊計算項目的速度 ?在開發(fā)過程中，用戶可增加、減少故事數(shù)，以及改變故事的優(yōu)先級。 極限編程的過程 ?設計 ： XP設計嚴格遵循 KIS原則，即使用簡單而不是復雜的表述。另外，設計為故事提供不多也不少的實現(xiàn)原則，不鼓勵額外功能性設計 。 ?鼓勵使用 CRC卡（類 責任 協(xié)作者 ）確定和組織與當前軟件增量相關的類； ?如果某個故事的設計中遇到困難，采用 Spike方案； ?鼓勵重構 ?XP的中心觀念是設計與編碼可以同時進行。 極限編程的過程 ?編碼 ： XP推薦的故事開發(fā)和基本設計完成之后，團隊不應直接開始編碼，而是開發(fā)一系列用于檢測本次（軟件增量）發(fā)布的包括所有故事的單元測試。 XP編碼活動中的關鍵概念之一是 結對編程 。 ?XP建議兩個人共同為一個故事開發(fā)代碼，提供實時解決問題和實時保證質量。 極限編程的過程 ?測試 ：在編碼開始之前建立單元測試是 XP方法的關鍵因素。所建立的單元測試應當使用一個可以自動實施的框架，這種方式支持代碼修改之后即時的回歸測試策略。 ?一旦將個人的單元測試組織到一個 “ 通用測試集 ”，每天都可以進行系統(tǒng)的集成和確認測試。 ?XP驗收測試，也稱為客戶測試，則客戶規(guī)定技術條件，并且著眼于客戶可見的、可評審的系統(tǒng)級的特征和功能。 極限編程的有效實踐 ? 增量式開發(fā) ? 小版本短周期交付 ? 結對編程 ? 代碼集體所有 ? 開放的工作空間 ? 可持續(xù)的開發(fā)速度： 40小時 /周，連續(xù)加班不超過兩周 ? 簡單的設計 ? 測試驅動開發(fā) ? 持續(xù)集成 ? 重構 ? 及時調整計劃 ? 客戶作為開發(fā)團隊成員 敏捷開發(fā)的優(yōu)點和缺點 ? 優(yōu)點： ? 對變化和不確定性有更快速更敏捷的反應 ? 在快速的同時保持可持續(xù)的開發(fā)速度 ? 能較好的地適應商業(yè)競爭環(huán)境下對小項目提出的有限資源和有限開發(fā)時間的約束 ? 缺點： ? 極限編程中的測試驅動開發(fā)可能會導致系統(tǒng)通過了測試但不是用戶期望的 ? 重構而不降低系統(tǒng)體系結構的質量是困難的 ? 用于大型項目有很多問題 敏捷開發(fā)實例 在敏捷軟件開發(fā)中，測試人員的職責有三個主要方面： ? 定義質量 (Define Quality) ? 交流缺陷（ Communication） ? 及時反饋 (Feedback) 我們的測試框架提供自助測試 (Selfassistant Test)：通過點擊測試用例列表中的某個具體用例，開發(fā)人員不需要中斷測試人員的工作就可以重現(xiàn)缺陷。 敏捷開發(fā)中的測試流程 結合一個軟件項目，詳細介紹項目流程中的主要測試活動，每個活動的前提條件和目標任務等。 項目介紹：根據(jù)一家在線 B2B 公司的要求，我們將為其開發(fā)一款類似于谷歌的搜索服務。作為 Web Service，該服務可以內(nèi)嵌于網(wǎng)頁中。當用戶輸入關鍵詞并選擇商戶的類型和位臵后，系統(tǒng)會返回具體商戶的列表 典型的敏捷開發(fā)和測試活動 主要由三部分構成 ， 從最初的用戶故事設計和發(fā)布計劃 ， 到幾次 Sprint 周期的迭代開發(fā)和測試 ， 以及最后的產(chǎn)品發(fā)布階段 。 每個時間段都有相應的測試活動 。 通常 Sprint 周期被分成兩類：特征周期 （Feature Sprint） 和發(fā)布周期 （ Release Sprint） 。 特征周期主要涉及 新功能的開發(fā)和各類測試 。 發(fā)布周期則會結合計劃 ， 確定新版本功能 ， 然后對最新的功能進行測試 。 典型的敏捷開發(fā)和測試活動 敏捷開發(fā)的主要活動 測試活動 用戶故事設計 尋找隱藏的假設 發(fā)布計劃 設計概要的驗收測試用例 迭代 Sprint 估算驗收測試時間 編碼和單元測試 估算測試框架的搭建 重構 詳細設計驗收測試用例 集成 編寫驗收測試用例 執(zhí)行驗收測試 重構驗收測試 Sprint 結束 執(zhí)行驗收測試 下一個 Sprint 開始 執(zhí)行回歸測試 發(fā)布 發(fā)布 典型的敏捷開發(fā)和測試活動 ? 在迭代的 Sprint 周期中 ， 開發(fā)部分可以根據(jù)傳統(tǒng)步驟分成編碼和單元測試 、 重構和集成 。 需要指出的是 ， 重構和集成是敏捷開發(fā)的 Sprint 迭代中不可忽視的任務 。 如果在新的 Sprint 周期中要對上次的功能加以優(yōu)化和改進 ， 必然離不開重構和集成 。 ? 在每個 Sprint 周期結束前 ， 測試團隊將提交針對該 Sprint 周期或者上個 Sprint 周期中已完成的功能的驗收測試 （ 在實際項目中 ， 測試團隊的進度通常會晚于開發(fā)團隊 ） 。 這樣一來 ， 開發(fā)團隊可以運行驗收測試來驗證所開發(fā)的功能目前是否符合預期 。 當然 ， 這個預期也是在迭代中不斷變化和完善的 。 ? 當產(chǎn)品的所有功能得以實現(xiàn) ， 測試工作基本結束后 ， 就進入了發(fā)布周期 。 此時 ， 測試團隊的任務相對較多 。 用戶故事設計和發(fā)布計劃階段 在用戶故事和發(fā)布計劃階段，項目經(jīng)理和產(chǎn)品經(jīng)理會根據(jù)客戶的需求，制定概要的產(chǎn)品發(fā)布日程計劃。此時，測試人員可以和開發(fā)人員一起學習新的功能，了解客戶的需求。其中，有兩個主要活動：尋找隱藏的假設和設計概要的驗收測試用例。 下面我們將對各階段相應的測試活動作詳細的介紹和分析 用戶故事設計和發(fā)布計劃階段 尋找隱藏的假設 開發(fā)人員通常關注一些重要的系統(tǒng)功能而忽視細節(jié) 。 此外 ， 敏捷開發(fā)倡導簡單的實現(xiàn)方案 ， 每個開發(fā) Sprint 周期不可能將功能完美得實現(xiàn)；相反 ，每個 Sprint 都會增量得開發(fā)一些功能 。 所以 ， 測試人員在最初就需要從各種角度來尋找系統(tǒng)需求 ， 探索隱藏的假設 。 用戶故事設計和發(fā)布計劃階段 項目實例： 從在線 B2B 公司角度思考 Q：這個搜索框對公司的業(yè)務有什么價值？