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

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

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

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

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

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

6、故事列表，并估算故事點產(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)品生命周期中，管理層不斷確定產(chǎn)品需求或對之做出改變，以保證產(chǎn)品適用性、實用性和競爭性。2、Sprint Backlog當前Spr

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

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

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

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

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

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

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

14、迭代完XX要重新調整。Prioritized(排好優(yōu)先級的)：將功能模塊根據(jù)商業(yè)價值進展排序。產(chǎn)品功能模塊的優(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 迭代完成后需要完成文