敏捷開發模式下的質量管理
- 瀏覽量：669
- 來源：中華名師網
- 2015-03-27
楊學明
動態
敏捷開發模式下的質量管理
前幾天，筆者與一位在互聯網公司從事質量保證的朋友交談，作為互聯網產品質量和測試的負責人，他最近負責的質量管理方面遇到了很多困難。主要有：1）測試團隊在敏捷開發模式下的價值非常有限；2）開發人員只顧自已寫代碼，沒有任何文檔，測試人員無從下手，3）由于進度的原因，測試人員測試的時間非常有限，上線后出現很多問題；4）由于測試人員得不到開發團隊的認可，離職率非常高；5）質量部門無法收集到數據，不能進行質量度量；6）測試團隊也有一批自動化測試專家，但派不上用場…..這些問題可能很多開發團隊都會遇到，總結一下，大致是這幾個方面：
} 越來越多的企業希望采用，但沒有把握
} 習慣于傳統的瀑布式產品開發流程已不滿足快速發展需要，但大規模改動不現實
} 缺少敏捷軟件開發專家和人才
} 技術人員需要觀念的轉變和方法培訓
} 缺乏相應的質量控制方法
} 需要經常的和及時的質量度量、測試、決策
} 自動化測試不能落到實處，每日構建仍是紙上談兵
在現在行業中，需求變化太快，不管我們怎么努力去做，發現還是不能滿足客戶的需要，不管需求搞得多么細，到交付產品給客戶的事情，總是有這樣那樣的問題，這個時候就不得不去修改我們的軟件，這是目前很多企業尤其是互聯網公司面臨的一個挑戰，如何解決這個問題？
筆者先后在華為、阿里巴巴軟件質量部門任職，最近也深入研究了騰訊敏捷開發平臺TAPD（騰訊敏捷產品開發）和IGD（集成游戲開發）一些資料，對國內敏捷項目的質量管理有很多獨到的見解，結合共創力咨詢公司多年的項目經驗，總結如下：
1）QA角色的轉變
QA要從警察的角色轉變到一個教練的角色。在以前，團隊實施CMM的時候，QA更多的是一個警察的角色，他整天拿著一個checklist、報告什么的到處去團隊里面看，你是否ok，不ok就要怎么怎么樣，整天就干這個活，但是引入敏捷之后，QA就覺得有點失落，都敏捷了，我都不知道該怎么下手了，在著名的通信企業華為的做法是將QA轉變了一下，將QA更多的充當教練的角色，充當SCRUM Master的角色，他去指導項目團隊該如何去開這個站立式會議，該怎么去做迭代的計劃等等指導性的工作，這樣QA也覺得挺好，這樣他能參與到在不同的團隊中去，QA的角色更多的偏向于全過程的敏捷活動指導，以提高產品開發效率和質量。QA在這個過程中也能得到一些數據，如代碼缺陷率，版本的不良率，上線遺留問題數，團隊成員配合度等等。
2）要使敏捷團隊整體參與
QA和測試人員也是敏捷團隊的一部分，作為敏捷教練，QA要向測試團隊提供支持和訓練，以使作們適應開發的快節奏。比如，如果你是敏捷團隊中的測試人員，并且計劃會議和設計討論沒有邀請你，或者業務用戶正在獨立定義故事和需求，那你應該主動站出來和團隊的其他成員交流，并償試“三方協作”，即測試人員、開發人員和業務專家。騰訊公司把業務專家稱為BA，即Bussiness Analyst, BA和開發人員DE、測試人員TE組成了敏捷開發團隊，這些成員不僅僅都在忙著最終的交付，他們還樂于收集和分享信息，與客戶或者產品負責人協作以幫助他們充分展示自已的需求，從而得到他們的需要的功能，同時向所有人提供項目進展的反饋。
3） 自動化回歸測試。敏捷團隊沒有自動化會成功嗎？可能也會成功，但我們所知道的成功團隊都依賴于自動化回歸測試，如騰訊和支付寶公司的Selenium框架，阿里巴巴和淘寶網的QTP框架。共創力咨詢認為，敏捷開發利用測試來指導開發，為了編寫的代碼能測試通過，需要快速而簡單地運行測試，沒有短期反饋周期和安全的回歸測試，團隊將很快陷入技術債務，缺陷不斷增加，速度越來越慢。
4） 提供并獲取反饋
反饋是敏捷的核心價值，敏捷的短期迭代可以提供持續的反饋以幫助團隊正常運轉，測試人員則通過自動化測試結果、探索性測試的發現和系統實際用戶的觀察結果的形式幫助提供支饋。如你怎么知道客戶手里拿到了預期行為的正確示例？你怎么知道編寫的測試用例正確地反映了這些示例？開發人員通過查看測試用例能夠理解應該編寫什么代碼嗎？QA和測試人員應該詢問開發人員是否得到了足夠的信息以理解需求并是否能夠指導編碼，詢問客戶是否理解質量標準，應花時間參與迭代計劃會議和回顧會議以討論這些問題并提出改進方案。把反饋的結構可表示為如下：
5） 構造核心的敏捷實踐活動
軟件行業有一名老話是：軟件質量是設計出來的。對于敏捷開發也是如此，共創力咨詢認為沒有一些基礎的實踐活動，無法產生出高質量的軟件。
①持續集成。持續集成（CI）是一項軟件開發實踐，其中團隊的成員經常集成他們的工作，通常每人每天至少集成一次，每次集成通過自動化構建完成。利用持續集成可以讓缺陷在引入的當天就被發現并解決，降低缺陷修改成本；將集成工作分散在平時，通過每天生成可部署的軟件；避免產品最終集成時爆發大量問題。
②灰度發布。這是互聯網產品的一個特點，說白了，就是對用戶一個逐步放量的一個過程，而且不要求團隊要盡早 的將產品包發布出來，也就是不要求馬上發布給所有用戶，而是會分批的去發布，比如按號段發布，比如在公司內部先體驗。發布的時候也有策略，比如發布時如何放量，對用戶有些什么樣的實驗，技術上怎樣做一些后臺開關，運營上怎樣跟進，怎樣保證4小時人員的留守，發布完后怎樣收集用戶反饋等等都會有一些統一的規則。比方實驗室某WEB產品的發布，可以同時有多個版本，1.1版可能會有100%的用戶在用，1.2版可能只有1%的用戶在用，它們是一個交叉升級的過程，目前騰訊采用了該活動。
③ 每日晨會：每個團隊每天大概花15-30分鐘，回顧昨天做了什么、昨天有些什么問題、同時也會介紹每個人今天計劃做些什么工作（特點：是站著開會）。筆者在阿里巴巴工作時，就經歷過每日晨會，一般主持人由敏捷團隊的成員輪流擔任，這個時候可以了解每天發生的問題。
④結對編程：兩位程序員在一臺電腦前工作，一個負責敲入代碼，而另外一個實時檢視每一行敲入的代碼；操作鍵盤和鼠標的程序員被稱為“駕駛員”，負責實時評審和協助的程序員被稱為“領航員”；領航員檢視的同時還必須負責考慮下一步的工作方向，比如可能出現的問題以及改進等。有助于提升代碼設計質量；研究表明結對生產率比兩個單人總和低15%，但缺陷數少15%，考慮修改缺陷工作量和時間都比初始編程大幾倍，所以結對編程總體效率更高，同時結對編程能夠大幅促進團隊能力提升和知識傳播。
⑤用戶故事。用戶故事是站在用戶角度描述需求的一種方式；每個用戶故事須有對應的驗收測試用例；用戶故事是分層分級的，在使用過程中逐步分解細化；典型的描述句式為：作為一個XXX客戶角色，我需要XXX功能，帶來XXX好處。用戶故事的好處是：用戶故事站在用戶視角便于和客戶交流，準確描述客戶需求；用戶故事可獨立交付單元、規模小，適于迭代開發，以獲得用戶快速反饋；用戶故事強調編寫驗收測試用例作為驗收標準，能促使需求分析人員準確把握需求，牽引開發人員避免過度設計。
⑥迭代回顧會議。在每輪迭代結束后舉行的會議，目的是分享好的經驗和發現改進點，促進團隊不斷進步；圍繞如下三個問題：本次迭代有哪些做得好？本次迭代我們哪些方面還能做得更好？我們在下次迭代準備在哪些方面改進？會議需要Team全員參加，氣氛寬松自由，暢所欲言，頭腦風暴發現問題，共同分析根因；會議關注重點是Team共同討論優先級，將精力放在最需要的地方（關注幾個改進就夠了）；會議結論要跟蹤閉環。
每個項目需要哪些實踐活動支撐，不是固定的，如有些團隊資源較少，還不具備結對編程的能力，還有些項目周期本來就短，就不需要每日構建了等等...這些活動是由敏捷開發團隊經過開會討論決定的。在項目開工會之前，大家坐到一起，把需要的實踐活動定下來，然后付諸行動，再作回顧。
總之，共創力咨詢認為，測試和質量是整個敏捷團隊的職責，團隊中的每一個人都應該關注手邊的一個任務或者故事，敏捷模式下的質量管理更具有挑戰性，但與傳統瀑布模式相比，其在應對需求變化、提升產品質量、加快需求響應、縮短交付周期、提前暴露風險、及時激勵員工以及平衡人力資源的使用等方面具有明顯優勢。敏捷的焦點在于持交付有價值的軟件讓一直到客戶滿意為止。在這個“快魚吃慢魚”時代，要想交付好而快的產品，不防用敏捷模式試試。
