本期話題：怎樣衡量監控敏捷型軟件項目質量（指標？工具？）【下】

一、背景說明

受診人：有實體產品的項目一般都有成熟的質量管理體系，成熟通用的標準要求，但軟件項目一般偏迭代和敏捷，沒找到有成熟的度量體系指標，做為項目經理如何直觀的監控到項目的軟件產品的開發質量，有哪些好的通用的指標或管理工具。

公司正在認證CMMI4，正在確定項目度量項，暫時制定了工作量、偏差、缺陷幾項指標，感覺無法反映出項目產品實際運行的質量情況。

二、診斷 

有小伙伴就問，我們都敏捷了，我們是在效率和質量中找平衡，說敏捷開發中的質量是不容易控制的，要回答這個問題，我設計了一個FAQ，內容如下：

問題1：

Q：敏捷開發是什么？ 

A： 敏捷開發是以需求為中心，以交付價值為目的，持續增量交付的一種軟件開發方法，至于什么是敏捷，就去問問度娘吧。對于敏捷團隊來說，是一個自組織的，有集體目標感的，打了雞血的理論上的全功能團隊。

問題2：

Q：軟件質量是什么？

A： 簡單點說，軟件質量就是軟件產出的結果與原始需要的相匹配程度，包含的方面包括簡裝修、正確性、效率、完整性，可維護性，靈活性等等等等。

問題3：

Q：相對與敏捷開發，傳統方式開發中軟件質量是如何控制的？

A：一般來說，對于軟件質量的控制是多角色、多層次的，一般會包含這些活動：

①過程管理，一般由QA這個覺得通過一些手段來保證整個軟件開發過程的正確性；

②評審活動，通常來說，在項目中產生的所有成果物都需要經過評審才能被使用或接收，從需求開始，也包含所有的設計文檔，測試用例，還有代碼等等；

③問題管理，經過評審了，那就不可能不出現問題，出現了問題怎么辦呢，那就需要修正、跟蹤，當然了，不是所有的問題就是由評審這個活動衍生出來的，也可能是由哪個項目干系人發現的，也有可能是由風險引發的；

④測試，測試活動像項目中的其他活動一樣，也需要計劃、實施、驗證，也會包含一些其他的管理方面，包括用例管理，缺陷管理等，另外，測試是分階段分層次的，要根據需求的雙向可追蹤性進行測試規劃，還有很多的測試策略等等，測試是一門專門的學科，有機會我們再探討。總之，測試在軟件研發活動種是重要的，也是必不可少的。

一般來說，反映軟件質量的指標和工具有比如，代碼測試覆蓋率，單位缺陷密度，帕累托分析什么的，這些學過PMP^®的同學都駕輕就熟，我就不多說了。

問題4：

Q：在敏捷開發中如何保證軟件的質量？

A：一般在敏捷開發中，提倡的是團隊整體參與的做法。也就是說，不只是單單一個質量，所有的事情都是全民參與的。那角色還是那些角色，QA和測試干啥去？其實，在敏捷開發中，這兩種角色有更高層次的價值體現，比如說，她們更像是一個團隊支撐和發現者。作為用戶的角色參與到項目中，提供交付價值的建議幫助需求提供者確定驗收標準，幫助團隊搭建測試自動化工具，做探索性測試等等，保證需求和過程的正確。

問題5：

Q：在敏捷軟件開發中，通常團隊會做哪些事情以保證質量呢？

A：①團隊中統一的標準和工具，統一的IDE，統一的編碼風格和規范，甚至統一的作息習慣，讓團隊更像是一個整體。

②靜態代碼檢查，既然有統一的編碼規范，這個活動完全可以用機器來解決，不符合規范的無法提交到版本庫。

③持續的單元測試，甚至是測試驅動開發（TDD），由編碼人員同時編寫單元測試用例和代碼。

④持續集成，持續檢查，持續測試，持續發布，在過程中保證代碼、需求、活動、業務行為的正確。

⑤重構，敏捷是快速交付的，總有些技術債是要還的，代碼的改進也是改進的一部分。

