深入淺出「敏捷軟體開發:Scrum」(中)

因字數過多,文章拆成上中下三篇

(上)篇包含:一、前言;二、Scrum名詞(Scrum角色、Scrum物件)

(中)篇包含:二、Scrum名詞(Scrum活動)

(下)篇包含:三、Scrum流程;四、總結;五、其他補充與建議

(三)Scrum中的活動

  1. Product Backlog Refinement
  2. Sprint Planning
  3. Sprint
  4. Daily Scrum
  5. Sprint Review
  6. Sprint Retrospective

(三) Scrum 中的活動

  1. Product Backlog Refinement:PO 與 開發團隊討論近期開始施工的 Item

就筆者的經驗來說,這個活動非常重要,尤其在一開始的時候。

有開發過的讀者應該清楚,當開始開發軟體系統的時候,正常步驟會先規劃軟體架構,接著才進行功能開發,例如就像蓋房子一樣,先畫設計圖,才慢慢從底層往上蓋起。如果沒有這個步驟,會讓軟體開發過程持續地進行打掉重來的步驟,反而浪費了時間,而在中間的過程當中,如果 Item 有所變更,也必須透過這個會議跟開發團隊更新,以便動態的因應需求變化。

所以這個活動通常會在兩個時間點出現:

(1) 軟體開發前(一次):講解所有未來可能發生的功能還有使用者故事,讓開發團隊可以先規劃初步架構,才不至於在未來開發規劃遇到困難。

-> 參與者:PO, Scrum Master, 全員

-> 時間:10% Sprint (假設是2週1 Sprint, 代表需要可能將近1天的時間要花在待辦事項的梳理上)

(2) Sprint 期間(每週):每週固定一次與開發團隊講解接下來可能做的 Item,讓他們提前知道彼此相依關係,尤其一定要講解更動後的 Item 。

-> 參與人員:PO, Scrum Master, 開發團隊

-> 活動時間:10% Sprint (假設是2週1 Sprint, 代表需要可能將近1天的時間要花在待辦事項的梳理上)

通常這個會議是間接的支持下一個或下下一個 Sprint,讓團隊在 Sprint Planning 時候有著更良好的節奏,跟開發團隊通常會有很多的討論(包含具體功能怎麼實現、架構應該怎麼規劃),會有幾件事情會發生

a. 敘述 Item 更新的需求內容(PO)

b. 將複雜以及大的 Item 切分成更細的待辦事項

c. 評估新的 Item

d. 重新評估已有 Item (當有新進度或有更多資訊去定義 Item 細節的時候)

上面參考自 Scrum Primer(點擊即可)

2. Sprint Planning:每次 Sprint 之前的會議,開發團隊與 PO 決定 Sprint 要開發哪些 Item。

Source: https://www.youtube.com/watch?v=2A9rkiIcnVI

敏捷開發沒有提到在 Sprint Planning 實際上到底要怎麼決定要開發的 Item ,也沒有明確提及要做甚麼事情,依照筆者自身的經驗,這個會議當中可以分成2個部分,Part 1為 Item講解,Part 2為 Item 的評分一系列的處理(會有4個事情需要決定)

Part 1 — 講解 Item:由 PO 講解接下來可能會排入的 Item,團隊成員對有問題的地方進行發問,如此 PO 所寫的 Item 和團隊成員對於目標的理解才會一致,才不會出現最後開發完成的功能非客戶所需的情形。

->會人員:PO, Scrum Master, 開發團隊

->活動時間:1 hour/week (如果2週1 Sprint,需約2小時)

由於 Product Backlog Refinement 就會固定更新 Item 內容,所以基本上 Part 1 會議可以在2小時內結束。

Part 2 — 分派Item:透過下面4個步驟將 Item 一步步的拆解成 Task 並進行分配。

->與會人員: Scrum Master, 開發團隊 ,PO(可以不在場,但必須可以被聯繫到,因為在拆解 Task時候可能會有細節必須詢問)

->活動時間:1 hour/week (如果2週1 Sprint,需約2小時)

(1) Product Backlog Item 評分

