敏捷開發方法綜述

什麼是敏捷開發？

敏捷開發以用戶的需求進化爲核心，採用迭代、按部就班的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分紅多個子項目，各個子項目的成果都通過 測試，具有可視、可集成和可運行使用的特徵。換言之，就是把一個大項目分爲多個相互聯繫，但也可獨立運行的小項目，並分別完成，在此過程當中軟件一直處於可 使用狀態。

它採用的是迭代式開發：迭代是指把一個複雜且開發週期很長的開發任務，分解爲不少小週期可完成的任務，這樣的一個週期就是一次迭代的過程；同時每一次迭代均可以生產或開發出一個能夠交付的軟件產品。

 

什麼是Scrum？

 Scrum是一種迭代式增量軟件開發過程，一般用於敏捷軟件開發。包括了一系列實踐和預約義角色的過程骨架。Scrum中的主要角色包括同項目經理相似的Scrum主管角色負責維護過程和任務，產品負責人表明利益全部者，開發團隊包括了全部開發人員。

 

Scrum敏捷開發的好處

   Scrum敏捷開發能夠顯著增長項目成功的可能。

   目前，淘寶，騰訊這樣的大公司早已實行了敏捷開發管理。在北京，上海的中小型公司裏Scrum敏捷開發也很流行，有很成功的項目經驗。

Scrum流程圖

 從這幅圖咱們不難發現，完成Scrum敏捷開發的流程爲：

第一步：Product Backing   找出完成產品須要作的事情。

第二步:Sprint Backlog   決定當前衝刺須要解決的事情。

第三步：Sprint   衝刺。

           衝刺期間要開每日立會(Scruming Meeting)，你們站着開會，你們一次報告：

              1.我昨天作了什麼。

              2.我今天要什麼。

              3.我碰到了哪些問題。

第四步：獲得軟件的一個增量版本，發佈給用戶。而後在此基礎上進一步計劃增量的新功能和改進。

Scrum開發的一些注意事項：

一、咱們首先須要肯定一個Product Backlog（按優先順序排列的一個產品需求列表），這個是由Product Owner 負責的；

二、Scrum Team根據Product Backlog列表，作工做量的預估和安排；

三、有了Product Backlog列表，咱們須要經過 Sprint Planning Meeting（Sprint計劃會議） 來從中挑選出一個Story做爲本次迭代完成的目標，這個目標的時間週期是1~4個星期，而後把這個Story進行細化，造成一個Sprint Backlog；

四、Sprint Backlog是由Scrum Team去完成的，每一個成員根據Sprint Backlog再細化成更小的任務（細到每一個任務的工做量在2天內能完成）；

五、在Scrum Team完成計劃會議上選出的Sprint Backlog過程當中，須要進行 Daily Scrum Meeting（每日站立會議），每次會議控制在15分鐘左右，每一個人都必須發言，而且要向全部成員當面彙報你昨天完成了什麼，而且向全部成員承諾你今天 要完成什麼，同時遇到不能解決的問題也能夠提出，每一個人回答完成後，要走到黑板前更新本身的 Sprint burn down（Sprint燃盡圖）；

六、作到每日集成，也就是天天都要有一個能夠成功編譯、而且能夠演示的版本；不少人可能尚未用過自動化的每日集成，其實TFS就有這個功能，它可 以支持每次有成員進行簽入操做的時候，在服務器上自動獲取最新版本，而後在服務器中編譯，若是經過則立刻再執行單元測試代碼，若是也所有經過，則將該版本 發佈，這時一次正式的簽入操做才保存到TFS中，中間有任何失敗，都會用郵件通知項目管理人員；

七、當一個Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，這時，咱們要進行 Srpint Review Meeting（演示會議），也稱爲評審會議，產品負責人和客戶都要參加（最好本公司老闆也參加），每個Scrum Team的成員都要向他們演示本身完成的軟件產品（這個會議很是重要，必定不能取消）；

八、最後就是 Sprint Retrospective Meeting（回顧會議），也稱爲總結會議，以輪流發言方式進行，每一個人都要發言，總結並討論改進的地方，放入下一輪Sprint的產品需求中；

 

 

運用Scrum開發流程中的一些場景圖：

上圖是一個 Product Backlog 的示例。

 

