400-888-5228

Scrum中的角色

Scrum Master——項目負責人、項目經(jīng)理

保護團隊不受外界干擾,是團隊的領導和推進者,負責提升 Scrum 團隊的工作效率,控制 Scrum 中的“檢視和適應”周期過程。與 Product Owner 一起將投資產(chǎn)出_大化,他確保所有的利益相關者都可以理解敏捷和尊重敏捷的理念。

Team——開發(fā)人員、測試人員、美工設計、DBA等全職能性團隊

團隊負責交付產(chǎn)品并對其質(zhì)量負責,團隊與所有提出產(chǎn)品需求的人一起工作,包括客戶和_終用戶,并共同創(chuàng)建 Product Backlog 。團隊按照大家的共識來創(chuàng)建功能設計、測試 Backlog 條目交付產(chǎn)品。

Product Owner——產(chǎn)品負責人、產(chǎn)品經(jīng)理、運營人員

從業(yè)務角度驅(qū)動項目,傳播產(chǎn)品的明確愿景,并定義其主要特性。Product Owner 的主要職責是確保團隊只開發(fā)對于組織_重要的 Backlog 條目,在 Sprint 中幫助團隊完成自己的工作,不干擾團隊成員,并迅速提供團隊需要的所有信息。

User——_終用戶、運營人員、系統(tǒng)使用人員

很多人都可能成為_終用戶,比如市場部人員、真正的_終用戶、_好的領域?qū)<?,也可能是因其專業(yè)知識而被雇傭的資訊顧問。_終用戶會根據(jù)自己的業(yè)務知識定義產(chǎn)品,并告知團隊自己的期望,提出請求。

Manager——管理層、投資人

管理層要為 Scrum 團隊搭建良好的環(huán)境,以確保團隊能夠出色工作,必要的時候,他們也會與 Scrum Master 一起重新組織結構和指導原則。

Customer——客戶、系統(tǒng)使用人員、運營人員

客戶是為 Scrum 團隊提出產(chǎn)品需求的人,她會與組織簽訂合同,以開發(fā)產(chǎn)品。一般來說,這些人是組織中的高級管理人員,負責從外部軟件開發(fā)公司購買軟件開發(fā)能力。在為內(nèi)部產(chǎn)品的公司中,負責批準項目預算的人就是客戶。

Scrum中的產(chǎn)出物

Product Backlog——Backlog 待開發(fā)項,積壓的任務。

產(chǎn)品 Backlog 包括了所有需要交付的內(nèi)容,其內(nèi)容根據(jù)業(yè)務需求的價值順序排列,每個 Backlog 的優(yōu)先級是可以調(diào)整的,需求是可以增減的,因此產(chǎn)品 Backlog 將根據(jù)不斷增長來持續(xù)驅(qū)動維護。

Sprint Backlog——Sprint 本意為“沖刺”,指迭代周期,長度通常是一至六周。

在 Sprint 開始前,定義本次 Sprint 要討論的“Sprint Backlog”,從中產(chǎn)生本次 Sprint 要完成的 “已定 Product Backlog”。

已定 Product Backlog是 Sprint 計劃會議的產(chǎn)物,它定義了團隊所接受的工作量,在整個 Sprint 過程中它將保持不變。

User Story、Task——用戶故事、任務

用 User Story 來描述 Sprint Backlog 里的項目,User Story 是從用戶的角度對系統(tǒng)的某個功能模塊所作的簡短描述。一個 User Story 描述了項目中的一個小功能,以及這個功能完成之后將會產(chǎn)生什么效果,或者說能為客戶創(chuàng)造什么價值。一個 User Story 的大小和復雜度應該以能在一個 Sprint 中完成為宜。如果 User Story 太大,可能會導致對它的開發(fā)橫跨幾個 Sprint,此時就應該將這個 User Story 分解。為了能夠及時,高效地完成每個 Story,Scrum 團隊會把每個 Story 分解成若干個 Task。每個Task 的時間_好不要超過8小時,_在1個工作日內(nèi)完成,如果 Task 的時間超過了8個小時,就說明Task的劃分有問題,需要特別注意。

障礙 Backlog——問題列表,積壓的待處理事務。

列舉了所有團隊內(nèi)部和團隊相關的和阻礙項目的進度的問題,Scrum Master 需要確保所有的障礙 Backlog 中的問題都已分配并可以得到解決。

通用會議規(guī)則

基本要求

?每次會議都要準時開始、準時結束。

?每次會議都采取開放形式,所有人都可以參加。

會前準備

?提前邀請所有必須參會的人,讓他們有時間準備。

?發(fā)送帶有會議目標和意圖的會議綱要。

?預訂會議所需的全部資源:房間、投影儀、掛圖、主持設備,以及此會議需要的其他東西。

?會前24小時發(fā)送提醒。

?準備帶有會議規(guī)則的掛圖。

會議推進

?展開討論時,會議的推進人必須在場。他不能參與到具體討論中,但是他需要注意討論進程,如果討論參與者失去重點,他還要將討論帶回正規(guī)。

?推進人展示會議的目標和意圖。

?有必要時,推進人可以商定由某個撰寫會議記錄。

?推進人可以記錄團隊的意見,或是教授團隊如何自己記錄文檔;而且推進人可能會在掛圖上進行記錄,將對話可視化。

?推進人會對會議進行收尾,并進行非常簡短的回顧。

會議輸出

?使用手寫或掛圖說明來記錄文檔,給白板和掛圖上的內(nèi)容拍照。

?必須傳達會議記錄和大家對會議結果的明確共同認知。

讓團隊坐在一起!

?大家都懶的動,盡量讓“產(chǎn)品負責人”和“全功能團隊”都坐在一起!

?互相聽到:所有人都可以彼此交談,不必大聲喊,不必離開座位。

?互相看到:所有人都可以看到彼此,都能看到任務板——不用非得近到可以看清楚內(nèi)容,但至少可以看到個大概。

?隔離:如果你們整個團隊突然站起來,自發(fā)形成一個激烈的設計討論,團隊外的任何人都不會被打擾到,反之亦然。

團隊建設

?Scrum 團隊_佳人數(shù)控制在“5~9”人。

?全職能性團隊:開發(fā)組(后臺開發(fā)、前端開發(fā)、測試人員——3~8人)、Scrum Master(項目經(jīng)理)、產(chǎn)品負責人

?兼職團隊成員:美工、DBA、運維

每日立會(Daily Standup Meeting)——建議下班前開始

會議目的

?團隊在會議中作計劃,協(xié)調(diào)其每日活動,還可以報告和討論遇到的障礙。

?任務板能夠幫助團隊聚焦于每日活動之上,要在這個時候更新任務板和燃盡圖。

構成部分

?任務板、即時貼、馬克筆

?提示:ScrumMaster 不要站在團隊前面或是任務板旁邊,不要營造類似于師生教學的氣氛。

基本要求

?成員:團隊、Scrum Master

?無法出席的團隊成員要由同伴代表。

?持續(xù)時間/舉辦地點:每天15分鐘,同樣時間,同樣地點。

?提示:團隊成員在聆聽他人發(fā)言時,都應該想這個問題:“我該怎么幫他做得更快?”

會議輸出

?團隊彼此明確知道各自的工作,_新的工作進度圖。

?得到_新的“障礙 Backlog”

?得到_新的“Sprint Backlog”

會議過程

?團隊聚在故事板旁邊,可以圍成環(huán)形。

?從左邊_個開始,向團隊伙伴說明他到現(xiàn)在完成的工作。

?然后該成員將任務板上的任務放到正確的列中。

?如果可以的話,該成員可以選取新的任務,交將其放入“進行中工作”列。

?如果該成員遇到問題或障礙,就要將其報告給 Scrum Master。

?每個團隊成員重復步驟2到步驟5。

每個人三個問題:

?上次會議時的任務哪些已經(jīng)完成?:把任務從“正在處理”狀態(tài)轉為“已完成”狀態(tài)?!裉焱瓿闪耸裁矗?/p>

?下次會議之前,你計劃完成什么任務?:如果任務狀態(tài)為“待處理”,轉為“正在處理”狀態(tài)。如果任務不在 Sprint Backlog 上,則添加這個任務。如果任務不能在一天成,把這任務細分成多個任務。如果任務可以在一天內(nèi)完成,把任務狀態(tài)設為“正在處理”。如果任務狀態(tài)已經(jīng)是“正在 處理”,詢問是否存在阻礙任務完成得問題?!魈熳鍪裁??

?有什么問題阻礙了你的開發(fā)?:如果有阻礙你的開發(fā)進度的問題,把該障礙加入到障礙 Backlog中?!裉煊龅搅耸裁磫栴}?

注意事項

?不要遲到

?不要超出限制時間

?不要討論技術問題

?不要轉變會議話題

?不要在沒有準備的情況下參加

?Scrum Master 不要替團隊成員移動任務卡片,不要替團隊更新燃盡圖。

?Scrum Master 不要提出問題,團隊成員不要向 Scrum Master 或管理層人員報告。

