大家好，這篇分享由 Kuanwei 和我 Rene 一同撰寫。我們目前在同一個 Scrum team 負責相同的專案。Kuanwei 負責App的自動化測試與DevOps相關開發，而我主要負責開發 Android 的 App 或 SDK。

最近團隊為了工作流程能更順暢、跨國溝通更有效率，把印尼及台灣同事聚集在台灣辦公室，花了四天時間讓大家一起上課溝通，列出痛點及討論出未來工作模式的改善方式，盡可能讓大家對於 Scrum 的理解與工作模式能達到共識。在分享心得前我想先我們團隊背景做個介紹，並讓大家盡可能理解我們遇到的問題。

團隊背景

我們這個 Scrum team 由台灣、印尼及韓國三個國家的成員共同組成，隨著時間演進，團隊人數也從10人內漸增至目前將近20人的大團隊。

• Planner: 2人
• Developer: android/5人, iOS/5人, server/2人
• QA: 3人
• Designer: 2人

基本上，我們是很活潑歡樂的團隊，成員協調及語言能力都不錯，因包含不同國家成員，大家也樂於互相學習對方的一些基本招呼或常用語，像在團隊內我們最常使用的就是印尼文的 mantap ，是類似 good job 的意思。相處上也很開放融洽，大家暢所欲言，討論公事時認真，私下也能開玩笑互相調侃。但隨著團隊的擴大，在工作流程上還是不可避免的浮現些問題。

遭遇問題

因部分資深團隊成員過去已有 Scrum 經驗，一開始在整個 Scrum 架構或方式的實行方面並沒有太大問題，但隨著人員的更替以及人數增多後，溝通成本隨之提高，潛藏的問題也漸漸浮現出來，底下我會分別描述團隊較為困擾的幾點：

1. 職責分工問題
   因為公司還在成長擴大當中，團隊成員時有更替，部分是新加入公司，部分則是因專案的更換，因此，成員因工作轉換，或是對 Scrum 流程的理解不同，對各自負責的工作認知上也會產生落差。
2. 跨國及跨平台溝通成本
   由於團隊成員分跨不同國家，可以預期溝通上必須花上更多時間，並且溝通因為透過英文，在理解與陳述上也帶來差距。另因團隊同時包含 android 與 iOS 2種平台的實作，但在使用者操作習慣與設計規範上有所不同，之前只有一位 designer 的狀態下，可能會快速把其中一種設計直接套在另一平台上，造成在實作時工程師產生疑問下，又回頭與 designer 來回確認與討論，溝通時間拉長，雙平台在各自與 planner/designer 討論下分別實作，最後實作出來才發現流程不一致，必須再行調整，耗時又費力。
3. 工具問題
   同樣的在跨國合作上，常常無法當面溝通，我們運用了很多工具來達到討論的目的。舉例來說，spec 在內部的 wiki 上，當 review spec 時，我們會把問題留到頁面上，除了 wiki 有時為了得到即時解答，我們也會把問題丟到 slack / line 上，也把設計問題留到 zeplin 上等待 designer 回覆。一路下來可以想見，訊息散落各處，如果沒有人幫忙把它再集中回統一的地方，各方接收到的訊息就產生落差或是各自解讀，更恍論除了上述提到的系統外，我們還有其他更多開發上的工具或系統，可以預見又是增加溝通成本的一個癥結點。

寫在 Workshop 之前

事實上，這個 workshop 不是憑空冒出。過去半年間，公司一直積極投入人力，協助各團隊增進工作效率並提升工作流程。去年底也曾在君悅酒店舉辦了兩天期的 workshop，目的除了大家檢視當前工作程序上的優缺點與聚集不同國家的合作同事增進感情外，更辦了一個腦力激盪的競賽，鼓勵大家激發想像力，構思基於當前服務外的更多功能或產品，當天備受肯定的想法除了可以拿到獎品外，更有機會實際產品化上線，讓同事們都很有成就感。