上圖就是每日的站立會議，參會人員能夠隨意姿式站立，任務看板要保證讓每一個人看到，

當每一個人發言完後，要走到任務版前更新本身的燃盡圖。

任務看版包含 未完成、正在作、已完成 的工做狀態，假設你今天把一個未完成的工做已經完成，那麼你要把小卡片從未完成區域貼到已完成區域。

 

每一個人的工做進度和完成狀況都是公開的，若是有一我的的工做任務在某一個位置放了好幾天，你們都能發現他的工做進度出現了什麼問題（成員人數最好是5~7個，這樣每人可使用一種專用顏色的標籤紙，一眼就能夠從任務版看出誰的工做進度快，誰的工做進度慢）

 

 

 上圖可不是撲克牌，它是計劃紙牌，它的做用是防止項目在開發過程當中，被某些人所領導。

怎麼用的呢？好比A程序員開發一個功能，須要5個小時，B程序員認爲只須要半小時，那他們各自取相應的牌，藏在手中，最後攤牌，若是時間差距很大，那麼A和B就能夠討論A爲何要5個小時...

 

 

下面列舉一個Scrum敏捷開發的具體案例：

• Sprint 計劃會議 1：原始需求者、產品負責人及團隊一塊兒，肯定任務優先級，定出 Sprint 目標和既定產品 Backlog。
• Sprint 計劃會議 2：團隊將既定產品 Backlog 中的每一項細化成多個任務。每一個任務完成的時間限定在一天內。
• Scrum 每日例會：項目團隊成員間的一個進度協調會議。會議天天都在同一時間同一地點舉行。時間限定在 15 分鐘內。
• Sprint 驗收會議：由原始需求者或產品負責人判定實際所發佈的功能是否與既定的 Sprint 目標一致。
• Sprint 回顧會議：項目團隊分析Sprint中的成功經驗和所遇到的障礙。

整個Sprint的週期（時間盒）肯定爲10天（兩週），具體的時間安排爲：

• Sprint會議（0.5天）
• 開發（8天）
• 驗收&總結（0.5天）
• 技術提高日（1天），自主學習技術

一、 需求收集

1.1  需求的分類

需求可與分爲業務團隊的，也能夠包括團度內部的，好比性能優化。

1.2  需求提交模板

需求種類	優先級	需求類型	需求標題	詳細描述	驗收條件	價值驗證	提交時間	需求人	備註

① 需求種類 可從如下四種狀況中選擇

• – 任務
• – 可用性問題（Bug）
• – 性能問題
• – 概念想法

注意：即便是概念性的想法，目前技術上沒法實現的想法均可以收集。

② 優先級 可從如下五種狀況中選擇

• – 特別的嚴重
• – 很是重要
• – 很重要
• – 普通
• – 低

注意：切忌將全部的任務的優先級都設置的很是的高，這裏不提供很是緊急這樣的表述。咱們只會根據重要程度去執行任務，因此緊急的任務須要業務部門及需求方儘早的提出。

③ 需求類型 能夠是兩種類型

• – 詳細需求
• – 毛坯需求

注意：咱們的需求並非要求必定要完整的，及時是一些很是毛坯的需求，也能夠提交過來，毛坯的需求由產品負責人進行分析和梳理，暫不清楚的可選擇擱置。

④ 需求標題 有本身進行書寫，可是須要遵照的規範是採用動賓短語格式。

好比：「導出+CN酒店天天的PV、UV等流量數據」

注意：這裏的需求內容必定是站長使用者角度是提出的，切勿出現專業的程序方面的表述：如添加一個導出的按鈕。還有須要注意的是動詞切忌使用大而寬泛的詞，好比「管理」，相似「管理關鍵詞」這樣的需求是嚴格避免的，這樣會使得要開發的內容變得沒有清晰的邊界。

⑤ 詳細描述 須要按照用戶故事的格式進行書寫。具體用戶故事格式的要求以下：

用戶故事是從用戶的角度來描述用戶渴望獲得的功能。須要注意的是用戶故事不可以使用技術語言來描述，要使用用戶能夠理解的業務語言來描述。一個好的用戶故事包括三個要素：

• 角色：誰要使用這個功能。
• 活動：須要完成什麼樣的功能。
• 商業價值：爲何須要這個功能，這個功能帶來什麼樣的價值。

