1、敏捷開發的相關簡介敏捷定義Scrum是一個輕量級的軟件開發方法Scrum是一個敏捷開發框架，是一個增量的、迭代的開發過程。在這個框架中，整個開發周期包括若干個小的迭代周期，每個小的迭代周期稱為一個 Sprint，每個Sprint的建議長度2到4周。在Scrum中，使用產品Backlog來管理產品或項目的需求，產品 backlog 是一個按照商業價值排序的需求列表，列表條目的體現形式通常為用戶故事。 Scrum的開發團隊總是先開發的是對客戶具有較高價值的需求。在每個Sprint中，Scrum開發團隊從產品Backlog中挑選最有價值的需求進行開發。Sprint中挑選的需求經過Sprint計劃會議

2、上的分析、討論和估算得到一個 Sprint的任務列表，我們稱它為Sprint backlog 。在每個迭代結束時，Scrum團隊將交付潛在可交付的產品增量。敏捷的原則個體與交互勝過過程與丄具可以工作的軟件勝過面面俱到的文檔客戶協作勝過合同談判響應變化勝過遵循計劃這四句價值觀用語句表達就是：自組織團隊與客戶緊密協作，通過高度迭代式、增量式的軟件開發過程響應變 化，并在每次迭代結束時交付經過編碼與測試的有價值的軟件。勝過與客戶確定合同后在初期制定并遵循基于活動的完整計劃，在重型過程和工具 指導下，通過完成大量文檔進行知識傳遞，最后交付需求。敏捷宣言12條原則1. 最優先的目標是通過盡早地、持續地交

3、付有價值的軟件來滿足客戶。2. 歡迎需求變化，甚至在開發后期。敏捷過程控制、利用變化幫助客戶取得競爭 優勢。3. 頻繁交付可用的軟件，間隔從兩周到兩個月，偏愛更短的時間尺度。4. 在整個項目中業務人員和開發人員必須每天在一起工作。5. 以積極主動的員工為核心建立項目，給予他們所需的環境和支持，信任他們能 夠完成工作。6. 在開發團隊內外傳遞信息最有效率和效果的方法是面對面的交流。7. 可用的軟件是進展的主要度量指標。8. 敏捷過程提倡可持續發展。發起人、開發者和用戶應始終保持穩定的步調。9. 簡化一一使必要的工作最小化的藝術一一是關鍵。10. 持續關注技術上的精益求精和良好的設計以增強敏捷性。

4、11. 最好的架構、需求和設計產生于自我組織的團隊。12. 團隊定期地對運作如何更加有效進行反思， 并相應地調整、校正自己的行為。敏捷的角色1產品負責人產品負責人（Product Own er）的職責如下：?確定產品的功能。?決定發布的日期和發布內容。?為產品的ROI負責。?根據市場價值確定功能優先級。?每個Sprint ,根據需要調整功能和優先級（每個 Sprint開始前調整）。?接受或拒絕接受開發團隊的工作成果。2 ScrumMaster作為TeamLeader和Product owner緊密地工作在一起，他可以及時地為團隊成 員提供幫助。他必須：?保證團隊資源完全可被利用并且全部是高產出

5、的。?保證各個角色及職責的良好協作。?解決團隊開發中的障礙。?做為團隊和外部的接口，屏蔽外界對團隊成員的干擾。? 保證開發過程按計劃進行，組織 Daily Scrum , Sprint Review and Sprint Pla nning meet ings 。3 Team負責產品的開發? 一般情況人數在5-9個左右?團隊要跨職能（包括開發人員、測試人員、用戶界面設計師等）?團隊成員需要全職。（有些情況例外，比如數據庫管理員）?在項目向導范圍內有權利做任何事情已確保達到Sprint的目標。?高度的自組織能力。? 向Product Owner演示產品功能。?團隊成員構成在sprint內不允許變

6、化。?團隊整體向產品開發負責。敏捷工件1、Product Backlog有優先級的故事列表，并估算故事點產品訂單：產品訂單(Product Backlog )是整個項目的概要文檔，它包含 已劃分優先等級的、項目要開發的系統或產品的需求清單， 包括功能和非功能性 需求及其他假設和約束條件。產品負責人和團隊主要按業務和依賴性的重要程度 劃分優先等級，并作出預估。預估值的精確度取決于產品訂單中條目的優先級和 細致程度，入選下一個沖刺的最高優先等級條目的預估會非常精確。產品的需求清單是動態的，隨著產品及其使用環境的變化而變化， 并且只要產品存在，它就 隨之存在。而且，在整個產品生命周期中，管理層不斷確

7、定產品需求或對之做出 改變，以保證產品適用性、實用性和競爭性。2、Sprint Backlog當前Sprint要完成的任務列表，并估算工時?團隊成員自己挑選任務，而不是指派任務?對每一個任務，每天要更新剩余的工作量估算?每個團隊成員都可以修改 Spri nt backlog，增加、刪除或者修改任務沖刺訂單：沖刺訂單是大大細化了的文檔，用來界定工作或任務，定義團隊 在Story中的任務清單，這些任務會將當前沖刺選定的產品訂單轉化為完整的 產品功能增量。沖刺訂單在沖刺規劃會議中形成， 其包含的不會被分派，而是由 團隊成員簽名認領他們喜愛的任務。 任務被分解為以小時為單位，沒有任務可以 超過16個小

