SCRUM-敏捷開發框架韓冬2023最新整理收集do

something前言對于“敏捷開發”我也是一個初學者，通過看一些資料，總結了一些相對實用的、有可能對我們日常開發管理有幫助的知識，分享給大家。與大家共勉。目錄入門與進階入門01回顧敏捷開發介紹敏捷開發的基本情況02什么是SCRUMScrum概述03SCRUM的角色在Scrum中都有哪幾類人。04SCRUM的三個工件Scrum重要的過程文檔。05SCRUM的4個活動Scrum的關鍵環節。06SCRUM的工作流程讓我們開始Scrum進階01怎樣編寫PRODUCTBACKLOG這不是一件簡單的事情02怎樣進行SprintPlan這是一個非常重要的事情。03怎樣進行每日立會站立的“立”04SPRINT演示與回顧終于快結束了。05額外的話。終于結束了。回顧敏捷開發打開“敏捷開發”這扇門。客戶的需求是不斷變化的，要能跟上變化，及時交付成果物。遵循計劃往往跟不上變化的節奏。隨時應對變化勝過遵循計劃大部分的需求來源是客戶，如果想通過一紙合同來要求或制約客戶（比如你這個功能不在合同里，我不能給你做），不如和客戶一起合作共同進行工作。客戶協作勝過合同談判客戶要的是精美的軟件，而不是要一批精美的文檔。個人理解敏捷開發并非拋棄所有文檔，而是不建議過度完善和冗余的文檔。可以工作的軟件勝過完備的文檔在日常工作中雖然有工作流程和管理工具輔助我們交流溝通，比如郵件、禪道。但從效率和效果上看遠沒有面對面溝通有效。人和交互勝過過程和工具什么是敏捷開發以用戶的需求變化為核心，采用迭代、循序漸進的方法進行軟件開發。敏捷宣言傳統項目管理：

1.事先對項目計劃進行評估、計劃、分析。

2.反對變更；變更需要重新估計、重新規劃。

3.嚴密的合同來減少風險，如果改變需要走CR（ChangeRequest）流程。

4.項目作為一個“黑盒子”，對客戶與供應商可視性差。

5.產品化和測試階段是分離的。

6.文檔和計劃驅動的方法。

7.軟件交付時間晚，意識到風險的時間晚。敏捷項目管理：

1.對整個項目做一個粗略的估計，每一次迭代都有詳細的計劃。

2.鼓勵變化，客戶價值驅動開發。

3.信任和賦予權力；合約使變更變得簡單和更有價值。

4.客戶和開發人員之間是緊密的連續的合作關系。

5.每次迭代都產生可交付的軟件。

6.專注于交付軟件。

