Agile 🏈 團隊問題又雜又亂?試試改用 ORID 方法開 Retro 檢討會

Jayden Lin
Jun 27 · 7 min read

筆者任職 Yahoo ,《軟體需求溝通 ─ 從外商公司學跨部門協作開發》線上課程講師,紛絲團《程式猿吃香蕉🍌》

你是否發現 Retro 討論會逐漸流於形式?在每一次 Sprint 後的 Retro 檢討會,大部分團隊用的句型都是:

1. 我們哪裡做得好?(Doing Good)
2. 我們哪裡可以做得更好 ? (Could be better)

但是,有些時候團隊中的問題已經「盤根錯節」或是「隱匿難尋」,不是僅僅靠上述的句型和討論就能把團隊「導回正軌」的,此時可以改用 ORID 的方式來開 Retro 檢討會,這也是我過去幾年與團隊時常使用的方法,並且收到很好的效果。以下將分享這個方法,以及實際的執行方式。

本篇內容:
✔ ORID 討論法怎麼做?
✔ ORID 討論法的優點與挑戰
✔ 小結

▍ORID 討論法怎麼做?

ORID 是一套國際知名且簡單易用的提問方法論,能夠幫助使用者更有結構性地思考與回應問題,ORID 四個英文字母分別代表「事實 Objective」、「感受 Reflective」、「詮釋 Interpretive」、「決定 Decisional」,討論時也依照這個順序層層推進。

需要一位主持人來引導大家提問和回應,還要準備一塊白板,或是使用 Google Jamboard 取代白板,來將大家的回應張貼在版上。

執行時將分為四個階段的討論,根據討論依序張貼「事實 Objective」、「感受 Reflective」、「詮釋 Interpretive」、「決定 Decisional」的貼紙,每一個階段結束後,才進入下一個階段,以下逐一說明各個階段:

指具體的事實,儘量客觀地討論「發生了什麼事?」,指出團隊哪些事情「正在發生」應該要被來討論,提問時可以用「你覺得 Daily Standup Meeting 中有發生什麼事?」或是 「你覺得在 Code Review 中有發生什麼事?」

在這個階段,提問與回應都先不涉及主觀的感受,避免定調個別事件,以下為回應的範例:

✅ 發現 Daily Standup Meeting 時間花得愈來愈久
✅ 發現 Code Review 時間愈來愈長
✅ 發現常常在新功能上線後要 Hotfix

在回應時避免直接提到「感受」與「解法」,以下為錯誤的回應範例:

❌ 我覺得 Daily Standup Meeting 好久超煩的 (提到感受)
❌ 我覺得 Daily Standup Meeting 每個人要限制報告時間 30 秒 (提到解法)
❌ 我覺得要增加 Code Review 人手 (提到解法)

在事實討論階段直接提出解法是危險的,你可能會讓團隊的人無法充分表達意見,例如:Daily Standup Meeting 開很久這件事情,可能會有這種情況:

  • 因為太多團隊參加所導致:由於團隊間溝通需要確實花時間,也許較好的解法是要分層做 Scrum of Scrum,並不是直接採用限制報告時間 30 秒可以解決。
  • 有些人完全不覺得很久:只是討論的項目跟某些人沒關係,所以那些人才覺得很久,也許解法是請那些人不要參加這場 Daily Standup,此時直接加入主觀感受說「好久超煩的」,可能會讓其他人的意見不敢表達。

每個人將自己的回應以便利貼張貼在白板上後,可以將類似的事實聚合在一起 (如下圖所示),之後再進入下一輪。

這個階段可以比較主觀地表達「感受為何?」或是「這件事有哪些印象深刻的地方?」。

根據在「事實」階段所提出的項目,來讓每個人發表感受,其中「感受」可能是正面的或是負面的,甚至對同一件事情,每個人的感受可能相差非常多,例如,我們可以問:「 Daily Standup Meeting 時間花得愈來愈久,你感受如何?」,可能會有人說:「對,好痛苦。」也會有人說:「不會呀!我覺得剛剛好。」

