什么是敏捷開發？
目前互聯網行業已占領軟件行業的半壁江山，越來越多的企業開始實施敏捷研發。那么什么是敏捷開發呢？
簡而言之，敏捷開發就是一種以人為核心，迭代循序漸進的開發方式。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成功都經過測試，具備集成和可運行的特征。而敏捷開發離不開迭代，迭代就是我們所說的一個子項目或者一個版本，通常一個迭代是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經過協商會更改部分需求，但是變更的需求沒有及時同步至測試相關人員，直至測試時才發現這個需求已經變更。
出現這個問題原因有：整個項目開發團隊人員比較分散，如果需求變更比較多，導致遺漏部分變更的需求；這個時候就需要產品和項目經理以及研發和測試人員及時同步需求變更問題。需求變更的源頭是產品經理而最終測試必須通知測試人員。所以需要相關負責人建立一套完整的需求變更反饋機制，不能遺漏任何一個環節。
延遲提測時間
研發提測時間的推遲，最直接的結果是如果無法延期上線時間，導致測試時間不充分，則軟件的質量可能會出現一些無法預測的問題。這里延遲轉測可能有以下原因：
- 研發過程發現需求缺陷，增加需求或變更需求比較大
- 測試用例編寫過程發現需求缺陷，增加需求或變更需求比較大
- 產品中間插入緊急用戶新需求，影響了整個迭代的開發進度
- 線上版本出現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團隊而言，需要不同維度協調提高團隊協作能力。敏捷開發團隊每個人都要有主動溝通和協作的意識，測試要樹立正確的敏捷測試觀念，整個團隊要以積極的心態擁抱變化。
部分內容摘自慕課網