?如果不能出席會議,需要通知團隊,并找一名代表參加。

任務板

?任務板集合了選擇好的 Product Backlog 和 Sprint Backlog,并以可視化方式展示。

?任務板只能由團隊維護,使用不同顏色的“即時貼”來區(qū)分開發(fā)人員,或者在“即時貼”寫上接受任務的姓名。

?盡量使用大白板,也可以使用軟件。

任務板有4列:

?選擇好的 Product Backlog:按照優(yōu)先級,將團隊在當前 Sprint 中要著手的 Product Backlog 條目或是故事放在該列中。

?待完成的任務:要完成一個故事,你得完成一些任務。在 Sprint 規(guī)劃會議中,或是在進行當前 Sprint 中,收集所有特定 Backlog 條目需要完成的新任務,并將它們放入該列。

?進行中的工作:當團隊成員開始某個任務后,他會將該任務對應的卡片放到“進行中的工作”列中。從上個每日 Scrum 例會開始,沒有完成的任務都會放在該列中,并在上面做標記(通常是個紅點)。如果某個任務在“待完成任務”列中所處時間超過一天,就盡量將該任務分為更小 的部分,然后把新任務放到那一列,移除其所屬大任務卡片。如果一個新任務因為某個障礙無法完成,就會得到一個紅點標記,Scrum Master 就會記下一個障礙。

?完成:當一個任務卡完成后,完成此任務的成員將其放入“完成”列,并開始選取下一張任務卡

燃盡圖

?跟蹤進度要由團隊來完成,燃盡圖的橫軸表示整個Sprint 的總時間,縱軸表示 Sprint 中所有的任務,其單位可以是小時,人天等。一般來說,燃盡圖有”Sprint燃盡圖和Release燃盡圖之分。

?團隊每天更新燃盡圖。

?如果燃盡圖一直是上升狀態(tài),或當 Sprint 進行一段時間之后,Sprint 燃盡圖上的Y值仍然與 Sprint 剛開始時相差無幾,就說明這個 Sprint 中的 Story 過多,要拿掉一些 Story 以_這個 Sprint 能順利完成。 如果Sprint 燃盡圖下降得很快,例如 Sprint 剛過半時Y值已經(jīng)接近0了,則說明這個 Sprint 分配的任務太少,還要多加一些任務進來。在 Sprint 計劃會議上,如果團隊對即將要做的任務理解和認識不充分,就很可能導致這兩種情況的出現(xiàn)。

?燃盡圖要便于團隊更新,沒必要讓它看起來很炫,也不要過于復雜,難以維護。

Release 燃盡圖:記錄整個Scurm項目的進度,它的橫軸表示這個項目的所有Sprint, 縱軸表示各個Sprint開始前,尚未完成的工作,它的單位可以是個(Story 的數(shù)量),人天等。

scrum 課程安排

常見問題

1、為什么任務要分給組而不是個人?答:因為怕出錯了牌又說不出所以然,這樣即使日后他不做這個功能,也對這個功能很了解。

2、為什么不讓_后領任務的人自己估算?

答:因為他很可能因為不知道某代碼可用、不知道某軟件不行....而選擇了錯誤的實現(xiàn)方法。

3、為什么不讓師傅估算大家采納,他不是_厲害嗎?

答:師傅的想法常常是徒弟們理解不了的,比如為什么不留在女兒國而偏偏去西天取經(jīng)之類的,共同估算就是讓大家在思考中對照自己的實現(xiàn)方法和師傅差異的過程。

Sprint評審會議(Review Meeting)

會議目的

?Scrum 團隊在會議中向_終用戶展示工作成果,團隊成員希望得到反饋,并以之創(chuàng)建或變更 Backlog 條目。

基本要求

?Sprint 復審會議允許所有的參與者嘗試由團隊展示的新功能。

構成部分

?有可能發(fā)布的產(chǎn)品增量,由團隊展示。

會議輸出

?來自_終用戶的反饋。

?障礙 Backlog 的輸入。

?團隊 Backlog 的輸入。

?來自團隊的反饋為 Product Backlog 產(chǎn)生輸入。

持續(xù)時間:90分鐘,在 Sprint 結束時進行。

會議過程

?Product Owner 歡迎大家來參加 Sprint 復審會議。

?Product Owner 提醒大家關于本次 Sprint 的目的:Sprint 目標、Scrum 團隊在本次 Sprint 中選定要開發(fā)的故事。

?產(chǎn)品開發(fā)團隊展示新功能,并讓_終用戶嘗試新功能。

?Scrum Master 推進會議進程。

