團隊的 agile，不該是五歲小孩的足球比賽

繼續紀錄跟朋友與讀者的討論。

有些遇到的團隊工作模式非常工整，sprint planning meeting ，每天的 standup ，與後來的 sprint review meeting 一個也沒有缺，但形式 100 分，卻一點也沒有輕快的感覺。說實在的，儒家文化就是這樣，注重禮數與形式，但是心法卻一點也不顧。

最重要的是，在『上線送貨』的過程中，非常在意一步到位，整個團隊會先互相協調，確定所有功能都準備好了，前端後端 DevOps 與 app 都完成了，才一起在同一天推出。

但是也因為在同一天內，要所有東西要同時上線，部門間又切得非常清楚，導致很多整合性的部份是上線後才發現問題，於是在上線後的狂暴時間， all-hands-on-deck，團隊進入英雄模式，到處滅火，直到問題穩定下來。

雖然因為 agile 的形式，每兩週要佈署一次，以 water fall 的時程來說算是非常短的。團隊卻因為每兩週都有這些上線抓馬（drama），壓力指數每兩週都會飆高一次，團隊成員也會有上線 PTSD（創傷後壓力症），心理狀態與家庭狀態受到影響。

五歲小孩的足球比賽

這種症頭，我在矽谷的朋友間叫它 “5 year old succor game（五歲小孩的足球比賽）" 。團隊以亞洲群體思維運作，要上一起上，要退一起退，然後所有小朋友同時間就會追著唯一的球滿場跑，團隊與隊友看起來都會很努力，但是成員們實在不知道為什麼這時候要在這裡，在這裡要做什麼？ XD

以下影片是個很好的例子，建議觀看。

球在哪裡，小朋友就群聚到哪裡，他們不知道自己跑到那邊要做什麼，他們都想踢球，但是都踢不到球，都想檔球，但都擋不到球，彼此之間完全沒有溝通與合作，不只是一盤散沙，還是一盤會相互妨礙的散沙。

之前網路上認為這影片是 junior vs senior 的比較，對我來說不然。這不是一個 junior vs senior 的比較，這是一個有沒有戰術的比較。

拆開團隊來上線，會比較有效

大家不用都在同一個時間，做同一件事情！在最好的情況下，團隊之間也不用等彼此，要把等待的時間縮到最小！

打個比方吧，如果你要上線的功能，有後端，有前端，有 iOS ，有 android ，還要管 DevOps 確定系統運行：

1. 前端與 app 在做功能的時候，當然不用等後端的功能上線。
   那些整合的 API 全都可以自己假設，喬好 spec 即可，然後誰也不用等誰。
   
2. 做好之後，就各自放到 staging 上面，對內釋出 APK，或是 testFlight，讓商業團隊可以驗證與迭代。至關重要。
   
3. 一旦後端的任何 API 上了 staging 或是 dev machine ，前端與 app 端就可以直接開始整合，然後 DevOps 就可以直接開始分析上線後對系統的影響。
   
4. 如果是個新功能，或者說上線對 user 端不會有影響，反正後端 API 上線後也沒人用，乾脆就跟 DevOps 喬好，直接上 production 。如果把 production 搞掛了，也是 fail early ，不會全部人都 hang 在那邊等你修（見上圖）。跟前端，app 團隊完全沒有關係。
   
5. 接下來，frontend 與 app 端，可以自己分別上線 production，分別測試，分別驗證。然後商業團隊要 demo 給客戶時也可以直接挑準備好的那個版本呈現即可。
   
6. 如果還是希望所有功能一起釋出給用戶，只要做個 feature 的開關即可。所有前端的新功能，讀某個後端 API 的版本號啟用。在版號不到之前，功能只對商業團隊開放。

這樣每個團隊都各自拆開，各自驗證，各自上線，商業團隊很快就可以驗證到某個平台上的功能，很快就可以 demo 給客戶，很快就可以有結論與新的學習，如果需要，很快就可以叫停開發，或是 pivot 。

人少，團隊小，不用等，動作自然就快。

Agile 一直都是驗證商業假設的過程，不只是一個開發產品的過程。驗證假設的成本越小，所需時間越短，就可以越快學習，迭代下一輪的假設。

怎麼衡量每個迭代（iteration/sprint） ？

這樣問題來了？不注重那些形式，你 agile 或是 sprint 的績效要如何衡量呢？不是要算 sprint 的 burn-down 嗎？

既然重要的是『結論』，你在 review meeting 時就應該直接衡量衡量結論的出產狀況，而不是坊間用的『分數』。如果你分數很高，團隊速度很快，但是沒有人知道我在哪裡，我要去哪裡，還有我為什麼要去那裡，這樣的速度（velocity）又有什麼作用呢？

更何況，用『分數』，很容易讓團隊針對分數去優化，然後糾結於分數，本末倒置。

回到這些外部指標的目的吧：假設 -> 結論。

我自己推薦的作法，是在 planning meeting 時把這個 sprint （或 iteration）的假設與結論都用文件寫出來，用 confluence，google docs，或是 txt 檔案都可以，紀錄好，review 的時候才能使用。

然後在 review meeting 時，跟團隊一起復盤（replay）整個 sprint 所經歷的事情：

1. 這次團隊的假設與結論是什麼？
2. 哪裡的進行順利？
3. 有哪些意外發生？
4. 團隊的學習是什麼？
5. 有時候是目標定得不切實際？
6. 有時候是團隊跑去做別的事情（比如說救火，或是家裡有事）？
7. 有時候是快得到結論，就差那一點，為什麼？下次要如何處理？
8. 有時候是得到結論了，但是過程中，團隊有沒有學習到別的可能性？

這些問題都問了，你應該已經很明白團隊這次 sprint （或 iteration）的表現如何了，那些分數，對這個階段的團隊，應該就只是參考，不是絕對的指標。

用分數衡量，而不在意『結論』，在英文中有個說法，叫做『tail wagging the dog』，尾巴搖狗，而不是狗搖尾巴，意指團隊糾結在某些不太重要的地方。

看到這裡，如果你有共鳴，請跟我討論，或幫我轉發朋友圈八 🙂
Email 訂閱： https://forms.gle/2n7nBjbGw3SRNvim8
加入 Facebook 粉絲團：https://www.facebook.com/winston.chen.sv/