如何提高團隊速率、保證產品質量和提高團隊積極性？

背景

團隊採用敏捷開發已經一年時間了，剛開始半年隨着團隊成員之間的磨合以及技術的熟悉，開發的效率確實逐漸在提高，因此自認爲團隊上路了只會原來越好，誰想到後面團隊沒有進步，反而退步得厲害。

1、什麼時候發現產品質量這個問題？

在指導對接監管平臺的過程當中忽然發現產品質量已經降低得如此厲害，隨便列出幾項：

• 1）監管平臺導入頻次、用法、劑型、診斷等字典數據都沒有驗證一下程序，後面一跑流程不少功能都用不了。
• 2）上傳到監管平臺的科室、醫生、病人、病歷、處方、診斷都沒有關聯起來，沒有人提出這個問題。
• 3）產品封版迭代中，盡然一下冒出140多個BUG。

總結：產品必定把關故事質量，SM把關技術質量，一塊兒合做細化故事的驗收條件。測試用例必定要覆蓋全面。

2、分析形成這種現象的緣由？

一、團隊產品質量降低的過程

• 1）每一個人都有偷懶的心態，能簡單完成，確定不會花太多時間去深刻思考。這時候若是SM沒有及時發現並糾正過來，這時候就出現一個破窗戶，一段時間下來基本上整個街道的窗戶都會出現破損。你們就這樣養成了偷工減料的習慣。
• 2）原本測試是把控質量這道關，可是隨着這種低級的BUG愈來愈多，大量佔用了他的時間，那他確定也就慢慢下降了對質量的要求。
• 3）而後就團隊一塊兒拿這個質量來應付產品經理，產品經理也沒有辦法了。

二、初步分析解決方案

• 1）靠外部力量來改變或者增強監督，不是好辦法，最好的辦法本身找到本身的問題，以及本身的解決方案。
• 2）收集數據，定義好質量的標準，造成制度。
• 3）《BUG分析總結會議》
• 4）《績效扣分加分制度》
• 5）《每個月一次的績效面談與簽字》

3、解決過程

1）組織團隊PO、SM會議，提出團隊問題，討論結果：

• 一、按期組織產品培訓、產品規劃、技術培訓，產品培訓由測試主講，產品規劃由PO主講，技術培訓由SM主持。
• 二、SM對於設計把關必定要當擔起責任，必定要識別出那些負責設計，影響面廣的設計，組織討論要評審後才能作。另外調動起團隊參與設計評審的積極性，這樣才能識別出更多的設計問題。

2）參加團隊早會，提出新的早會制度

規範每日站會的流程

• 一、你們講

三句話，昨天作了什麼，今天準備作什麼，有什麼難點；你們圍成一圈順時針輪流講，講的時候不須要看電腦；有難點先不討論只是提出來；

• 二、SM提問

你們講完後，SM針對看板上延期的故事和任務提問，必定要找到延期的緣由和解決辦法。

• 三、會後難點討論

最後，有難點的成員留下來討論一下，找出解決辦法。

3）參加團隊迭代總結會議，重點總結了產品質量產生的緣由

• 一、需求反覆
• 二、開發不熟悉不是本身編寫的那塊代碼或業務，在不熟悉的代碼上增長新功能致使產生不少bug
• 三、測試在迭代中覆蓋不全面，增強自動化測試，分析bug產生緣由，反過來要求開發提高
• 四、態度問題，不是本身的事情不作本身的任務不考慮細緻深刻，應付式的完成，包括開發測試都這樣
• 五、開發分析問題要找到根本緣由，而不是直接打個補丁。

4）組織BUG分析總結會議，從新定義BUG分類

• 一、開發不該該犯的BUG
  • 粗枝大葉
  • 邏輯不嚴謹
  • 反覆出現
• 二、值得總結的BUG
  • 設計不合理
  • 業務不熟悉
  • 經驗不足

5）績效面談與簽字

• 一、扣分加分明細表
• 二、績效表簽字
• 三、意見反饋收集

4、總結

根據這段時間的觀察和改進，總結出3點來提高咱們團隊的產品質量；

一、收集數據，全部的問題都要進禪道管理，並對這些問題進行分類。

二、BUG分析總結會，每一個迭代後，有測試組織對本次迭代中產生的BUG進行分析與總結，提出改進建議。

三、績效面談與簽字，月底SM跟團隊每一個人進行績效面談，包括本月員工取得的成績、優勢與不足、改進措施。

附件：

一、績效扣分加分制度：

一、迭代故事沒有完成扣績效

二、迭代後bug沒有處理完成扣績效

三、代碼評審發現問題扣績效

四、每次迭代以後進行一次產品演示，發現問題扣績效，開發測試都扣

五、迭代之星加績效

六、給團隊培訓加績效

七、熱心爲團隊作了技術服務加績效

八、主動發現產品問題並登記進禪道加績效

二、平常注意事項：

A、早會上不要講一些很空洞的問題，不要等他們本身解決，要把問題具體化，並找到解決方案。

B、測試全部問題要登禪道，除了發羣裏，這樣今天沒有解決的bug在明天早會上過，並給出解決方案。

C、一個團隊是否優秀主要看SM，因此SM不要承擔太多的雜活，能夠培養一個開發分擔這些技術雜活。

三、文檔：互聯網醫院迭代17產生BUG分析.note

四、互聯網醫院團隊績效分數統計