1）紧紧抓住“需求定义”，要求对方把所有需求都反映到文档中，定期Review这些文档（1周1回吧）
2）要求对方做出“整体计划”，在其中表现出各个重要的“里程碑”，然后根据整体计划制定各个阶段的“详细计划”
3）根据“详细计划”，定期检查项目进度，至少1周1回。首先得有“周报”，然后基于“周报”确认一下这一周的问题点，是否有延迟，下周是否有风险，共同商讨对策。
4）评价是否到达“里程碑”不能由对方随口报告，而是要由发注方对“需求定义”以及“代码”都比较熟悉的人，参与Reiew后，在问题点都基本解决的情况下，才可以判断为到达里程碑，可以进入到下一个开发阶段。
5）最容易出问题的阶段是编码实现阶段，因为有大量功能本身就存在一定的“歧义”，很难用简单的语言进行定义；大部分的开发人员会认为“开发出能用的产品”就OK了，而很多“可扩展性”、“可维护性”的东西很难在事前说下。为了解决这种问题，在编码之前，整合开发人员的思路，统一大家的意识，这些“设计”工作就很必要了；重要的整合内容务必保存为“设计资料”，在今后的代码审查阶段，要基于“需求定义”和“设计资料”这些上游资料进行检查
6）进入到测试阶段，相对就比较好管理了，把所有的“测试用例”都消化完的计划做好，每个“Bug”的类似问题都检查一下，需要重新测试的部分重新回归测试一下
7）最好在每个阶段的开始和结束之间留下一些预留的空档，哪怕仅有2、3天，一来是预留对应风险的时间，二来是调整一下开发人员的节奏，总结、反省一下上游工程的问题点，规避一下下游工程可能发生的风险和问题.
此文章由 http://www.ositren.com 收集整理 ,地址为: http://www.ositren.com/htmls/67142.html
2）要求对方做出“整体计划”，在其中表现出各个重要的“里程碑”，然后根据整体计划制定各个阶段的“详细计划”
3）根据“详细计划”，定期检查项目进度，至少1周1回。首先得有“周报”，然后基于“周报”确认一下这一周的问题点，是否有延迟，下周是否有风险，共同商讨对策。
4）评价是否到达“里程碑”不能由对方随口报告，而是要由发注方对“需求定义”以及“代码”都比较熟悉的人，参与Reiew后，在问题点都基本解决的情况下，才可以判断为到达里程碑，可以进入到下一个开发阶段。
5）最容易出问题的阶段是编码实现阶段，因为有大量功能本身就存在一定的“歧义”，很难用简单的语言进行定义；大部分的开发人员会认为“开发出能用的产品”就OK了，而很多“可扩展性”、“可维护性”的东西很难在事前说下。为了解决这种问题，在编码之前，整合开发人员的思路，统一大家的意识，这些“设计”工作就很必要了；重要的整合内容务必保存为“设计资料”，在今后的代码审查阶段，要基于“需求定义”和“设计资料”这些上游资料进行检查
6）进入到测试阶段，相对就比较好管理了，把所有的“测试用例”都消化完的计划做好，每个“Bug”的类似问题都检查一下，需要重新测试的部分重新回归测试一下
7）最好在每个阶段的开始和结束之间留下一些预留的空档，哪怕仅有2、3天，一来是预留对应风险的时间，二来是调整一下开发人员的节奏，总结、反省一下上游工程的问题点，规避一下下游工程可能发生的风险和问题.
此文章由 http://www.ositren.com 收集整理 ,地址为: http://www.ositren.com/htmls/67142.html