qileilove

          blog已經(jīng)轉(zhuǎn)移至github,大家請訪問 http://qaseven.github.io/

          敏捷項目管理實戰(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. 單元測試評審活動



            面對面代碼復(fù)審

            在比較常見的輕型代碼復(fù)審過程中,開發(fā)人員提交代碼到配置庫上,然后代碼復(fù)審人員從配置庫上獲取相應(yīng)代碼并借助一些代碼復(fù)審工具將復(fù)審結(jié)果形成意見提交給代碼作者進(jìn)行處理,并跟蹤復(fù)審意見的處理結(jié)果。代碼復(fù)審人員往往只在復(fù)審過程中有疑問的情況下才找代碼作者進(jìn)行確認(rèn)。這種輕型的代碼復(fù)審復(fù)審表面上執(zhí)行起來比較容易,成本也比較低。但是它和《敏捷宣言》中提到的“個人與交互勝過過程與工具”這一價值觀是相違背的。因為它缺乏有效的人與人間的交互。這種缺乏人員間交互的方式也導(dǎo)致了評審結(jié)果最終呈現(xiàn)給代碼作者的往往是問題。這一方面使得代碼作者只是被動得發(fā)現(xiàn)問題和解決問題。被動得發(fā)現(xiàn)和解決問題往往導(dǎo)致當(dāng)事人對問題及其解決方法印象不深刻從而極易導(dǎo)致相同或者類似問題重復(fù)得出現(xiàn)。雖然我們可以將復(fù)審過程中典型的問題形成檢查表由開發(fā)人員在代碼提交前對檢查表中的項目進(jìn)行自檢,但是這個檢查表往往也是在重復(fù)的問題被重復(fù)得發(fā)現(xiàn)后才形成的。另一方面,這種代碼復(fù)審?fù)o代碼作者一種“挑刺”的感覺,而作者自認(rèn)為代碼中比較優(yōu)雅的部分往往也被人忽略了,因為那不是問題因此復(fù)審人員也不會將其指出。這容易導(dǎo)致開發(fā)人員對代碼復(fù)審的本能性排斥心理,因為人總是傾向于被他人肯定,而不是總是被人指出問題。

            筆者在所帶的項目中開展面對面代碼復(fù)審。面對面代碼復(fù)審活動中,代碼作者通過電腦顯示器或者投影儀向其他參與人展示其代碼并逐行對其代碼進(jìn)行講解。其他參與人則對其講解進(jìn)行分析判斷,并將其分析判斷的結(jié)果提出同其他復(fù)審人員進(jìn)行討論。復(fù)審人員發(fā)現(xiàn)比較優(yōu)雅的代碼時可以及時指出來,并對代碼作者給予肯定。因此,面對面代碼復(fù)審某種程度上也是編程經(jīng)驗和優(yōu)秀實踐的一個交流形式。另外,對于經(jīng)過討論后確認(rèn)的問題則記入代碼復(fù)審意見表由復(fù)審人員跟蹤其處理結(jié)果。代碼作者對其代碼講解的過程某種程度上說也是其本人對其代碼進(jìn)行回顧和再思考的過程。因此,代碼講解過程中,講解人往往會自己發(fā)現(xiàn)代碼中的問題,從而對發(fā)現(xiàn)的問題有深刻的印象,這有助于避免同樣或者類似的問題再次產(chǎn)生。另一方面,由于代碼中的問題會當(dāng)眾暴露出來,對代碼往往有種敝帚自珍心理的開發(fā)人員在代碼復(fù)審前會小小謹(jǐn)慎地去檢查代碼,從而避免“當(dāng)眾出丑”。因此,面對面的代碼復(fù)審某種程度上也是一種缺陷預(yù)防的措施。

          表 5. 面對面代碼復(fù)審活動

            Story演示與轉(zhuǎn)測試控制

            《左傳·莊公十年》提到“夫戰(zhàn),勇氣也!一鼓作氣,再而衰,叁而竭”。返工不僅增加了成本,阻礙了進(jìn)度,還影響了士氣降低了質(zhì)量。返工往往是由于某道工序缺乏它的入口條件控制。比如,Story 轉(zhuǎn)測試這道工序如果沒有控制其入口條件,則很容易由于事先未評估被轉(zhuǎn)測的 Story 質(zhì)量導(dǎo)致在測試時仍然有大量的缺陷存在。這就意味著在第一次轉(zhuǎn)測試后,開發(fā)人員需要修復(fù)大量的缺陷,并且開發(fā)人員在修復(fù)缺陷的過程中往往又引入了新的缺陷,進(jìn)而導(dǎo)致了對于同一個 Story 需要進(jìn)行多次修復(fù)缺陷和多次轉(zhuǎn)測試的工序才能使這個 Story 滿足質(zhì)量要求。

            因此,對 Story 轉(zhuǎn)測試這道工序進(jìn)行入口控制可以有效避免返工現(xiàn)象。任何一個 Story 在其轉(zhuǎn)測試前,我們要首先評估其質(zhì)量是否滿足一定的要求才決定其能否轉(zhuǎn)測試。

            筆者在所帶項目中通常以 Story 演示作為 Story 的轉(zhuǎn)測試控制。Story 演示要求開發(fā)人員在 Story 轉(zhuǎn)測試前召集該 Story 的測試人員及其他相關(guān)人員對該 Story 的各個驗收測試用例的執(zhí)行情況進(jìn)行展示。其他參與演示的人員則根據(jù)展示的結(jié)果分析各個驗收測試用例是否真正通過,進(jìn)而評價所演示的 Story 的質(zhì)量水平并決定所演示的 Story 能否轉(zhuǎn)測。

            Story 演示過程發(fā)現(xiàn)的問題以及疑問可以記錄入 Story 演示記錄。Story 演示記錄樣例見表 6。

          表 6. Story 演示活動

          表 7. Story 演示記錄樣例

            結(jié)論

            經(jīng)驗過程控制模型為敏捷質(zhì)量管理提供了一個簡單易行的理論指導(dǎo)。缺陷預(yù)防是質(zhì)量管理的一個重要思想,而經(jīng)驗過程控制模型可以幫助我們具體實施缺陷預(yù)防。另外,敏捷宣言所體現(xiàn)的敏捷價值觀也為質(zhì)量管理提供了思想指導(dǎo)。




          posted on 2012-07-25 09:54 順其自然EVO 閱讀(481) 評論(0)  編輯  收藏 所屬分類: 測試學(xué)習(xí)專欄管理方向

          <2012年7月>
          24252627282930
          1234567
          891011121314
          15161718192021
          22232425262728
          2930311234

          導(dǎo)航

          統(tǒng)計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 云龙县| 青岛市| 铅山县| 米脂县| 永和县| 清水河县| 潮安县| 清苑县| 东乡县| 西充县| 裕民县| 萍乡市| 平顶山市| 凤山县| 深泽县| 翁牛特旗| 宜春市| 宁乡县| 彭泽县| 桦甸市| 壶关县| 广灵县| 陵水| 邢台县| 澄江县| 齐齐哈尔市| 天峨县| 女性| 韶关市| 南开区| 永泰县| 白银市| 郧西县| 城步| 嵊州市| 西安市| 苏尼特右旗| 景洪市| 民勤县| 五常市| 平和县|