用戶故事一般按照以下的格式來表達：做爲一個<角色>, 我想要<活動>, 以便於<商業價值>

好比：做爲一名酒店前端開發人員，我指望查看全部酒店頁面的頁面打開時間，以便了解哪些頁面須要進行技能優化。

一個好的用戶故事同時要符合INVEST原則，INVEST原則分別是：

• 獨立性（Independent）: 要儘量的讓一個用戶故事獨立於其餘的用戶故事。用戶故事之間的依賴使得制定計劃，肯定優先級，工做量估算都變得很困難。一般咱們能夠經過組合用戶故事和分解用戶故事來減小依賴性。
• 可協商性（Negotiable）: 一個用戶故事的內容要是能夠協商的，用戶故事不是合同。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細節。具體的細節在溝通階段產出。一個用戶故事帶有了太多的細節，實際上限制了和用戶的溝通。
• 有價值（Valuable）: 每一個故事必須對客戶具備價值。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個用戶故事並非一個契約並且能夠進行協商的時候，他們將很是樂意寫下故事。
• 能夠估算性（Estimable）:開發團隊須要去估計一個用戶故事以便肯定優先級，工做量，安排計劃。可是讓開發者難以估計故事的問題來自：對於領域知識的缺少（這種狀況下須要更多的溝通），或者故事太大了（這時須要把故事切分紅小些的）。
• 短小（Small）: 一個好的故事在工做量上要儘可能短小，最好不要超過8我的/天的工做量,至少要確保的是在一個迭代可以完成。用戶故事越大，在安排計劃，工做量估算等方面的風險就會越大。
• 可測試性（Testable）: 一個用戶故事要是能夠測試的，以便於確認它是能夠完成的。若是一個用戶故事不可以測試，那麼你就沒法知道它何時能夠完成。

注意：

• 角色的範圍不能過大，好比是做爲一名「用戶」，這樣是的不被接受的。
• 商業價值也不能大而寬泛，好比，能爲公司創造業績。若是要寫也必定要對業績作初步估算，好比，預期會給公司帶來每個月1萬張訂單。

⑥ 驗收條件 是開發完成後檢驗的標準，因此必定要認真填寫，不然可能開發出來的東西與預期不達標。

以上面的「導出+CN酒店天天的PV、UV等流量數據」爲例，它的驗收條件能夠爲：

• 1)   能夠爲每一個用戶設置是否擁有此導出權限
• 2)   導出的時間能夠細化的天。便可導出天天的流量。
• 3)   導出數據的最大時間跨度爲31天
• 4)   對於導出數據作好日誌記錄，後期可查是誰進行了導出。
• 5)   導出的字段包括：PV、UV、跳出率、新訪客佔比。

⑦   價值驗證 說明如何跟蹤上線後的效果

二、Sprint 計劃會議 1

目標：定出 Sprint 目標和既定產品 Backlog。

2.1 會議準備

□ 全部會議資源都已預訂

□ 會議室

□ 投影儀

□ 筆記本

□ 在會議前一天肯定議程，將目標和議程發送給全部與會者

□ 原始需求人（可選擇不來）

□ 產品負責人

□ Scrum Master

□ 開發團隊

□ 已按優先級排列產品 Backlog整理完畢

□ Sprint 時間表已經安排

□ Sprint 計劃會議 1 的時間安排

□ Sprint 計劃會議 2 的時間安排

□ Sprint 的第一天已肯定

□ Sprint 的最後一天已肯定

□ Scrum 每日例會的時間安排

□ Sprint 驗收會議的時間安排

□ Sprint 回顧會議的時間安排

2.2 會議議程

□ 把 Sprint 時間表公開給全部人

□ 產品負責人向團隊產品闡述需求（用戶故事）

□ 開發人員對用戶故事不清楚的點能夠及時提出。

□ 產品負責人或者原始需求者負責解答不清楚的故事點。

□ 若是討論現場發現有遺漏的需求，可由產品負責人添加至產品Backlog。

□ 若是對需求的優先級存在異議，可會上討論，肯定最終的執行順序。

□ 產品負責人& 需求方和小組成員相互承認這 Sprint 目標和既定產品 Backlog

2.3 會議結果

□ 爲 Sprint 計劃會議2的進行準備好既定產品 Backlog

2.4 補充內容

