總結：敏捷開發的愚見

什麼是敏捷開發？

目前互聯網行業已佔領軟件行業的半壁江山，愈來愈多的企業開始實施敏捷研發。那麼什麼是敏捷開發呢？

簡而言之，敏捷開發就是一種以人爲核心，迭代按部就班的開發方式。在敏捷開發中，軟件項目的構建被切分紅多個子項目，各個子項目的成功都通過測試，具有集成和可運行的特徵。而敏捷開發離不開迭代，迭代就是咱們所說的一個子項目或者一個版本，一般一個迭代是3周左右，每3周進行一次上線包括需求開發、測試和上線。

圖中就是一個完整的迭代過程當中項目經理、PO、研發和測試整個Scrum team的工做流程。首先是PO組織相關Scrum人員進行迭代需求評審，而後是Scrum團隊中的研發人員進行研發的過程，這個過程通常持續2周左右；在研發的過程當中測試須要完成這個迭代的用例編寫；而後是研發人員轉測，測試人員執行用例，這個時間大概一週左右，測試人員完成測試工做，PO驗證完成這個迭代進行上線。在規劃的全部迭代完成以後，會產出一個最終的產品軟件，這個時候交付客戶，進行線上驗證和後期推廣等操做。

在敏捷開發中測試如何工做？

在互聯網企業中，每一個測試都要求獨當一面。一我的經常負責一個單獨的模塊或多個模塊。互聯網發展快的特性使得企業爲了快速響應需求，上線要求週期短並且發佈頻繁。互聯網易變的特性使得愜意需求變動成爲老生常談。

此外，負責的模塊會常常變化，負責的需求人員、研發人員及測試人員也會變化，最終致使咱們制定或參與的測試計劃也會常常變化。在互聯網這個大環境下，咱們更須要自我管理，自我計劃的能力。

這時候，須要執行測試計劃，須要經過計劃去管理變化，將風險降至最低，以至於能夠將風險扼殺在搖籃中。

從下面這張圖中咱們能夠看到敏捷開發的核心是擁抱變化和遞增變化。

在敏捷開發中，測試的工做是貫穿始終的，在需求階段測試已經介入工做進行需求的合理性驗證。在完成需求評審以後，測試須要根據需求規格說明書和原型完成測試計劃，而後採用合理的測試策略進行測試用例設計。在開發人員進行研發的過程當中，相關測試人員同步進行需求的用例編寫，這個過程也是不斷了解需求，完善需求的過程。

通常通過兩週左右的開發，在第二週週四左右，測試會提供這個迭代的測試用例給開發人員，研發人員須要根據測試用例的優先級和重要性，將需求中已經實現的功能進行自測，不斷完善代碼，自測經過以後，將於週五進行轉測申請提交，至此這個迭代的工做重心將從研發人員轉職測試人員，變爲測試爲主。

這個時候測試人員會根據測試計劃和項目約定的要求，採用2+2+1的模式執行測試用例。

這裏的2+2+1模式是對於上線迭代的此需求，須要測試進行3輪測試任務。

第一輪：完成此迭代涉及到的全部需求的測試用例的執行(根據不一樣項目狀況，須要執行的測試分爲接口測試、功能測試、性能測試、兼容性測試等)。

第二輪：完成該迭代的bugs的迴歸操做，而且保證全部上線功能的bug中等級別以上bug所有修復，bug等級低或者其餘UI、易用性問題能夠根據項目時間安排儘可能在本迭代內完成修復。

第三輪：第二輪bugs迴歸完成以後，進行的第三輪則主要是產品和UI驗收階段。

PO和UI驗收完成以後則進行上線發佈階段。這個時候須要郵件通知相關項目干係人進行線上部署、發佈以及驗證和後期推廣等操做。

通常在項目結束以後，須要項目管理者和PO以及Scrum team人員總結這次迭代中的經驗和教訓，不斷完善、提升整個團隊的合做能力。

至此，在敏捷開發中，一個完整的迭代就這樣結束了。這裏舉例的模式是2+2+1，不一樣的項目不一樣的迭代功能須要根據項目實際狀況進行合理安排測試的時間，具體問題具體對待。若是說整個迭代的功能需求多，那可能採起的是3+2+1，或者其餘更好的方法。

