敏捷開發(fā)流程(自己總結)

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

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

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

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

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

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

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

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

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

10、。 下次會議前準備完成什么。 工作中遇到了哪些障礙。 匯報的對象是團隊，不是任何一位領導（PO,SM,團隊負責人）。匯報的重點在于提出問題，進而解決。每日站會不是進度匯報會議，這個會議是為將產品backlog條目轉化成為增量的人（團隊）召開的。團隊承諾實現(xiàn)Sprint目標和完成產品Backlog條目。每日站會是檢驗朝向Sprint目標的進程，如果有必要進行后續(xù)會議對Sprint中的下一步工作進行調整，目的在在于增加團隊實現(xiàn)目標的可能性。這是Scrum經驗過程中的重要檢驗和適應的會議。3、Sprint評審會議Sprint評審會議用來演示在這個Sprint中開發(fā)的產品功能給Product Owne

11、r.Produc Owner會組織這階段的會議并且邀請相關的干系人參加。 團隊展示Sprint中完成的功能 一般是通過現(xiàn)場演示的方式展現(xiàn)功能和架構 不要太正式 不需要PPT 一般控制在2個小時 團隊成員都要參加 可以邀請所有人參加4、Sprint回顧會議Sprint回顧會議上，全體成員討論有哪些好的做法可以啟動，哪些不好的做法不能再繼續(xù)下去了，哪些好的做法要繼續(xù)發(fā)揚。 團隊的定期自我檢視，發(fā)現(xiàn)什么是好的，什么是不好的。 一般控制在15-30分鐘 每個Sprint都要做 全體參加 Scrum Master 產品負責人 團隊 可能的客戶或其它干系人開發(fā)流程階段參與人事務輸出開發(fā)調研PO，SM，團隊

12、討論產品需求條目問卷調查分析故事列表工作量估算SM，團隊使用估算撲克估算故事點確定故事的依賴關系帶估算的故事列表發(fā)布計劃會議PO，SMPO確定當前發(fā)布的時間和應該包含的故事PO向各干系人公開發(fā)布規(guī)劃產品BacklogSprint計劃會議SM，團隊PO確定最近1-2個Sprint的最優(yōu)先級故事團隊從產品Backlog中的最高優(yōu)先級故事中挑選承諾完成的條目分解條目成為工作項評估工作項工時（小時為單位）Sprint BacklogSprintSM，團隊按Sprint Backlog產出軟件產品軟件產品必須是潛在可交付的（經過完整測試，可運行，有完整用戶文檔）潛在可交付的產品增量Sprint評審會議P

13、O，SM，團隊團隊向PO及相關干系人演示產品增量收集意見，為下一個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注意事項：DEEPDetailed appropriately(粗細適中)：指將當前優(yōu)先級高的功能模塊盡量細化，而相對優(yōu)先級較低的功能模塊，只需要知道大體功

14、能點既可。Estinnated(估算過的)：對每個功能點進行估算。Emergent(涌現(xiàn)的)：功能模塊隨著開發(fā)的推移是變化的，因此每次迭代完成都要重新調整。Prioritized(排好優(yōu)先級的)：將功能模塊根據商業(yè)價值進行排序。產品功能模塊的優(yōu)先級最好用（10，20，30計算），方便需求變更，附加功能插入。4 sprint planning-想要什么以及為什么？5 選擇部分product backlog（優(yōu)先級）作為當前sprint的sprint backlog，并創(chuàng)建sprint面板。6 sprint準備會，確定每個人做什么以及怎么做（最好是，自己選擇）？確定此次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 迭代完成后需