來這家公司一直是做敏捷迭代的，在這麼長的時間，對敏捷也有一些初步的認識

 一個完成的敏捷開發從需求確認到開發到整個迭代結束的一個週期，包括蒐集需求，需求方的優先順序評審（當然這些不需要我們測試參與），產品框圖的準備，產品組的內部評審，技術可行性的評估（這時就需要測試的參與），然後就是prd的編寫，框圖的交付等等，然後再次交給產品leader評審，評審過後及開產品衝刺會，然後技術開發，測試，上線。。。。

但是在敏捷開發過程中進場出現的一些問題：

   1 產品每個迭代都會加一些需求，這時增加需求首先就得評估工期，並且每個迭代增加的需求涉及到的產品，開發，測試，task，工作量都有相關記錄。至於好處個人認為可以在每個迭代的總結會上提出，1 減少後期迭代需求的增加，2 明白每個迭代對應負責人增加的工作量

   2 對於一個專案多個分組溝通的情況： 同一個專案組多個分組，以至於經常會出現多個組改一個模組的東西，不同需求改動一個功能不能同步，導致程式碼冗和容易出錯

    出現問題：一個小組改同一個模組的功能導致小組間的測試一直有問題：

        解決辦法：1 各組產品在需求評審時儘量都在一起。特別是涉及到同一大塊的模組功能探討清楚

                           2 各個小組的master及時溝通，並發現問題

                           3 開發在修改別人的模組的程式碼時儘量先溝通，提前瞭解一些注意事項，減少無所謂的bug

   3  對於專案開始中刪除和增加功能，都得發到群裡，讓大家周知並督促產品更新prd

   4 如何提高敏捷測試的效率：工程效率是每個大公司都比較重視的一點，當然最關鍵的一點就是提高提測質量，如何提高提測質量目前來說：就是制定CC及時率和通過率的標準並嚴格執行CC通過率和及時率，並在每天日報更新並標記不通過原因同時加上負責該功能更的開發

  5 對於專案風險的把控：敏捷對與專案風險的把控不想普通開發，講究的是一個快，所以很多東西來不及打磨就上線了，所以測試就得每天吧可能存在的風險在每天的早會和日報裡面提出來，爭取規避，並對每個迭代的出現的漏測bug輸出原因及總結並存檔，

 6 關於需求，可能有的需求不合理，有的需求冗餘，對於這種需求，儘量及時提出來，最好通過溝通把這些沒必要的需求砍掉。

7在開發過程中，開發實現方法與產品要求的不一致，可能大多數是基於技術實現的問題。關於這種需求，及實現方案和風險，也要記錄下來。

8.合理的拆分task，API的儘量排在客戶端之前，留給開發聯調時間。每個task要有優先順序。如果API不能排在客戶端之前，要跟開發溝通，如何通過mock來測試

9 有的專案需求非常的複雜，這些東西一定要讓產品給開發和測試及時梳理出邏輯。最好能在立項的時候就把這個邏輯給大家梳理出來。在專案過程中，遇到產品prd文件沒寫，但是現實的邏輯，需要做出來的，這些東西，不急，甩給產品。

10 越來越覺得專案的把控，進度的把控，風險的把控的重要程度完全不亞於技術

11 對於專案的排期：一個好的排期對測試也是很有幫助的，一般在開發排完後，負責相關功能模組的的測試及時反饋排期是否合理，比如api排期比和客戶端和FE晚，這樣依賴介面的功能排期最好相互對照一下，尋找折中的時間。如果優先順序不高可跟開發溝通是否可使用mock測試，相信辦法總比困難多