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

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

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

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

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

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

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

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

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

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

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

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

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

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

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