1.問題的提出

當前軟件工程的監理規范基本是基于以文檔為驅動的瀑布式開發模型，即，在整個開發活動中要編制大量的文檔，在需求文檔評審通過后，開發人員根據文檔進行開發，一切以文檔為依據。明顯這種開發模式能較好地適用于成熟業務的軟件工程項目。

隨著改革的不斷推進，現實中的軟件工程項目大量出現了需求不確定的非成熟業務場景，甚至很多時候客戶對需求的感知和確認需要承建單位用適當的方式給予不斷地啟發。應對這種局面顯然更適合于敏捷開發(Agile Development)這種以人為核心、迭代、循序漸進的開發模式，但這也同時給基于現行軟件工程監理規范的監理工作造成了問題。

2.軟件工程監理成效的評價

現實中軟件工程項目對監理成效的評價應該有四個需要考慮的維度：

1）建設單位（含用戶單位）

這個維度的核心評價要素主要涉及項目過程是否清晰順暢，項目效果是否良好，項目涉及的各種風險是否規避、防范到位等。

2）承建單位

這個維度的核心評價要素主要涉及雙方工作目標是否一致，溝通是否專業、順利，項目控制措施是否必要及合情合理，控制實施時機是否對項目推進實質性有利等。

3）項目驗收組

項目控制是否清晰、合理，項目資料是否符合邏輯并能完整支撐項目工作、成果的自證，項目成果是否滿足***終質量目標—“用戶滿意”，是否滿足合同履約驗收條件等。

4）審計

項目管理是否與政策、法規有沖突（合規性），項目形成的資產是否滿足發包及合同要求的對價關系，項目形成的資產屬性是否清晰、已明晰記錄并可查證等。

3.敏捷開發模式下軟件工程監理工作要考慮的問題

上述維度中的各要素似乎與監理規范的關系并不大，因此現行監理規范似乎成了既要遵守卻又對監理成效評價其實沒啥影響的，甚至還會對項目產生負面影響的問題，而且這種影響特別在敏捷開發模式下的軟件工程項目中顯得尤為突出。

監理工作應圍繞上述監理成效評價要素開展，這樣***可取得******項目質量和提高工作效率之間的平衡，而不變的是監理工作的******目標之一，即順利推進項目，實現項目目的。監理工程師應為達成******目標貢獻驅動向前的正能量，特別不應是為了規范而規范，對項目推進形成干擾，造成拖項目后腿的效果。這種為規范而規范的工作思路不但不能提升企業核心競爭力，相反可能是實質性削弱。

由于與瀑布模式過程的各種狀態相差甚遠，敏捷開發模式下軟件工程為******項目順利推進監理工作需要思考、處理的問題***會很多，其中一個***是“需求評審后置”，這是監理工作如何適應敏捷開發模式軟件工程必須要考慮、處理的顯然而又核心問題之一。其余有關問題因篇幅有限以后再討論吧。

敏捷開發四句宣言對理解敏捷開發很有幫助：

個體與交互勝過過程與工具。

可以工作的軟件勝過面面俱到的文擋。

客戶協作勝過合同談判。

響應變化勝過遵循計劃。