不應(yīng)忽視小型項(xiàng)目開發(fā)的管理問題

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

小型軟件項(xiàng)目，通常是指工作量在3-12人月之間的項(xiàng)目，在小型軟件開發(fā)企業(yè)中，這類項(xiàng)目一般是放任自流，少有管理。在這類項(xiàng)目中，項(xiàng)目經(jīng)理的角色常常由公司老總或部門老總親自充當(dāng)， 項(xiàng)目往往具有投資少、人員少、時(shí)間緊、需求不明確等特點(diǎn)。由于針對(duì)小型項(xiàng)目，缺乏科學(xué)有效的管理方式，或企業(yè)難以負(fù)擔(dān)類似于大型軟件開發(fā)的管理成本，這類項(xiàng)目的開發(fā)過程往往會(huì)產(chǎn)生諸如項(xiàng)目進(jìn)度難以控制、產(chǎn)品缺陷多、后期維護(hù)工作量大、客戶滿意度低、文檔缺乏等諸多問題。一項(xiàng)調(diào)查表明，大約有70%的小型軟件開發(fā)項(xiàng)目超出了預(yù)期時(shí)間，90%以上的項(xiàng)目費(fèi)用超出預(yù)算。因此，小型項(xiàng)目迫切需要引入適度的開發(fā)管理。本文將針對(duì)小型軟件項(xiàng)目開發(fā)過程中的核心管理問題給出一些行之有效的解決方案。
　　一、需求管理
　　對(duì)于任何類型的軟件項(xiàng)目，需求階段都是最重要的階段，需求管理是整個(gè)軟件項(xiàng)目管理的重中之重。需求管理通常包括兩個(gè)大方面的問題：需求收集分析與需求變更管理。
　　首先，對(duì)于需求收集與分析，核心風(fēng)險(xiǎn)來自于需求不明確。由于客戶和軟件開發(fā)團(tuán)隊(duì)的背景不同，對(duì)同一問題的理解自然存在差異。這些差異如果不能在需求的最初階段盡量彌合，那么必然導(dǎo)致需求增加與需求更改。因此，在需求分析階段，要求需求分析人員具有豐富的客戶溝通經(jīng)驗(yàn)，必須多花一些時(shí)間，充分了解用戶的目標(biāo)與工作過程，站在客戶立場(chǎng)上，設(shè)身處地考慮問題，幫助用戶將模糊的需求清晰化，將簡(jiǎn)略的需求明細(xì)化、完善化，將混亂的需求邏輯化、條理化。
　　其次，任何項(xiàng)目都無(wú)法承受頻繁的需求變更與需求增加。因此，除了在需求收集階段需要盡可能將需求細(xì)化外，還需要在適當(dāng)階段盡量?jī)鼋Y(jié)需求。公司的銷售人員往往傾向于接受用戶模糊的要求，并暗示用戶“什么都好商量”。這往往給項(xiàng)目后期甚至項(xiàng)目完成后又頻繁更改需求，甚至導(dǎo)致項(xiàng)目嚴(yán)重拖延、開支嚴(yán)重超出預(yù)算埋下禍根。因此，在需求細(xì)化的后期階段，必須“拉下臉來”，就需求凍結(jié)和后期需求增加的費(fèi)用支付方式和客戶達(dá)成共識(shí)。
　　二、關(guān)注項(xiàng)目設(shè)計(jì)的靈活性
　　對(duì)于中小型項(xiàng)目，在設(shè)計(jì)過程中，必須關(guān)注設(shè)計(jì)的靈活性。在實(shí)際的項(xiàng)目中，即使在需求階段花再多的經(jīng)歷，也沒法完全避免開發(fā)階段的需求變更。因此，在架構(gòu)設(shè)計(jì)中，盡可能采用靈活的設(shè)計(jì)就至關(guān)重要。對(duì)于項(xiàng)目設(shè)計(jì)人員，可以借鑒RUP(Rational Unified Process)中基于組建的體系結(jié)構(gòu)思想，利用基于獨(dú)立的、可替換的、模塊化組件的體系結(jié)構(gòu)管理復(fù)雜性，提高重用率，構(gòu)建有彈性的、能適應(yīng)變化的、易于理解的、有助于重用的體系結(jié)構(gòu)。
　　三、開發(fā)進(jìn)度管理
　　開發(fā)進(jìn)度管理，主要需要關(guān)注如下幾個(gè)方面：
　　1. 任務(wù)分配、人力資源分配、時(shí)間分配要和工程進(jìn)度協(xié)調(diào);
　　2. 任務(wù)分解要合理，并且盡量并行化;
　　3. 對(duì)項(xiàng)目進(jìn)度控制要盡量細(xì)致，并且在實(shí)際執(zhí)行過程中審查要嚴(yán)格;
　　4. 針對(duì)項(xiàng)目中不容易控制的部分，譬如技術(shù)難點(diǎn)、來自于客戶的時(shí)間拖延要做好充分的準(zhǔn)備;
　　5. 要為測(cè)試、缺陷修正和預(yù)期的需求變更預(yù)留足夠的時(shí)間;
　　如有必要，還應(yīng)采用適當(dāng)?shù)膮f(xié)同進(jìn)度管理工具。
　　四、開發(fā)團(tuán)隊(duì)管理
　　對(duì)于開發(fā)團(tuán)隊(duì)管理，要做到分工明確、因人施用。根據(jù)水平的高低，合理分配工作量。并且關(guān)注團(tuán)隊(duì)內(nèi)部的交流溝通結(jié)構(gòu)，避免“互相等”和“誤解”。盡量讓每個(gè)人的工作量飽和化。在項(xiàng)目開始以后，要盡可能保持團(tuán)隊(duì)穩(wěn)定，避免人員變更給團(tuán)隊(duì)帶來的協(xié)作混亂。
　　五、配置管理和SQA
　　軟件配置管理(SCM)的主要作用是標(biāo)識(shí)、控制、和狀態(tài)統(tǒng)計(jì)。
　　這些功能的意圖是維護(hù)和跟蹤功能、配置、產(chǎn)品、產(chǎn)品基線、需求規(guī)約和其他文檔的變更，軟件版本的描述;跟蹤變更申請(qǐng)，問題報(bào)告和解決記錄，提供配置控件委員會(huì)(CCB)會(huì)議紀(jì)要等。
　　軟件開發(fā)之后的變更需要從多個(gè)側(cè)面加以注意:
　　1. 任何返工都是有代價(jià)的
　　2. 將資源用于返工則無(wú)法開展新項(xiàng)目 項(xiàng)目管理者聯(lián)盟，項(xiàng)目管理問題。
　　3. 如果變更不能精確的標(biāo)識(shí)和控制，那么軟件的版本就會(huì)因?yàn)槲粗蜎]有記錄的修改而無(wú)法跟蹤
　　4. 如果變更沒有考慮到所有的副作用，那么對(duì)于一個(gè)變更所引起的連鎖反應(yīng)的跟蹤是非常費(fèi)時(shí)間的
　　5. 變更次數(shù)的增加會(huì)使系統(tǒng)面目全非
　　當(dāng)項(xiàng)目經(jīng)常變更時(shí)候，SQA是非常重要的。SQA應(yīng)該進(jìn)行Pareto分析和趨勢(shì)分析以確定引起變更的根本原因。SQA同時(shí)要保證系統(tǒng)的影響是可跟蹤、可測(cè)試和可驗(yàn)證的。SQA的一個(gè)主要目標(biāo)是在開發(fā)的早期發(fā)現(xiàn)問題，避免其進(jìn)入下游開發(fā)中。
　　六、文檔管理
　　對(duì)于小型項(xiàng)目，首先，必須有文檔要求，否則后期的修改、維護(hù)、升級(jí)都會(huì)變得異常困難;其次，對(duì)文檔的要求應(yīng)該“適度”，即夠用即可。一切以便于后續(xù)工作為目標(biāo)，不做過于繁瑣的要求，不應(yīng)把大量精力投入進(jìn)過于繁瑣的文檔編寫。此外，還應(yīng)注意文檔的版本控制，保證文檔和代碼的一致性。 考試大編輯整理