有小夥伴就問，我們都敏捷了，我們是在效率和質量中找平衡，說敏捷開發中的質量是不容易控制的，要回答這個問題，我設計了一個FAQ，內容如下：
敏捷開發是什麼？
敏捷開發是以需求為中心，以交付價值為目的，持續增量交付的一種軟件開發方法，至於什麼是敏捷，就去問問度娘吧。對於敏捷團隊來說，是一個自組織的，有集體目標感的，打了雞血的理論上的全功能團隊。
軟件質量是什麼？
簡單點說，軟件質量就是軟件產出的結果與原始需要的相匹配程度，包含的方面包括簡裝修、正確性、效率、完整性，可維護性，靈活性等等等等。
相對與敏捷開發，傳統方式開發中軟件質量是如何控制的？
一般來說，對於軟件質量的控制是多角色、多層次的，一般會包含這些活動：
1、過程管理，一般由QA這個覺得通過一些手段來保證整個軟件開發過程的正確性；
2、評審活動，通常來說，在項目中產生的所有成果物都需要經過評審才能被使用或接收，從需求開始，也包含所有的設計文檔，測試用例，還有代碼等等；
3、問題管理，經過評審了，那就不可能不出現問題，出現了問題怎麼辦呢，那就需要修正、跟蹤，當然了，不是所有的問題就是由評審這個活動衍生出來的，也可能是由哪個項目干係人發現的，也有可能是由風險引發的；
4、測試，測試活動像項目中的其他活動一樣，也需要計劃、實施、驗證，也會包含一些其他的管理方面，包括用例管理，缺陷管理等，另外，測試是分階段分層次的，要根據需求的雙向可追蹤性進行測試規劃，還有很多的測試策略等等，測試是一門專門的學科，有機會我們再探討。總之，測試在軟件研發活動種是重要的，也是必不可少的。
一般來說，反映軟件質量的指標和工具有比如，代碼測試覆蓋率，單位缺陷密度，帕累託分析什麼的，這些學過PMP的同學都駕輕就熟，我就不多說了。
在敏捷開發中如何保證軟件的質量？
一般在敏捷開發中，提倡的是團隊整體參與的做法。也就是說，不只是單單一個質量，所有的事情都是全民參與的。那角色還是那些角色，QA和測試幹啥去？其實，在敏捷開發中，這兩種角色有更高層次的價值體現，比如說，她們更像是一個團隊支撐著和發現者。作為用戶的角色參與到項目中，提供交付價值的建議幫助需求提供者確定驗收標準，幫助團隊搭建測試自動化工具，做探索性測試等等，保證需求和過程的正確。
在敏捷軟件開發中，通常團隊會做這些事情以保證質量，並貫穿整個開發過程中
1、團隊中統一的標準和工具，統一的IDE，統一的編碼風格和規範，甚至統一的作息習慣，讓團隊更像是一個整體
2、靜態代碼檢查，既然有統一的編碼規範，這個活動完全可以用機器來解決，不符合規範的無法提交到版本庫
3、持續的單元測試，甚至是測試驅動開發（TDD），由編碼人員同時編寫單元測試用例和代碼
4、持續集成，持續檢查，持續測試，持續發佈，在過程中保證代碼、需求、活動、業務行為的正確
5、重構，敏捷是快速交付的，總有些技術債是要還的，代碼的改進也是改進的一部分
6、回顧，事後諸葛亮的事，為項目目標造成阻礙的事件或者是一些典型的缺陷都要徹底分析
7、與客戶合作，只有客戶才知道他要的到底是什麼（也可能有的時候根本就不知道），只有看見的成果才能有建議，滿足客戶的需要也是質量的重要部分
在敏捷中，我們跟關注缺陷或者問題存在了多久，而不是他存在多少，也就是缺陷或者問題的生命週期，這個指標一般我們會定義缺陷的幾個狀態，比如說，open-fixed-close-reopen等，我們看在每個階段停留的時間，分別去看看缺陷定位的時間（缺陷是不是描述的競爭），缺陷修復時間（改了多久），改了幾遍（改沒改對或者引發其他缺陷的）。另外，現在比較火的就是DevOps了，好處就不多說了，在這個過程中，有很多地方都是與質量和業務價值相關的，有興趣的小夥伴請自行度娘。
經常看到有小夥伴反映因為過渡到了敏捷開發導致質量崩塌的案例，其實我覺得大家都有個誤區，不一定我們追求效率了，那一定就會犧牲質量（另外，敏捷絕對不是用更短的時間），只不過我們可能沒有找到合適的方法，或者說團隊還不是那麼的敏捷。所以對於質量這件事來說，不管是傳統方法還是敏捷，我覺得企業質量文化對軟件產品質量還是最重要的。總是能找到一種合適的方法，把項目質量搞上去。
分享到:
閱讀更多 懶人項目管理 的文章
