敏捷的框架来做事：有角色的划分，任务的分解，有各种会议，也有sprint - 但迭代过程是随意、松散的、没有任何约束的，所以失败。
1-明确了短期目标，一个迭代在两周左右，可以明确告诉客户，在一个迭代周期内，只能完成200个里面的40个，先做最有价值的前20个。
2-便于进度控制和风险预测。
3-检视与调整，逐步完善的过程 ， 迭代结束之后，产生可交付的成果，给客户演示，及早获得反馈，小步前进，不停思考，反省和总结。不停地进行自我检视，调整和完善，一步步走向卓越。
灵活运用敏捷开发
项目负责人还要懂得“做人”。和客户方负责人、联系人保持良好的关系是非常非常重要的
敏捷开发中，注重概念和架构设计，而轻详细设计
概念设计： 可以看出为何要做这个模块，强调的是产品路线规划，市场趋势，客户价值 和技术趋势等
架构设计，可以看成从整体上看，概念设计应该用什么方式实现、分几个层次、多少组件、不同层次和组件之间关系是什么。
详细设计，则是具体的设计和做法、API接口等。
SWOT 分析，在敏捷开发中，更加注重客户需求。对产品进行SWOT分析，就能选出最小工作量，但能获得最大价值的模块。
业务和客户驱动而非技术驱动：敏捷开发强调在整个开发周期内，业务人员和开发人员中必须天天都在一起工作，确保技术人员能够开发出客户需要的产品。
时刻考虑版本的兼容性， 当设计变动、API接口重构、配置文件变更时，要时刻考虑产品的架构、规划路线图，老版本的兼容性，及迁移平滑性。否则，随着版本的增多，必将面对着大量的维护工作。
轻文档而非文档， 强调沟通的重要性， 但并不意味着无文档，在敏捷开发过程中，适量的文档还是很有帮助，有助于整体思路，加快沟通和讨论；
产品敏捷开发中，每个迭代结束，都会有一个产品迭代演示大会，把这个月的开发结果演示给组员、业务人员、售前，甚至客户，并收集反馈。此外，在开发的过程中，产品的业务人员和售前时刻保持与产品开发团队的沟通和工作，保证开发出来的产品是符合业务需求。
充分利用资源和时间，敏捷开发后，迭代开发、强调沟通、缩减文档，在每个迭代初期就可以充分地利用开发、测试人员的时间，达到效率最大化。
每日交付
产品开发过程中，每天都会做自动化Build，并生成可以交付的产品。业务人员、客户都可以试用并提供反馈和新需求。
充分自动化
需要自动化去支持变化，在变化的同时保证质量和开发速度，包括编译自动化、单元测试自动化、功能测试自动化、UI测试自动化、集成测试自动化等。
架构师和Scrum Master的重要性
1) 产品架构师 架构师是个举足轻重的角色，需要有深厚的行业背景、创新能力、技术洞察力以及架构能力。
成熟的模块；
发展中的模块；
研究中的下一代产品方向；
2）Scrum Master
其工作内容和开发组长没什么太大的区别：安排任务、协调资源、控制进度和解决难题。Scrum Master会协调解决每天碰到的问题，确保产品进度和质量。