问：敏捷开发如何融入到现在在推行的CMMI中?

　　答：首先，我想说一下为什么会在CMM的基础上提出CMMI。BarryBoehm在其新作《BalancingAgilityandDiscipline:AGuideforthePerplexed》一书中对此进行了比较深入的阐述。从总体上来说，有两个主要原因：1、对CMM中那些容易导致官僚的部分进行了大幅度的更改；2、把风险驱动作为一个核心内容纳入到CMMI的框架之中，这样在CMMI的框架中可以比较顺畅的制定出一些可以非常敏捷的过程了。但是，CMMI的敏捷性是很难刻画的，因为作为一个过程改进参考模型，它更加贴近一组需求而不是一组实践。也是说，我们只能刻画那些为满足这些需求而开发出的过程。一般来说，CMMI在需求方面的约束少于SW-CMM。如果以更为宽广的观点去解释需求可以获取更多的敏捷性。然而，如果在实施时采用了全面保守的做法并且使用了由SW-CMM所提供的重量级成熟度评估方法，那么所得出的CMMI兼容过程将是重型且非常计划驱动的。因此，我觉得敏捷本来可以非常顺畅地融入到CMMI的模型中。如果说有问题的话，我觉得更多在于实施者对敏捷的排斥，而非其他。

　　问：敏捷开发流程是如何应对各种可预知和不可预知的风险?例如:人员流动和变更，项目周期的变更，客户代表的变更等风险。

　　答：人员流动和变更、项目周期的变更以及客户代表的变更等风险是任何一个软件开发项目都不可避免要面临的。一个好的过程方法应该能够使得这些风险导致的损失小化。敏捷方法试图营造一种非常舒适的开发环境，这是一种典型的craftsmanship文化。在这种文化中，人们都一自己的技艺为荣，以开发出高质量的软件为荣，并且不断追求技艺的提高。在这样的环境中，人员流动和变更的频度被大大地降低。另外，敏捷方法对面对面沟通、结对编程以及高质量代码和文档的强调也使得由于人员变动所导致的风险大大降低。

　　对于项目周期的变更，我想再也没有比快速、短的迭代更有效的应对方法了。正是这些快速的短迭代为我们带来的大量的反馈信息，使得我们对于项目的状况具有全面、深入并且是真实的了解。有了这个基础，我们在小化项目周期变更风险方面处于一个非常有利的位置。而快速的短迭代正是敏捷的重要特征。什么是敏捷呢？敏捷是：“shortcyclesthataretest-drivenandfeedback-driven，yieldingconstantimprovements.”对于客户代表的变更，我不想多说。因为无论是对于敏捷方法还是计划驱动方法，客户代表的变更带来的风险都是一样的。如果，没有一个好的客户代表，那么肯定是一个失败的项目。

　　问：敏捷开发流程是否适用于大型、复杂的应用系统？因为对于一些架构比较简单，代码量小的系统，可以通过不断的代码重构进行改进，但对于一些体系结构比较复杂的系统在投入运行后，短时间内，由于客户业务的扩张导致的数据容量的增大或者网络访问量的增加，而导致原有的核心架构设计已经不能满足用户的需求，而这些重要的架构在系统核心服务中起重要作用而很难进行变更。这种情况，变更这些方面的代价会很高，因此需要早期花费精力预期此类变更。而且这类软件的复杂性和规模会导致严格的代码重构代价过高而且容易出错。

　　答：首先我们得在什么是大型、复杂的应用系统这个问题上取得共识。Scrum方法应用的大的一个项目是一个医疗图像信息系统，共有800人。XP方法应用的大一个项目是一个企业资源综合管理系统，共有50人。当然，在人数增多时，必须要采取一些变通的实践（否则不敏捷了）。对于架构方面的问题，我觉得应该这样看。如果是一个相对成熟的领域，那么可以借鉴很多业界已有的经验，特别是一些相关的模式。这一点很重要，否则是要走很多弯路，付出很多代价的。比如：我觉得在并发、分布式通信领域，一个合格的系统工程师必须应该知道并理解《Pattern-OrientedSoftwareArchitecture，Volume2》中的所有模式。但是，这只是为你提供了一个方向，一个防止你犯重大错误的方向。这些模式为你代码的重构和系统的演化提供了一个指引。如果不了解这些模式，基本不可能做出一个的架构。了解了这些模式后，是不是可以在一开始把它们堆砌起来以形成一个能够适应未来的架构呢？当然不行。要想构建一个能够适应未来的架构，有两种途径，一种需要天才的系统架构师，一种是在领域模式的引导下，通过TDD和Refactoring的方式不断、逐步地修改。显然，第2种方法是一种切实可行的方法。

