如何弥补敏捷方法中的薄弱环节？
近几年来，敏捷作为一种很实用、上手快、轻量级的方法，被越来越多的开发团队所采用。然而，在很多大团队中，敏捷方法的实施带来了包括在人员管理、工作计划、沟通和文档记录等诸多问题。
2009年，有知名市场研究机构对美国的上千家企业做了开发方法的调查显示，有近30%的组织采用了敏捷方法，远远高过迭代、瀑布和基于度量的传统方法。然而，数据显示调查中称未使用任何方法的机构占最大比例，约占被调查企业总数的三分之一，无论是在中小企业（员工少于1,000人）还是大企业（员工超过1,000人）。更为有趣的是，在采访过程中发现，这些自称没采用任何方法的企业中，实际上很多采用了多种方法混合使用。
不难发现，越来越多的企业发现了单纯的敏捷方法的局限性，混合敏捷方法将成为未来ALM发展的趋势。2010年，TechExcel全球CEO、首席软件架构师周铁人博士在原有的需求驱动开发（Specification Driven Development，简称SpecDD）方法基础上，提出了整合的敏捷方法（Balanced Agile Development）。整合的敏捷方法遵从了敏捷的基本原则，融合多种敏捷方法和传统方法的元素，企业结合自身业务特点和企业文化，从而形成一种整合的敏捷开发方法。同时，整合的敏捷方法将项目管理和质量管理的元素融入到敏捷方法中，倡导需求驱动开发。
需求敏捷or任务敏捷？
整合的敏捷开发，结合了客户需求、功能点、Backlog统一管理。首先，将客户需求、内部需求和性能上的需求分解为功能点，基于功能点产生开发任务和Backlog，根据结构化的需求和任务，制定计划。
敏捷，是因为谁都不知道需要做什么。因此，在敏捷过程中，有两个产物：一个是可执行的软件，一个是由结构化的功能点所组成的概念产品。在开发的过程中，这两个产物都将随着开发的推进不断调整。每一轮迭代都会产生一个新的可执行产品，而可执行的软件会反过去影响概念产品，如重新调整功能点的优先级、新增需求等。整合的敏捷开发，不是追求任务的敏捷，而是需求的敏捷。
敏捷能计划吗？
有的人说，敏捷就不需要计划了。相反，敏捷是可以计划的，还可以有很漂亮的计划。整合的敏捷方法实现了产品、版本、里程碑、Sprint多个层次的项目规划。
针对每一个Sprint，计划的过程中都可以合理的安排团队和工作量，让项目经理、产品负责人充分发挥团队中的每一份力量。
敏捷如何保证质量？
使用敏捷方法如何保证产品质量呢。敏捷开发不同于传统的测试：
非常短的开发周期
缺乏完整的文档和测试方案
传统的测试方法和工具在敏捷中都不再使用
需要与客户和开发人员直接交流
及时针对需求的变化调整测试方案
针对这些特点，整合的敏捷开发倡导的SpecDD方法使得需求能够驱动测试，保证了测试模板和测试任务，保证了从需求到开发任务，到测试的可追溯性。
如何评判一个开发方法？
软件研发的本质是选择最佳的开发方法，保证开发的质量和效率。正确的开发方法，必然会会软件产品的以下指标带来影响：
高效性（efficiency）
可靠性（reliability）
可理解性（understandability）
可维护性（maintainability)
可重用性（reusability）
可修改性（modifiability）
可适应性（adaptability）
可移植性（portability）
可追踪性（traceability）
可互操作性（interoperability）
一种多元化、开放的敏捷开发方法将是现代企业的首选。敏捷开发顺应了软件开发的潮流，从开发方法上适应了需求的改变，能够不断进化并且适应新的需求。对于企业来说，最佳的敏捷方法必然是一种混合的方法，它融合敏捷和多种开发方法的元素，解决敏捷方法中对计划、资源和质量管理方面的不足，将各种元素融会贯通，从而形成符合企业自身业务特点的开发方法，使之最有效的服务于开发团队。
原帖地址：http://community.techexcel.com.cn/010DevSuite/news/953AgileDisadvan
[解决办法]
敏捷,一句话就可以描述:
先进的生产手段,灵活的组织形式,灵巧的管理方式
这里面每一项都是依托实实在在的实现手段,
比如,我们的开发由设计文档管理系统驱动,
即便是所有代码delete,我们甚至可以在一天之内重建整个项目,
我们几乎每天都有能力交付客户新的版本,
我们欢迎客户迭代设计文档(只有设计文档的迭代才可能导致代码的修改),
那意味着服务费用的增加,
那么,打成这样的效果,源于我们的"设计文档管理系统",这就是先进的生产手段
[解决办法]
敏捷很容易成为没有方法的代名词。假设它不是去使用比其它方法更严格、要求更高的方法（仅仅在方法上不同，而不是不注重技术），那么你所遇到的敏捷开发就必定是假敏捷。
[解决办法]
举个例子吧。每一个开发人员都可以修改别人的代码中的bug，因为每一个开发人员（即使他们分布在世界不同地点）向系统版本管理系统提交代码之前都要运行自动化测试，让成百上千个自动化测试小程序跑上几万次。只有具有这个技术，才能做到有勇气去随时修改别人的代码，而不是去“规范地奢求”代码只能被当初写他的那一个程序员去修改。
可见，协调团队开发、保证产品每一天都几乎有可随时发布的质量，这是极高的技术手段，而不是靠搞行政那一套，不是靠仅仅多开几个站立会议就敏捷了。
[解决办法]
在炫耀那么多“这个性、那个性”之前，敏捷的核心的性质是“仅仅做最简单的事情”。如果不是这样，那么奢谈这个性、那个性地，必定会让人去追求“完美”，追求“拖延足够长的时间”去做表面文章。这也说明了敏捷开发中必须强调这个技术对团队中的领导者的要求要比以往的RUP之类的技术其实更清晰也更技术化一些。
所谓“融合”的做法，很可能是弱化了敏捷开发中更高的、更难的技术要求，而又容易走回老路上去了。许多人急于拿个“敏捷开发证书”而不想费心血去精通敏捷开发的技术要求。可以理解许多人担心敏捷开发变成了鼠目寸光的开发，但是确实存在着想把没有方法偷换成方法融合这个名词的危险。
