團隊採用敏捷開發已經一年時間了,剛開始半年隨着團隊成員之間的磨合以及技術的熟悉,開發的效率確實逐漸在提高,因此自認爲團隊上路了只會原來越好,誰想到後面團隊沒有進步,反而退步得厲害。html
在指導對接監管平臺的過程當中忽然發現產品質量已經降低得如此厲害,隨便列出幾項:測試
總結:產品必定把關故事質量,SM把關技術質量,一塊兒合做細化故事的驗收條件。測試用例必定要覆蓋全面。spa
規範每日站會的流程設計
三句話,昨天作了什麼,今天準備作什麼,有什麼難點;你們圍成一圈順時針輪流講,講的時候不須要看電腦;有難點先不討論只是提出來;3d
你們講完後,SM針對看板上延期的故事和任務提問,必定要找到延期的緣由和解決辦法。htm
最後,有難點的成員留下來討論一下,找出解決辦法。blog
##4、總結開發
根據這段時間的觀察和改進,總結出3點來提高咱們團隊的產品質量;文檔
一、收集數據,全部的問題都要進禪道管理,並對這些問題進行分類。產品
二、BUG分析總結會,每一個迭代後,有測試組織對本次迭代中產生的BUG進行分析與總結,提出改進建議。
三、績效面談與簽字,月底SM跟團隊每一個人進行績效面談,包括本月員工取得的成績、優勢與不足、改進措施。
一、績效扣分加分制度:
一、迭代故事沒有完成扣績效
二、迭代後bug沒有處理完成扣績效
三、代碼評審發現問題扣績效
四、每次迭代以後進行一次產品演示,發現問題扣績效,開發測試都扣
五、迭代之星加績效
六、給團隊培訓加績效
七、熱心爲團隊作了技術服務加績效
八、主動發現產品問題並登記進禪道加績效
二、平常注意事項:
A、早會上不要講一些很空洞的問題,不要等他們本身解決,要把問題具體化,並找到解決方案。
B、測試全部問題要登禪道,除了發羣裏,這樣今天沒有解決的bug在明天早會上過,並給出解決方案。
C、一個團隊是否優秀主要看SM,因此SM不要承擔太多的雜活,能夠培養一個開發分擔這些技術雜活。
三、文檔:互聯網醫院迭代17產生BUG分析.note
四、互聯網醫院團隊績效分數統計
原文出處:https://www.cnblogs.com/kakake/p/11144488.html