概述
最近公司使用敏捷中的雙週迭代，也即是每兩個星期發佈一次應用。雙週迭代是控制團隊交付節奏的，但是如果玩的不好，會導致大量的線上bug。先講一下我們之前遇到的一個雙週迭代問題。
產品需求提出後，我們研發這邊開始分析需求，輸出user story，並估算故事點。這個階段的時間是非常短的，一般就一天，爲啥呢？因爲是雙週發佈上線一次，因此測試人員會根據上線時間進行倒推，要求開發在哪一天必須提測，不然上線就有風險。因此就形成了一個惡性循環，開發分析任務時間短、開發時間短，自測時間短，與前端聯調的時間短，測試人員的測試時間也短，但是爲了那個人爲設定的deadline，只能加班加點的搞。到了最後上線的時候，經常出現了各種線上故障。
對這樣的病態雙週迭代流程，我是強烈抗議的，我們做軟件，質量是第一位的，開發質量不行了，就會影響後續的整個流程，整條鏈路都會非常的累和忙。
但是這個是老闆定的流程哦，我們應該如何處理呢？答案是對上思辨，並不是老闆的定的東西就是對的，可能之前他在其他公司，用過這個方法，成功了。但是這種只是階段性成功，在當前公司的實際場景下，確未必是適用的。
由於公司有個聚合層單體應用，在上面開發的程序員有幾十號人，稍有不慎，線上就頻繁出現問題，因此，當前的首要任務是降低線上故障數量，保證系統穩定性，這個是最迫切需要解決的，而雙週迭代對此毫無幫助，且會由於開發時間短，造成更多的故障。
後面我們換了一種方式，給開發留足估算任務的時間，儘量的瞭解任務細節後，輸出故事點，然後纔開始排期，並且把單元測試、自測、前後端聯調，code review都作爲一個任務，這樣子，才能儘量保證提測的東西質量好，從而也提高的測試人員的測試效率。
執行了幾次後，每次上線，故障都基本沒有。
雙週迭代的另外一種運行方式
如果你一定要保持雙週一發布的節奏，那麼你可以嘗試這樣來玩，第一個雙週迭代，就是給開發人員用的，也即是，有兩週的開發時間，在這兩週內提測任務，然後測試人員在下個雙週迭代測試上個雙週迭代的任務，這樣，測試人員也有兩個星期的測試時間。
這樣的話，就不會造成整條鏈路都非常忙，測試人員使勁來催的事情了。