這一階段要讓開發團隊針對 Item 進行「困難程度評分」,透過這個評分便可以估算在 Sprint 內能完成多少個 Item,也會直接影響到開發時程。

那麼問題來了,要怎麼決定這個分數?另外怎麼決定一個 Sprint 可以塞進去總共幾個分數,才不會讓 Sprint 完成項目太少,或者項目完成太快沒有 Item繼續做?

這邊先回答第一個問題,第二個問題將在下一段解釋。

評分的時候由每個開發團隊成員一起評分,採用費式數列 1 、2、3、5、8、13、21、34…( F0 = 0, F1 = 1,Fn = Fn-1 + Fn-2),從 1 開始評分,由 PO 講解完 Item 內的項目之後,數到3,團隊成員一起舉起個數字,接著取一個最大眾的數字即可。

不過這裡又有實際運行會發生的幾個問題:

a. 分數的依據?

通常由開發團隊自行估算預計的時間,例如總共有8位成員,Sprint = 10天,1天=8小時,所以總共有640小時的開發時間,假設 Sprint 總分不得超過 80 分,代表 1分為8小時(當團隊成員運行幾次之後,便能大概評估分數與時間的對應關係)

b. 分數的認定不同?

資深工程師跟一般工程師評估的分數總會不一樣,職能不同的工程師評估的標準又會不一,但是這並沒有關係,只要記得原則「自己主觀評分」即可,原因在於敏捷開發使用費式數列,當該 Item 超過3分時候,就不是一般的正常數列,目的就是為了讓估算分數「擴大」,將未知的風險考慮進去。

一般在預估 Item 時候,功能越小的越容易估算清楚,當功能越大的時候常常會遇到意想不到的 Bug 或者超出自己過去實作以外的技術,這時候花費的時間往往會大於自己的想像,所以費式數列正是彌補了這一點,無意間中將這些「風險處理時間」估算進去。

另一方面,如果該 Item 主要的工作內容偏向某個職能,例如很明顯就是屬於數據工程師的工作,那由該職能工程師們評分即可。

要注意的是,常常 Junior 工程師到最後會跟著資深工程師的風向走,要記得貫徹數到3再一起亮牌,這樣才會讓 Sprint 的 Item 不因少數人而決定(畢竟不是所有的 Item 都是那幾位資深工程師下去開發,每個人的開發速度不一)

(2) 決定 Sprint 的 Item

在決定到底要將哪個 Item 放入 Sprint 時候,記得要遵守2個原則

a. 依照 PO 的優先順序選擇 Item

b. Item 不要超過估算的分數:舉例來說,給8人開發團隊的分數基準為Sprint 2周最多只能承擔 80 分,依照費式數列 1,2,3,5,8,13,21,34,55… ,最後分配的 Item 加總必須要小於 80 分

Source: https://ppt.cc/fOUgOx

另外補充一下,基本上在規劃 Item 的時候,PO 可以盡量徵求開發團隊資深人員意見(在 Sprint Meeting or Product Backlog Refinement ),了解該 Item 可能分數的落點,最好是將 Item 的分數落在最短需要一天內跟最多需要三天完成的分數,以上面所舉的8人團隊來說,一個Item盡量至少8分,最高不大於24分

所以當評估的 Item 小於8分怎麼辦?大於24分怎麼辦?

首先小於8分的 Item 可以先看看是否為新功能或者為待修的 Bug,通常後者筆者會盡量把同一個 Item 的 Bug 集結在一起請開發團隊評估,前者的話看看有沒有類似功能或者同一頁面是能夠合併描述的,如果沒有的話也沒關係,就依照開發團隊的評估分數納入 Sprint Backlog。

如大於 24 分,PO 需將其再分割成複數以上的 Item,盡所能把 Item 控制在 8–24分左右 (也就是集結開發團隊之力1天-3天能完成)。而限制不超過24分的原因在於,如此 Sprint 結束後完成的 Item 數量,如果相當順利的話,最多能完成4個(24*3+8*1),但因為費式數列緣故,所以 21分會往下跳到 34分,這樣的 Item 有太多開發風險難以掌控,致使 Scrum 窒礙難行。