7.第一次迭代就可交付能工作的版本，風險發現的早。敏捷PK傳統敏捷開的收益提高了生產率；減少“浪費”（不需要的文檔，重復工作等），項目的每次迭代都有明確的目標。提高客戶滿意度；短期內產生成效，按預期交付軟件，每次迭代結束產生可以運行的軟件。改善員工的滿意度；團隊精神，減少官僚，能夠規劃和管理自己的工作，減少“恐慌”，穩定的工作量（可持續的步伐）IT開發管理方法使用情況什么是SCRUM探索SCRUMScrum是一種工作管理的方法，不僅僅限于軟件開發，可以用來管理其他活動，不包含技術方法或實踐。依賴迭代和增量的敏捷方法。簡單，但高度的紀律性。Scrum是管理軟件項目中的一個輕量級的敏捷方法，名字來源于橄欖球運動中的scrum過程SCRUM概述SCRUM的角色在SCRUM中都有哪幾類人SCRUM的角色產品所有者Scrum大師Scrum團隊ProductOwnerScrumMasterScrumTeamProductOwner一般由客戶擔當，但根據情況也可以是項目經理擔當。具體的需求內容及優先級由客戶提供或需求部門提供，隨時解答團隊工作中產生的各項和產品、業務相關的問題。創建和維護ProductBacklog(產品需求清單），管理項目的范圍。決定產品有哪些功能。產品的目標。ScrumTeam敏捷是建立在信任和授權的基礎上，因此團隊是自發組織，組員選擇自己的任務，而不是別人強制加以分配。他們需要自我激勵和對工作的目標進行承諾。Scrum團隊中的角色是不分等級的；不應當出現“我是開發人員我不做測試”。Scrum團隊是職能交叉的，包涵產品交付的所有角色：開發人員、測試人員、設計人員。等Scrum團隊是Scrum的中心角色，產品交付要依靠團隊。Scrum團隊最佳規模6-10人ScrumMaster服務于Produce

Owner，服務于Scrum

Team主要職責：評價過程的健康情況，加強Scrum過程，消除障礙，促進過程改進。Scrum

Master通常由項目組的成員擔當，組長或者項目經理。Scrum

Master負責確保Scrum被理解并實施，為了達到這個目的，ScrumMaster要確保Scrum團隊遵循Scrum的理論、實踐和規則。ScrumMaster是Scrum團隊中的服務式領導。Scrum

Master應該是專注的、有決心的、有領導才能的。SCRUM的三個工件Scrum重要的過程文檔產品需求清單（product

Backlog)包括內容：產品需求清單(Product

Backlog)是Scrum的核心，也是一切的起源。從根本上說，他就是一個需求、故事、或特性等組成的列表，按照重要性的級別進行了排序。他里面包含的是客戶想要的東西，并用客戶的術語加以描述。產品負責人（Product

Owner)負責產品需求清單(Product

Backlog)列表的內容、可用性和優先級。功能方面的需求，功能點。非功能方面的需求，如性能改進等。需要修改的bug，上一版本已知的問題。新技術，如支持新的操作系統或平臺。問題，日后可能新增的項，新功能。產品需求清單是不斷完善的。在項目進行中隨時新增、修改、刪除功能，變更優先級。Product

Backlog示例序號優先級，重要程度需求描述(story)發布人Product

Backlog示例ID:序號Name：名稱Imp：重要程度Est：估算How

to

demo：如何演示Notes：說明，備注。迭代(沖刺）任務清單（SprintBacklog)能提取多少產品任務清單中的任務取決于Scrum團隊能承諾完成多少。SprintBacklog主要是從產品任務清單（ProductBacklog)中挑選出高優先級的任務，確定本次迭代的任務目標。承諾總是來自于內部，不能從外部加強。迭代不應當有空閑時間，因此規劃的迭代內容要保證工作量是穩定的）依賴的因素較多：團隊的能力，技術的成熟度，當前迭代增量的情況。產品所有者（ProductOwner)定義每個迭代的任務說明、目標。使迭代更具有針對性。Sprint

Backlog示例沖刺目標：SprintGoal任務執行人估算完成狀態任務受阻燃盡圖（Burn-DownChart)在Sprint開始的時候ScrumTeam會標示和估計在這個Sprint需要完成的詳細的任務。所有這個Sprint中需要完成，但沒有完成的任務的工作量是累積工作量，團隊會根據進展情況每天更新累積工作量，如果在Sprint結束時，累積工作量降低到0，Sprint就成功結束。SprintBurndownChart顯示了Sprint中積累剩余的工作量，他是一個反應工作量完成狀況的趨勢圖。Y軸代表的是剩余工作量，X軸代表的是Sprint的工作日。Burn-DownChart示例在沖刺開始時預先估算的時間剩余工作量匯總剩余工作量增加快速下降：進度快SCRUM的4個活動Scrum的關鍵環節沖刺計劃會議（SprintPlanMeeting）決定在Sprint中需要完成哪些工作。產品責任人(ProductOwner)向團隊介紹排好序的需求清單。并和開發團隊(ScrumTeam)確認在這一次的沖刺(Sprint）中能夠完成的需求列表。產品每個Sprint都以Sprint計劃會議作為開始，這是一個固定時長的會議，在這個會議中,Scrum團隊共同選擇和理解在即將到來的Sprint中要完成的工作。最終產生沖刺需求清單(SprintBacklog)每日Scrum會議（DailyScrum）立會最長15分鐘，在整個迭代過程中每天定時召開。ScrumMaster負責整個會議。其他人可以參與，但只允許Scrum

Master和Scrum

Team團隊成員講話。團隊成員之間交流信息。了解項目的真實進展情況。交流風險和存在的問題。面對面的會議加強了承諾。核心的3個問題：昨天（上次會議之后）你做了什么？今天（下次會議之前）你準備做什么？有沒有障礙？沖刺評審（SprintReview）ScrumMaster主持會議，Scrum團隊負責演示。會議其他參與者：

產品所有者(ProductOwner)必須參加、客戶、管理人員、以及其他感興趣的人，例如其他Scrum團隊。產品Sprint結束時,Scrum團隊和相關人員一起評審Sprint的產出。確保成果與預期的一致，收集反饋。為項目提供一個參考點，根據目前的位置計劃下一期的旅程。為下一次迭代提供輸入（改正、修改、新的想法），可以由產品所有者（ProductOwner)添加到產品需求清單。總體時間不超過4個小時。沖刺回顧（SprintRetrospective）ScrumMaster主持，持續半天，Scrum團隊參加(產品所有者ProductOwner)也可以參加。回顧的目的是評價本次迭代并醞釀改進，使得下一個迭代進行得更好。ScrumMaster總結本次迭代；迭代任務清單，重要的事情和決策。每個組員陳述迭代中哪些方法進行的好，哪些需要改進，哪些需要在下一個Sprint中改變。對預估生產率和實際生產率進行比較，如果差異較大的話我們會分析原因。對重要的問題計劃相應的措施：團隊自己解決，或者提交給公司的管理層。簡單流程：SCRUM的工作流程讓我們開始Scrum。Scrum整體框架可工作的軟件迭代開發沖刺需求清單SprintBacklog2-4周迭代ScrumMaster產品需求清單ProductBacklogProductOwner產品所有者ScrumTeamSprintPlanMeeting計劃會議DailyScrum每日立會SprintReview沖刺評審會SprintRetrospective沖刺回顧入門－小結讓我們也進行一次短暫的回顧。1.什么是敏捷開發。2.敏捷宣言。3.敏捷和傳統開發方式的對比。4.敏捷開發的收益。回顧敏捷開發什么是ScrumScrum重要組成流程框架入門－小結1.Scrum概述1.3個角色。2.3個工件。3.4個活動流程圖中場休息清理思路，再接再厲。進階01怎樣編寫PRODUCTBACKLOG這不是一件簡單的事情02怎樣進行SprintPlan這是一個非常重要的事情。03怎樣進行每日立會站立的“立”04SPRINT演示與回顧終于快結束了。05額外的話。終于結束了。怎樣編寫ProductBacklog這不是一件簡單的事情。需要了解的細節推薦的方法：比較好的方法是Product

Ownder\Scrum團隊、客戶／管理以及其他相關方（比如其他Scrum團隊）舉行一次或多次研討會。需求的來源：客戶，標書，需求規格說明書。Scrum團隊的想法，增強型新功能等。現有產品迭代增量，已知錯誤，技術問題等。ScrumMaster或者ProductOwner來促成會議，必須有人要來做。要有效率，要圍繞主題、溝通良好、避免不同的假設。承諾并且共通合作，確定優先級。通常規則為在PPT文檔下中英文各使用一種字體以保持全文檔統一。這里輸入文字，自由替換文字、圖片和圖標，這里輸入文字，自由替換文字、圖片和圖標，方便編輯易用大方。需求清單的重要元素ID:序號Name：名稱Imp：重要程度Est：估算How

to

demo：如何演示Notes：說明，備注。要點初始估算：換算單位是故事點(StoryPoint),大致相當于一個理想的人天。Imp:重要程度：產品負責人評出一個數值,指示這個故事（Story）有多重要。例如10或150。分數越高越重要。避免“優先級”這個說法,因為一般說來優先級1都表示“最高”優先級,如果后來有其他更重要的東西就麻煩了。它的優先級評級應該是什么呢?優先級0?優先級-1?