?_終用戶的反饋將會由 Product Owner 和/或 Scrum Master 記錄在案。

注意事項

?不要展示不可能發(fā)布的產(chǎn)品增量。

?Scrum Master 不要負責展示結果。

?團隊不要針對 Product Owner 展示。

Sprint反思會議(Retrospective Meeting)

會議目的

?該會議的對應隱喻:醫(yī)療診斷!其目的不是為了找到治愈方案,而是要發(fā)現(xiàn)哪些方面需要改進。

構成部分

?參與人員:團隊成員、Scrum Master

基本要求

?從過去中學習,指導將來。

?改進團隊的生產(chǎn)力。

注意事項

?不要讓管理層人員參與會議。

?不要在團隊之外討論找到的東西。

會議輸出

?障礙 Backlog 的輸入。

?團隊 Backlog 的輸入。

持續(xù)時間:90分鐘,在 Sprint 評審會議結束后幾分鐘開始。

會議過程

?準備一個寫著“過去哪些做的不錯?”的掛圖。

?準備一個寫著“哪些應該改進?”的掛圖。

?繪制一條帶有開始和結束日期的時間線。

?給每個團隊成員發(fā)放一疊即時貼。

?開始回顧。

?做一個安全練習。

?收集事實:發(fā)放即時貼,用之構成一條時間線。每個團隊成員(包括 Scrum Master)在每張即時貼上寫上一個重要的事件。

?“過去哪些做的不錯?”:采取收集事實同樣的過程,不過這次要把即時貼放在準備好的掛圖上。

?做一個分隔,以區(qū)分“過去哪些做的不錯”和接下來要產(chǎn)出的東西。

?“哪些應該改進?”:像“過去哪些做的不錯”那樣進行。

?現(xiàn)在將即時貼分組:

?我們能做什么》團隊 Backlog 的輸入。

?哪些不在我們掌控之內(nèi)?》障礙 Backlog 的輸入。

?根據(jù)團隊成員的意見對兩個列表排序。

?將這兩個列表作為下個 Sprint 的 Sprint 規(guī)劃會議_部分和 Sprint 規(guī)劃會議第二部分的輸入,并決定到時候要如何處理這些發(fā)現(xiàn)的信息。

PMP在線題庫·免費刷·免費學
每日一練
每日一練 綜合練習 夯實基礎
高頻考點
重點難點 高效學習 背誦記憶
仿真模考
全真模擬 綜合模擬 鞏固知識
錯題本
查漏補缺 反復學 反復練

微信掃碼進入小程序

發(fā)表回復

您的電子郵箱地址不會被公開。 必填項已用*標注

  • 2024-09-26 20:00
    職場故事:從戰(zhàn)略規(guī)劃到項目管理交付
  • 2024-10-10 20:00
    解決方案評價:評估解決方案的高效績效工具
  • 2024-10-15 20:00
    研發(fā)績效管理:組織戰(zhàn)略如何解碼到績效指標?組織績效與個人績效管理
  • 2024-10-17 20:00
    科學的降本增效
  • 2024-10-22 20:00
    職場故事:“煉金術”與數(shù)字的交響曲:一位化學研發(fā)工程師的職業(yè)升級之旅
  • 2024-10-24 20:00
    助力財務運營自動化:機器人流程自動化(RPA)技術的實際應用
  • 2024-10-29 20:00
    職場故事:從在日工作的經(jīng)驗教訓談職場需要的技能
  • 2024-10-30 20:00
    嚴謹求實:安全評估和測試
  • 2024-10-31 20:00
    什么是數(shù)據(jù)標準?如何制定數(shù)據(jù)標準?這份指南送上
  • 更多直播講座
    小艾老師還在安排中…
查看全部 >

掃碼一鍵預約全部

查看更多 > 查看更多 >

數(shù)字化轉型8大核心認證

  1. PMP項目管理認證

    艾威最近一期班: 針對2025年03月考試
  2. CBAP業(yè)務分析認證

    艾威最近一期班·開課時間: 2024-11-23
  3. CBPP流程管理認證

    艾威最近一期班·開課時間: 2024-12-07
  4. ITIL4 IT管理認證

    艾威最近一期班·開課時間: 2024-10-26
  5. TOGAF企業(yè)架構認證

    艾威最近一期班·開課時間: 2024-11-02
  6. CDMP數(shù)據(jù)管理認證

    艾威最近一期班·開課時間: 2024-11-23
  7. CISA信息安全審計師認證

    艾威最近一期班·開課時間: 2024-12-01
  8. CISSP信息安全專家認證

    艾威最近一期班·開課時間: 2024-11-16
近期課程安排