這兩天的 workshop 更像是一個改善流程開始的里程碑，除了能學習到不同團隊有效率處，更能反思自己團隊內的不足。也因為能面對面的與整日只在視訊會議對面出現的同事直接溝通，能更有效減少對話理解上的落差，繼而提出改善的方式，部分問題也在此得到初步的解決。當然，兩天裡飯店美味的午餐也是一個很重要的功臣。(笑

Workshop

第一天 Scrum & Snowflake Game

因團隊內印尼大部分同事都還沒上過 Scrum 相關課程，這次也邀請 DMT (Delivery Management Team) 一位非常有經驗的同事，特地從日本公司飛到台灣的幫大家上 Agile / Scrum 等概念，並經由實際演練來讓大家快速進入情境。其中，分組體驗 Scrum 的雪花遊戲個人覺得相當有趣，可以觀察到成員不同的思維以及策略性。

第二天 Scrum & R&R

第二天早上，講師繼續接續前一日介紹 Scrum 其他概念，但因團隊其實已經跑了將近 20 個 sprint，所以發問很踴躍，大家都嘗試把遇到問題拋出，請教講師想法跟實際執行時的難處，講師在被一輪問題轟炸後，歸納出了大家的幾個疑問，決定臨時改變預定的課程，讓大家投票決定下午想做的活動。而投票結果發現，大家都一面倒的希望透過活動來釐清職責問題。於是講師動態地調整了訓練內容，大家花了一個下午的時間去做了一個 Role & Responsibility 的釐清活動。這一天結束時，講師也讓每個人發表這兩天下來的感想，一輪聽下來感覺大家都收穫滿滿。

第三天 Specification By Example 訓練

在深入了解了Scrum精神及方法後，第三天我們進入了全新的領域，接受了 Specification By Example（需求規格實例化）方法論的訓練。主要的目的是團隊在開發軟體產品的過程中，如何透過實際的例子來說明需求規格，並將該實例自動化後成為一份團隊可共同參考的文件，以減少過去因為溝通不良，造成交付的產品與預期不符，以及文件維護困難的問題。

本書是2012年 JLOT 震撼獎的得獎作品，該書的作者是 Gojko Adzic。JLOT 獎相當於軟體領域的奧斯卡獎。該獎主要表彰那些給軟體業帶來震撼的產品，方法，和書籍。

Specification By Example，由於定義了需求，實例與自動化的關係，因此非常適合用在敏捷開發的框架下，尤其是在於 BDD（Befavior-driven development）的開發概念上。特別是此種方法針對過去大型專案往往開發完成後，軟體文件常因缺少更新而不具參考價值，進而提出了『Living Document』這個概念，團隊可以用 Living Document 來了解需求，執行開發，該實例也可以用來做自動化程式開發來檢測產品品質，未來新成員也可以用此文件參考過去開發的功能，可以有效減少後續文件維護困難的問題。

訓練的過程中，我們先了解到需求實例化的出發點在於，如何有效的接收到需求後，把該需求切到最小的單位，並且提出該單位對應的實際例子。比如説當 Product Owner 提出了他想要一個查詢系統，當我們接收到這個任務之後，我們必須列出查詢系統實際操作會遇到的實例，像是是否需要時間區間查詢，查詢的字串規則是什麼等等。當我們有不清楚之處時，就直接將問題還給 Product Owner 請他解釋他的期望。其中一個重點是，千萬不要自己自由想像 Product Owner 可能會要什麼，而是直接發問請 Product Owner 回答，如果 Product Owner自己不清楚，團隊成員也可以提供建議讓 Product Owner 參考確認。

團隊成員也了解到，溝通有很多方式，比如面對面溝通，電話溝通，Email溝通等，其中最有效率的方式就是面對面用白板溝通，許多問題可以當面問清楚，或是將流程畫在白板上，讓雙方能清楚得取得共識。

而一個專案可能需求非常龐大，此時我們可以將整個 team 拆分成數個小組，由小組成員各自將屬於自己的需求提出實例化結果，並向團隊分享，如此一來可以更快速且效率的濃縮需求，而不會把時間都花在開會及討論上。

第四天 Internal Discussion

最後一天所有團隊成員集合進行內部討論，共同 review 前3天上課的內容並討論如何導入專案之中。過去由於分隔兩地缺少面對面溝通的機會，剛好藉由這次印尼成員來台，我們可以坐下來一起討論像是優化開發流程及設計流程等，讓大家取得共識。

整個會議的的過程中，很重要的一點是有紀律的發言，因為如果大家七嘴八舌的講，往往無法專注在發言者身上，所以團隊準備了1個會發出怪聲的小豬，只有拿到小豬的人才能發言，其他人必須聆聽。

在討論的過程中讓大家把各自的想法以及問題，在幾天的訓練後，其實仍有不少人對於細節有疑問，也趁今天這個會議討論清楚。

其中討論最多的主題就是在 Scrum 如何正確進行 story point 的估點，畢竟每個工程師的對於 story 的評估各有不同，如何取得共識是最重要的一點。其中講師也分享到 pair programming 的重要性，如果2位工程師對於 story 的評估不同，估點較多的工程師可以配合估點較少工程師共同進行 pair programming，以利了解如何用更短的時間完成。

心得

除了這兩次較大的 workshop，公司內部持續辦有各式各樣的 training 也鼓勵主動提出不同想法。光是 Scrum 與 Unit test training 就開了好幾場，也很不計成本的請外部講師來公司內上課。員工在有空時也都會積極報名參加。而這一場 workshop 讓我們得以重新檢視 agile/scrum 的精神與團隊的默契，收穫不僅僅是自身能力的提升，更大的是團隊整體的獲益！

底下我們想就自身實際實行 scrum 的經驗與此次 workshop 結束後做幾點心得分享：

1. Agile/Scrum 的精神重於工具或方法
   過去 waterfall model 或是聽令做事的習慣會限制大家的想像，並執著於該拿到怎麼樣產品規格說明文件，產品流程該誰決定等等細節。但攤開敏捷軟體開發宣言，可以看到其更著墨於互動與自主性。講師也強調大家應該要更積極溝通並表達自己想法，產品開發並不是 product owner 一言堂，每個人的想法都有其價值，達成共識才能讓產品順利發展，且團隊的凝聚力才能更高。
2. Story point 的估算需要練習與默契
   估點的準確度一直以來都是一個大問題。透過這次的練習活動，在 refinement meeting 中，我們將團隊分為更小單位的群組，並聚焦在點數的 scale，而非實際的工時上，5-7分鐘內小組會有一個估點結果，在聚集所有組別結果，看是否一致，如果一致認同則進行下一個估算，不同的話則繼續請不同意見的組別發表意見來討論。很幸運地，透過這個練習，我們團隊在最後的幾個 story 估算上都很一致地達成共識，也不用再花過多時間討論。其主要的原因，一是分組的效果，另一方面，我們也認為透過練習與磨合，大家的 scale concept 逐漸達成一致，能更快速達成共識。
3. 責任的歸屬與主動承擔 
   這次最大的一個收穫之一，就是透過 R&R 活動，大家清楚認知到每個不同角色的人平時的工作內容究竟是哪些，進而也釐清模糊地帶的工作，需要成員主動地去參與，而非等著被分配或是坐享其成。舉例來說，refinement meeting 中提出的問題與最後決定的結果，必須有人主動紀錄並更新至文件中。測試產品也不僅僅是 QA 的工作等等。這其實也對應到理想的 Scrum 以及 T 型人才的概念，裡面角色只有 Scrum Matser、Product Owner 以及 Team 三種，大家盡可能水平方向地擴展自身的技能，並能互相協助或處理對方的工作。雖然在現實中，尤其是大公司角色的細分化之下，各自的專業方向可能沒有重疊，但能在這樣的模式下多學習到不同的技能也是對自己有很大的好處！
4. 朝 Mature team 方向邁進
   總歸來說，100間公司就可能有101種 Scrum 的跑法，Scrum 也不是簡單鬆散的特效藥，需要搭配強大的紀律及專業，一步步磨合團隊，才能邁向成功。而這次團隊在解決流程上的過程中，慢慢建立出獨屬於我們團隊的文化與紀律，創造凝聚力並簡化流程，未來也希望朝著不再需要 Scrum Matser 的成熟團隊發展，所有成員都能自主獨立地協調完成工作，這樣除了能為自己也能為團隊及公司創造更高價值。

最後

公司推崇尊重與信賴的團隊文化，希望培養擁有自主導向的團隊，並且願意讓大家停下工作，不計成本提供場地、餐飲經費、講師等等支援大家主動地去創造一個更好的工作環境與文化流程。很幸運公司有這樣的態度。這類型的 workshop 相信之後還是會陸續進行與發生，相信這只是一個起點。這也讓團隊有更多元的發展與想法，很開心能與大家分享初步的經驗，之後團隊有更多的成果希望再與大家討論！