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

因為太多團隊參加所導致：由於團隊間溝通需要確實花時間，也許較好的解法是要分層做Scrum of Scrum，並不是直接採用限制報告時間30 秒可以解決。

有些人 ... GetunlimitedaccessOpeninappHomeNotificationsListsStoriesWritePublishedin程式猿吃香蕉Agile🏈團隊問題又雜又亂？試試改用ORID方法開Retro檢討會筆者任職Yahoo，《軟體需求溝通─從外商公司學跨部門協作開發》線上課程講師，紛絲團《程式猿吃香蕉🍌》你是否發現Retro討論會逐漸流於形式？在每一次Sprint後的Retro檢討會，大部分團隊用的句型都是：1.我們哪裡做得好？(DoingGood)2.我們哪裡可以做得更好？(Couldbebetter)但是，有些時候團隊中的問題已經「盤根錯節」或是「隱匿難尋」，不是僅僅靠上述的句型和討論就能把團隊「導回正軌」的，此時可以改用ORID的方式來開Retro檢討會，這也是我過去幾年與團隊時常使用的方法，並且收到很好的效果。

以下將分享這個方法，以及實際的執行方式。

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

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

2.執行階段執行時將分為四個階段的討論，根據討論依序張貼「事實Objective」、「感受Reflective」、「詮釋Interpretive」、「決定Decisional」的貼紙，每一個階段結束後，才進入下一個階段，以下逐一說明各個階段：(1)事實Objective指具體的事實，儘量客觀地討論「發生了什麼事？」，指出團隊哪些事情「正在發生」應該要被來討論，提問時可以用「你覺得DailyStandupMeeting中有發生什麼事？」或是「你覺得在CodeReview中有發生什麼事？」在這個階段，提問與回應都先不涉及主觀的感受，避免定調個別事件，以下為回應的範例：✅發現DailyStandupMeeting時間花得愈來愈久✅發現CodeReview時間愈來愈長✅發現常常在新功能上線後要Hotfix在回應時避免直接提到「感受」與「解法」，以下為錯誤的回應範例：❌我覺得DailyStandupMeeting好久超煩的(提到感受)❌我覺得DailyStandupMeeting每個人要限制報告時間30秒(提到解法)❌我覺得要增加CodeReview人手(提到解法)在事實討論階段直接提出解法是危險的，你可能會讓團隊的人無法充分表達意見，例如：DailyStandupMeeting開很久這件事情，可能會有這種情況：因為太多團隊參加所導致：由於團隊間溝通需要確實花時間，也許較好的解法是要分層做ScrumofScrum，並不是直接採用限制報告時間30秒可以解決。

有些人完全不覺得很久：只是討論的項目跟某些人沒關係，所以那些人才覺得很久，也許解法是請那些人不要參加這場DailyStandup，此時直接加入主觀感受說「好久超煩的」，可能會讓其他人的意見不敢表達。

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

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

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

」也會有人說：「不會呀！我覺得剛剛好。

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

(3)詮釋Interpretive此階段為描述從「事實Object」到「感受Reflective」的「心路歷程」，可以詳細描述為什麼這個「事實Object」會造成這個「感受Reflective」，讓團隊可以掌握更多細節，舉例：✅CodeReview時間愈來愈長，讓我壓力山大，因為每次季末要考核進度，如果目前CodeReview的權限都卡在少數人身上，每一次Reviw又有一堆東西要改，我擔心我在季末會做不完。

✅DailyStandupMeeting好久超煩的，很多時候別人在報告時，我都在放空，那些內容跟我一點關係都沒有，但我又擔心不參加會議會跟整個團隊脫節。

以CodeReview的例子，我們可以發現團隊成員的「心路歷程」：1.擔心「季末考核」2.CodeReview的權限集中少數人甚至我們可以發現他的程式碼總是有「一堆東西要改」，可能本身的程式碼品質就不好，在了解這些心路歷程後，我們便可以針對這些點逐一解決。

以DailyStandupMeeting的例子，我們可以從「心路歷程」發現團隊成員雖然覺得開會很煩，但擔心「會跟整個團隊脫節」所以被迫持續地參加會議。

我們在思考解法時，也許可以透過安排「技術分享會」讓他定期參加，使他不與團隊脫節，然後讓他先暫時離開目前的DailyStandupMeeting，不要浪費時間。

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

(3)決定Decisional最後一個階段是討論解法，根據剛才的「事情->感受->詮釋」的脈絡找出適合的解法。

​▍ORID討論法的優點與挑戰以下為我自己團隊使用這個方法多次的心得：1.優點這個方法可以幫助團隊發現許多「深層」的問題，透過層層討論，了解每個問題背後牽涉的子問題，探索每個人在意的事情是什麼，逐一解決。

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

2.挑戰這個方法最大的挑戰在於「你的團隊願意跟你說真話」，以及你要讓你的團隊相信「你有能力幫他們解決問題」。

這讓我想起小時候看過的軍教片《號角響起》，蘇有朋在軍中對長官說了真話的片段，並時時警惕自己，要有「說真話」的團隊文化，使用ORID辦檢討會才有意義。

▍小結當你發現傳統的Retro討論會逐漸流於形式，好像提出什麼解法都無濟於事，甚至你隱隱覺得好像有什麼深層問題沒有爆發，此時便可以嘗試採用ORID討論法挖掘出團隊「真正的問題」，並且逐一擊破。

之後我會再分享在大型團隊進行Retro會遇到的細節問題，敬請期待！若是喜歡我分享的內容，歡迎幫我按個拍手，可拍50下，給我一點鼓勵，或是加入我的粉絲團《程式猿吃香蕉🍌》，一起分享軟體知識與心得！程式猿吃香蕉『來點更營養的軟體知識，吃香蕉吧！』成員均為軟體開發愛好者，任職於網路產業，熱於分享與討論交流，一起加入吧！banana4coder.ccMorefrom程式猿吃香蕉我們是一群軟體開發愛好者，喜歡將軟體知識以簡單生動的方式講給你聽，順口好消化，營養又健康！Readmorefrom程式猿吃香蕉AboutHelpTermsPrivacyGettheMediumappGetstartedJaydenLin1.5KFollowersYahoo擔任LeadEngineer，負責廣告系統，帶團隊做跨國開發。

也是《程式猿吃香蕉》團隊創辦人，喜歡將實用的軟體知識以簡單生動的方式講給大家聽😄😄😄FollowMorefromMediumSteffenScrumvs.Kanban=ScrumBan?MoLiSoftwareProjectEstimationAndBiaseskashifkhanSprintRetrospectiveinRemoteTeamsusingTrelloChee-HongHsiaHowtoFailasanAgileCoachinScrumHelpStatusWritersBlogCareersPrivacyTermsAboutKnowable