1.问题的提出
当前软件工程的监理规范基本是基于以文档为驱动的瀑布式开发模型，即，在整个开发活动中要编制大量的文档，在需求文档评审通过后，开发人员根据文档进行开发，一切以文档为依据。明显这种开发模式能较好地适用于成熟业务的软件工程项目。
随着改革的不断推进，现实中的软件工程项目大量出现了需求不确定的非成熟业务场景，甚至很多时候客户对需求的感知和确认需要承建单位用适当的方式给予不断地启发。应对这种局面显然更适合于敏捷开发(Agile Development)这种以人为核心、迭代、循序渐进的开发模式，但这也同时给基于现行软件工程监理规范的监理工作造成了问题。
2.软件工程监理成效的评价
现实中软件工程项目对监理成效的评价应该有四个需要考虑的维度：
1）建设单位（含用户单位）
这个维度的核心评价要素主要涉及项目过程是否清晰顺畅，项目效果是否良好，项目涉及的各种风险是否规避、防范到位等。
2）承建单位
这个维度的核心评价要素主要涉及双方工作目标是否一致，沟通是否专业、顺利，项目控制措施是否必要及合情合理，控制实施时机是否对项目推进实质性有利等。
3）项目验收组
项目控制是否清晰、合理，项目资料是否符合逻辑并能完整支撑项目工作、成果的自证，项目成果是否满足***终质量目标—“用户满意”，是否满足合同履约验收条件等。
4）审计
项目管理是否与政策、法规有冲突（合规性），项目形成的资产是否满足发包及合同要求的对价关系，项目形成的资产属性是否清晰、已明晰记录并可查证等。
3.敏捷开发模式下软件工程监理工作要考虑的问题
上述维度中的各要素似乎与监理规范的关系并不大，因此现行监理规范似乎成了既要遵守却又对监理成效评价其实没啥影响的，甚至还会对项目产生负面影响的问题，而且这种影响特别在敏捷开发模式下的软件工程项目中显得尤为突出。
监理工作应围绕上述监理成效评价要素开展，这样***可取得******项目质量和提高工作效率之间的平衡，而不变的是监理工作的******目标之一，即顺利推进项目，实现项目目的。监理工程师应为达成******目标贡献驱动向前的正能量，特别不应是为了规范而规范，对项目推进形成干扰，造成拖项目后腿的效果。这种为规范而规范的工作思路不但不能提升企业核心竞争力，相反可能是实质性削弱。
由于与瀑布模式过程的各种状态相差甚远，敏捷开发模式下软件工程为******项目顺利推进监理工作需要思考、处理的问题***会很多，其中一个***是“需求评审后置”，这是监理工作如何适应敏捷开发模式软件工程必须要考虑、处理的显然而又核心问题之一。其余有关问题因篇幅有限以后再讨论吧。
敏捷开发四句宣言对理解敏捷开发很有帮助：
个体与交互胜过过程与工具。
可以工作的软件胜过面面俱到的文挡。
客户协作胜过合同谈判。
响应变化胜过遵循计划。
微信扫一扫