這一個階段,每個人將自己的感受貼在對應的事實旁邊(如下圖所示),輪流發表後,進入下一輪。

此階段為描述從「事實 Object 」到「感受 Reflective」的「心路歷程」,可以詳細描述為什麼這個「事實 Object 」會造成這個「感受 Reflective」,讓團隊可以掌握更多細節,舉例:

✅ Code Review 時間愈來愈長,讓我壓力山大,因為每次季末要考核進度,如果目前 Code Review 的權限都卡在少數人身上,每一次 Reviw 又有一堆東西要改,我擔心我在季末會做不完。✅ Daily Standup Meeting 好久超煩的,很多時候別人在報告時,我都在放空,那些內容跟我一點關係都沒有,但我又擔心不參加會議會跟整個團隊脫節。

以 Code Review 的例子,我們可以發現團隊成員的「心路歷程」:

1.擔心「季末考核」
2.Code Review 的權限集中少數人

甚至我們可以發現他的程式碼總是有「一堆東西要改」,可能本身的程式碼品質就不好,在了解這些心路歷程後,我們便可以針對這些點逐一解決。

以 Daily Standup Meeting 的例子,我們可以從「心路歷程」發現團隊成員雖然覺得開會很煩,但擔心「會跟整個團隊脫節」所以被迫持續地參加會議。我們在思考解法時,也許可以透過安排「技術分享會」讓他定期參加,使他不與團隊脫節,然後讓他先暫時離開目前的 Daily Standup Meeting,不要浪費時間。

在白板上,可以將你想要的「詮釋」貼在對應的「感受」上(如下圖所示),之後進到下一輪。

最後一個階段是討論解法,根據剛才的「事情->感受->詮釋」的脈絡找出適合的解法。​

▍ORID 討論法的優點與挑戰

以下為我自己團隊使用這個方法多次的心得:

這個方法可以幫助團隊發現許多「深層」的問題,透過層層討論,了解每個問題背後牽涉的子問題,探索每個人在意的事情是什麼,逐一解決。

以剛才 Daily Standup Meeting 的例子來說,有一個深層的問題是要幫團隊成員解決​「擔心會跟整個團隊脫節」的問題,透過 ORID 討論法可以發現出來,而這個問題不是直觀地透過縮短報告秒數可以解決的。

這個方法最大的挑戰在於「你的團隊願意跟你說真話」,以及你要讓你的團隊相信「你有能力幫他們解決問題」。這讓我想起小時候看過的軍教片《號角響起》,蘇有朋在軍中對長官說了真話的片段,並時時警惕自己,要有「說真話」的團隊文化,使用 ORID 辦檢討會才有意義。

▍小結

當你發現傳統的 Retro 討論會逐漸流於形式,好像提出什麼解法都無濟於事,甚至你隱隱覺得好像有什麼深層問題沒有爆發,此時便可以嘗試採用 ORID 討論法挖掘出團隊「真正的問題」,並且逐一擊破。之後我會再分享在大型團隊進行 Retro 會遇到的細節問題,敬請期待!

若是喜歡我分享的內容,歡迎幫我按個拍手,可拍 50下,給我一點鼓勵,或是加入我的粉絲團《程式猿吃香蕉🍌》,一起分享軟體知識與心得!

程式猿吃香蕉

喜歡將軟體知識以簡單生動的方式講給你聽

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!

Jayden Lin

Written by

Yahoo 擔任 Lead Engineer,負責廣告系統,帶團隊做跨國開發。也是《程式猿吃香蕉》團隊創辦人,喜歡將實用的軟體知識以簡單生動的方式講給大家聽 😄😄😄

程式猿吃香蕉

『來點更營養的軟體知識,吃香蕉吧!』我們是一群軟體開發愛好者,喜歡將軟體知識以簡單生動的方式講給你聽,順口好消化,營養又健康!