02.26 Scrum的22個基礎知識點

以下的22個基礎知識點基本上涵蓋了Scrum所涉及的內容,如果您能夠正確理解所有知識點,那麼您已經具備了作為一名Scrum Master的基本素質;當然,作為一名合格的Scrum Master,更重要的是經驗,因為Scrum Master更多的需要和人打交道,很多實際問題的處理方式是必須在實踐中才能體會的,有些還很微妙。

也許您對這些知識點的理解不盡相同,這沒有關係,同樣的框架和方法由於應用的環境與對象的不同,所使用的方法和理解也不一定一樣,這也正是Scrum的特色之一,它幫助你找到最適合你的方式。Scrum並不是你需要嚴格執行的流程,而是幫助你找到適合自己的流程的框架。

Scrum的22個基礎知識點

01 實施Scrum框架的好處

降低變更對系統造成的風險。

  • 提高ROI(投入產出比)。
  • 幫助我們持續改進。
  • 持續快速的發佈可用的軟件產品。
  • 所有人對真實可用的軟件產品都有明確的認識,並在迭代過程中不停的改進。

在DevCloud中可以對創建的項目類型進行選擇,DevCloud提供了兩種模板的項目類型:Scrum模板和看板模板。

Scrum的22個基礎知識點

02 Scrum的組織結構

Scrum的組織結構可以根據不同的項目稍作調整,一般來說,它採用2-4周的迭代週期,幷包含以下角色:

  • Scrum Master
  • Product Owner
  • 開發團隊

03 Scrum Master的主要職責

  • 幫助團隊剷除一切阻礙,讓團隊可以順利完成衝刺目標。
  • 幫助團隊最大化生產力。
  • 使用技術手段幫助團隊變得更加高效,比如:引入自動化腳本,單元測試,持續集成等敏捷實踐。
  • 協助團隊和PO更好的進行協作。
  • 保證Scrum實踐的正確推行。

04 Scrum過程中都使用哪些工件?

Scrum所使用的工件很簡單,主要包括:

  • Sprint待辦列表 Sprint Backlog
  • 產品待辦列表 Product Backlog
  • 增量 Increment

05 什麼是產品待辦列表?

在團隊獲取可用的Sprint待辦列表sprint backlog之前,PO需要使用另外一個列表來管理新特性、變更請求、功能改進和缺陷等內容,並對他們進行優先級排序,這就是產品待辦列表(Product Backlog)。這些內容在得到了PO和團隊的認可後會交付給團隊進行開發,就變成了sprint backlog,這個過程可能很複雜(比如包含多層分解、涉及多個子產品/組件、多個團隊協作),也可能很簡單;轉換成sprint backlog的過程一般還包括了任務分解和工期估算的工作內容。

06 什麼是增量?

增量(Increment)指在一個衝刺內完成的產品待辦工作項的數量。

在每一個衝刺結束時,所有的增量必須處於完成狀態。這裡的完成必須是可以用的、可部署的,無論PO是否決定進行新的生產部署。

07 什麼是用戶故事?

在Scrum中,用戶故事是一個工具。通常用戶故事是一個短小的、一般用一句話可以說明的特性或者功能以及場景的描述。通過用戶故事,我們讓用戶可以自然的講述需求,並可以通過用戶故事討論和跟蹤需求。

08 什麼是故事點?

在Scrum中使用用戶故事(情景)作為描述一個產品特性的方式,同時使用“故事點”作為這個產品特性大小的定量估算單位,故事點的大小標識了一個產品特性的開發難度和所需要的投入(小時/人天等)。但我們一般不使用直接的小時或人天等時間單位來表示這個值,而是使用斐波納奇數列中的數值來標識不同特性的相對大小,這樣做的好處時我們可以屏蔽直接使用時間單位所造成的主觀差異,更快更準確的進行評估(因為在沒有進行實際開發之前是很難直接估算時間,但是不同特性的相對大小是比較容易評估的)。最終,我們可以使用數據分析手段在故事點單位和時間單位之間建立換算關係,幫助我們掌控項目進度。

09 什麼是Scrum撲克?

Scrum 撲克(計劃撲克)是一種進行量化估算的方法和工具。

在團隊進行規劃的過程中需要對工作量(故事點)、商業價值等進行量化評估,為了達到“評估結果是團隊的集體決策結果”的目的,Scrum中發明了這種方法和附帶的工具(一種撲克),在撲克上使用斐波納奇數列標識每張撲克,在進行規劃的時候每個成員按照自己理解出牌,並由數值最大和最小的兩名成員進行解釋,大家進行討論後得出最終的數值估計。

Scrum的22個基礎知識點

斐波納奇數列的特性決定了每個數字之間的差異會越來越大,這對於我們進行相對值評估非常有效。

Scrum的22個基礎知識點

10 什麼是Scrum衝刺?

Scrum項目採用一個接一個的“衝刺”完成開發工作。

衝刺是一個可重複的,標準化的工作循環單元,在這個單元中採用了Scrum的各種方法,並隨時準備進行評審和改進。

11 理想的衝刺週期是多長,這個週期對工作方式有怎樣的影響?

Scrum採用2-4周的衝刺週期。

