前面對我朋友 Larry 公司執行的「新系統 2.0」重構專案聊了很多，今天要講的是其中最被乎略的 QA 的故事。
QA 主管 Nathan 是個老好人，我們雖不在一起工作，但因為共同朋友多，私交還是不錯的。那天，是我幾年來第一次看他這麼生氣。氣到我把髒話 filter 掉後，留下來的內容只剩以下這些：
「都說了叫他們做一個段落就拿來給我測一下看看情況怎樣，也不要，最後一口氣塞一整個大系統給我是要怎麼測？」
「說好了 5 個月要給，我後面工作都安排好了，你又多拖 3 個月，後面的東西也不能 delay，叫我們的人怎麼做事？」
「測試時間一下子變短，又要全測，是要逼死誰？」
「自己也知道時間很趕，自己 bug 那麼多又修得慢，好不容易壞的改好了，結果好的又壞了，難道怪我嗎？」
「我就說了當天要來，是你們 RD 說不用，很安全。事後開檢討會議沒我的份，檢討出來就都我的錯，要確定捏！」
大概這樣，總之，他真的挺衰的。
Nathan 的衰，我想各位讀都一連幾篇看下來都能感同身受了，但事後整件事情回想起來，我倒認為，從他們公司的 Component Team 分組與工廠流水線式開發方式雙重作用力之下，QA 的「衰」這件事，註定了是很難避免的。
我們再來複習一下 Winston Royce 的瀑布模型：
我們可以看到，QA 在台灣常見的 Component Team 加工廠流水線式開發方式下，通常是在一個案子的最後一個階段才接觸。這時，對前面幾個階段（也就是其他 Teams）的人來說，他們的工作已經「做完」了。這時，身為 CODING 階段主力的 RD 們，你會特地把時間留下來等人家測到問題然後馬上解嗎？不會吧？你肯定是會趕快接下一個案子以趕上 KPI 對吧？
我明白這不是你的問題，因為身為 RD，你肯定是沒有發現自己程式有 Bug 才會把東西交給 QA 的對吧？對吧？至於為什麼沒有發現 Bug？因為在這樣的體制底下，抓 Bug 就不是你的工作呀！你的 KPI 是「做功能」+「解 Bug」，因此，做完功能後多花時間自測，根本是拿自己的績效獎金開玩笑呀！
俗話（？）說得好：「我們養 bug，bug 也養我們。」
這句話如果聽起來大家會覺得好笑，對筆者來說真的挺心酸的。
前文介紹過的 Feature Team，對這個問題有明顯的療效。我們來看看 LeSS 怎麼定義 Feature Team 的：
A feature team… is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one.
也就是說，這是一個長期存在的團隊，它自己就有能力完成一個又一個的 end-to-end 的功能（Feature）。筆者認為，這裡有兩件事的定義，會決定這個團隊工作的組成與工作效率。
首先就是對「完成」的定義。如果只是把 Code 寫完，那只要有前後端 RD 就好，但付出代價就是出貨後有很大機會會被 QA 丟回來的 issue 回馬槍打到；如果定義為功能性測試完成，那 QA 就會加入團隊，這時出貨後的東西會被退回來的機率就會降低了。
同時，因為測試變成我們同一個 Team 裡的工作了，這時把手動、耗時、機械式的測試工作盡量自動化，對我們自己就很有好處了。
很多人在與筆者聊到公司內部推自動化測試推不動，筆者分析起來，團隊組成也是很重要原因之一。
其次，就是團隊一次同時進行的工作有幾個。照 LeSS 的說法，one-by-one 是最建議的。「一次做一個工作，那不是效率很低嗎？」如果你這麼想，我建議你要冷靜一點看下去。
當團隊一次做很多事，我做的事與你無關，請問我有事要找人討論時要怎麼辦？沒錯，我要「等」。如果我們是做同一個功能的不同組件，或是我們根本就是用 pairing 或 mobbing 的方式一起工作呢？有什麼好等的，我的事就是你的事，有問題就解囉！
筆者認為，用持續、可預測、不容易出錯的步調來做事，正是 Feature Team 最大的好處。
在 Larry 與 Nathan 的故事中，「維運」也是一個單獨的 Team。這有什麼問題？嗯，其實說穿了也一樣，開發的是我，維護的是你，請問上線後收到客訴，或是線上出了錯，誰要查？誰要修？重點：誰要扛？
各位看過了前面 Feature Team 的原理以後，這個問題應該很好理解了。俗話（又）說的好，打不過就加入。解決 Developer 與 Operator 紛爭的方法，就是讓他們變成同一伙人。這時這一伙人就同時擁有 Operator 的維運知識與 Developer 的自動化能力了，多好！
變成同一伙人示意圖，圖片取自網路。
「就算你都能整合，那難纏的客戶你總沒輒了吧？」
nonono，不要小看我們軟體工程師解決問題的能力。Kent Beck 的 Extreme Programming（XP）的建議中，有一個就是要有 Real Customer Involvement。Martin Fowler 則解釋道，這代表客戶要出現在開發團隊找得到的地方，他看起來就像是團隊的一份子，他可以隨時回答團隊的問題，Review 做出來的功能是不是他要的，並協助團隊決定接下來的目標調整。
P 啦！最好客戶這麼閒啦，還拉椅子坐你旁邊咧！
當然，如果你也認同這麼做的價值，但客戶的直接參與無法這麼高時，當然實務上，公司的商務部門伙伴可就比較好找了吧？如果再不行，那至少 PO 可以擔任這個角色吧？無論如何，客戶本人或是客戶的「代理」（Proxy）的參與，肯定比冷冰冰的文件，對於「減少做錯功能」來說還是要更有幫助的。
如果各位對 Domain Driven Development（DDD）有研究，也肯定發現了，其實 DDD 講究的「與領域專家緊密互動」，也是在講同一件事。在任何好消息出現時提前知道，在任何壞消息變更壞之前提前告知，並共商因應之道，是現代軟體開發的一條重要道路。
有一種分組是筆者很常看到，但從沒聽過有好下場的，也就是 Component 與 Feature 並存的「矩陣型分組」。
在原有的一個一個 Component Team 中，抽出幾個人組成 Feature Team，並安排一位 PO，這個 Feature Team 不是長期存在，而是「任務型」的，也就是說，當這個任務完成並交付後，團隊歸建，等待時機再行組建，由不同人馬來組成新的 Feature Team，以執行下一個任務。
還記得 Scrum Guide 說的嗎？PO 的工作就是為產品的樣貌下決策並負責任。如前所述的「矩陣型分組」，當 PO 的想法跟原 Component Team 的 Team Leader 不同時，請問團隊成員聽誰的？聽 Team Leader 的，那手上工作的 AC 就可能達成不了；聽 PO 的，我的考績是 Team Leader 打的，要我違背他？要確定捏！
「那把團隊固定下來呢？是不是就會好一點？」
會，會好一點。但是 PO 與 Component Team 的 Team Leader 意見相左時，團隊無所適從的問題依舊存在。
說到底，這種矩陣型分組也有其用途。它在組織轉型成 Component Team 的過程中，其實可以用來當成一個工作方式轉換的緩衝，同時也可以透過實際操作與重新打散分組，找出合作起來最適當的 Feature Team 與 PO 組合。但一段時間後，Component Team 的力量就要慢慢削弱，而逐步往 Feature Team 靠攏。
還記得前文中提到筆者的好朋友 Jasmine 的故事嗎？她就是「矩陣型分組」的典型受害者之一。
前面講了這麼多分團隊與團隊組成的方式，真要說哪一種最好，其實也沒有一個定論，這些都只是「方法」。筆者認為是這樣，你現在組織的瓶頸在哪？找到瓶頸，承認它是個瓶頸，想辦法解決它，而且不要想著「導入」個什麼東西就能長治久安，一但情況有變，就再想別的辦法解決新的瓶頸，以此類推，不斷不斷地嘗試、分析、再改善，這才是「敏捷開發」這正想做的事。
謎之聲：「把我們之間的問題變成我們的問題，解了以後我跟你就沒有問題了。」
iThome鐵人賽
看影片追技術