敏捷項目管理實戰(zhàn)之質(zhì)量管理
簡介:本文以筆者的項目管理實踐為基礎(chǔ),介紹基于經(jīng)驗過程控制(Empirical Process Control)模型、缺陷預(yù)防以及敏捷價值觀的敏捷質(zhì)量管理思想及其實踐。希望通過本文為廣大項目管理人員提供質(zhì)量管理的一些思路和經(jīng)驗分享。
經(jīng)驗過程控制
經(jīng)驗過程控制是一種問題驅(qū)動的輕型過程控制模型。在進(jìn)一步介紹經(jīng)驗過程控制之前,我們先看一個日常生活中應(yīng)用經(jīng)驗過程控制的一個例子:在菜肴的烹飪過程中,人們往往先觀察菜肴的顏色,或者用筷子檢查其軟硬度來判斷菜肴是否已經(jīng)煮熟。若不夠熟,則繼續(xù)煮。待到菜肴快熟時,我們開始放鹽、味精之類的調(diào)料。然后嘗嘗菜肴的咸淡是否適中,若太淡了則繼續(xù)加鹽,直到我們滿意為止。經(jīng)過這樣一個過程,烹飪者滿意的一道菜肴才能完成。
上述例子正好體現(xiàn)了經(jīng)驗過程控制的三大支柱——透明性(Transparency)、檢查(Inspection)、適應(yīng)(Adaption)。透明性指影響最終產(chǎn)出結(jié)果的因素對于過程控制者來說可觀察或者使其可觀察。“透明性”在上述例子中表現(xiàn)為:菜肴煮熟程度是影響菜肴質(zhì)量的一個因素,而這個因素可以通過菜肴的顏色或其硬度反映出來。檢查指對影響最終產(chǎn)出的因素進(jìn)行觀察和評價的動作。上述例子中提到的觀察菜肴的顏色、嘗嘗菜肴的咸淡就是“檢查”。適應(yīng)指檢查過程中發(fā)現(xiàn)不可接受的結(jié)果、偏差時所采取的矯正動作。上述例子提及的在發(fā)現(xiàn)菜肴味道偏淡的情況下采取的繼續(xù)加鹽的動作就是“適應(yīng)”。
從經(jīng)驗過程控制的三大支柱我們可以看到其問題驅(qū)動的性質(zhì)。問題驅(qū)動是指在過程實施時所進(jìn)行的活動是基于有哪些因素影響了最終產(chǎn)出的結(jié)果,而不是像一些傳統(tǒng)的過程控制實施者是從一些預(yù)定義的活動集合中“剪裁”一些活動。從一個活動集合中剪裁出一些活動,這本身就要求剪裁者對這個活動集合中的每個活動足夠了解,從而能夠選擇適合自己的活動。這個剪裁的過程使得這些傳統(tǒng)的過程控制實施起來相對困難,而經(jīng)驗過程控制因為省卻了“剪裁”的過程而使得其實施相對容易。
基于經(jīng)驗過程控制的質(zhì)量管理其實施的基本思路是先通過經(jīng)驗或者對質(zhì)量問題進(jìn)行根因分析(Root Cause Analysis)發(fā)現(xiàn)影響質(zhì)量的因素,再采取措施使這些因素成為可觀察的因素(對應(yīng)經(jīng)驗過程的“透明性”)。然后,在項目實施過程中對這些因素進(jìn)行檢查(對應(yīng)經(jīng)驗過程控制的“檢查”)。檢查過程中發(fā)現(xiàn)不可接受的結(jié)果或者偏差時及時采取措施進(jìn)行矯正以防止缺陷的引入或者缺陷流入下一道工序中(對應(yīng)經(jīng)驗過程控制的“適應(yīng)”),從而保證了最終產(chǎn)出的質(zhì)量。
缺陷預(yù)防
《孫子兵法·謀攻》中提到“百戰(zhàn)百勝非善之善者,不戰(zhàn)而屈人兵,善之善者”。每次打仗都取勝不是戰(zhàn)爭的最高境界,戰(zhàn)爭的最高境界是不費兵卒而取得勝利。同樣,在軟件開發(fā)過程中,找出所有缺陷并將其一一去除不是質(zhì)量管理的最高境界。質(zhì)量管理的最高境界是將缺陷扼殺在搖籃之中——缺陷預(yù)防。經(jīng)驗過程控制三大支柱所體現(xiàn)的其問題驅(qū)動的特性說明了它可以幫助我們?nèi)嵤┤毕蓊A(yù)防?;诮?jīng)驗過程控制的缺陷預(yù)防是通過使缺陷來源成為可觀察的因素,然后在軟件開發(fā)過程中對這些因素進(jìn)行檢查,發(fā)現(xiàn)不可接受的偏差時及時采取措施進(jìn)行矯正,從而避免了缺陷的引入。比如,當(dāng)我們發(fā)現(xiàn)開發(fā)人員對需求理解的錯誤、不全面是缺陷的一個重要來源時,我們就可以應(yīng)用經(jīng)驗過程控制的思想,先采取措施使開發(fā)人員對需求的理解成為可觀察的因素。然后對其進(jìn)行檢查,若發(fā)現(xiàn)有需求理解上的偏差,則進(jìn)行矯正,從而避免了因需求理解偏差而引入缺陷。
誠然,軟件測試的目的是發(fā)現(xiàn)缺陷。也正因此大多數(shù)公司和個人也就把測試人員定位成缺陷的發(fā)現(xiàn)者。然而,測試畢竟是一種事后控制型的質(zhì)量管理手段,這不是上上策。能否往測試人員這個角色的職責(zé)的定義中增加一個缺陷預(yù)防的職能呢?筆者曾經(jīng)在所帶團(tuán)隊中引導(dǎo)測試人員往缺陷預(yù)防方面發(fā)展,在這方面多做貢獻(xiàn),而不是僅僅把自己定位為缺陷的發(fā)現(xiàn)者。在開發(fā)測試一體化團(tuán)隊中,測試人員同開發(fā)人員一起參與需求分析、評審。項目經(jīng)理可以通過一些獎勵措施鼓勵測試人員多去發(fā)現(xiàn)需求本身的錯誤以及開發(fā)人員對需求理解的偏差,從而避免了需求相關(guān)的缺陷。另一方面,測試人員往往習(xí)慣于從發(fā)現(xiàn)缺陷中獲得成就感。在引導(dǎo)測試人員在缺陷預(yù)防上多做貢獻(xiàn)的過程中,項目經(jīng)理需要引導(dǎo)測試人員使其認(rèn)識到預(yù)防缺陷比發(fā)現(xiàn)缺陷更加能夠體現(xiàn)一個人的能力和價值。
需求澄清
需求規(guī)格說明書本身的錯誤、不明確是軟件缺陷的一個重要來源。因此,消除需求本身的問題是缺陷預(yù)防的一個重要內(nèi)容。筆者在所帶的項目中是通過開展需求澄清活動來消除需求本身的問題的。在開發(fā)團(tuán)隊內(nèi)部進(jìn)行需求規(guī)格說明書評審之后,評審意見被匯總成一個列表,這個列表可以是一個 Excel 表格,我們稱之為需求問題確認(rèn)列表。然后,我們邀請客戶過來和開發(fā)團(tuán)隊一起對問題列表中的每個問題進(jìn)行討論。團(tuán)隊成員負(fù)責(zé)提出和解釋問題確認(rèn)列表中的問題,客戶代表則負(fù)責(zé)解答和澄清團(tuán)隊成員提出的問題。客戶對于問題的回復(fù)我們會記錄到問題確認(rèn)列表的“回復(fù)”一欄。需求澄清活動往往是以頭腦風(fēng)暴會議的形式展開的,而不僅僅是一個一問一答的過程。對于客戶當(dāng)場給的問題回復(fù),團(tuán)隊成員可能因為通過自己的分析認(rèn)為客戶的回復(fù)是錯誤或者不合理的而當(dāng)場對客戶代表的回復(fù)提出質(zhì)疑??蛻舸硗惨虼藢ζ浠貜?fù)進(jìn)行重新思考從而給出與會人員一致認(rèn)同的回復(fù)。
《敏捷宣言》中提到“客戶協(xié)作勝過合同談判”,需求澄清活動的基本前提就是客戶代表的參與。因此它是符合敏捷開發(fā)的價值觀的。
表 1. 需求澄清活動
需求宣講
團(tuán)隊成員對需求理解的偏差也是軟件缺陷的一個重要來源。我們可以應(yīng)用經(jīng)驗過程控制的思想對這種因需求理解偏差而引入的缺陷進(jìn)行預(yù)防。其基本思路是先使團(tuán)隊成員對需求的理解成為可觀察的因素,然后對這個因素進(jìn)行檢查。檢查過程中發(fā)現(xiàn)不可接受的偏差時及時采取措施進(jìn)行糾正,從而避免了缺陷的引入。筆者通過在團(tuán)隊內(nèi)開展需求宣講活動來具體實施這個缺陷預(yù)防。
需求宣講是在開發(fā)人員開始編碼、測試人員開始設(shè)計測試用例前,由全體團(tuán)隊成員參與的一個頭腦風(fēng)暴會議。在這個會議上,開發(fā)人員隨機選取一個 Story,然后口頭表述其對所選擇的 Story 的理解。通過這個講解,開發(fā)人員對需求理解就成為了一個可以觀察的因素。當(dāng)其他與會人從需求講解人的講解中發(fā)現(xiàn)其對需求理解上的偏差時,可以及時指出進(jìn)行糾正。其他與會人員也可對其講解提出疑問和質(zhì)疑。當(dāng)講解人的回復(fù)無法得到團(tuán)隊成員的一致認(rèn)同時,則進(jìn)行討論,最終達(dá)到對需求理解的一致。而對于討論無法達(dá)成一致認(rèn)識的問題,可以記錄入需求問題確認(rèn)列表會后再進(jìn)行確認(rèn)。
當(dāng)然,當(dāng)開發(fā)人員被要求講述其對需求的理解時,可能會說他其實已經(jīng)理解了需求只是不知道如何表述。且不論這句話是否屬實,項目經(jīng)理應(yīng)當(dāng)引導(dǎo)團(tuán)隊成員意識到:在敏捷開發(fā)團(tuán)隊中,個人對需求是如何理解的,理解的對與錯,深與淺不是其一個人的事情,而是整個團(tuán)隊的事情,因為它影響了這個團(tuán)隊最終交付的軟件的質(zhì)量!從另外一個角度來講,當(dāng)一個人能清晰得表述一件事物時,才說明其對這件事物是真正理解的。
雖然需求評審和需求澄清這兩個活動也能一定程度上反映活動參與者對需求的理解,但是它們更多的是用于發(fā)現(xiàn)需求本身的問題。而需求宣講則是專門用于檢驗活動參與者對需求的理解正確性和全面性。
表 2. 需求宣講活動
設(shè)計會話(Design Session)與簡單設(shè)計(Simple Design)
設(shè)計階段所引入的缺陷不僅包括設(shè)計本身的缺陷還包括了因編碼人員對設(shè)計方案理解的錯誤和偏差而引入的缺陷。極限編程所強調(diào)的是簡單設(shè)計雖然一定程度上降低了設(shè)計本身缺陷的概率,并且也有助于降低設(shè)計方案理解偏差而引入缺陷的可能性。但是,從經(jīng)驗過程控制和缺陷預(yù)防的角度來看,我們?nèi)匀恍枰獙⒕幋a人員對設(shè)計方案的理解這一影響質(zhì)量的因素成為可觀察的因素,并對其進(jìn)行檢查。
筆者在所帶的項目中開展設(shè)計會話活動。在設(shè)計會話中,通常由設(shè)計人員借助白板講解設(shè)計方案,其他人員對講解的內(nèi)容有疑問和異議時可以提出集體討論。主講的設(shè)計人員也可以針對其講解提出一些問題讓其他參與人回答,以確定參與人是否真正理解設(shè)計方案。設(shè)計會話結(jié)束后,白板上的內(nèi)容可以先保留一段時間,以方便事后再查看。有條件的團(tuán)隊也可將其拍照存檔。設(shè)計會話中所討論的設(shè)計方案可以事后由編碼人員寫入 Story 文檔。由于相關(guān)人員事先都參與過設(shè)計會話,在 Story 文檔評審時對其中的設(shè)計部分多少也許自己的認(rèn)識和意見,這有助于發(fā)現(xiàn)對設(shè)計方案理解的偏差。
設(shè)計會話體現(xiàn)了《敏捷宣言》中提到的“個人與交互勝過過程與工具”這一價值觀,避免了僅僅通過設(shè)計規(guī)格說明溝通設(shè)計方案導(dǎo)致的溝通效率低下、設(shè)計方案理解偏差的問題,充分發(fā)揮了人與人直接溝通的優(yōu)勢。
表 3. 設(shè)計會話
單元測試評審
單元測試是軟件開發(fā)中被普遍接受的優(yōu)秀實踐,也是影響軟件質(zhì)量的一個重要方面。有效的、充分的單元測試能夠提高代碼質(zhì)量,從而有效避免了返工。但是如何保證單元測試得到有效的執(zhí)行呢?按照經(jīng)驗過程控制的思想,我們可以先使單元測試成為一個可觀察的因素,然后對其進(jìn)行檢查。檢查過程中發(fā)現(xiàn)偏差時及時進(jìn)行糾正從而保證單元測試得到有效的執(zhí)行。
定義單元測試的產(chǎn)出物可以使單元測試活動成為可觀察的因素。對單元測試產(chǎn)出物進(jìn)行評審可以發(fā)現(xiàn)單元測試所覆蓋的測試用例是否真正執(zhí)行通過以及測試用例覆蓋是否充分。若單元測試評審過程中發(fā)現(xiàn)有測試用例未通過的或者遺漏的,則及時反饋給開發(fā)人員進(jìn)行糾正,從而避免了缺陷進(jìn)入下一道工序——Story 測試。
筆者曾經(jīng)在一個基于 SOA(Service Oriented Architecture)的項目中將單元測試過程中系統(tǒng)所產(chǎn)生的接口日志文件定義為單元測試產(chǎn)出物。在這個項目中,開發(fā)人員會將單元測試過程中每個測試用例執(zhí)行時系統(tǒng)所產(chǎn)生的接口日志文件按所覆蓋的測試用例的名稱進(jìn)行命名提交到配置庫上,然后知會其他項目組成員進(jìn)行評審。由于這個單元測試產(chǎn)出物能夠反映系統(tǒng)所要實現(xiàn)的功能,評審人員可以通過分析產(chǎn)出物判斷每個測試用例是否真正執(zhí)通過以及測試用例是否覆蓋充分。評審者把評審過程中發(fā)現(xiàn)的測試用例未通過或者未覆蓋等問題會整理成評審意見提交到配置庫上,并知會開發(fā)人員進(jìn)行處理。
表 4. 單元測試評審活動
posted on 2012-07-25 09:54 順其自然EVO 閱讀(481) 評論(0) 編輯 收藏 所屬分類: 測試學(xué)習(xí)專欄 、管理方向