目前網際網路行業已占領軟體行業的半壁江山，越來越多的企業開始實施敏捷研發。那麼什麼是敏捷開發呢？
簡而言之，敏捷開發就是一種以人為核心，迭代循序漸進的開發方式。在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成功都經過測試，具備整合和可執行的特徵。而敏捷開發離不開迭代，迭代就是我們所說的乙個子專案或者乙個版本，通常乙個迭代是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團隊而言，需要不同維度協調提高團隊協作能力。敏捷開發團隊每個人都要有主動溝通和協作的意識，測試要樹立正確的敏捷測試觀念，整個團隊要以積極的心態擁抱變化。
部分內容摘自慕課網
敏捷開發 Scrum 總結
最近把之前學習 scrum 的資料整理為一篇文件，在接下來的團隊和專案開發中，根據專案的情況引入 scrum 的一些實踐，提高團隊成員之間的協作能力和專案的交付質量。參考資料 scrum 工具 scrum 中的角色 scrum master 專案負責人 專案經理 保護團隊不受外界干擾，是團隊的領導和...
敏捷開發流程總結
agile 敏捷開發，作為cmm神話崩潰後被引入的一套新的軟體開發模式，這幾年來被廣泛引起關注，並被寄予厚望。敏捷開發在其他業界的應用是否理想不得而知，但以下總結了我所在公司的敏捷開發試驗，希望可以達到管中窺豹的目的。敏捷開發宣言 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 ...
敏捷開發學習筆記 總結
我好像還沒有完全踐行過敏捷開發。不過這段時間一通學習下來，結合以往的一些經歷，認為敏捷的精髓在於多職能團隊和迭代思想。1 多職能團隊 意味著團隊成員參與了整個專案的絕大部分工作 任務領用 需求分析 設計及開發 測試 評審。比如，需求分析，以往都是由乙個所謂系統分析員來寫 而在敏捷裡，是由產品經理在計...