產品Backlog模板（基本同需求模板）

需求種類

優先級

需求類型

需求標題

詳細描述

驗收條件

提交時間

需求人

備註

跟進人

預計完成時間

實際完成時間

Sprint版本號

處理狀況

處理狀況可從如下幾種類型中選擇

• –    等待處理
• –    正在進行
• –    已經完成
• –    不予處理
• –    暫時擱置
• –    須要討論

三、Sprint 計劃會議 2

目標：肯定全部任務，生成 Sprint Backlog，確認 Sprint 目標

3.1 會議準備

□ 要求原始需求者離開會議，參會人員爲

□ 產品負責人

□ Scrum Master

□ 開發團隊

□ 在Sprint 計劃會議1後10分鐘舉行

□ Sprint 計劃會議1中整理的既定產品 Backlog

□  任務估時牌（按1,2,3,5,8,13估算）

3.2 會議進程

□ 團隊成員按順序分析既定產品 Backlog的討論實現細節

□ 編碼

□ 測試

□ 代碼審覈

□ 學習新技術

□ 編寫文檔

□ 部署

□ 上傳

□ 可看狀況肯定是否使用撲克估時

□ 任務超過一天時，須要拆成多個小任務

□ 若是團隊評估下來任務過多，可和產品負責人一塊兒刪減任務

□ 若是團隊評估下來任務過少，可和產品負責人一塊兒從產品Blaclog中引入新的需求。

3.3 會議結果

□ 將最終確認的可完成的需求清單郵件至

□ 原始需求人

□ 產品負責人

□ Scrum Master

□ 開發團隊

□ 將最終確認的任務列表郵件至

□ 產品負責人

□ Scrum Master

□ 開發團隊

3.4 補充內容

Sprint Backlog模板

優先級	需求標題	詳細描述	驗收條件	需求人	跟進人	處理人	任務描述	處理日期	估時	實際耗時

需求和任務是一對多的關係，及一個需求能夠產生多個任務，任務能夠是程序類描述，如「數據數據庫設計」

四、Scrum 每日例會

目標：團隊成員間工做進度的溝通和協調

4.1 會議準備

□ 邀請與會者

□ 外部團隊協助人員（若有有須要的話）

□ 原始需求人（只有選擇是否參加，過程當中不可發言）

□ 在 Sprint Backlog 上的全部任務都是能夠增刪修改，可重排序的

□ 一臺電腦，中間標識任務的狀態，可設爲「待處理」，「正在處理」，「已完成」的。

4.2 會議進程

注意：

• – 會議限定在15分鐘內
• – 團隊裏的每一個成員都必須回答如下三個問題，並考慮其相關的行動。

□ 上次會議時的任務哪些已經完成?

□把任務從「正在處理」狀態轉爲「已完成」狀態

□ 下一次會議以前，你計劃完成什麼任務？

□ 若是任務狀態爲「待處理」：轉爲「正在處理」狀態

□ 若是任務不在 Sprint Backlog 上：添加這個任務

□ 若是任務不能在一天內完成：把這任務細分紅多個任務

□ 若是任務能夠在一天內完成：把任務狀態設爲「正在處理」

□ 若是任務狀態已是「正在處理」：詢問是否存在阻礙任務完成得問題

□ 有什麼問題阻礙了你的開發

□ 若是有阻礙你開發進度的問題：把該障礙加入到障礙 Backlog 中，Scrum Master負責記錄

□ 若是展開了一個問題的討論

□ 提醒團隊的成員們注意把精力集中在回答關鍵問題上

□ 若是相關人員想發表些言論

□ 禮貌地提醒他，該會議只容許讓小組成員討論

4.3 會議結果

□ 獲得最新的障礙 Backlog

□ 獲得最新的 Sprint Backlog

□ 最新的工做進度圖（燃盡圖）

□ 第一次的例會建立一封郵件，由Scrum Master會議後將例會內容回覆此郵件。

4.4 障礙Backlog

障礙 Backlog 列舉了全部團隊內部和團隊相關的和阻礙項目進度的問題。Scrum Master 須要確保全部的障礙 Backlog 中的問題都已分配並能夠獲得解決。

10 大典型障礙

–    會議規則沒能被遵循

–    產品遠景和 Sprint 目標不清晰

