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.持續關注技術上的精益求精和良好的設計以增強敏捷性。11.最好的

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

5、解決團隊開發中的障礙。做為團隊和外部的接口，屏蔽外界對團隊成員的干擾。保證開發過程按方案進展，組織Daily Scrum, Sprint Review and Sprint Planning meetings。3 Team負責產品的開發一般情況人數在5-9個左右團隊要跨職能包括開發人員、測試人員、用戶界面設計師等團隊成員需要全職。有些情況例外，比方數據庫管理員在工程向導X圍內有權利做任何事情已確保到達Sprint的目標。高度的自組織能力。向Product Owner演示產品功能。團隊成員構成在sprint內不允許變化。團隊整體向產品開發負責。敏捷工件1、Product Backlog有優先級的

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

7、int要完成的任務列表，并估算工時團隊成員自己挑選任務，而不是指派任務對每一個任務，每天要更新剩余的工作量估算每個團隊成員都可以修改Sprint backlog，增加、刪除或者修改任務沖刺訂單：沖刺訂單是大大細化了的文檔，用來界定工作或任務，定義團隊在 Story 中的任務清單，這些任務會將當前沖刺選定的產品訂單轉化為完整的產品功能增量。沖刺訂單在沖刺規劃會議中形成，其包含的不會被分派，而是由團隊成員簽名認領他們喜愛的任務。任務被分解為以小時為單位，沒有任務可以超過 16 個小時。如果一個任務超過 16 個小時，那么它就應該被進一步分解。每項任務信息將包括其負責人及其在沖刺中任一天時的剩余工作

8、量，且僅團隊有權改變其內容。3、發布燃盡圖直觀反響當前發布剩余的工作量，以Sprint周期數和故事點數為單位。燃盡圖Burndown Chart是一個公開展示的圖表，縱軸代表剩余工作量，橫軸代表時間，顯示當前沖刺中隨時間變化而變化的剩余工作量可以是未完成的任務數目，或在沖刺訂單上未完成的訂單項的數目。剩余工作量趨勢線與橫軸之間的交集表示在那個時間點最可能的工作完成量。我們可以借助它設想在增加或減少發布功能后工程的情況，我們可能縮短開發時間，或延長開發期限以獲得更多功能。它可以展示工程實際進度與方案之間的矛盾。4、Sprint燃盡圖Sprint燃盡圖直觀的反映了Sprint過程中，剩余的工作量情

9、況，Y軸表示剩余的工作，X軸表示Sprint的時間。隨著時間的消耗工作量逐漸減少，在開場的時候，由于估算上的誤差或者遺漏工作量有可能呈上升態勢。Sprint過程1、Sprint方案會議團隊從產品backlog中挑選他們承諾完成的條目。做什么創立Sprint Backlog 怎么做標識具體的任務并為任務做估算由團隊協作完成，而不是ScrumMaster考慮了高層設計2、Scrum每日站會團隊每天進展15分鐘的檢驗和適應的會議稱為Scrum每日站會。每日站會上，每個團隊成員需要匯報以下三個問題：從上次會議到現在完成了哪些工作。下次會議前準備完成什么。工作中遇到了哪些障礙。匯報的對象是團隊，不是任何

10、一位領導PO,SM,團隊負責人。匯報的重點在于提出問題，進而解決。每日站會不是進度匯報會議，這個會議是為將產品backlog條目轉化成為增量的人團隊召開的。團隊承諾實現Sprint目標和完成產品Backlog條目。每日站會是檢驗朝向Sprint目標的進程，如果有必要進展后續會議對Sprint中的下一步工作進展調整，目的在在于增加團隊實現目標的可能性。這是Scrum經歷過程中的重要檢驗和適應的會議。3、Sprint評審會議Sprint評審會議用來演示在這個Sprint中開發的產品功能給Product Owner.Produc Owner會組織這階段的會議并且邀請相關的干系人參加。團隊展示Spri

11、nt中完成的功能一般是通過現場演示的方式展現功能和架構不要太正式不需要PPT一般控制在2個小時團隊成員都要參加可以邀請所有人參加4、Sprint回憶會議Sprint回憶會議上，全體成員討論有哪些好的做法可以啟動，哪些不好的做法不能再繼續下去了，哪些好的做法要繼續發揚。團隊的定期自我檢視，發現什么是好的，什么是不好的。一般控制在15-30分鐘每個Sprint都要做全體參加 Scrum Master產品負責人團隊可能的客戶或其它干系人開發流程階段參與人事務輸出開發調研PO，SM，團隊討論產品需求條目問卷調查分析故事列表工作量估算SM，團隊使用估算撲克估算故事點確定故事的依賴關系帶估算的故事列表發布

12、方案會議PO，SMPO確定當前發布的時間和應該包含的故事PO向各干系人公開發布規劃產品BacklogSprint方案會議SM，團隊PO確定最近1-2個Sprint的最優先級故事團隊從產品Backlog中的最高優先級故事中挑選承諾完成的條目分解條目成為工作項評估工作項工時小時為單位Sprint BacklogSprintSM，團隊按Sprint Backlog產出軟件產品軟件產品必須是潛在可交付的經過完整測試，可運行，有完整用戶文檔潛在可交付的產品增量Sprint評審會議PO，SM，團隊團隊向PO及相關干系人演示產品增量收集意見，為下一個Sprint作準備Sprint回憶會議PO，SM，團隊對開

13、發流程進展回憶，檢查哪些方法是值得保存的，哪些是要廢棄的。更好的Scrum流程敏捷的開發流程1首先組建scrum團隊5-9人2 確定團隊成員職責scrummaster,po,team3需求設計分析，列出product backlog,格式如下:ID NAME IMP EST HOW TO DEMO NOTES考前須知：DEEPDetailed appropriately(粗細適中)：指將當前優先級高的功能模塊盡量細化，而相對優先級較低的功能模塊，只需要知道大體功能點既可。Estinnated(估算過的)：對每個功能點進展估算。Emergent(涌現的)：功能模塊隨著開發的推移是變化的，因此每次

14、迭代完XX要重新調整。Prioritized(排好優先級的)：將功能模塊根據商業價值進展排序。產品功能模塊的優先級最好用10，20，30計算，方便需求變更，附加功能插入。4 sprint planning-想要什么以及為什么.5 選擇局部product backlog優先級作為當前sprint的sprint backlog，并創立sprint面板。6 sprint準備會，確定每個人做什么以及怎么做最好是，自己選擇.確定此次sprint的“可交付物也就是完成這次迭代要到達的效果。并且確定當前sprint哪些功能是必須實現的must，哪些是應該做的，但假設沒時間就算了should，哪些是不太需要，但有更好could。7 sprint開發開場，創立sprint的任務版和sprint backlog的燃盡圖，并確保每日更新，每日晨會。Sprint任務版:Sprint backlog to do doing done燃盡圖：在迭代開發過程中，會發生需求的變更或者功能點的添加，但只要對本次迭代影響不是特別大，就不要對本次迭代發生變更。記錄迭代中的變更8 迭代完成后需要完成文