實(shí)踐中的敏捷開發(fā)之如何管理項(xiàng)目質(zhì)量

1、 實(shí)踐中的敏捷開發(fā)之如何管理項(xiàng)目質(zhì)量 【常見的質(zhì)量問題現(xiàn)象】軟件質(zhì)量問題很大程度上可以從其開發(fā)過程上表現(xiàn)出來。在缺乏有效項(xiàng)目管理的團(tuán)隊(duì)中，下面的現(xiàn)象我相信是典型的。一個(gè)功能第一次轉(zhuǎn)測的時(shí)候，測試人員能夠發(fā)現(xiàn)n個(gè)低級(jí)錯(cuò)誤型的bug。接著開發(fā)人員”改完”代碼后，測試人員進(jìn)行回歸測試?yán)^續(xù)發(fā)現(xiàn)n個(gè)bug。這些bug有些是第一輪測試中發(fā)現(xiàn)的bug沒有修復(fù)正確或者完全的，而很大一部分可能是因修改之前的bug而引入的新bug。于是，這種現(xiàn)象不斷得在第三次、第四次回歸測試中出現(xiàn)。上面的現(xiàn)象就是典型的返工。返工不僅浪費(fèi)了時(shí)間和人力，也是質(zhì)量問題的標(biāo)志。而最后交付的功能還有若干bug被發(fā)現(xiàn)。因?yàn)椋瑴y試人員漏測試了

2、?！驹蚍治雠c解決問題的經(jīng)驗(yàn)分享】質(zhì)量問題的產(chǎn)生原因主要有兩個(gè)因素:個(gè)人的因素和項(xiàng)目管理的因素。人的因素主要有開發(fā)人員、測試人員的知識(shí)、能力和經(jīng)驗(yàn)以及工作習(xí)慣。比如，雖然敏捷開發(fā)一直強(qiáng)調(diào)測試先行。但是，仍然有很多開發(fā)人員習(xí)慣于先編碼后測試。更為不好的是，很多開發(fā)人員習(xí)慣于把所有代碼都”寫好”，然后集中對這些代碼進(jìn)行測試。這樣做的結(jié)果往往是一個(gè)地方發(fā)現(xiàn)的問題往往在其它地方也存在。于是，他不得不重復(fù)得修改這些問題。這種情形不僅浪費(fèi)了他們的寶貴時(shí)間。也往往使問題沒有被徹底修正。另外，很多沒有計(jì)算機(jī)專業(yè)背景的人被培訓(xùn)機(jī)構(gòu)以高薪為誘惑被培訓(xùn)為測試人員。對于這些測試人員，當(dāng)被測試的對象的技術(shù)性比較鮮明的時(shí)

3、候，他們往往不知怎么測試。但是，人的因素往往很難短期內(nèi)有所改善。所以，我將重點(diǎn)從項(xiàng)目管理的角度來分析。返工和漏測試是軟件質(zhì)量的兩大問題。返工從項(xiàng)目管理的角度看，很大程度上是因?yàn)槿狈τ行У牧鞒炭刂?。即，在一個(gè)功能轉(zhuǎn)測試人員進(jìn)行測試前，沒有檢查其質(zhì)量是否滿足一定的要求最低質(zhì)量要求。這一點(diǎn)，其實(shí)可以借鑒建筑工程中的材料驗(yàn)收。比如，建設(shè)一棟大樓，其所需的鋼筋水泥等材料如果我們不在使用它們前檢查其質(zhì)量是否符合要求。那么，后面才發(fā)現(xiàn)它們的質(zhì)量問題則必然要返工。關(guān)于如何進(jìn)行流程控制，以使被轉(zhuǎn)測的功能符合最低質(zhì)量要求，可以借鑒下story演示這個(gè)具體實(shí)踐。感興趣的讀者可以借鑒下ibm developerworks網(wǎng)站上的文章:當(dāng)然，質(zhì)量問題是一個(gè)系統(tǒng)性的問題。那么，解決這個(gè)問題的方法也必然是要系統(tǒng)性。另外，管理不是照著菜譜做菜。管理者必須要掌握一套質(zhì)量管理的方法，而非”拷貝”所謂優(yōu)秀實(shí)踐。學(xué)習(xí)優(yōu)秀實(shí)踐的意義在于掌握其背后所體現(xiàn)的方法與思想。下面的文章中以這樣的一種思路分享了基于“經(jīng)