這是敏捷開發團隊管理系列的第二篇。（之一，之二，之三，之四）
這幾個團隊都是我自己親身經歷的團隊，從質量的角度來分析敏捷團隊的工作方式。
第乙個是乙個較為大型的團隊，約有25～30人，研發乙個單一產品。
這個團隊在一年半的時間裡邊，從5個人成長為25人，其中有一半人員來自剛畢業不到半年的本科或碩士（在2023年，還很難找到「有10年經驗的程式設計人員」）；在這個團隊擁有25名成員的時候，只有1～2個測試人員。
按一般的常理而言，這個產品應該面臨很大的質量問題，因為這些新來者應該編寫大量的缺陷，而測試人員又嚴重不足，不足以發現這些缺陷。
但實際情況是，這個產品是我後來經歷的所有大型團隊中最好的乙個，包括後來擁有眾多測試人員的團隊；此產品執行於cctv，屬於高度實時性和可靠性的產品；此產品在上市7年左右的時候占有市場的60%份額（之後資料不詳）……
第二團隊個可以說是個團隊，也可以說是個個人，是我之後為某家軍工企業開發的乙個小軟體。
「無損檢測系統」專案歷時3.5個月，涉及步進電機、超聲波掃瞄卡等各種軟硬體，儘管就這麼多人工，最後甲方說做了個「國內領先的無損檢測系統」（只能說可見國內行業底子之差）。
乙個人開發，當然只能自己開發自己測試，但是質量卻是有史以來最好的，整個專案的測試期只有幾天，而交付後一年中客戶沒有發現過缺陷，只在更換硬體平台後發現乙個水土不服的時序問題。
這兩個軟體，是我自己親自或近距離參與的專案中質量最好的兩個，但奇怪的是他們都沒有專業測試人員。
這裡先不分析程式設計人員與測試人員的分工、合作問題，先看看程式設計人員除了被「測試」之外，自己有哪些方法可以提高質量。
在這個團隊擴張的後期，這種審查制度被凝結在師徒制度中，以把原來「幫忙」做審查變成「審查義務」。這一變化的原因是中間曾經發生過一次「不負責任」的審查，造成一大段兩個月的**未經充分審查就進入**庫，釀成後來的一次現場故障。這種「不負責任」來自於本來就沒有設定責任，只是幫忙，所以才發生了組織結構的變化。
在建立師徒制度後，師傅們將對小組的成敗包括質量負責。實際上，新人的流動率很高，如果留下垃圾**，還是要師傅來維護，所以師傅「被迫」很盡責。師傅們普遍的做法是不只在最後才審查**——因為那時候肯定面臨乙個爛攤子——而是在前期就指導徒弟編出良好的**，乃至在更早的時間點介入，做出良好的設計。
這些制度後來演化成松結對程式設計方法。
第二個專案則是本人做度量最仔細的乙個專案。
原因是在離開上一家公司後，我去了乙個測試人員眾多的企業，但其產品質量卻奇差無比，甚至導致後來乙個產品被放棄，40人因此離職。所以萌生了乙個念頭，就是仔細度量一下缺陷是怎麼來的，又是怎樣被發現的。
針對這個專案有乙個100多個檢查項的**檢查表，每天對**進行30～60分鐘的**檢查。在整個專案過程中一共有240多個缺陷，不過只有6個發現於系統測試期，9個發現於與硬體的整合測試，63個來自於除錯（就是完成編譯到按下f5除錯成功中發現的問題，一般大家都是不記錄的，但這個專案中也被記錄下來），剩下的有112+53個來自於「看**」（有自查和後查兩種形式），這個專案沒有單元測試活動。
大致結論是只有微乎其微的缺陷是由測試活動發現的，而剩下的缺陷則是由開發活動發現的。
這個專案的資料還揭示出一些有價值的資訊：
1. 開發人員可以有效地降低總缺陷率
在為期27天的編碼期（這個專案是瀑布式開發）中，千行**的總缺陷率趨勢從第一天的130/千行降低到最後一天的60/千行，說明若開發人員能潛心消除缺陷，那麼在很短的時間裡就能大幅降低自己**的總缺陷率；極少有測試活動能做到類似的效果。
2. 「所有缺陷無需測試活動即可消除」
下面是當時的「過程效益」分析，所謂過程效益，就是某個過程對消除缺陷的能力。比如如果說「除錯」的過程效益是40%，就是說如果有100個缺陷到達除錯環節，除錯中會發現其中40個，而60個會被漏到後面去。圖中的藍線就是「除錯」的過程效益，注意前期的除錯缺陷經常很低，表明「除錯起來一切正常，但是一測試就發現很多問題」；後期的除錯效益經常是100%，這個意思是說在完成除錯（就是f5）後，之後再也沒有任何人、任何活動從這天編寫的**中發現任何缺陷。
確切說系統測試的6個缺陷，全部發現於前13天的**中；換一種說法：如果全程都能像後13天一樣編寫**，系統測試的缺陷將為0。
「所有缺陷無需測試活動即可消除」這句話被打上引號，是因為它是一種很理想的狀態。但是與「所有缺陷可以被某種測試活動消除」相比，我更相信前者。
3. 程式設計人員可以訓練出行之有效的排除缺陷的手段
「自查」的過程效益始終沒有達到100%，但是它與除錯的作用越來越互補。比如在初期自查+除錯後，還有大量缺陷被發現（所以除錯的效益很低）；但如果每天仔細分析自己自查發現的缺陷和除錯發現的缺陷，就可能在短短乙個半月的時間內大幅度提公升自身發現缺陷的能力，乃至於到達不把缺陷留給測試環節，更不會留給客戶的程度。
從上面圖中的資料可以看出來，這個專案的質量不是由乙個「能力很強的人」保證的，因為剛開始除錯後還是有很多缺陷會留給測試活動發現，只是後來的訓練導致了能力的增強。因此人的因素有，但是不是絕對的。
這些專案揭示出來的規律是：程式設計師應該負責產品質量，他們有能力，也有時間。
第乙個專案並沒有因為「程式設計師還要負責質量」而耽誤進度或造成功能「太少」影響到市場競爭力；第二個專案甲方後來坦然說「原定計畫一年，沒想到三個半月就結束了」（此前他們自己曾經嘗試2個人研發過一年，此外也了解另外兩家競爭對手投入的情況）。
很多人一定認為上述經驗有很大的侷限性，比如對個人能力的要求很高，其實不然。第乙個專案中，那些剛畢業的本科生和研究生與今天動輒工作5、6年乃至10年的程式設計師的水平不可同日而語；第二個專案中我本人當時工作經驗也只有8年，其中做職業程式設計師的時間則只有4～5年左右，編碼量僅在2萬行左右。
所以關鍵還是方法，而不是人；或者說是「使用正確方法的人」就足夠了，「使用正確方法的正確的人」不是乙個強制條件。
在後續的章節中，會談到如何在一般情況下，推行這些方法。
此外還會提到，在這種方法大行其道的時候，專業的測試團隊是否還有必要存在，以及還有「什麼用」，以及應該如何工作。
敏捷開發團隊管理系列之四 程式與測試團隊III
這是敏捷開發團隊管理系列的第四篇。之一，之二，之三，之四 整體上有兩種測試團隊的模型，既然都有存在，自然是各有各的道理。城裡城外的人倒不必互相羨慕，只是要觀察對面的優點，分析自己的缺點，嘗試做點事情補償一下。所以，下面多說一點各自的壞處。這個就是著名的與程式團隊打架的測試團隊。好處 獨立團隊，還是能...
敏捷開發團隊管理系列之四 程式與測試團隊III
這是敏捷開發團隊管理系列的第四篇。之一，之二，之三，之四 整體上有兩種測試團隊的模型，既然都有存在，自然是各有各的道理。城裡城外的人倒不必互相羨慕，只是要觀察對面的優點，分析自己的缺點，嘗試做點事情補償一下。所以，下面多說一點各自的壞處。這個就是著名的與程式團隊打架的測試團隊。好處 獨立團隊，還是能...
敏捷開發團隊管理系列之一 序言與出發點
這是敏捷開發團隊管理系列的第二篇。之一，之二，之三，之四 之前的各個系列中，已經涉及了很多團隊管理相關的內容，比如松結對程式設計系列中提到過大型團隊分拆為微觀開發團隊的管理，產品管理系列中提到過product owner團隊的管理，敏捷開發績效管理系列中提到過 用中醫理論管理團隊 敏捷開發般若敏捷系...