在軟件開發(fā)中,質(zhì)量很重要(這個(gè)估計(jì)誰都知道)，但是很多時(shí)候質(zhì)量看上去卻又不能保證（基于進(jìn)度壓力下）。然后，就亂了… 這個(gè)情景我想大多數(shù)人都經(jīng)歷著，呵呵。

“高質(zhì)量、高口碑的軟件開始于好的分析與設(shè)計(jì)階段，并不是靠后期的測(cè)試與修補(bǔ)來完成的”

我就發(fā)表下下面這幾個(gè)階段會(huì)影響質(zhì)量的地方吧：

1. 分析與設(shè)計(jì)階段
2. 計(jì)劃安排
3. 開發(fā)階段

一、分析與設(shè)計(jì)階段

如何才能做好這個(gè)步驟呢？要獲取用戶真正的需求，同時(shí)考慮好可能產(chǎn)生變化的需求點(diǎn)，我認(rèn)為這兩點(diǎn)基本上能保證分析與設(shè)計(jì)階段的高質(zhì)量進(jìn)行了。這里PM是肯定要花大功夫的，由于這里的“可能產(chǎn)生變化的需求點(diǎn)”需要比較好的業(yè)務(wù)領(lǐng)域知識(shí)，所以PM就要做足這個(gè)行業(yè)的功課了。呵呵，關(guān)于PM的工作部分，我不是很清楚…

二、計(jì)劃安排

上面所提的亂，出現(xiàn)的原因很多時(shí)候是因?yàn)闀r(shí)間問題。所以我認(rèn)為也需要在計(jì)劃安排這里花大力氣---列出的計(jì)劃需要周詳，不能缺少步驟，并且時(shí)間上是差不多夠的。當(dāng)然要是上級(jí)要求必須在某某時(shí)間完成，這時(shí)怎么辦？那就需要這個(gè)項(xiàng)目負(fù)責(zé)人對(duì)上級(jí)提出異議，保護(hù)這個(gè)團(tuán)隊(duì)。

三、開發(fā)階段

采用迭代開發(fā)時(shí)，往往是先開發(fā)部分功能，接著QA測(cè)試那些完成的功能。假如開發(fā)的質(zhì)量有問題，比如很多低級(jí)錯(cuò)誤、又或者很不穩(wěn)定，這樣的程序交給QA去測(cè)試，QA看了后不暈才怪，連看都不想去看了（情有可原）。QA測(cè)試不通過，必然開發(fā)人員再去進(jìn)行修改，所以時(shí)間會(huì)根據(jù)質(zhì)量的高低程度產(chǎn)生急劇的浪費(fèi)！這里有很多原因發(fā)生開發(fā)質(zhì)量不高，比如：主觀上的不做單元測(cè)試、客觀上的由于進(jìn)度緊不做單元測(cè)試，湊合著交給QA

1.主觀上的不做單元測(cè)試

a.這個(gè)要么是開發(fā)人員根本不知道單元測(cè)試是何物（估計(jì)沒多少人是這個(gè)原因）

b.或者過渡信任自己的程序沒有bug

這個(gè)只要適當(dāng)提醒下就行了

c.不積極工作的表現(xiàn)

這個(gè)需要注意阿！很危險(xiǎn)了

2.客觀上的由于進(jìn)度緊不做單元測(cè)試

a.一種是由于原先計(jì)劃安排上有問題

這個(gè)我想也就只能通過排計(jì)劃的那人考慮周詳點(diǎn)、需求要在排計(jì)劃之前就要90%弄清楚（不知道90%是不是太高了…）

b.一種是所采用的技術(shù)需要攻關(guān)

技術(shù)研發(fā)部門要抓緊時(shí)間了，研發(fā)部門內(nèi)部損耗來了，要解決

c.一種是由于需求老有問題導(dǎo)致了開發(fā)階段較多的非開發(fā)時(shí)間的產(chǎn)生，而消耗了本該屬于開發(fā)的時(shí)間

需求獲取有問題，或者分析那里不夠細(xì)致，可能是分析時(shí)想的不夠細(xì)，還存在著許多想當(dāng)然的東西，沒有分析到能夠交給開發(fā)人員做的地步（這地方有挑戰(zhàn)！）

d.還有一種是a+b+c，哈哈（這種還居多）

阿門，依次解決上面幾個(gè)問題吧

原文鏈接：http://www.cnblogs.com/aarond/archive/2011/05/11/2043785.html

【編輯推薦】

1. 新手軟件項(xiàng)目經(jīng)理之誰是你的敵人？ 
2. 新手軟件項(xiàng)目經(jīng)理該如何入門
3. 項(xiàng)目經(jīng)理的力量應(yīng)該從哪里來？
4. 軟件項(xiàng)目管理總體流程設(shè)計(jì)
5. 新手軟件項(xiàng)目經(jīng)理之最后期限的迷局