接續上一篇文章《敏捷方法的成功密技（七之一）》，除了新領域、新團隊，最有機會嚐試新作法之外，我們也談到了，只要開發團隊夠紮實，產品的開發就能夠打帶跑，因為品質才能夠被掌控得好。怎麼說呢？
心態要正確，方法要用對
從過去20多年來從事軟體相關產品的開發，以及管理過許多軟硬體整合性專案的經驗歸納起來，我不會要一個新手必須寫出很多的程式嗎，產出很多的成果。但相對的，我會嚴格要求，只要是寫出來的程式碼，品質就必須達到「幾乎可以出貨的水準」。更重要的是，我會灌輸、教育研發團隊（不歸我管的也一樣），不可以有「依賴 QA 工程師們來幫軟體工程師們抓 bug」的錯誤心態！
軟體的品質，是軟體工程師們「設計」出來的，不是靠品保工程師們「測試」出來的！那到底又該如何做，才能夠達到這樣的成效呢？答案其實也並不是什麼稀奇的神器，其實就只是好好地做 Pair Programming、Unit Test，以及「持續整合所有程式碼」（Continuously Integration）而已！
Pair Programming 的中文被翻成「配對編程」，就是「兩人配對編寫程式碼」之意。實際上的做法就是，一個人掌控鍵盤並撰寫程式碼，另外一個人就仔細盯著這些程式碼，檢視有沒有什麼地方是邏輯錯誤會產生問題的，有沒有更好的寫法可以讓程式碼看起來更精簡、更好維護，甚至是運行效能可以更好的。
兩個人在這個過程當中，都可以直接討論，或者是不斷地互換角色，直到共同完成一個軟體功能的開發為止。當然，也不必然需要整天八小時都這樣做，因為配對編程是一件需要非常聚精會神、非常消耗腦力和體力的事情啊！
配對的方式，我通常會讓老手和他要教導的新手一起配對，以開發一個新的軟體功能。這樣做的好處是，新手和老手在互動的過程當中，就可以彼此充分互相了解，建立團隊合作的工作默契，尤其是在對工作品質的要求上。另外一個好處是，老手有豐富的實戰經驗，而新手有無限充沛的創意，兩個人搭配，更可以互相激盪，彼此補足對方的不足之處。
然而，想要讓這樣的安排發揮成效，兩人當中就必須一定得至少有一位是極度自我要求的種子工程師才行，如果兩個人都是行事馬虎的作風，那奉勸您也就別瞎忙了吧。
選對好工具，不愁團隊沒有好默契
經過這樣的安排，我團隊內的新手通常都能夠在三個月之內，其工作的產出量和品質，就能夠逼近一個老手的水準，完全可以獨立運作而再也不需要主管的操心！團隊成員之間的默契，也因為這樣的長時間緊密互動，而變得牢不可破！
然後，美好的事情發生了！團隊成員之間，自動自發地互助合作，也就變得是一件稀鬆平常的事，完全不需要我這個主管的要求或是規定！而產品的品質，更是出乎意料地好，好到讓品保工程師們都幾乎沒業績了（都測試不出什麼嚴重的大 bug 啊）！那麼，到底為何效果會這麼好呢？
其實這是有許多的潛在心理效應的。
當新手在撰寫程式碼的時候，老手會叮嚀囑咐，這裡漏了防範，那裡應多些保護措施；當換老手寫的時候，新手也往往能看到老手類似的盲點，正是所謂的「當局者迷，旁觀者清」的效應！況且，老手被新手抓包，面子也會掛不住，往往在配對編程的過程當中，老手會比平時自己一個人做事的時候，更加地小心謹慎。因此，配對編程對於軟體的品質，效果可是好得不得了的！
「配對編程」只是第一道運用 XP（極限軟體編程 Extreme Programming）方法的軟體品質防護。搭配 Unit Test 之後，讓工程師撰寫的程式碼，在送上伺服器與他人的程式碼做整合之前，先一個個功能單元（unit 或 sub-routine 或 class）地，分別用模擬資料做驗證測試，這樣就建立起了第二道的品質防護。然後，等自己的程式碼在伺服器上，與所有其他人撰寫的程式碼，一起透過「每天的數十次持續整合（Continuously Integration）」的自動編譯、測試系統處理過之後，又完成了第三道的品質防護。這些層層的品質防護，當然就會讓品保工程師們徒呼負負，不太能測試出什麼大 bug 啊！
對於開發團隊（無論是 RD 或 QA）來說，實質面的生產力均大幅提昇了，因為事情大都一次就做好做到位，令人厭惡和挫敗的重工相關工作（例如，紀錄、回應、跟催 bug 等），亦大幅地消失，加班少了，甚至是變得不需要了，團隊的工作士氣也因此就更高了。如此，就形成一個非常良性的循環，組織當然也就更有競爭力了。
這樣的一個團隊，不就是大家夢寐以求，理想中的 Scrum 開發團隊嗎？
在每兩週就能交付出可測試、可使用的產品雛型給其他單位同仁們試用的過程當中，沒錯，我就相當於一個 Scrum Master，和相當於 Product Owner 的產品經理密切地合作、討論、修正！我有開發團隊的人事考核權，但是，這卻一點也不影響我引導培育出這樣一個生產力高到不可思議的 Development Team！
是誰說 Scrum Master 不能有開發團隊的人事考核權的？是誰說開發團隊一定得一開始就湊足5-7人的？又是誰說開發團隊成員得事先懂得所有完成產品所需的技術的？
能順利交付出對客戶、用戶有價值的產品，甚至是對組織自己本身都產生極高的價值（如，創造出超優良的開發團隊），這不就是個好敏捷方法嗎？誰管你有沒有完全符合 Scrum 的規矩！