　　问：敏捷开发流程是否不支持创建可复用产品？对于一个工程型，可复用的产品对于节约成本和提高效率是极其重要的!

　　答：关于可复用性的问题，一直都是软件界讨论的热点。一般来说，有机制层面的复用，比如：一般的函数库或者类库，也有应用领域逻辑的复用，比如：各种领域相关的应用框架。第一种复用方法相对比较容易，但是带来的好处也相对较低。而第二种复用方法能给我们带来大的好处，但是非常的困难。也正是因为这一点，在业界一度有“复用神话”的说法。无数实践表明，要想得到一个相对可用的领域框架，必须要经受至少3个同质领域实践的锤炼。并且，失败的数目要远远大于成功的。而试图在一开始把可复用性作为目标的项目基本上没有取得成功的（这样的框架一般具有这样的特点：本来一件简单的任务，但在使用了该框架后却变得非常复杂。）。因此，现在业界比较一致的看法是，首先应该针对你开发的领域搭建一个特定于项目的、简单的框架。一开始不要考虑复用性，而关注于系统的清晰性和简单性。在另一个同质的项目中，通过重构、演化的方法在对这个框架进行修正，使之更具通用性，如此循环往复。在经历过多个项目后，可能你得到了一个比较具有可复用性的框架。也是说，应该关注于创建那些比较容易演化为可重用框架的东东，这个东东应该具有两个特点：1、针对具体问题；2、非常简单清晰。敏捷方法非常注重这种框架的形成，但是不会刻意去这样做，它的思路是在不断的循环、迭代中把它演化出来。在这个循环迭代中，敏捷方法以DRY（Don'tRepeatYourself）原则来逐步建立起更大规模重用的基础。

　　问：敏捷开发流程的质量保证机制是否足够满足开发有严格安全性和可靠性要求的软件？对于在电力，电信系统中一些有严格安全性要求的软件敏捷开发流程支持的质量控制机制似乎并没有证明来说服使用者软件是安全的。是否还需其它措施进行补充?

　　答：首先我要说的是，安全性和可靠性是属于用户需求的范畴，而敏捷方法中把客户满意放在了非常重要的位置上，单从过程方法的思想基础方面来说，没有那种方法能比敏捷方法更关注客户的满意度了。其次，安全性和可靠性不是通过一些条条框框说出来的，那些在系统方案中空洞地罗列一些安全性和可靠性方面的术语的做法，对于保证系统的可靠性和安全性没有任何用处。保证安全性和可靠性的方法是去检验，随着系统的演化，不断地检验。把用户在安全性和可靠性方面的需求通过测试用例的方式编写出来，频繁地去验证系统是否能够通过这些测试，如果不通过，是一次集成失败。不知大家在保证系统可靠性和安全性方面是如何做的？

　　问：目前的项目和部门的组织架构，内部客户和外部客户离开发人员都很远，怎样能够达到零距离?虽然单个客户和开发人员在一起工作可以有效对需求变更进行跟踪，及时响应需求变更，但如果系统面对的客户是不同的，如何避免开发期间一些需求变更的单一性和独特性?

　　答：无论项目采用任何方法，它对于客户都有同样的要求，是这个客户必须是CRACK（Collaborative、Representative、Authorized、Committed、Knowledgeable）型的客户。鉴于目前我们所处的各种环境，完全的CRACK和现场客户可能不太可能。但是一个能够合格地担当其客户角色，并且能够比较频繁的参与到项目开发中来的人员对于项目的成功来说是必须的。另外，应对需求的变化正是敏捷方法的强项，如果这些变化是客户真正需要的，那么为何要避免呢？此时，我们应该利用这些变化取得优势。

　　问：如何避免开发人员利用够用文档这个借口偷懒少写文档？

　　答：处于敏捷文化中的人以高质量地完成任务为荣，如果写文档是高质量地完成任务的一部分，那么他肯定会高质量地写出这份文档。否则，写再多言之无物、只满足格式的文档又有什么用呢？敏捷实践都是能够真正提供开发人员技能的实践，敏捷方法强烈反对那些仅仅是为了防止开发人员“偷懒”而制定的规程。