敏捷模型

前面的那些模型以前非常流行，但現(xiàn)在開發(fā)人員在使用的時候會遇到各種問題。主要困難包括在項目開發(fā)期間處理來自客戶的變更請求，以及合并這些變更所需要的高成本和時間。

• 在實際工作中，一款產(chǎn)品的功能是不斷在變化的

---

所以為了克服這些缺點，就提出了敏捷軟件開發(fā)模型。在敏捷模型中，需求被分解成許多可以增量開發(fā)的小部分。敏捷模型采用迭代開發(fā)。每個增量部分都是在迭代中開發(fā)的。

• 敏捷模型主要旨在幫助項目快速適應(yīng)變更請求。因此，敏捷模型的主要目的是促進(jìn)項目的快速完成
• 敏捷性是通過是過程適應(yīng)項目，刪除對特定項目可能不是必須的活動來實現(xiàn)的
• 避免任何浪費時間和精力的事情

敏捷模型中有一個非常重要的《敏捷宣言》：

• 個體與交互重于過程和工具（強調(diào)高效溝通）
• 可用的軟件重于完備的文檔（強調(diào)輕文檔，文檔不應(yīng)該作為工作驗收的標(biāo)準(zhǔn)）
• 客戶協(xié)作重于合同談判（主動了解當(dāng)下的需求）
• 響應(yīng)變化重于遵循計劃（能夠主動迎接變化）
  總結(jié)出敏捷模型的四個特點：輕文檔、輕流程、重目標(biāo)、重產(chǎn)出

scrum

敏捷開發(fā)有很多種?式，其中 Scrum 是?較流?的?種。在 Scrum 模型中，主要有三個角色和五個重要會議

三個角色

• product owner（產(chǎn)品經(jīng)理）負(fù)責(zé)整理 user story（用戶故事），定義其商業(yè)價值，對其進(jìn)行排序，制定發(fā)布計劃，對產(chǎn)品負(fù)責(zé)。收集需求，產(chǎn)出軟件需求文檔
• scrum master（項目經(jīng)理）負(fù)責(zé)召開各種會議，協(xié)調(diào)項目，為研發(fā)團(tuán)隊服務(wù)。
• team（研發(fā)團(tuán)隊）則由不同技能的成員組成，通過緊密協(xié)同，完成每一次迭代的目標(biāo)，交付產(chǎn)品。

迭代開發(fā)

與瀑布不同，Scrum 將產(chǎn)品的開發(fā)分為若干個小 sprint（迭代），其周期從 1 周到 4 周不等。參與的團(tuán)隊一般是 5 到 9 人。每期迭代要完成的 user story 是固定的，每次迭代會產(chǎn)生一定的交付

五個重要會議：

• 產(chǎn)品負(fù)責(zé)人負(fù)責(zé)整理 user story（用戶需求），形成 product backlog（需求列表）
• 發(fā)布計劃會議：product owner 負(fù)責(zé)講解 user story，對其進(jìn)行估算和排序，發(fā)布計劃會議的產(chǎn)出就是制定出這一期迭代要完成的 story 列表，sprint backlog
• 迭代計劃會議：項目團(tuán)隊對每一個 story 進(jìn)行任務(wù)分解，分解的標(biāo)準(zhǔn)是完成該 story 的所有任務(wù)，每個任務(wù)都有明確的負(fù)責(zé)人，并萬策劃那個工時的初估計
• 每日例會：每天 scrum master 召集站立會議，團(tuán)隊成員回答昨天做了什么，今天計劃做什么，有什么問題
• 演示會議：迭代結(jié)束之后，召開演示會議，相關(guān)人員都受邀參加，團(tuán)隊負(fù)責(zé)向大家展示本次迭代取得的成果。期間大家的反饋記錄下來，由 po 整理，形成新的 story
• 回顧會議：項目團(tuán)隊對本期迭代進(jìn)行總結(jié)，發(fā)現(xiàn)不足，制定改進(jìn)計劃，下一次迭代繼續(xù)改進(jìn)，以達(dá)到持續(xù)改進(jìn)的效果

敏捷中的測試

輕文檔和快速迭代

• 敏捷模型中強調(diào)輕文檔，所以測試人員不應(yīng)使用傳統(tǒng)的 Excel 填寫測試用例的方法，更多的是使用思維導(dǎo)圖、探索性測試（強調(diào)自由度，設(shè)計和執(zhí)行同時進(jìn)行，根據(jù)測試結(jié)果不斷調(diào)整測試計劃）、自動化測試等
• 敏捷講求合作，在敏捷項目組中，測試人員應(yīng)主動跟開發(fā)人員了解需求、討論設(shè)計、一起研究 bug 出現(xiàn)的原因

測試模型

V 模型

• V 模型中，明確的標(biāo)注了測試過程中存在的不同類型的測試
• 右邊的測試，都需要參考左邊對應(yīng)高度的要求

缺點：
僅僅把測試作為在編碼之后的一個階段，未在需求階段就介入測試。缺點和瀑布模型一樣

---

W 模型（雙 V 模型）

V 模型中未將測試前置的問題在 W 模型中得以解決

• 開發(fā) V 模型并不是單單指編碼階段，而是為產(chǎn)品開發(fā)流程而實施的各個階段
• 測試的對象不僅是程序，需求、設(shè)計等同樣需要測試，測試與開發(fā)時同步的

缺點：

• 去求、設(shè)計、編碼等活動被視為串行的
• 測試和開發(fā)活動也保持著一種線性的前后關(guān)系，上一階段完全結(jié)束，才可正式開始下一個階段工作
• 重流程，無法支持敏捷開發(fā)模式。對于當(dāng)前軟件開發(fā)復(fù)雜多變的情況，W 模型并不能解除測試管理面臨著困惑