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

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

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

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

灵活运用敏捷开发

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

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

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

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

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

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

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

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

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

产品敏捷开发中，每个迭代结束，都会有一个产品迭代演示大会，把这个月的开发结果演示给组员、业务人员、售前，甚至客户，并收集反馈。此外，在开发的过程中，产品的业务人员和售前时刻保持与产品开发团队的沟通和工作，保证开发出来的产品是符合业务需求。

充分利用资源和时间，敏捷开发后，迭代开发、强调沟通、缩减文档，在每个迭代初期就可以充分地利用开发、测试人员的时间，达到效率最大化。

每日交付

产品开发过程中，每天都会做自动化Build，并生成可以交付的产品。业务人员、客户都可以试用并提供反馈和新需求。

充分自动化

需要自动化去支持变化，在变化的同时保证质量和开发速度，包括编译自动化、单元测试自动化、功能测试自动化、UI测试自动化、集成测试自动化等。

架构师和Scrum Master的重要性

1) 产品架构师

一个好的产品，特别是面向行业的产品，要具有长期的生命力，需要具有下图所示的产品模型：

成熟的模块：指的是推出市场有一段时间，这些功能模块因满足客户的需求而被广泛使用。随着市场趋于稳定，大量竞争对手的产品也推出类似的功能。这些成熟模块都是产品的基本模块，不代表产品的竞争力。产品中如果只具有这些功能模块，随着需求和竞争的激烈，慢慢会走向灭亡。如90年代的BP机一样，当手机一旦推出，这个产品也就走向灭亡。

发展中的模块：指的是刚推出市场并且具有强劲的市场生命力、符合客户当前几年的业务发展需求，正在被大客户所接受的功能模块。这些功能模块是产品占领市场的动力，是继成熟的功能模块后，产品的新的增长动力。

研究中的下一代产品方向：指的是还没有推出市场、正在研究中的、符合未来行业五到十年发展方向的模块。当然如果能创造出未来的发展方向，则是最高境界。如任天堂的Wii、苹果公司的iPhone。

一个行业软件产品要保持长期的生命力，在整个产品的生命周期架构规划中，需要考虑到这三种模块和特性，只有这样才能保持产品的先进性和长久生命力。

敏捷开发也强调拥抱市场变化，这对产品架构师提出了很高的要求——深厚的业务背景、创新能力、技术洞察力和架构思想。

2) Scrum Master

其工作内容和开发组长没什么太大的区别：安排任务、协调资源、控制进度和解决难题。Scrum Master会协调解决每天碰到的问题，确保产品进度和质量。

每天早上需要主持小组成员进行一个10分钟左右Scrum会议。每个组员汇报昨天完成的任务，是否完成任务以及碰到的问题，最后是今天打算完成的任务。Scrum Master会协调解决每天碰到的问题，确保产品进度和质量。具体到业务中，Scrum Master各自负责架构中的不同模块，并和开发人员一起把模块分解成一个个单独的、可以衡量的用例，然后协调开发人员高质量的完成任务。