上面說明的敏捷開發中整個迭代是3周，最後一週須要測試、研發修復bugs和驗證驗收以後進行上線發佈、驗證；可是有些狀況下，可能整個項目劃分了N個迭代，而每一個迭代的時間緊，任務重；這個時候可能就沒有一個完整的一週時間留給測試和研發人員進行bugs的修復工做，這個時候在第三週開發進行第二個迭代的研發功能，測試執行第一個迭代的用例，須要研發人員合理安排時間進行bugs修復和第二迭代的研發。整個項目計劃中必須留出足夠的時間給測試人員完成用例的執行，不能壓縮測試人員的工做時間；因此這個時候就是考驗項目管理者和PO的時候，須要合理安排計劃。

敏捷開發中遇到的問題？

對於敏捷開發而言，需求的變化、人員的變化會致使出現各類問題。

迭代需求變動不一樣步

前面說了，敏捷的核心原則就是變化，因此敏捷開發中需求變動會很頻繁。常常是研發過程當中發現某一需求實現和以前的功能衝突，這個時候研發和PO通過協商會更改部分需求，可是變動的需求沒有及時同步至測試相關人員，直至測試時才發現這個需求已經變動。

出現這個問題緣由有：整個項目開發團隊人員比較分散，若是需求變動比較多，致使遺漏部分變動的需求；這個時候就須要產品和項目經理以及研發和測試人員及時同步需求變動問題。需求變動的源頭是產品經理而最終測試必須通知測試人員。因此須要相關負責人創建一套完整的需求變動反饋機制，不能遺漏任何一個環節。

延遲提測時間

研發提測時間的推遲，最直接的結果是若是沒法延期上線時間，致使測試時間不充分，則軟件的質量可能會出現一些沒法預測的問題。這裏延遲轉測可能有如下緣由：

1. 研發過程發現需求缺陷，增長需求或變動需求比較大
2. 測試用例編寫過程發現需求缺陷，增長需求或變動需求比較大
3. 產品中間插入緊急用戶新需求，影響了整個迭代的開發進度
4. 線上版本出現bug，緊急修復

針對問題1和2，則須要PO在定義需求時，更加嚴謹，並且研發人員在制定計劃時，要仔細拆分各個功能點，每一個功能點的實現方式作到成竹在胸。

這樣即便再次出現問題1和2，也不會是大的需求變動，相對增長的工做量都在可控範圍內。

針對問題3，咱們須要創建一套適合的用戶反饋需求的機制。項目經理和PO須要根據當前迭代的任務量適當處理用戶的緊急需求。

針對問題4，對於線上版本的bug修復，須要根據bug的嚴重和影響程度以及修復成本，確認是否修復。對於影響和嚴重級別比較高的bug，則必須立刻修復。因此若是出現此類程度的bug則須要測試人員自查，確認bug產生的緣由是漏測仍是環境配置形成的問題，須要測試人員在之後的測試中關注此類問題，避免再次出現此類bug。

需求理解不一樣致使上線延遲

產品提出的需求可能描述不清晰，致使研發和測試執行過程當中沒有發現此類需求功能缺陷，直到產品驗收時才發現此需求實現有問題，沒有達到產品的預期，這個時候的修復成本就比較高。

這裏就須要產品在評審時明確需求說明書和原型中的每個功能點，而研發和測試在評審和研發以及測試執行過程當中有任何疑問都要及時提出來，不能想固然。

管理工具使用不一樣步形成時間成本增長

目前使用的項目管理工具是JIRA和confluence，一般產品的需求在confluence上會有一份功能點說明和原型圖連接地址，而在JIRA上是各個功能任務詳細說明和開發分配拆分的子任務。而變動需求只會在JIRA中標記，confluence中又不會出現變動的需求功能點。而測試和開發人員又是以confluence爲主，JIRA對於開發人員而言就是拆分子任務和關閉分配的任務的工具，對於測試人員而言，在提交bug時會使用JIRA。

實際上這也是致使需求變動不一樣步和延期的一個緣由，增長了產品、開發和測試的溝通成本，因此在項目開始時須要根據狀況肯定項目的使用工具，以避免出現此類問題。

溝通問題

在敏捷開發中，項目經理、PO等Scrum team須要明確本身的工做職責，項目經理和PO要作好各方面的溝通協調工做，使得測試更集中精力執行測試工做，而開發則專一於研發工做，提升工做效率，下降無效溝通。

以上就是整個敏捷開發團隊中所遇到的問題，對於項目管理、PO整個Scrum team團隊而言，須要不一樣維度協調提升團隊協做能力。敏捷開發團隊每一個人都要有主動溝通和協做的意識，測試要樹立正確的敏捷測試觀念，整個團隊要以積極的心態擁抱變化。

部份內容摘自慕課網