⑥回顧，事后諸葛亮的事，為項目目標造成阻礙的事件或者是一些典型的缺陷都要徹底分析。

⑦與客戶合作，只有客戶才知道他要的到底是什么（也可能有的時候根本就不知道），只有看見的成果才能有建議，滿足客戶的需要也是質量的重要部分。

三、 QA

Q：敏捷和迭代的區別是什么？

A：敏捷是迭代的，但是迭代的不一定敏捷。敏捷更適合自己研發產品的那種互聯網企業。

Q：敏捷的迭代是什么？

A：一般來說，敏捷的迭代都是固定周期，且在一定的速率下，有潛在可交付成果的。

Q：敏捷開發，相關的文檔什么的，都會弱化嗎？一般哪些文檔是必須的？

A：其實不是，其實如果你的組織曾經有完整的管理體系的話，在敏捷轉型的過程中，一個合格的引導者會想辦法把你曾經的過程幫助你們融合到敏捷過程中。

比如說需求，一般我們傳統做需求會新做需求說明書，需求跟蹤矩陣。

在敏捷中，我們是用需求故事看板和用戶故事地圖去代替這些東西。

Q：文檔弱化，需求文檔需要嗎？若是沒有的話，爭議有依據嗎？

A：如果是在一個敏捷團隊中，理論上需求爭議會被弱化。

一來，用戶會參與到你的研發活動中，二來，你有更窄的反饋周期，然而，需求看板的作用是引發討論和確認標準的。

Q：看了你們聊了這么多，我感覺作為甲方，我不需要敏捷，我需要快速迭代？

A：快速迭代增量開發，并持續的反饋和驗證是對甲方有利的。其實做為敏捷來說，是一個持續的過程。就是團隊在跟甲方也好，用戶也好，不停的在對需求，不停的問我這做的對不對，不對馬上改。

Q：敏捷項目的成本如何去管理呢？

A：敏捷的成本一般來說由團隊整體負責，一般的做法是做一個成本目標，這里的成本不光是錢，還是有資源，還有人力還有時間，團隊的目標就是在幾個迭代中交付怎樣的價值成果，以及想對應的成本目標。

結語：

在敏捷中，我們跟關注缺陷或者問題存在了多久，而不是他存在多少，也就是缺陷或者問題的生命周期，這個指標一般我們會定義缺陷的幾個狀態，比如說，open-fixed-close-reopen等，我們看在每個階段停留的時間，分別去看看缺陷定位的時間（缺陷是不是描述的競爭），缺陷修復時間（改了多久），改了幾遍（改沒改對或者引發其他缺陷的）。另外，現在比較火的就是DevOps了，好處就不多說了，在這個過程中，有很多地方都是與質量和業務價值相關的，有興趣的小伙伴請自行度娘。

經常看到有小伙伴反映因為過渡到了敏捷開發導致質量崩塌的案例，其實我覺得大家都有個誤區，不一定我們追求效率了，那一定就會犧牲質量（另外，敏捷絕對不是用更短的時間），只不過我們可能沒有找到合適的方法，或者說團隊還不是那么的敏捷。所以對于質量這件事來說，不管是傳統方法還是敏捷，我覺得企業質量文化對軟件產品質量還是最重要的。總是能找到一種合適的方法，把項目質量搞上去。

“我見過很多團隊因為轉型敏捷造成質量崩潰的事了，這就是對敏捷是個什么東西還沒弄清楚，或者還沒找到所謂敏捷能落地的策略，在這種情況下，不太建議直接轉型。”

討論內容整理 ：

【以下關于項目團隊管理的內容都來自于希賽「PM創造營」群內診斷會，由?@小M妹妹? 整理，由以下小伙伴分享完成@大懶-青島-智能健身@小糊涂仙-重慶-物聯網@Simon-杭州-聚合支付@沫水-合肥-軟件@Lucy-成都-智慧園區運營@過客+鄭州+實施@圣徒子-北京-人防環保政務三維GIS@啊潮-廣州-互聯網】