(3) 拆解 Item 成 Task

在理論上拆解 Task 是依照開發團隊共同討論出來,以該職能工程師為主導角色,將細項要做的事情寫出來,接著估算需要的工時,並分配 Task 給不同的工程師。

另外,基於所有 Item ,工程師必須要按照未來會開發的功能勾勒出架構,遵守架構的細節拆分 Task ,此時,資深工程師會起到很大的作用,比較能知道 Task 內容該如何撰寫以及做甚麼事情,之後再分派不同的Owner。

在拆解 Task 和評估時數時,建議2個原則

a. 拆解 Task 基準以2–5小時可完成的範疇為主

b. 評估時數可以費式數列的 2,3,5 即可

如果評估時數有1小時的範圍,依照筆者過去經驗,大部分工作開發團隊會拆到太細,反而會讓撰寫時間拉長,而且完成的成就感比較低。

如果大於5個小時,通常 Task 會超過一天才完成,會讓開發團隊沒有「每天有進度」的感覺,所以假設該Task是大於5個小時,必須考量再拆解更小的Task分工。

(4) 指派 owner

指派 owner 時候,必須要注意兩件事情

a. 該 Owner 的時數是否已滿:根據 Sprint 的時間估算每個人最大可乘載的 Tasks ,所以分派 Tasks 必須要注意每個人目前的乘載量如何,舉例來說,假設 Sprint 2週,每個人一天工作 8 小時,兩週最大的乘載量就是 80 小時。(另外筆者 Sprint 團隊偶爾會被抓去做其他事情,所以會額外去事先詢問開發團隊每個人預先可以開發的時間,以免給了超過負載的任務。還有通常一天開發團隊個人的開發時間不會到8小時,因為休息、溝通、開會等等事情會佔據)

b. 該 Owner 是否充分了解或熟悉該 Task:在分配任務之後,可以請該 Owner 詳細解釋一次大概會怎麼去做,讓開發團隊的人知道彼此的工作內容,如此會降低溝通成本。

3. Sprint:按照分配的 Task 開始進行開發

Souce: https://www.visual-paradigm.com/scrum/why-fixed-length-of-sprints-in-scrum/

-> 參與人員:PO, Scrum Master, 開發團隊

-> 活動時間:1–4個禮拜,但筆者認為實務上以2個禮拜為主

如果是1周的話,光是 Sprint 的活動,每個開發人員的 Sprint 開發承載量應該會只有24–32小時左右,所以不建議1周Sprint。

筆者試過2周和3周,以3周來說,迭代的速度其實會有點緩慢,如果處在需求變動比較大的產品時候,往往就失去了所謂的彈性,另一方面,開發團隊在第一周時候往往會想「還有下下周才 Review」,在開發上的心態往往就會趨於較消極的狀況,而且每次 Sprint Review 會讓團隊成員覺得達到一個「小目標」,看到產品有功能展示,自然成就感也會高漲起來,但拉到3周會使的這樣的循環拉得有點長。

2周的話迭代速度剛好,可以快速的因應變動的需求、短一點的循環讓開發團隊會更有成就感(承接上一段小目標的敘述),而且 Sprint 時間短,代表 Item 也要拆的細一點,也會使開發的風險和理解不一致的情形降到最低。

另外 Sprint 期間有幾點必須要提醒:

(1) 不能更動(包含增加、更新、刪除) Sprint 目前正在開發的事項,一切都等 Sprint 結束後再進行下一次的調整,否則會讓開發團隊要再重新與 PO 溝通,減少開發時間。

通常最常會發生在PO, 老闆或者客戶會直接去找 Sprint 開發團隊要求直接更動某項內容,此時候就是 Scrum Master 該出面阻止的時候,一切都等到 Sprint Review 活動時後再提出意見,並在 Item 上直接進行修改。

(2) Sprint 時間固定,不隨意更動

如同上面在估算時間還有分數時候所說,開發團隊會在每一次的 Sprint 當中可以理解怎麼樣的 Item 會需要花多少時間,這樣的時間以分數評估來講會是幾分,並在每一次的 Sprint 內可以完成幾分的項目;同時 PO 也可以漸漸學習知道怎麼規劃 Item ,讓開發團隊降低和 PO 來回之間的溝通,而一旦更動了時間,這些都會重來。

4. Daily Scrum:每日的站立會議,每個人輪流講述3個事項 (1)昨天做了甚麼 (2) 今天準備做甚麼 (3) 有遇到甚麼困難。

->與會人員:Scrum Master, 開發團隊, PO(建議到場,才會理解現在的開發狀況,有遇到甚麼理解上的困難)

->活動時間:不超過15分鐘

Daily Scrum 最基本的目的就是資訊互相流通,讓開發團隊彼此知道做了甚麼事情,所以有可能你正在遇到的 Bug 提出之後,剛好別人昨天已經解過,那就可以增加開發效率,畢竟開發人員一遇到無法解的 Bug 都會事先上網尋求幫助,再一步一步慢慢解,假設已經有人經歷過類似的問題,那麼這段時間就可以節省下來開發分派的 Task。

在 Daily Scrum 當中,如果有問題需要討論,就結束之後再另起會議找相關人員進來一起開會。

5. Sprint Review:Sprint 結束時候的會議,交互討論 Sprint 產出內容

-> 參與人員:PO, Scrum Master, 開發團隊, 相關利益人(客戶、專家等等)

-> 活動時間:Sprint 1週對應1小時(如果Sprint 2週就不超過2小時)

請記得,這個階段不需要準備任何的投影片,主要由 PO 進行軟體的交互操作,藉由可產出清單進行檢視,並依照 Acceptance Criteria 的步驟進行。

在這過程當中,PO 與開發團隊應該會有來回的互動交流,彼此才會知道在 Item 的撰寫描述和實際開發內容的差異和認知,漸漸地 PO 會知道 Item 如何撰寫能使開發團隊理解,開發團隊也會理解 PO 撰寫 Item 文字的目標為何;

任何參與者都可以詢問問題或提出任何意見。

6. Sprint Retrospective:Sprint 的回顧會議

->參與人員:Scrum Master, 開發團隊, PO

->活動時間:Sprint 1週對應1小時(如果Sprint 2週就不超過2小時)

通常 Sprint Retrospective 會議是不需要 PO 參加的,因為會議中會詳細檢視過去 Sprint 在 Run Scrum 時候所有環節遇到的問題,接著討論然後進行改善,到下一次 Sprint 時候實施。

實際進行的時候自然會遇到一些阻礙,例如都沒有人反應問題,或者一直在提問題,感覺像是一個檢討大會,久而久之會讓這個氣氛變得不是很好,所以這邊筆者做出了幾項的建議

(1) Scrum Master 為會議主導者:Scrum Master 需要先列出看到的問題,同時建議也列出好的部分,讓這個會議不是在「檢討」,而是在相互交流和精進最適合開發團隊的方法。

(2) 強迫開發團隊發言:建議請開發團隊每個人講至少3樣好的現象,1樣需要改進的項目,就算那些現象或項目很小也沒關係,重點是透過這樣的機制鼓勵大家互相交流發言,這種機制後續甚至也可以變化方式,例如發兩張紙,一張紙寫下自己在這次 Sprint 中犯的錯誤與缺點 or 看到可以改進的地方,另一張紙寫下右邊三個人,描述每個人至少一個好的現象,等等諸如此類的,讓檢討會更加活潑互動更多

(3) 筆者認為 PO 是要參加的,原因在於 Scrum 活動的細節跟 PO 所開的 Item 息息相關,包含 Item 內容說明、Item 評分、Item的Task拆分與分配等等,透過理解開發團隊在 Sprint 上遇到的問題以及狀況,PO也可以詳細知道 Item 的方向調整,以及面對客戶提出的需求改變要怎麼應付。

曾在外商擔任過工程師、技術顧問,AI 新創擔任過產品經理的小小職員,目前在醫藥業擔任技術 PM,希望透過技術和遊戲化設計改變部分傳統思維。

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store