背景
團隊採用敏捷開發已經一年時間了，剛開始半年隨著團隊成員之間的磨合以及技術的熟悉，開發的效率確實逐漸在提升，所以自認為團隊上路了只會原來越好，誰想到後面團隊沒有進步，反而退步得厲害。
一、何時發現產品質量這個問題？
在指導對接監管平臺的過程中突然發現產品質量已經下降得如此厲害，隨便列出幾項：
- 1）監管平臺匯入頻次、用法、劑型、診斷等字典資料都沒有驗證一下程式，後面一跑流程很多功能都用不了。
- 2）上傳到監管平臺的科室、醫生、病人、病歷、處方、診斷都沒有關聯起來，沒有人提出這個問題。
- 3）產品封版迭代中，盡然一下冒出140多個BUG。
總結：產品一定把關故事質量，SM把關技術質量，一起合作細化故事的驗收條件。測試用例一定要覆蓋全面。
二、分析造成這種現象的原因？
1、團隊產品質量下降的過程
- 1）每個人都有偷懶的心態，能簡單完成，肯定不會花太多時間去深入思考。這時候如果SM沒有及時發現並糾正過來，這時候就出現一個破窗戶，一段時間下來基本上整個街道的窗戶都會出現破損。大家就這樣養成了偷工減料的習慣。
- 2）本來測試是把控質量這道關，但是隨著這種低階的BUG越來越多，大量佔用了他的時間，那他肯定也就慢慢降低了對質量的要求。
- 3）然後就團隊一起拿這個質量來應付產品經理，產品經理也沒有辦法了。
2、初步分析解決方案
- 1）靠外部力量來改變或者加強監督，不是好辦法，最好的辦法自己找到自己的問題，以及自己的解決方案。
- 2）收集資料，定義好質量的標準，形成制度。
- 3）《BUG分析總結會議》
- 4）《績效扣分加分制度》
- 5）《每月一次的績效面談與簽字》
三、解決過程
1）組織團隊PO、SM會議，提出團隊問題，討論結果：
- 1、定期組織產品培訓、產品規劃、技術培訓，產品培訓由測試主講，產品規劃由PO主講，技術培訓由SM主持。
- 2、SM對於設計把關一定要當擔起責任，一定要識別出那些負責設計，影響面廣的設計，組織討論要評審後才能做。另外調動起團隊參與設計評審的積極性，這樣才能識別出更多的設計問題。
2）參加團隊早會，提出新的早會制度
規範每日站會的流程
- 1、大家講
三句話，昨天做了什麼，今天準備做什麼，有什麼難點；大家圍成一圈順時針輪流講，講的時候不需要看電腦；有難點先不討論只是提出來；
- 2、SM提問
大家講完後，SM針對看板上延期的故事和任務提問，一定要找到延期的原因和解決辦法。
- 3、會後難點討論
最後，有難點的成員留下來討論一下，找出解決辦法。
3）參加團隊迭代總結會議，重點總結了產品質量產生的原因
- 1、需求反覆
- 2、開發不熟悉不是自己編寫的那塊程式碼或業務，在不熟悉的程式碼上增加新功能導致產生很多bug
- 3、測試在迭代中覆蓋不全面，加強自動化測試，分析bug產生原因，反過來要求開發提升
- 4、態度問題，不是自己的事情不做自己的任務不考慮細緻深入，應付式的完成，包括開發測試都這樣
- 5、開發分析問題要找到根本原因，而不是直接打個補丁。
4）組織BUG分析總結會議，重新定義BUG分類
- 1、開發不應該犯的BUG
- 粗心大意
- 邏輯不嚴謹
- 反覆出現
- 2、值得總結的BUG
- 設計不合理
- 業務不熟悉
- 經驗不足
5）績效面談與簽字
- 1、扣分加分明細表
- 2、績效表簽字
- 3、意見反饋收集
四、總結
根據這段時間的觀察和改進，總結出3點來提升我們團隊的產品質量；
1、收集資料，所有的問題都要進禪道管理，並對這些問題進行分類。
2、BUG分析總結會，每個迭代後，有測試組織對本次迭代中產生的BUG進行分析與總結，提出改進建議。
3、績效面談與簽字，月底SM跟團隊每個人進行績效面談，包括本月員工取得的成績、優點與不足、改進措施。
附件：
1、績效扣分加分制度：
1、迭代故事沒有完成扣績效
2、迭代後bug沒有處理完成扣績效
3、程式碼評審發現問題扣績效
4、每次迭代之後進行一次產品演示，發現問題扣績效，開發測試都扣
5、迭代之星加績效
6、給團隊培訓加績效
7、熱心為團隊做了技術服務加績效
8、主動發現產品問題並登記進禪道加績效
2、日常注意事項：
A、早會上不要講一些很空洞的問題，不要等他們自己解決，要把問題具體化，並找到解決方案。
B、測試所有問題要登禪道，除了發群裡，這樣今天沒有解決的bug在明天早會上過，並給出解決方案。
C、一個團隊是否優秀主要看SM，所以SM不要承擔太多的雜活，可以培養一個開發分擔這些技術雜活。
3、文件：網際網路醫院迭代17產生BUG分析.note
4、網際網路醫院團隊績效分數統計