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

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

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