對于小型 項目,首先,必須有文檔要求,否則后期的修改、維護、升級都會變得異常困難;其次,對文檔的要求應該“適度”,即夠用即可。一切以便于后續工作為目標,不 做過于繁瑣的要求,不應把大量精力投入進過于繁瑣的文檔編寫。此外,還應注意文檔的版本控制,保證文檔和代碼的一致性。

  小型軟件項目,通常是指工作量在3-12人月之間的項目,在小型軟件開發企業中,這類項目一般是放任自流,少有管理。在這類項目中,項目經理的 角色常常由公司老總或部門老總親自充當, 項目往往具有投資少、人員少、時間緊、需求不明確等特點。由于針對小型項目,缺乏科學有效的管理方式,或企業難以負擔類似于大型軟件開發的管理成本,這類 項目的開發過程往往會產生諸如項目進度難以控制、產品缺陷多、后期維護工作量大、客戶滿意度低、文檔缺乏等諸多問題。一項調查表明,大約有70%的小型軟 件開發項目超出了預期時間,90%以上的項目費用超出預算。因此,小型項目迫切需要引入適度的開發管理。本文將針對小型軟件項目開發過程中的核心管理問題 給出一些行之有效的解決方案。

  一、需求管理

  對于任何類型的軟件項目,需求階段都是最重要的階段,需求管理是整個軟件項目管理的重中之重。需求管理通常包括兩個大方面的問題:需求收集分析與需求變更管理。

  首先,對于需求收集與分析,核心風險來自于需求不明確。由于客戶和軟件開發團隊的背景不同,對同一問題的理解自然存在差異。這些差異如果不能在 需求的最初階段盡量彌合,那么必然導致需求增加與需求更改。因此,在需求分析階段,要求需求分析人員具有豐富的客戶溝通經驗,必須多花一些時間,充分了解 用戶的目標與工作過程,站在客戶立場上,設身處地考慮問題,幫助用戶將模糊的需求清晰化,將簡略的需求明細化、完善化,將混亂的需求邏輯化、條理化。

  其次,任何項目都無法承受頻繁的需求變更與需求增加。因此,除了在需求收集階段需要盡可能將需求細化外,還需要在適當階段盡量凍結需求。公司的 銷售人員往往傾向于接受用戶模糊的要求,并暗示用戶“什么都好商量”。這往往給項目后期甚至項目完成后又頻繁更改需求,甚至導致項目嚴重拖延、開支嚴重超 出預算埋下禍根。因此,在需求細化的后期階段,必須“拉下臉來”,就需求凍結和后期需求增加的費用支付方式和客戶達成共識。

  二、關注項目設計的靈活性

  對于中小型項目,在設計過程中,必須關注設計的靈活性。在實際的項目中,即使在需求階段花再多的經歷,也沒法完全避免開發階段的需求變更。因此,在架構設計中,盡可能采用靈活的設計就至關重要。對于項目設計人員,可以借鑒RUP(Rational Unified Process)中基于組建的體系結構思想,利用基于獨立的、可替換的、模塊化組件的體系結構管理復雜性,提高重用率,構建有彈性的、能適應變化的、易于理解的、有助于重用的體系結構。

  三、開發進度管理

  開發進度管理,主要需要關注如下幾個方面:

  1. 任務分配、人力資源分配、時間分配要和工程進度協調;

  2. 任務分解要合理,并且盡量并行化;

  3. 對項目進度控制要盡量細致,并且在實際執行過程中審查要嚴格;

  4. 針對項目中不容易控制的部分,譬如技術難點、來自于客戶的時間拖延要做好充分的準備;

  5. 要為測試、缺陷修正和預期的需求變更預留足夠的時間;

  如有必要,還應采用適當的協同進度管理工具。

  四、開發團隊管理

  對于開發團隊管理,要做到分工明確、因人施用。根據水平的高低,合理分配工作量。并且關注團隊內部的交流溝通結構,避免“互相等”和“誤解”。盡量讓每個人的工作量飽和化。在項目開始以后,要盡可能保持團隊穩定,避免人員變更給團隊帶來的協作混亂。

  五、配置管理和SQA

  軟件配置管理(SCM)的主要作用是標識、控制、和狀態統計。

  這些功能的意圖是維護和跟蹤功能、配置、產品、產品基線、需求規約和其他文檔的變更,軟件版本的描述;跟蹤變更申請,問題報告和解決記錄,提供配置控件委員會(CCB)會議紀要等。

  軟件開發之后的變更需要從多個側面加以注意:

  1. 任何返工都是有代價的

  2. 將資源用于返工則無法開展新項目

  3. 如果變更不能精確的標識和控制,那么軟件的版本就會因為未知和沒有記錄的修改而無法跟蹤

  4. 如果變更沒有考慮到所有的副作用,那么對于一個變更所引起的連鎖反應的跟蹤是非常費時間的

  5. 變更次數的增加會使系統面目全非

  當項目經常變更時候,SQA是非常重要的。SQA應該進行Pareto分析和趨勢分析以確定引起變更的根本原因。SQA同時要保證系統的影響是可跟蹤、可測試和可驗證的。SQA的一個主要目標是在開發的早期發現問題,避免其進入下游開發中。

  六、文檔管理

  對于小型項目,首先,必須有文檔要求,否則后期的修改、維護、升級都會變得異常困難;其次,對文檔的要求應該“適度”,即夠用即可。一切以便于 后續工作為目標,不做過于繁瑣的要求,不應把大量精力投入進過于繁瑣的文檔編寫。此外,還應注意文檔的版本控制,保證文檔和代碼的一致性。

Blogged with the Flock Browser

Tags: , ,