一般來說,大多數團隊採用2周的週期,這主要是因為2周的衝刺讓團隊更加容易和接近現實的進行規劃並完成手頭的工作。同時,2周的長度也給予Product Owner足夠的時間來調整優先級,並給團隊和業務需求之間提供足夠的緩衝,讓他們可以專注於現有需求的開發。

12 Sprint計劃會議上一般需要做哪些工作?

在Sprint計劃會議上,一般需要完成以下工作:

  • 團隊針對當前衝刺需要完成的待辦工作項進行分析,並給出工期估算。
  • 將產品待辦工作分解為任務。
  • 如果經過估算,衝刺中仍然有剩餘工作量可用,則按照優先級從產品待辦工作中繼續拿取需求放入衝刺。
  • 對於需求描述中的不清晰內容與PO進行溝通、澄清。

13 衝刺回顧會議的作用

衝刺回顧會議(Sprint Retrospective)為團隊提供了總結和改進的方式,在每個衝刺結束後大家一起總結在這個衝刺中的改進和不足,並一同商討應對措施,進行持續改進。

14 Scrum中的衝刺和迭代有什麼區別?

迭代(Iteration)是一個通用詞彙,表達的是開發過程中的某個循環過程的單元。這個單元可以是開發人員編寫代碼時的編寫、編譯、調試、重構,也可以是一個開發週期的規劃、開發、測試、迴歸、發佈。也就是說,這個單元可大可小,都可以使用迭代來進行描述。

衝刺(Sprint)特指在Scrum中的某個產品開發週期,是一個2-4周的規劃、開發、測試、迴歸和發佈過程。

15 燃盡圖可以說明什麼問題?

燃盡圖一般用來跟蹤一個衝刺的進度狀態。

團隊把燃盡圖作為預測指標來使用,可以直觀得看到當前進度是快還是慢。

一般團隊需要在Daily Scrum的最後查看燃盡圖的最新狀態,並根據情況採取措施。

16 燃盡圖應該包含哪些元素?

燃盡圖應該包括工作日作為橫軸,工作量作為縱軸,理想曲線,真實工作進度曲線。

Scrum的22個基礎知識點

17 什麼是團隊速率?

團隊速率(Velocity)是一個團隊在一個衝刺內能夠完成的需求量。

需求量的單位一般使用工作量或者商業價值衡量。工作量使用“故事點”來代表,商業價值一般也作為產品待辦工作的評估指標之一。

速率標識一個團隊完成工作的速度,是評估團隊效率的重要指標。

Scrum的22個基礎知識點

18 什麼是Sashimi和Impediments?

Sashimi的原意是“生魚片”,在Scrum中是團隊用來表達“完成”的一種說法。不同團隊對於“完成”的定義可以是不一樣的,但在一個團隊內必須統一,在Scrum中一個團隊需要定義不同級別的“完成規範”來統一這個概念。“完成規範”可以是任務級別的,團隊級別的或者產品特定級別的。

Impediments的意思是“障礙”,是團隊在向著“完成規範”所定義的狀態努力過程中遇到的阻礙。一般來說,Scrum Master需要作為消除障礙的主要負責人。

19 什麼是 Daily Scrum?

Daily Scrum 是一個簡短的團隊會議,由團隊的所有成員在每天固定的時間和地點進行,會議上每個成員需要回答3個問題:

  • 你昨天做了什麼?
  • 今天計劃做什麼?
  • 是否遇到了障礙,需要其他人的幫助?

Daily Scrum 不是一個彙報會議,因為所有的參與者都必須抱著平等的心態參加,你所回答的3個問題是說給所有人聽的,所有人的3個問題也都是說給你聽的。Daily Scrum一般由Scrum Master進行協調和組織,但Scrum Master並不對成員所描述的業務特性/任務內容進行評價,而只關注會議本身是否高效。

Daily Scrum必須站立進行,所有有很多人稱之為Daliy stand-up,站立的目的是為了讓會議高效並讓每個人都集中精力,放下手頭的工作。

Scrum的22個基礎知識點

20 什麼是Scrum of Scrum?

一般在大型團隊中很常見,就是每天的Daily Scrum後,團隊負責人還會參加更多的會議進行團隊間的溝通和進一步的規劃。

21 Scrum的不足

  • 對於目標不夠清晰的項目,Scrum Master比較難以把控。
  • Daily Scrum在開始階段會讓團隊感受比較大的壓力,並佔用一定的工作時間。
  • 對於團隊成員的技術水平、協作水平有較高要求。
  • Scrum中對於變更的容忍度非常高,但這也會讓項目干係人感受比較大的不安。
  • 會暴露非常多的問題,如果組織對於變化的接受度不高,會有很大的組織性衝擊。
  • 會引發很多變革的發生,一定程度造成混亂的局面。

22 在什麼情況下Scrum並不適用?

Scrum模式並不適用於所有的團隊,特別當團隊規模很大(幾十上百上千)的時候,我們無法在整個團隊範圍內實施Scrum,而必須將團隊分割成5-10人的小團隊,並在團隊間進行Scrum of Scrum 的實施。

Scrum也不適合跨部門、跨職能的協作,如果團隊成員分散於不同的地理位置或者不同的部門,我們需要首先在組織結構上進行調整,至少需要合併開發和測試部門,組成按照特性或產品領導的團隊,同時從其他不同部門抽調人員組成團隊。

以上內容整理自網絡。


分享到:


相關文章: