Scrum的遊戲規則 – Scrum Guide在講什麼

前言摘要:

本篇討論Scrum Guide。一份十五頁的指南,清楚簡單的告訴所有對Scrum有興趣的公司組織。團隊,或個人,如何遵行這個Scrum的遊戲規則。不管您己經在執行Scrum,或者開始接觸,絕對不要錯過。


常常有人問我以下一些問題: Andrew, Scrum團隊包括哪些人,以及多少人呀? 這些人要做什麼事呢?什麼是短衝(Sprint短程衝刺)呀?Scrum要開會嗎?要開那些會呀?我聽說跑Scrum不是不用再開會了嗎?每次的短衝應該多久呢?可以延長嗎 ?產品待辦(Product Backlog)和短衝待辦(Sprint Backlog)到底是什麼呀?常聽你問別人:您們的團隊有對“完成”下過定義嗎?這個“完成”的定義(Definition of Done)到底是什麼?為什麼它很重要呢?

相信大家對Scrum一定有很多問題,我自己也不例外,這時候當然先問一下Google,或者我建議大家也可以翻一下Scrum Guide。當然大家也可以看一下筆者之前的文章或者以後的文章,或者筆者演講的內容,這些當然都有幫助。

這篇我們就來討論,Scrum Guide在講什麼?為什麼它很重要?

 

Scrum是在1995由Ken Schwaber和Jeff Sutherland所提出。Scrum Guide也是由兩人所撰寫,提供以及支持。Scrum Guide基本上定義了Scrum的遊戲規則。就像任何運動一樣,打的好不好很重要,但是規則更重要。如果有人說,我們的Scrum團隊每天的Daily Scrum是三十分鐘,或者我們不需要開短衝回顧檢討會議(Sprint Retrospective),因為我們很忙。那麼不好意思,您跑的不叫Scrum。就這麼簡單。

Scrum Guide最近更新的版本為2013年7月,可以免費下載,更好的是,它有中文繁體版,翻譯的人剛好也是筆者。

Scrum指南只有十五頁,夠簡單了吧。我們就接著看下去。

首先Scrum到底是什麼?

它是一個架構(Framework),用來幫助處理複雜的問題,常被使用在複雜的產品開發上。等一下,Scrum不是軟體工程師在用的嗎?這跟我的了解不一樣啊?Scrum起源於產品開發,並不是侷限於軟體開發。當然在產品開發過程也許會有軟體的部分,但是一開始它跟軟體開發的關係遠遠沒有和精實(Lean)來的密切。筆者在一次簽書會問了Jeff Sutherland(Scrum的兩位發明者之一),我問他: What is next for Scrum? Scrum下一步會往那裡走? 他的回答很有趣,他說Ken Schwaber也問過這個問題,Jeff覺得應該會應用在硬體上。這個回答對臺灣的硬體業也許會更有興趣,他是有點回到初衷的感覺,如果製造業也開始跑Scrum的話,應該會有很好的火花與想法出來。

Scrum同時是很輕量的,很淺顯易懂的(就十五頁而己,不是嗎?),但是它很難精通。它有點像下棋,學會怎麼下不難,但要精通而成為專家,就不容易了。筆者大約在2008年左右接觸敏捷開發,每天還是有新的想法與觀念在被談論。

 

Scrum的團隊:

Scrum團隊有幾個重要的角色,分別是:

產品負責人(Product Owner):

這是一個人,不是一個委員會。她/他必須對產品的價值當責,使其達到最大。產品負責人最重要的一件事就是管好產品待辦(Product Backlog)產品待辦簡單說就是一份排好順序,跟開發這個產品所要做的所有事情的項目(產品待辦項目,Product Backlog items)

產品負責人必須要清楚的表達這些產品待辦項目,按照每個項目所產生的價值來排好順序,以及確定大家都很清楚地看到接下來要做的項目。

開發團隊(Development team):

這是一群人,一群在做事的團隊。他們自我管理(self-organizing)以及跨職能(cross-functional)。自我管理和跨職能是很大的題目,我們另外再討論。

另外一個大家常常討論的是團隊的大小問題。Scrum Guide提出,少於三人可能會有技能上的限制,進而無法產出具有逐步遞增(Increment)的成品。超過九個人則需要太多協調。產品負責人和Scrum隊長(Scrum Master)並不包含在以上數字內。

另外一個簡單的公式是7加減2。不然就是亞馬遜公司有名的2個比薩(two pizza team),如果2個比薩不夠您的團隊吃,那您的團隊太多人了。或者筆者常說的,三個人可以做的,就不需要四個人,五個人可以做的,就不需要六個人了。

Scrum隊長(Scrum Master):

大家好像對Scrum隊長最有興趣,名字聽起來很cool,那他/她到底在做什麼呢?Scrum隊長確認Scrum的團隊遵守Scrum的作法和規則。他/她不是傳統的經理人角色,也不是專案經理。他/她是一位服務領導人(servant-leader)

Scrum隊長必須對產品負責人提供多方面服務,包含: 如何更有效來管理產品待辦,如何將產品待辦項目按照所產生的價值來排好順序,了解以及執行Scrum。

Scrum隊長對開發團隊所提供的服務,包含: 指導開發團隊如何自我管理和跨職能,幫助開發團隊創造高價值的產品,最重要的一件事之一: 移除開發團隊的障礙(impediments)。

另外一點大家常忘記的是,Scrum隊長對公司組織所提供的服務,包含: 帶領和指導公司組織對Scrum的採行,幫助員工了解Scrum,以及引發Scrum團隊增加生產力的改變。

Scrum隊長一定要擁抱改變,林氏法則這時候就可以派上用場,有關林氏法則請參閲以前的文章 ”敏捷或者Scrum所相關的規則(Rules),法則(Laws),和定理(Principles)”。

 

講完了Scrum的角色,接下來就是事件(Events),簡單講就是會議。

Scrum要開會嗎?答案是: 不好意思,要的。然而跑Scrum的好處在於所有的會議的長度都是固定的(time-boxed events)。延長會議是不被允許的。以此來減少其他不必要的會議。

Scrum到底包含那些會議呢?

短程衝刺,簡稱短衝(Sprint): Scrum的核心就在於短衝。短衝是固定一個月或更短期限(新的團隊我建議三個星期的短衝,四個星期有點長,如果是比較成熟的團隊,兩個星期是不錯的選擇),在這時間內開發團隊必須產出一個完成,有逐步遞增可發行的產品。前一個短衝結束,隔天緊接開始。不好意思,中間沒有休息時間。

短衝本身並不是會議,它其實包含了以下會議:

短衝先從短衝計劃會議(Sprint Planning)開始:

等一下,跑Scrum不是不用計劃嗎?要的,不過我們只計劃這個短衝要做什麼,至於下個月要做什麼,那是下個月的事。

如果您的短衝是兩個星期,那這個會議最長四個小時。最主要是回答兩個問題: 團隊要做什麼,以及要怎麼做。

這個會議有一點挑戰,因為開起來有點久,所以Scrum隊長別忘了帶些甜甜圈加珍珠奶茶。別忘了要草擬出短衝目標(Sprint Goal),用來指引開發團隊這次短衝為什麼要做出這個成品的目的。

開完短衝計劃會議,接著就是最有名的每天的Scrum匯報了。筆者上一篇文章“每天,站著開會”有非常詳細的介紹,麻煩大家看一下那篇囉。

以兩個星期的短衝而言,第一天先開完短衝計劃會議,接著每天的Scrum匯報,到最後一天,大家來看一下我們到底做出了什麼東西出來,最後一天有兩個會議,先來個短衝展示會議(Sprint Review),接著是短衝回顧檢討會議(Sprint Retrospective)。

短衝展示會議: 如果您的短衝是兩個星期,那這個會議最長兩個小時。產品負責人可以邀請跟我們做的有關的所有人來參加,開發團隊展示完成的產品以及回答問題,重新評估產品的市場是否改變了原本接下來要做的事。可千萬不要準備簡報,重點在於展示可以用的產品。

最後一個會議就是短衝回顧檢討會議: 如果您的短衝是兩個星期,那這個會議最長一個半小時。就不用邀請所有相關的人了,這個會議是屬於Scrum團隊的。這個會議很多團隊都跳過,原因之一是不知道怎麼開。其實有很多技巧可以使用在這個會議上。

這個會議的目的在於找出那些做的很好,那些可以改進,海星圖(Starfish diagram),是不錯的方式。Scrum隊長要鼓勵Scrum團隊改善(Kaizen)流程以及作法,讓下一個短衝有更好的效能和工作更愉快。快樂的團隊產能更高,生產的品質更好。

 

最後,對於那些己經在跑Scrum的團隊,恭喜您們,請持續下去 (May the Force be with you)。

 

如果您的團隊或者公司組織還在尋找一套更有效率的做事方式,試試看Scrum或者其它敏捷手法。看一下您的手機,是不是每兩三個星期就一堆Apps要更新呢?對的,大家都在跑Scrum或者敏捷。別等了。There is only one way to find out, let’s try it。

 

對了,免費的繁體中文Scrum指南可以從這兒下載 http://www.scrumguides.org/download.html

 

附上一個簡單的Scrum架構圖與上面文章內容對照,希望有所幫助。

Scrum Framework

 

寫於聯合航空925班機,London往Washington DC,11/29/2015

Andrew Lin, PMP / PMI-ACP / CSM / CSPO / CSP

andrewlin@01uni.com

原文刊登於2016年6月專案經理雜誌,請在下面留言,有問有答,謝謝大家。

No comments yet.

Leave a Reply