軟件項(xiàng)目“免坑”指南
作者:網(wǎng)絡(luò)轉(zhuǎn)載 發(fā)布時間:[ 2012/4/25 17:32:29 ] 推薦標(biāo)簽:
● 預(yù)先行其事,必先利其器。用軟件武裝團(tuán)隊(duì)提高生產(chǎn)效率,例如:版本控制,錯誤跟蹤,信息發(fā)布,自動發(fā)布,CASE工具,調(diào)試工具,測試工具,文檔管理,代碼生成工具等等。
● 分析項(xiàng)目類型,在管理和構(gòu)建之間找尋平衡。商業(yè)系統(tǒng)、使命攸關(guān)的系統(tǒng)、性命攸關(guān)的系統(tǒng)在整個項(xiàng)目階段具備不同的控制粒度。需要根據(jù)項(xiàng)目的具體類型來確定管理的嚴(yán)謹(jǐn)程度,避免“過度控制”或“控制不足”。
● 需求必須被凍結(jié)。需求必須被凍結(jié),如果需求不能凍結(jié),那么誰來了都沒有用。再強(qiáng)的團(tuán)隊(duì)也無法完成一個無盡的任務(wù)。
● 變更必須走流程。正確應(yīng)對變更,變更并不可怕,可怕的是失控的變更。以下建議希望對讀者有所幫助:
在構(gòu)建期間處理需求變更
1、核對需求,評估質(zhì)量:如果需求不夠好,停下來,把它做好再開始。
2、確保每一個人都知道需求變更的代價:讓客戶知道需求辦更并不像在Excel上進(jìn)行幾個修改那樣容易,“進(jìn)度”和“成本”是你有力的武器。
3、建立一套變更控制程序:固定的變更控制程序讓你知道在什么時候處理變更,讓客戶知道你會處理他們的提議。
4、使用能適應(yīng)變更的開發(fā)方法:迭代與增量。
5、放棄這個項(xiàng)目:如果以上提議沒有一條奏效,需求變更極其頻繁,那么,評估你的項(xiàng)目,考慮放棄它吧,繼續(xù)下去你只會越陷越深。
6、注意項(xiàng)目的商業(yè)案例:性價比,沒必要滿足超出項(xiàng)目成本的需求。
● 關(guān)于加班。做IT的加班是很正常的,但加班要加的有意義,而且不應(yīng)該長期加班。必須針對關(guān)鍵路徑上的工作進(jìn)行趕工,而不是做些無法加快整體進(jìn)度的工作。而且,應(yīng)當(dāng)安排調(diào)休,而不是支付加班費(fèi)。其主要原因也是我不贊成加班的原因??疲勞更容易引人缺陷。加班無疑會使人疲勞,每個人都想盡快結(jié)束手上的工作后回家休息。在長期疲憊的情況下,人員的工作效率會下降,士氣會低落,非正常離職率增加,重要的是疲憊的團(tuán)隊(duì)很難保證軟件的質(zhì)量,缺陷在不知不覺中引人,在后期無疑會為此付出代價。項(xiàng)目的總成本和周期,都會隨著引人缺陷的數(shù)量的增加而倍增,而且發(fā)現(xiàn)的越晚越嚴(yán)重。
● 做好版本控制和配置管理。版本控制和配置管理是必須有的,即便是再小的項(xiàng)目也不能忽視,必須加以重視,一旦版本混亂,多多少少會對構(gòu)活動造成影響。所以,平時不要偷懶,管理好每個基線。
● 授權(quán)的好處。授權(quán)好處多多,包括:一,減少管理者工作量;二,對人員有意識地進(jìn)行鍛煉,培養(yǎng)儲備人才;三,提高人員對項(xiàng)目的參與度,從而提高士氣。
● 樂觀管理與悲觀管理。樂觀與悲觀完全取決于人的性格,一般來講多數(shù)傾向于樂觀,應(yīng)該清楚這兩種性格在項(xiàng)目中的優(yōu)勢與劣勢。我本人傾向于悲觀,可能是性格使然,但悲觀的管理至少不會誤事。樂觀管理的優(yōu)勢在于,很容易營造氣氛,擅長給客戶或領(lǐng)導(dǎo)描繪一個美好的未來。這種作風(fēng),前期很舒服,但后期可能要吃苦了。樂觀管理容易出現(xiàn)的問題是對風(fēng)險(xiǎn)的預(yù)計(jì)不足,不能預(yù)留充足的緩沖時間,沒有準(zhǔn)備足夠的預(yù)防措施。其表現(xiàn)是,在進(jìn)行進(jìn)度計(jì)劃時,總是認(rèn)為的問題可以解決,已經(jīng)修復(fù)的BUG將不會再次出現(xiàn),用戶需求是后一次變更,等等諸如此類的樂觀想法會使管理者蒙蔽雙眼,而沒有做足風(fēng)險(xiǎn)應(yīng)對,其結(jié)果是不管怎么加班是趕不上進(jìn)度,因?yàn)檫M(jìn)度計(jì)劃被設(shè)計(jì)為順利的情形,而不是現(xiàn)實(shí)場景。悲觀管理的好處是,為潛在風(fēng)險(xiǎn)做足了準(zhǔn)備。但悲觀管理有一個非常大的缺陷,是“過度控制”,可以比喻為“疑心病”(小心的都有些病態(tài)了)。其表現(xiàn)是為:按照之前的措施,發(fā)現(xiàn)遺漏了一個問題,那么悲觀管理者會在之前措施基礎(chǔ)上增加新的保障措施,然后又發(fā)現(xiàn)遺漏了一個問題,之后會繼續(xù)追加保障措施。乍看之下沒啥問題,因?yàn)槭窃诓粩嗟剡M(jìn)行過程改進(jìn),但問題出在保障措施的增長速度過于驚人,稱其為“疑心病”一點(diǎn)也不為過,悲觀管理者容易在很小的地方施加過多的控制,造成人日的浪費(fèi),而忽略掉本應(yīng)該關(guān)注的更為重要的問題。不管那種性格的管理,清楚自己的弱點(diǎn)總是好的。
● 有效的溝通,不要踢皮球。軟件項(xiàng)目因?yàn)槠浔旧淼膹?fù)雜度和涉眾眾多,所以更加需要溝通。溝通問題是所有大型項(xiàng)目都共用的問題,在大多數(shù)團(tuán)隊(duì)中往往也不認(rèn)為溝通是個問題。但我還是想請讀者認(rèn)真對待溝通,比如郵件。郵件可以回復(fù)的慢,但請回復(fù)郵件。當(dāng)我在一個連發(fā)出的郵件都沒人回復(fù)的團(tuán)隊(duì)中工作時,除了無法解決問題,讓我感受到的只有無奈以及冷漠。
● 客戶是我們的朋友。把你的客戶當(dāng)成朋友,客戶是我們做重要的資源之一。在每個客戶背后往往隱藏著更多潛在的客戶。我們必須清楚,客戶作為非專業(yè)人士,其可能并不理解我們的工作,在項(xiàng)目執(zhí)行階段產(chǎn)生摩擦是難免的。但是,這些都不能成為我們遷怒客戶或故意在工作中放水的借口。即便是為了項(xiàng)目能成功收尾,我們也必須維護(hù)好與客戶的關(guān)系。
● 不要超前設(shè)計(jì),不要項(xiàng)目鍍金。超前設(shè)計(jì)和項(xiàng)目鍍金都是不可取的,因?yàn)樗窃诶速M(fèi)資源。滿足需求以外的東西,不會對你的項(xiàng)目有任何好處,但是卻可能引人缺陷。
● 總結(jié)經(jīng)驗(yàn)教訓(xùn)。必須對階段進(jìn)行經(jīng)驗(yàn)教訓(xùn)總結(jié),沒有什么比這些收獲更有價值。這樣文檔是組織的資產(chǎn),是以后類似項(xiàng)目的參考和依據(jù),并在持續(xù)優(yōu)化方面發(fā)揮更為重要的作用。
● 不要讓會議和文檔拖了團(tuán)隊(duì)的后腿。“當(dāng)船快要沉的時候,我們需要的是一個發(fā)號施令的,而不是開會。”軟件項(xiàng)目的核心問題是降低復(fù)雜度,越是復(fù)雜的項(xiàng)目越需要溝通,但別讓開會拖了我們的后腿。沒有必要的會盡量少開或不開,要常開會,開小會,每次會議幾個相關(guān)干系人碰頭溝通下可以了,沒有必要擴(kuò)大為全員參與。冗長的討論應(yīng)該適時的終止,畢竟會議室上只能做出決策,而解決問題還得在會下。所以我認(rèn)為應(yīng)該精簡那些冗長的會議,別然開會成為我們的工作。此外,要時刻謹(jǐn)記客戶終需要的是可以良好運(yùn)行的軟件產(chǎn)品而不是華麗的文檔。所以,文檔要恰到好處,寫的再漂亮的文檔沒有完備的系統(tǒng)也不過是廢紙一堆,別丟了西瓜撿芝麻,可以正常工作的軟件才是我們的工作重心。
● 核對表的你的好助手。像飛機(jī)工程師在檢查飛機(jī)時使用核對表一樣,軟件項(xiàng)目也可以大量使用核對表。核對表可以幫助檢驗(yàn)文檔的質(zhì)量,降低缺陷數(shù)量,以及改進(jìn)項(xiàng)目管理。好的核對表,是你工作中的好助手。
● 小范圍的受控好過大范圍的失控。要注意控制的粒度,事無巨細(xì)。根據(jù)項(xiàng)目規(guī)模,人員構(gòu)成,要采用不同的控制粒度。評估可控范圍,并不是控制越廣越好,控制不了是失控。 對無暇顧及的地方授權(quán)別人管理是個可行的做法。 即便是小范圍是受控,也好過大范圍的失控。一個失控的項(xiàng)目,誰也不知道其會走向何方。
相關(guān)推薦
相關(guān)產(chǎn)品

最新發(fā)布
性能測試之測試環(huán)境搭建的方法
2020/7/21 15:39:32軟件測試是從什么時候開始被企業(yè)所重視的呢?
2020/7/17 9:09:11Android自動化測試框架有哪些?有什么用途?
2020/7/17 9:03:50什么樣的項(xiàng)目適合做自動化?自動化測試人員應(yīng)具備怎樣的能力?
2020/7/17 8:57:06幾大市面主流性能測試工具測評
2020/7/17 8:52:11RPA機(jī)器人能夠快速響應(yīng)企業(yè)需求,是怎么做到的?
2020/7/17 8:48:05Bug可以真正消滅嗎?為什么?
2020/7/17 8:43:03軟件測試基本概念是怎么來的?軟件測試生命周期的形成歷經(jīng)了什么?
2020/7/16 9:11:10