敏捷项目管理

敏捷的框架来做事：有角色的划分，任务的分解，有各种会议，也有sprint - 但迭代过程是随意、松散的、没有任何约束的，所以失败。

1-明确了短期目标，一个迭代在两周左右，可以明确告诉客户，在一个迭代周期内，只能完成200个里面的40个，先做最有价值的前20个。

2-便于进度控制和风险预测。

3-检视与调整，逐步完善的过程 ， 迭代结束之后，产生可交付的成果，给客户演示，及早获得反馈，小步前进，不停思考，反省和总结。不停地进行自我检视，调整和完善，一步步走向卓越。

灵活运用敏捷开发

项目负责人还要懂得“做人”。和客户方负责人、联系人保持良好的关系是非常非常重要的

敏捷开发中，注重概念和架构设计，而轻详细设计

概念设计： 可以看出为何要做这个模块，强调的是产品路线规划，市场趋势，客户价值 和技术趋势等

架构设计，可以看成从整体上看，概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。

详细设计，则是具体的设计和做法、API接口等。

SWOT 分析，在敏捷开发中，更加注重客户需求。对产品进行SWOT分析，就能选出最小工作量，但能获得最大价值的模块。

业务和客户驱动而非技术驱动：敏捷开发强调在整个开发周期内，业务人员和开发人员中必须天天都在一起工作，确保技术人员能够开发出客户需要的产品。

时刻考虑版本的兼容性， 当设计变动、API接口重构、配置文件变更时，要时刻考虑产品的架构、规划路线图，老版本的兼容性，及迁移平滑性。否则，随着版本的增多，必将面对着大量的维护工作。

轻文档而非文档， 强调沟通的重要性， 但并不意味着无文档，在敏捷开发过程中，适量的文档还是很有帮助，有助于整体思路，加快沟通和讨论；

产品敏捷开发中，每个迭代结束，都会有一个产品迭代演示大会，把这个月的开发结果演示给组员、业务人员、售前，甚至客户，并收集反馈。此外，在开