? ? 這篇文章本該幾個月前就發(fā)，實習這么久來，實習的第一份工作是傳統的大瀑布模型的項目，但是團隊也是在搞敏捷迭代開發(fā)，所以也算是敏捷團隊吧，那么這篇文章就聊一聊敏捷。

為什么要搞敏捷？

這就要說下傳統的大瀑布的不足

? ? 1.在開發(fā)中，如果有需求變更，那么變化會很大，可能之前開發(fā)的都要去重構，成本很高，響應變化困難

? ? 2.開發(fā)完成后，PM才能看到項目的最終結果，在開發(fā)中，PM是看不到項目的全貌的，而且可能連模塊級別的都無法看到，項目末期才能看到項目全貌

? ? 3.如果項目有延期風險，都是在最終快結項時才會暴露出來，應對風險能力差

敏捷宣言：

? ? 個體和互動 高于 流程和工具

? ? 工作的軟件 高于 詳盡的文檔

? ? 客戶合作 高于 合同談判

? ? 響應變化 高于 遵循計劃

? ? 百度百科對敏捷的解釋是：敏捷開發(fā)以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發(fā)。

? ? 我所在的團隊使用的是Kanban方法，每天早晨9點30準時開站會，站會內容大概如下：

? ? ? ? 1.回顧昨天做了什么

? ? ? ? 2.今天要做什么

? ? ? ? 3.有什么風險

? ? ? ? 4.需要協調什么資源

? ? 站會發(fā)言順序可以按職能來，產品—數據—前端—后端—測試

? ? 站會發(fā)言順序也可以按模塊來，eg:登錄注冊功能—好友功能—朋友圈功能—個人信息功能

? ? 具體怎么安排可以由leader去決定，每個角色按照站會內容去發(fā)言，會議中每個人要精簡發(fā)言，控制發(fā)言時間，有歧義可以會后單獨拉小會去討論。

? ? 敏捷這個概念一直都有，但是近幾年國內的團隊才開始轉型敏捷，我所在的公司是有專門的敏捷教練，但敏捷教練不是一個團隊一個，而是一個敏捷教練對應多個敏捷團隊，教練定期給不同的團隊leader做敏捷培訓，再由團隊leader去實施敏捷，這一定程度上也限制了敏捷實施的效果，因為敏捷教練并不是針對性的去對某一個團隊做培訓，而是通過各個團隊的共性來制定的敏捷方案，所以最終可能會是不同的團隊會有不同的效果。

1.在敏捷這種節(jié)奏下，作為QA該如何去應對呢？

? ? 很多人認為團隊搞敏捷就是去快速迭代，兩周一迭代或者一周一發(fā)版，但是敏捷≠快，敏捷講究的是顆粒度，任務的顆粒度，模塊的顆粒度，我所理解的就是小瀑布，既然都是瀑布模型，那還是按著瀑布來走，不過是按顆粒度分。那么QA也應該要去適應這種節(jié)奏，開發(fā)的同時可以提前介入測試，梳理出測試case，并且提前準備好測試數據+測試環(huán)境，按照提測的模塊來進行測試，提測多少就測多少，QA要有自己的測試節(jié)奏，今天提測哪些模塊，測試進度要完成到多少，如果今天測試的模塊有依賴項，需要提前報備風險，并且測試進度也要降低，對整體的測試進度要有把握。

2.開發(fā)測試如此快的周期，那么作為QA如何保障最終的質量呢？

? ? 如果出現了bug，那么誰來背鍋呢？PM說RD沒按MRD開發(fā)，RD說QA沒有測出來，QA說PM提的需求有問題，如此循環(huán)反復誰都不想背鍋，這時候作為QA的質量意識、用戶意識就要表現出來，一名QA不光是去和RD、PM溝通，也要把自己當做用戶去體驗產品，這也就是所謂的體驗性測試。

? ? 在設計、建筑、哲學等很多領域，有這么一句話——Less is More，少即是多，那么產品同樣也適用于這句話，PM也好、RD也好、QA也罷，最終都是服務產品，服務用戶，RD技術再好，開發(fā)的產品用到了多么高大上的技術，用戶不買賬，又有什么意義呢？在用戶的角度看來，這個東西好用就行，能給自己帶來什么好處，這才是用戶所在乎的，同樣作為QA的我們，就要在用戶的角度去考慮所測的產品，RD可以不關心產品對用戶的體驗，但是QA必須要關心，因為QA是產品面向用戶的最后一道關卡。?

? ? QA要有質量意識，在保障產品功能沒問題的前提下，去考慮產品的可靠性和易用性，后期還要考慮到產品的可維護性、可移植性和兼容性。保障最終的質量，這一切的前提都是功能性完全OK，所以保障最終的質量，需要從多方面去考慮，但是最基礎的還是保障功能性。

3.在敏捷中該如何去做測試？

? ? 1).上面有提到過，作為QA要提前介入測試，盡可能的讓自己的排期擴大

? ? 2).RD提測之前要保證自測OK，QA可以根據測試case輸出一版RD自測case，如果自測未通過，QA可以打回，并指導RD去做單元測試和簡單的mock接口測試

? ? 3).對于迭代周期較穩(wěn)定的項目，可以定期進行功能全量回歸，每周定期可以做性能、壓力、模擬攻擊等測試

? ? 4).QA也有必要去針對性的做自動化，比如接口自動化/部分UI自動化，但是UI自動化維護成本較高，針對不同的項目去考慮自動化

? ? 5).QA要做到上達業(yè)務，下通開發(fā)，提升自己的技能水平，針對不同的需求去用不同的測試方案進行測試

? ? 6).要學會使用工具去提升工作效率，比如使用靜態(tài)代碼檢查工具，可以減少在CR中遇到的坑，因為CR是比較耗時的事，但是CR大部分可以定位到疑難BUG

? ? 7).測試環(huán)境，測試數據要提早準備，提前準備相關資源，減少后期測試中因環(huán)境等其他因素導致的延期

? ? 8).QA自身也要遵循敏捷文化，面向價值，擁抱變化

? ? 雖然現在所在的團隊不是敏捷團隊，但是所做的項目絕對是比敏捷還要敏捷的項目，萬變不離其宗，再怎么變，QA還是控制產品的最后一道關。在大環(huán)境下，QA的要求并不是像以前簡單的黑盒和功能測試，更多的是其他的能力，比如CR能力、產品能力、架構能力等等。

? ? 感謝大家閱讀，一只QA實習小菜鳥對敏捷的心得感悟，如果對敏捷有更多看法的歡迎留言探討。

? ? 祝大家新年快樂~