怎樣監(jiān)控敏捷型軟件項(xiàng)目質(zhì)量？【下】-診斷會(huì)

本期話題：怎樣衡量監(jiān)控敏捷型軟件項(xiàng)目質(zhì)量（指標(biāo)？工具？）【下】

一、背景說(shuō)明

受診人：有實(shí)體產(chǎn)品的項(xiàng)目一般都有成熟的質(zhì)量管理體系，成熟通用的標(biāo)準(zhǔn)要求，但軟件項(xiàng)目一般偏迭代和敏捷，沒找到有成熟的度量體系指標(biāo)，做為項(xiàng)目經(jīng)理如何直觀的監(jiān)控到項(xiàng)目的軟件產(chǎn)品的開發(fā)質(zhì)量，有哪些好的通用的指標(biāo)或管理工具。

公司正在認(rèn)證CMMI4，正在確定項(xiàng)目度量項(xiàng)，暫時(shí)制定了工作量、偏差、缺陷幾項(xiàng)指標(biāo)，感覺無(wú)法反映出項(xiàng)目產(chǎn)品實(shí)際運(yùn)行的質(zhì)量情況。

二、診斷 

有小伙伴就問(wèn)，我們都敏捷了，我們是在效率和質(zhì)量中找平衡，說(shuō)敏捷開發(fā)中的質(zhì)量是不容易控制的，要回答這個(gè)問(wèn)題，我設(shè)計(jì)了一個(gè)FAQ，內(nèi)容如下：

問(wèn)題1：

Q：敏捷開發(fā)是什么？ 

A： 敏捷開發(fā)是以需求為中心，以交付價(jià)值為目的，持續(xù)增量交付的一種軟件開發(fā)方法，至于什么是敏捷，就去問(wèn)問(wèn)度娘吧。對(duì)于敏捷團(tuán)隊(duì)來(lái)說(shuō)，是一個(gè)自組織的，有集體目標(biāo)感的，打了雞血的理論上的全功能團(tuán)隊(duì)。

問(wèn)題2：

Q：軟件質(zhì)量是什么？

A： 簡(jiǎn)單點(diǎn)說(shuō)，軟件質(zhì)量就是軟件產(chǎn)出的結(jié)果與原始需要的相匹配程度，包含的方面包括簡(jiǎn)裝修、正確性、效率、完整性，可維護(hù)性，靈活性等等等等。

問(wèn)題3：

Q：相對(duì)與敏捷開發(fā)，傳統(tǒng)方式開發(fā)中軟件質(zhì)量是如何控制的？

A：一般來(lái)說(shuō)，對(duì)于軟件質(zhì)量的控制是多角色、多層次的，一般會(huì)包含這些活動(dòng)：

①過(guò)程管理，一般由QA這個(gè)覺得通過(guò)一些手段來(lái)保證整個(gè)軟件開發(fā)過(guò)程的正確性；

②評(píng)審活動(dòng)，通常來(lái)說(shuō)，在項(xiàng)目中產(chǎn)生的所有成果物都需要經(jīng)過(guò)評(píng)審才能被使用或接收，從需求開始，也包含所有的設(shè)計(jì)文檔，測(cè)試用例，還有代碼等等；

③問(wèn)題管理，經(jīng)過(guò)評(píng)審了，那就不可能不出現(xiàn)問(wèn)題，出現(xiàn)了問(wèn)題怎么辦呢，那就需要修正、跟蹤，當(dāng)然了，不是所有的問(wèn)題就是由評(píng)審這個(gè)活動(dòng)衍生出來(lái)的，也可能是由哪個(gè)項(xiàng)目干系人發(fā)現(xiàn)的，也有可能是由風(fēng)險(xiǎn)引發(fā)的；

④測(cè)試，測(cè)試活動(dòng)像項(xiàng)目中的其他活動(dòng)一樣，也需要計(jì)劃、實(shí)施、驗(yàn)證，也會(huì)包含一些其他的管理方面，包括用例管理，缺陷管理等，另外，測(cè)試是分階段分層次的，要根據(jù)需求的雙向可追蹤性進(jìn)行測(cè)試規(guī)劃，還有很多的測(cè)試策略等等，測(cè)試是一門專門的學(xué)科，有機(jī)會(huì)我們?cè)偬接?。總之，測(cè)試在軟件研發(fā)活動(dòng)種是重要的，也是必不可少的。

一般來(lái)說(shuō)，反映軟件質(zhì)量的指標(biāo)和工具有比如，代碼測(cè)試覆蓋率，單位缺陷密度，帕累托分析什么的，這些學(xué)過(guò)PMP^®的同學(xué)都駕輕就熟，我就不多說(shuō)了。

問(wèn)題4：

Q：在敏捷開發(fā)中如何保證軟件的質(zhì)量？

A：一般在敏捷開發(fā)中，提倡的是團(tuán)隊(duì)整體參與的做法。也就是說(shuō)，不只是單單一個(gè)質(zhì)量，所有的事情都是全民參與的。那角色還是那些角色，QA和測(cè)試干啥去？其實(shí)，在敏捷開發(fā)中，這兩種角色有更高層次的價(jià)值體現(xiàn)，比如說(shuō)，她們更像是一個(gè)團(tuán)隊(duì)支撐和發(fā)現(xiàn)者。作為用戶的角色參與到項(xiàng)目中，提供交付價(jià)值的建議幫助需求提供者確定驗(yàn)收標(biāo)準(zhǔn)，幫助團(tuán)隊(duì)搭建測(cè)試自動(dòng)化工具，做探索性測(cè)試等等，保證需求和過(guò)程的正確。

問(wèn)題5：

Q：在敏捷軟件開發(fā)中，通常團(tuán)隊(duì)會(huì)做哪些事情以保證質(zhì)量呢？

A：①團(tuán)隊(duì)中統(tǒng)一的標(biāo)準(zhǔn)和工具，統(tǒng)一的IDE，統(tǒng)一的編碼風(fēng)格和規(guī)范，甚至統(tǒng)一的作息習(xí)慣，讓團(tuán)隊(duì)更像是一個(gè)整體。

②靜態(tài)代碼檢查，既然有統(tǒng)一的編碼規(guī)范，這個(gè)活動(dòng)完全可以用機(jī)器來(lái)解決，不符合規(guī)范的無(wú)法提交到版本庫(kù)。

③持續(xù)的單元測(cè)試，甚至是測(cè)試驅(qū)動(dòng)開發(fā)（TDD），由編碼人員同時(shí)編寫單元測(cè)試用例和代碼。

④持續(xù)集成，持續(xù)檢查，持續(xù)測(cè)試，持續(xù)發(fā)布，在過(guò)程中保證代碼、需求、活動(dòng)、業(yè)務(wù)行為的正確。

⑤重構(gòu)，敏捷是快速交付的，總有些技術(shù)債是要還的，代碼的改進(jìn)也是改進(jìn)的一部分。

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

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

三、 QA

Q：敏捷和迭代的區(qū)別是什么？

A：敏捷是迭代的，但是迭代的不一定敏捷。敏捷更適合自己研發(fā)產(chǎn)品的那種互聯(lián)網(wǎng)企業(yè)。

Q：敏捷的迭代是什么？

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

Q：敏捷開發(fā)，相關(guān)的文檔什么的，都會(huì)弱化嗎？一般哪些文檔是必須的？

A：其實(shí)不是，其實(shí)如果你的組織曾經(jīng)有完整的管理體系的話，在敏捷轉(zhuǎn)型的過(guò)程中，一個(gè)合格的引導(dǎo)者會(huì)想辦法把你曾經(jīng)的過(guò)程幫助你們融合到敏捷過(guò)程中。

比如說(shuō)需求，一般我們傳統(tǒng)做需求會(huì)新做需求說(shuō)明書，需求跟蹤矩陣。

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

Q：文檔弱化，需求文檔需要嗎？若是沒有的話，爭(zhēng)議有依據(jù)嗎？

A：如果是在一個(gè)敏捷團(tuán)隊(duì)中，理論上需求爭(zhēng)議會(huì)被弱化。

一來(lái)，用戶會(huì)參與到你的研發(fā)活動(dòng)中，二來(lái)，你有更窄的反饋周期，然而，需求看板的作用是引發(fā)討論和確認(rèn)標(biāo)準(zhǔn)的。

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

A：快速迭代增量開發(fā)，并持續(xù)的反饋和驗(yàn)證是對(duì)甲方有利的。其實(shí)做為敏捷來(lái)說(shuō)，是一個(gè)持續(xù)的過(guò)程。就是團(tuán)隊(duì)在跟甲方也好，用戶也好，不停的在對(duì)需求，不停的問(wèn)我這做的對(duì)不對(duì)，不對(duì)馬上改。

Q：敏捷項(xiàng)目的成本如何去管理呢？

A：敏捷的成本一般來(lái)說(shuō)由團(tuán)隊(duì)整體負(fù)責(zé)，一般的做法是做一個(gè)成本目標(biāo)，這里的成本不光是錢，還是有資源，還有人力還有時(shí)間，團(tuán)隊(duì)的目標(biāo)就是在幾個(gè)迭代中交付怎樣的價(jià)值成果，以及想對(duì)應(yīng)的成本目標(biāo)。

結(jié)語(yǔ)：

在敏捷中，我們跟關(guān)注缺陷或者問(wèn)題存在了多久，而不是他存在多少，也就是缺陷或者問(wèn)題的生命周期，這個(gè)指標(biāo)一般我們會(huì)定義缺陷的幾個(gè)狀態(tài)，比如說(shuō)，open-fixed-close-reopen等，我們看在每個(gè)階段停留的時(shí)間，分別去看看缺陷定位的時(shí)間（缺陷是不是描述的競(jìng)爭(zhēng)），缺陷修復(fù)時(shí)間（改了多久），改了幾遍（改沒改對(duì)或者引發(fā)其他缺陷的）。另外，現(xiàn)在比較火的就是DevOps了，好處就不多說(shuō)了，在這個(gè)過(guò)程中，有很多地方都是與質(zhì)量和業(yè)務(wù)價(jià)值相關(guān)的，有興趣的小伙伴請(qǐng)自行度娘。

經(jīng)常看到有小伙伴反映因?yàn)檫^(guò)渡到了敏捷開發(fā)導(dǎo)致質(zhì)量崩塌的案例，其實(shí)我覺得大家都有個(gè)誤區(qū)，不一定我們追求效率了，那一定就會(huì)犧牲質(zhì)量（另外，敏捷絕對(duì)不是用更短的時(shí)間），只不過(guò)我們可能沒有找到合適的方法，或者說(shuō)團(tuán)隊(duì)還不是那么的敏捷。所以對(duì)于質(zhì)量這件事來(lái)說(shuō)，不管是傳統(tǒng)方法還是敏捷，我覺得企業(yè)質(zhì)量文化對(duì)軟件產(chǎn)品質(zhì)量還是最重要的?？偸悄苷业揭环N合適的方法，把項(xiàng)目質(zhì)量搞上去。

“我見過(guò)很多團(tuán)隊(duì)因?yàn)檗D(zhuǎn)型敏捷造成質(zhì)量崩潰的事了，這就是對(duì)敏捷是個(gè)什么東西還沒弄清楚，或者還沒找到所謂敏捷能落地的策略，在這種情況下，不太建議直接轉(zhuǎn)型。”

討論內(nèi)容整理 ：

【以下關(guān)于項(xiàng)目團(tuán)隊(duì)管理的內(nèi)容都來(lái)自于希賽「PM創(chuàng)造營(yíng)」群內(nèi)診斷會(huì)，由?@小M妹妹? 整理，由以下小伙伴分享完成@大懶-青島-智能健身@小糊涂仙-重慶-物聯(lián)網(wǎng)@Simon-杭州-聚合支付@沫水-合肥-軟件@Lucy-成都-智慧園區(qū)運(yùn)營(yíng)@過(guò)客+鄭州+實(shí)施@圣徒子-北京-人防環(huán)保政務(wù)三維GIS@啊潮-廣州-互聯(lián)網(wǎng)】