總結敏捷開發之Scrum

敏捷開發的概念

敏捷開發是一種以人爲核心，迭代，按部就班的開發方法。

爲何說是以人爲核心？傳統的瀑布模型是以文檔驅動的，可是在敏捷中，只寫少許的文檔，注重的是人與人之間面對面的交流。

什麼是迭代？迭代就是把一個很長的開發週期，劃分紅一個個小的週期，在每一個週期的結束都會有可交付的產品，這個咱們就叫作迭代。

 

Scrum是敏捷的一種。（咱們公司用的就是Scrum）

Scrum中三大角色：

PO（Product Owner）：產品擁有者，主要負責給團隊提需求，肯定產品的功能，以及驗收產品。

Scrum Master：負責整個團隊內部的協調工做；保護團隊不受外界干擾，保證團隊正常運行。

Scrum Team：跨職能團隊，負責實現每一個迭代的需求。

 

Scrum流程：

1.PO按照優先級列出一個產品需求列表。

2.Scrum Master 與PO以及XXX開預計劃會，肯定哪些需求是要在接下來一個迭代進行的，哪些需求移到之後的迭代中。

3. Scrum Team開計劃會。（1）會上PO給你們講解每一個Stroy（Scrum中把功能劃分紅不少小功能，一個小功能就叫作一個story）要完成的功能，你們針對這些story有疑問的，能夠現場提問，直到沒有問題。（2）接下來你們給每一個story分別估點，開發估開發的點，測試估測試的點。（3）每一個成員各自領取本身的任務

4.迭代開始了。天天上午開站立會，會議控制在15分鐘之內，你們站在一塊兒，依次彙報昨天完成了什麼，而且計劃今天作什麼。同時遇到不能解決的問題也可在站立會上提出。彙報完後，走到黑板前把本身所take的story移到燃盡圖的相應狀態中。

5.迭代演示會議：每一個迭代結束的時候，成員須要將這個迭代內完成的story在其餘成員面前展現。

6.最後是回顧會，以輪流發言的方式進行，每一個人依次總結本次迭代中有哪些優缺點。會議主持人（咱們通常是PO）負責記錄這些優缺點。若是有須要改進的，具體實施到下個迭代中去解決改進。

 

敏捷測試與傳統測試的不一樣：

1.流程不一樣：

傳統測試中階段性很明顯，需求分析，設計評審，單元測試到集成測試，系統測試等，測試計劃，測試設計，測試執行，測試報告等。

而在敏捷測試中，更增強調產品的持續測試，質量的持續反饋，流程更簡化，階段性更模糊。

 

2.傳統測試會比較注重測試計劃的制定，可是在敏捷中強調測試的速度和適應性，側重計劃的不斷調整以適應需求的快速變化。

 

3.傳統測試中，開發和測試角色分的很清楚。

可是在敏捷中產品質量的把關不僅是測試的事，更像是整個項目組的事。好比咱們測試人員寫完測試用例，用例是須要三方（開發，測試，產品）共同評審確認的，這樣更能找出測試人員設計出來的用例的缺失和不足，以便找出產品更多的缺陷。

 

4.傳統測試鼓勵自動化測試，可是自動化測試的成功與否對測試沒有致命影響。

可是在敏捷測試中，因爲發佈版本太快，週期過短，必需要有自動化協助測試人員進行迴歸測試，不然敏捷沒法進行。也就是說敏捷測試的基礎就是自動化測試。

 

5.傳統測試強調發現的缺陷都要記錄下來，方便之後跟蹤缺陷，分析缺陷(分析缺陷產生的根本緣由，分析這些缺陷中哪些優先級較高需在這個版本上線以前修復，哪些能夠遺留到下一版本解決)，生成缺陷報告，而且很注重缺陷的處理和跟蹤流程。

但在敏捷中，更增強調的是面對面的溝通和交流，而且更注重的是產品自己，更不關注缺陷自己。

 

6.敏捷中不須要寫測試用例，直接是基於用例，基於對需求的理解來完成新功能的驗證。即便要寫測試用例，只要保證各個功能點被覆蓋便可，沒必要過於詳細。

 

7.傳統測試中得等開發把產品開發完畢，纔開始測試。但在敏捷中，一旦某塊新代碼完成，就開始測試，而不是等全部的代碼都開發完畢纔開始驗證。（這其實就至關於咱們把一個story劃分的特別細）