8、時。如果一個任務超過16個小時，那么它就應該被進一步分解。 每項任務信息將包括其負責人及其在沖刺中任一天時的剩余工作量，且僅團隊有權改變其內容。3、發布燃盡圖直觀反應當前發布剩余的工作量，以 Sprint周期數和故事點數為單 位。燃盡圖（Burndown Chart ）是一個公開展示的圖表，縱軸代表剩余工作量， 橫軸代表時間，顯示當前沖刺中隨時間變化而變化的剩余工作量（可以是未完成 的任務數目，或在沖刺訂單上未完成的訂單項的數目）。剩余工作量趨勢線與橫 軸之間的交集表示在那個時間點最可能的工作完成量。我們可以借助它設想在增 加或減少發布功能后項目的情況，我們可能縮短開發時間，或延長開發期限以獲

9、 得更多功能。它可以展示項目實際進度與計劃之間的矛盾。4、Sprint燃盡圖Sprint燃盡圖直觀的反映了 Sprint過程中，剩余的工作量情況，Y軸表 示剩余的工作，X軸表示Sprint的時間。隨著時間的消耗工作量逐漸減 少，在開始的時候，由于估算上的誤差或者遺漏工作量有可能呈上升態 勢。Sprint過程1、Sprint計劃會議?團隊從產品backlog中挑選他們承諾完成的條目。（做什么）?創建 Sprint Backlog（怎么做）? 標識具體的任務并為任務做估算?由團隊協作完成，而不是 ScrumMaster?考慮了高層設計2、Scrum每日站會團隊每天進行15分鐘的檢驗和適應的會議稱為

10、 Scrum每日站會。每日站會上, 每個團隊成員需要匯報以下三個問題：?從上次會議到現在完成了哪些工作。?下次會議前準備完成什么。?工作中遇到了哪些障礙。匯報的對象是團隊，不是任何一位領導（PO,S M團隊負責人）。匯報的重點在于提出問題，進而解決。每日站會不是進度匯報會議，這個會議是為將產品backlog條目轉化成為增量的 人（團隊）召開的。團隊承諾實現 Sprint目標和完成產品Backlog條目。每日 站會是檢驗朝向Sprint目標的進程，如果有必要進行后續會議對 Sprint中的下 一步工作進行調整，目的在在于增加團隊實現目標的可能性。 這是Scrum經驗過 程中的重要檢驗和適應的會議

11、。3、Sprint評審會議Sprint評審會議用來演示在這個Sprint中開發的產品功能給Product Own er.Produc Ow ner會組織這階段的會議并且邀請相關的干系人參加。?團隊展示Sprint中完成的功能? 一般是通過現場演示的方式展現功能和架構?不要太正式?不需要PPT?一般控制在2個小時?團隊成員都要參加?可以邀請所有人參加4、Sprint回顧會議Spri nt回顧會議上，全體成員討論有哪些好的做法可以啟動，哪些不好的做法 不能再繼續下去了，哪些好的做法要繼續發揚。?團隊的定期自我檢視，發現什么是好的，什么是不好的。? 一般控制在15-30分鐘?每個Sprint都要做?

12、全體參加? Scrum Master?產品負責人? 團隊?可能的客戶或其它干系人開發流程階段參與人事務輸出開發調研PO，SM，團隊討論產品需求條目冋卷調查分析故事列表工作量估算SM，團隊使用估算撲克估算故事點確定故事的依賴關系帶估算的故事列表發布計劃會議PO，SMPO確定當前發布的時間和應該包含的故事PO向各干系人公開發布規劃產品 BacklogSprint 計劃會議SM，團隊PO確定最近1-2個Sprint的最優先級故事團隊從產品Backlog中的最高優先級故事中挑選承諾完成的條目分解條目成為工作項評估工作項工時（小時為單位）SprintBacklogSprintSM，團隊按Sprint B

13、acklog 產出軟件產品軟件產品必須是潛在可交付的（經過完整測試，可運行，有完整用戶文檔）潛在可交付的產品增量Sprint 評審會議PO，SM，團隊團隊向PO及相關干系人演示產品增量收集意見，為下一個Sprint作準備Sprint 回PO，SM，對開發流程進行回顧，檢查哪些方法更好的Scrum顧會議團隊是值得保留的，哪些是要廢棄的。流程敏捷的開發流程1首先組建scrum團隊（5-9人）2 確定團隊成員職責（scrummaster,po,team ）3需求設計分析，列出product backlog,格式如下：ID NAME IMP EST HOW TO DEMO NOTES 注意事項：DEE

14、PDetailed appropriated 粗細適中）：指將當前優先級高的功能模塊 盡量細化，而相對優先級較低的功能模塊，只需要知道大體功能點既 可。Estinnated（估算過的）：對每個功能點進行估算。Emergent（涌現的）：功能模塊隨著開發的推移是變化的，因此每次迭 代完成都要重新調整。Prioritized（排好優先級的）：將功能模塊根據商業價值進行排序。產品功能模塊的優先級最好用（10，20，30計算），方便需求變更， 附加功能插入。4 spr int pla nnin g-想要什么以及為什么？5選擇部分product backlog（優先級）作為當前 sprint 的spri

15、nt backlog，并創建sprint 面板。6 spri nt準備會，確定每個人做什么以及怎么做（最好是，自己選擇）？確定此次sprint的“可交付物”（也就是完成這次迭代要達到 的效果）。并且確定當前sprint哪些功能是必須實現的（must），哪 些是應該做的，但若沒時間就算了（ should），哪些是不太需要，但 有更好（could）。7 sprint 開發開始，創建sprint的任務版和sprint backlog 的燃 盡圖，并確保每日更新，每日晨會。Sprint任務版:Sprint backlog to do doing done燃盡圖：在迭代開發過程中，會發生需求的變更或者功能點的添加， 但只要對 本次迭代影響不是特別大，就不要對本次迭代發生變更。 （記錄迭代 中的變更）8迭代完成后需要完成文檔工作: