敏捷軟體開發之 Scrum

2022-10-11 09:03:14 字數 3257 閱讀 9516

scrum 是乙個用於開發和維護複雜產品的框架 ,是乙個增量的、迭代的開發過程。在這個框架中,整個開發過程由若干個短的迭代週期組成,乙個短的迭代週期稱為乙個sprint,每個sprint的建議長度是2到4周(網際網路產品研發可以使用1周的sprint)。在scrum中,使用產品backlog來管理產品的需求,產品backlog是乙個按照商業價值排序的需求列表,列表條目的體現形式通常為使用者故事。scrum團隊總是先開發對客戶具有較**值的需求。在sprint中,scrum團隊從產品backlog中挑選最高優先順序的需求進行開發。挑選的需求在sprint計畫會議上經過討論、分析和估算得到相應的任務列表,我們稱它為sprint backlog。在每個迭代結束時,scrum團隊將遞交潛在可交付的產品增量。 scrum起源於軟體開發專案,但它適用於任何複雜的或是創新性的專案。

scrum流程如下圖:

產品負責人(product owner)

scrum master

開發團隊

主要負責構建正確的產品,確定 scrum 團隊交付什麼並解釋為什麼做這些工作。產品負責人是產品方面的佼佼者。他們專注於了解業務、客戶和市場要求,然後相應地確定工程團隊需要完成的工作的優先順序。高效的產品負責人應能:

產品負責人並不一定是產品經理。產品負責人專注於確保開發團隊為企業帶來最大價值。此外,產品負責人是乙個個體,這一點非常重要。沒有開發團隊需要多個產品負責人所提供的的混合指導。

主要負責幫助產品負責人和開發團隊中的每個人理解和擁抱scrum的價值觀、原則和實踐。

scrum master 是其團隊中在 scrum 方面的佼佼者。他們負責對團隊、產品負責人和企業進行 scrum 流程方面的培訓,並尋找方法細調他們在此方面的實踐。

高效的scrum 主管應深入了解團隊正在執行的工作,並可協助團隊優化其透明度和交付流程。作為最主要的推動者,此角色負責安排衝刺規劃、每日短會、衝刺審核和衝刺回顧所需的資源(人力和物力)。

負責以正確的方式構建產品,執行具體工作任務。scrum團隊是具體工作的執行者,成員通常為 5 到 7 名。確定團隊規模的一種方法是亞馬遜首席執行官 jeff bezos提出的著名「兩個披薩原則」(團隊應該足夠小,以便分享兩個披薩)。

團隊成員具有不同的技能,並且彼此互相錘煉,因此沒有人會成為交付工作的瓶頸。強大的scrum 團隊遵循自我組織原則,且會在處理專案時採取明確的「我方」立場。團隊的所有成員會互相幫助,以確保成功完成衝刺。

scrum團隊可推進每個衝刺的計畫。他們將自己的歷史速度用作指導,**他們認為自己在迭代過程中可以完成的工作量。保持迭代長度固定可為開發團隊提供有關其預估和交付流程的重要反饋,進而使其能隨著時間的推移做出更加準確的**。

產品backlog(product backlog)

sprint backlog

產品增量(increment)

產品待辦事項集合,整個產品的使用者故事集合,這些使用者故事可以來自甲方客戶、終端使用者、po自己對產品的理解、研發團隊等。

本質上,這是團隊的「待辦事項」列表。產品負責人對產品待辦事項進行不斷反思、重新排定優先順序和維護,因為隨著我們了解的更多或隨著市場的變化,列表中的專案可能不再相關,或是可能會以其他方式解決問題。

衝刺待辦事項列表,乙個衝刺目標階段內的使用者故事列表。這些使用者故事來自product backlog,每次衝刺前,po根據交付價值,將優先順序最高的使用者故事放入迭代。

每次衝刺之前,在衝刺規劃會議(我們將在後文進行討論)中,團隊從產品待辦事項中選擇為進行衝刺而處理的專案。衝刺待辦事項可能較為靈活,可以在衝刺期間發展。但是,基本的衝刺目標(團隊希望通過在當前衝刺中實現的目標)不能受到影響。

增量是乙個 sprint 完成的所有產品待辦列表項的總和,以及之前所有 sprint 所產生的增量的價值總和。在 sprint 的最後,新的增量必須是「完成」的,這意味著它必須可用並且達到了 scrum 團隊「完成」的定義的標準。

在完成以上三個工件的時候,團隊可以選擇定義很多變體,因為工件維護最好保持開放態度。比如「已完成」、「故事點」重新定義能更好的提公升效率和品質,那你完全可以根據需求進行新的定義。

sprint(sprint本身是乙個事件,包括了如下4個事件)

sprint計畫會議(sprint planning meeting)

每日站會(daily scrum meeting)

sprint評審會議(sprint review meeting)

sprint回顧會議(sprint retrospective meeting)

由整個開發團隊在本次會議期間規劃當前衝刺期間要執行的工作(範圍)。本次會議由 scrum master主持,而團隊則在會議期間決定衝刺目標。接著,可將產品待辦事項中的特定用途故事新增到衝刺中。這些故事應與目標始終保持一致,且 scrum 團隊也承諾可在衝刺期間完成。 在規劃會議結束時,每位 scrum 成員均需清楚在衝刺期間可以交付的內容,以及如何交付增量變化。

這是每天在同一時間(通常是早晨)和地點舉行的超短例會,以確保此會議簡潔明瞭。很多團隊試圖在15 分鐘內完成會議,但這只是乙個參考。此會議也被稱為「每日短會」,它強調需快速舉行會議。每日 scrum 旨在讓團隊中的每乙個成員都保持同步,共同朝著衝刺目標努力,並制定未來 24 小時的計畫。 您可在每日短會上說出自己在實現衝刺目標或解決任何障礙時遇到的問題。 每日短會的其中一種常見舉行方法是讓每個團隊成員在實現衝刺目標的過程中回答三個問題: • 我昨天做了什麼? • 我今天打算做什麼? • 是否存在障礙? 然而,我們發現會議很快會變成大家陳述昨天和第二天的日程表。每日短會的理論基礎是:它可以分散日常會議的注意力,這樣團隊就可以在當天剩下的時間裡專注於工作。因此,如果它不幸淪為了每日日程表閱讀會,則應果斷做出改變以求創新。

在衝刺結束時,團隊聚集在一起進行非正式會議,以**增量演示或檢查增量。開發團隊向利益相關者和團隊成員展示目前處於「已完成」狀態的待辦事項,以徵求他們的反饋意見。儘管在多數情況下都會發布增量,但產品負責人仍可決定是否發布增量。

此次審核會議也是產品負責人根據當前衝刺重新處理產品待辦事項之時,當前衝刺可為下一次衝刺規劃會議提供相關資訊。對於為期乙個月的衝刺,可考慮將您的衝刺審核時間限制為最長四個小時。

是指團隊聚集在一起共同記錄和討論衝刺、專案、人員或關係、工具甚至在某些儀式中哪些有效以及哪些無效。我們的思路是創造乙個地方,讓團隊能夠專注於哪些工作進展順利和哪些地方有待改進,而不是專注於出了什麼問題。

承諾 – 願意對目標做出承諾

專注– 把你的心思和能力都用到你承諾的工作上去

開放– scrum 把專案中的一切開放給每個人看

尊重– 每個人都有他獨特的背景和經驗

勇氣– 有勇氣做出承諾,履行承諾,接受別人的尊重

敏捷軟體開發模型 SCRUM

一 什麼是scrum?scrum 英式橄欖球爭球隊 軟體開發模型是敏捷開發的一種,在最近的一兩年內逐漸流行起來。scrum的基本假設是 開 發軟體就像開發新產品,無法一開始就能定義軟體產品最終的規程,過程中需要研發 創意 嘗試錯誤,所以沒有一種固定的流程可以保證專案成功。scrum 將軟體開發團隊比...

敏捷軟體開發模型 SCRUM

標籤 分類 softwareengineering 一 什麼是scrum?scrum 英式橄欖球爭球隊 軟體開發模型是敏捷開發的一種,在最近的一兩年內逐漸流行起來。scrum的基本假設是 開發軟體就像開發新產品,無法一開始就能定義軟體產品最終的規程,過程中需要研發 創意 嘗試錯誤,所以沒有一種固定的...

敏捷軟體開發模型 SCRUM

一 什麼是scrum?scrum 英式橄欖球爭球隊 軟體開發模型是敏捷開發的一種,在最近的一兩年內逐漸流行起來。scrum的基本假設是 開發軟體就像開發新產品,無法一開始就能定義軟體產品最終的規程,過程中需要研發 創意 嘗試錯誤,所以沒有一種固定的流程可以保證專案成功。scrum 將軟體開發團隊比擬...