–    沒有產品負責人負責回答提問

–    產品 Backlog 未能按商業價值區分優先級

–    並非全部負責交付產品的人員都是團隊裏的成員

–    Scrum Master 還要處理其餘任務，不能集中精力

–    團隊人數過多

–    團隊沒有能坐在一塊兒工做的空間

–    團隊的 Sprint Backlog 混亂

–    中間遇到了技術難題

五、Sprint 驗收會議

目標：根據團隊此次 Sprint 所發佈的版本，評審相關的 Backlog 中的問題，檢查是否已達到 Sprint 的目標。

5.1 會議準備

□ 全部會議資源都已預訂

□ 會議室

□ 投影儀

□ 筆記本

□ 在會議前一天肯定議程，將目標和議程發送給全部與會者

□ 原始需求人（可選擇不來）

□ 產品負責人

□ Scrum Master

□ 開發團隊

□ 對於每一個人來講 Sprint 目標都是公開的

□ 對每一個人來講既定產品 Backlog 是公開的，可獲取的

5.2 會議進程

□ 團隊按 Backlog 中的問題，逐個地介紹此次 Sprint 的結果，和演示新功能。

□ 若是產品負責人或需求方想要改變功能：添加一個新問題到產品 Backlog 中

□ 若是對功能有一個新的想法：添加一個新問題到產品 Backlog 中

□ 若是小組報告項目遇到阻礙如今還沒能解決：把該障礙加入到障礙 Backlog

5.3 會議結果

□ 對此次 Sprint 的結果和整個產品的開發狀態的共識

六、Sprint 回顧會議

目標：經過總結以往的實踐經驗來提升團隊生產力。

注意：主要指導原則：無論咱們如今發現了什麼問題，咱們必須懂得並堅信每一個人經過他們當時所知的，他所擁有的技能和可獲得的資源，在限定的環境下，都盡其所能作出了最好的成績。

6.1 會議準備

□ 邀請與會者：

□ Scrum Master

□ 團隊全部成員

□ 產品負責人（可選）

□ 附屬工具

□ 便籤紙

□ 白板

□ 在白板上寫上主要指導原則

□ 在白板上畫上一個至少三頁紙連在一塊兒長的時間軸

□ 在白板上寫上「咱們的成功經驗是什麼」

□ 在白板上寫上「有什麼可以改進」

□ 在白板上寫上「誰負責」，而後分紅兩個區域——「團隊」和「公司」

附屬工具：

6.2 會議進程

□ 介紹會議目標

□ 介紹會議主要指導原則

□ 在時間軸上，標記出 Sprint 的開始和結束時間

□ 向與會者解說如何使用該便籤紙進行工做

□ 派發便籤，而且讓每人寫上他們認爲此次 Sprint 中最爲重要的事，限時 5 分鐘

□ 每一個與會者輪流把他的貼紙貼到白板的時間軸上，並用兩句話來解說這事有什麼特別的地方

□ 分發便籤紙，並讓每人寫上「咱們的成功經驗是什麼」，限時5分鐘

□ 每一個與會者輪流把他的貼紙貼到白板「咱們的成功經驗是什麼」的區域上，並解說。

□ 分發便籤紙，並讓每人寫上「有什麼可以改進的」，限時5分鐘

□ 每一個與會者輪流把他的貼紙貼到白板「有什麼可以改進的」的區域上，並解說。

□ 對於掛紙板上「有什麼可以改進」的區域中的每一項

□ 詢問團隊「誰去負責解決這個問題？」

□ 把便籤紙移到掛紙板中「誰負責」的區域中

□ 和團隊一塊兒把這些區域按優先次序排好

□ 給會議作個總結

□每一個與會者對 Sprint 回顧會議做簡短的回饋

6.3 會議結果

□ 白板上「誰負責」這欄對於公司內全部人是公開的

□ 把與公司範圍相關的障礙增長到障礙 Backlog 中去

□ 把與團隊範圍相關的障礙增長到障礙 Backlog 中去

□ 整理全部會議結果，郵件至團隊中全部人

 

 

 

註明：

案例分析參考博客：      http://www.biaodianfu.com/scrum-flow.html

Scrum一些場景圖參考：http://blog.csdn.net/bihailan123/article/details/50708863

文章寫的很簡明，謝謝以上兩位博主！