重要程度10和20的區別。只代表20比10重要。不是重要2倍。要有一些跨度。額外的字段：類別（后臺系統，優化），組件（服務端，客戶端，數據庫），請求者（客戶，其他項目干系人）怎樣進行SprintPlan這是一件重要的事情。如何決定放哪些story到Sprint中方法論產品負責人必須參加會議。產品負責人Sprint計劃會議非常關鍵。舉辦會議的成果：明確Sprint的目標，團隊成員名單以及投入程度。產出SprintBacklog,確定好評審（演示）日期。Sprint

Plan產品負責人必須要參加如果產新品負責人堅持不參加怎么辦？每一個需求（story)都有3個變量，范圍，重要程度，估算。其中范圍和重要程序需要產品負責人確定。1.嘗試讓產品負責人理解，為什么要參加的重要性。2.實驗在團隊中找一個人，可以充當產品負責人的代表。3.推遲會議日期。直到產品負責人找到時間參會為止。4.換人，嘗試說服管理團隊重新分配產品負責人。方法論如何決定將哪些Story放入Sprint中？1.本能反應法2.計算生產率法。Scrummaster:“伙計們,我們在這個sprint里面能完成故事A嗎?”(指向產品backlog中最重要的條目)Lisa:“呃。當然可以。我們有三個星期,這只是個微不足道的特性。Scrum

master:“OK,那加上B怎么樣?”(指向第二重要的條目)Tom和Lisa一起回答:“自然沒問題。”Scrum

master:“OK,那A、B、C一起呢?”Sam(對產品負責人說):“故事C要包括高級錯誤處理么?”產品負責人:“不,你現在可以跳過它,只需要完成基的錯誤處理。”Sam:“那C應該沒問題。”Scrum

master:“OK,那再加上D呢?”Lisa:“嗯......”Tom:“我覺得能完成。”Scrum

master:“有多少把握?90%?還是50%?”Lisa和Tom:“差不多90%”Scrum

master:“OK,D也加進來。那再加上E呢?”Sam:“也許吧。”Scrummaster:“90%?50%?”Sam:“差不多50%”Lisa:“我沒把握。”Scrum

master:“OK,那先把它放一邊去。我們要做完A、B、C和D。如果有時間的話當然還可以做完E,不過既然沒人指望它能做完,所以我們不會把它算到計劃里面來。現在怎么樣?”所有人:“OK!”

本能反應法確定如果sprint時間不長,小團隊根據直覺進行估算可以收到很好的效果計算生產率法舉個例子：假設在上個sprint里面,由Tom,Lisa和Sam組成的3人團隊在3個星期內工作了45個人-天,一共完成18個故事點。現在我們要為下一個sprint估算一下生產率。新伙計Dave的加入讓情況更復雜了。把假期和新成員算上,我們在下個sprint中一共有50個人-天。實際投入真是這樣嗎？上一次迭代投入程度＝18／45＝40%新迭代的估算生產率＝50*40%＝20

故事點：StoryPoint一般大致相當于一個“理想的人天(man-day)”什么是生產率？在一次迭代開發中能夠實際投入的開發量。可投入的開發資源（人－天）＊投入程度（focusfactor)＝估計速度如果沒有可參考的上一次迭代可設置一個默認投入程度：70%怎樣進行每日立會(DailyScrum)這是站立的“立”。工欲善其事。怎么布置團隊房間還是有一定作用的。燃盡圖不一樣的看板神奇的看板這是每天必做的一件重要的事情。DailyScrum神奇的看板找一面尚未使用或者充滿無用信息(如陳舊圖表或者丑陋的涂鴉)的大墻。清理墻壁(除非不得已才去請求別人許可)。在墻上貼上一張很大很大的紙(至少2x2平方米,大團隊需要3x2平方米)神奇的看板UnDo:未開始做的事情Doing:正在進行的工作完成的工作燃盡圖在一次Sprint結速前已經完成了所有的Backlog。可以從這里選取任務白色標簽在所有黃色標簽