大师们的确不但要总结一些有关敏捷方法的理论，而且要有切实可行的方法去操作，还要有相应的商业模式的配合，否则总是说敏捷宣言原则实践或者经验，没有一点儿理论和商业模式支持，一遇到有关收费的问题就没的可讲的了，谁为敏捷的交流付费，谁为敏捷的变化付费，如何才能通过第三方信任一个敏捷团队，这些都是商业模式的问题。
敏捷方法有时需要把各种新鲜的东西都放到敏捷中来讲，以为敏捷保罗万象，有人提个问题，回答得神乎其人，云山雾罩，让人觉得漏洞百出就不好了。
或者本来说过程控制不是敏捷，结果在实践中又不得不以形式化过程作为敏捷开发的主要活动。
或者在一个项目中敏捷，到了另外的项目就不敏捷了，有的敏捷项目实际上不敏捷，有的是急功近利而后患无穷，或者毫无规划而得过且过。
这些负面的东西都会让人产生怀疑，敏捷到底要提高工作效率还是要降低工作效率。
从这篇文章开始，我试图从理论和商业模式角度描述和总结敏捷，以此将敏捷从概念，起源和已有的实践中总结出一些东西，至少将敏捷开发方法同相对传统的软件工程方法以及各种概念的区别揭示出来，将敏捷的定义，适用范围、类型、规模、商业模式，约束条件等相对严格定义出，而不是感性的实践经验。虽然我知道我的定义不一定是非常准确的，也可能有错误，但是这个尝试总比糊涂的，情绪化的敏捷崇拜者更好地对实践进行指导。
所谓理论基础元素，本来打算是为形成一套完整的理论服务的，但是写作过程中，发现以目前的素材，虽然我将一些案例进行总结，但是仍然不能称为理论，所以暂且改为基础元素吧，可以作为真正理论需要解决问题和关注点，去逐步发展吧。
敏捷的价值观
首先从观念上讲，如何是敏捷的。
敏捷的价值在于共同的成长，所以，敏捷宣言中第1条和第3条说，个体和交互更重要，客户参与也更重要。就是将工作中的每个人都平等起来，大家共同完成一个目标，从这两点上，敏捷的宣言是从哲学上去说，而不是方法学上的。
敏捷的价值还在于在一个哲学基础上，使用任何方式方法都可以称为敏捷。所以，敏捷宣言中第2条写运行的软件更重要，就是实现目标很重要，第4条写响应变化更重要，其实第4条是第2条的一个附属方法，既然实现目标是最重要的，当然目标如果发生改变，我们就要自然要适应这种改变了。
交流也是敏捷中的重要因素，通过交流获得正确的目标。交流不是单向的，需求调研算不算交流？敏捷的交流应该是双向的，就是每个人都可能被影响，用户可能会影响到开发人员，开发人员也会影响到用户，这是平等的。
然后我们看看不重要的方面，被弱化的4项中，1、过程和工具，2、文档，3、合同谈判，4、遵循计划，在敏捷开发中，这些内容不是不需要，而是在平等交流下进行确定，也是大家都认为是很舒服去适应的方式方法，标识标志，所以也无所谓UP还是XP，Scrum还是迭代，只要这个项目的成员包括用户都认可，那么就可以使用，或者不使用。
敏捷是一个原则，在这个原则下，会有多种实践方法，这些方法可能会对症一个敏捷思想的一部分，是不全面的敏捷分支。
敏捷要想成为一种真正的开发理论，一定会包容一切，承载一切，将好的开发方法和过程容纳进来，并使其更加高效，而不是排斥或者对立。
敏捷的起源
无论是敏捷还是其他理念，一个软件系统，实现是第一目标，然后可以优化和提高，就像人的生存，生存-温饱-小康。如果我们第一个目标就是小康，那窝头咸菜等东西不吃，茅棚草席麻片不去住，人类可能就在大自然中消失了，不会发展到小康。软件也是一样，强烈的实现意识，使开发人员在尽l量短的时间内，将第一个版本实现，这是大家共同的目标。
敏捷和传统的软件工程分歧在于，软件需求的实现是要整体设计，还是不要整体设计。
设计的好和坏，是设计者和构架师的水平问题，但设计不设计，是开发理念。
在软件工程中，每个迭代目标明确后，需要对目标进行分解，然后才能一个模块一个模块地实现，其实这个目标清晰和分解的过程，就是构架的过程。
构架可以分系统构架，大构架和项目内部的构架，不同规模的构架关注不同粒度的部分。如系统构架关注于系统系统之间的关系，而项目内部的构架更接近于代码结构和设计模式。
由于构架是事先设计的，所以，在开发过程中，混乱和不明确的情况会少得多，但是有些设计可能是过度的，或者多余的，各个实现之间通过构架完成，耦合小。成员对于全局理解不够深刻。
由于构架要了解软件需求中的各个方面，并且要设计软件开发过程中的构架，但是并不实现，所以项目中的一部分人员不必参与，用户也不能在这个过程中看到他们可以理解的成果，降低了参与度。
如果设计，实现，部署3个主要步骤时间都是30天，那么最快30天后，用户才能看到运行的软件，如果60天后看到软件，用户就只能是被培训了。
而敏捷方法也说，对于目标，通过小的迭代Scrum进行完成，但是敏捷的迭代更小，更盲目一些，更接近表面，所以内部结构往往是混乱的，从而导致必须通过重构，这种特殊构架方式进行设计活动，这样的结果有一个好处，就是完全避免了过度设计，由于交流的通畅，所有的过程团队成员更加清楚构架产生的过程，没有多余的代码。
如果敏捷方式开发，30天或更长时间实现，30天重构，30天部署，最快在最初几天内，用户就可能看到运行的软件，但是功能和界面有限，用户可以进一步修改和验证他的想法，直到软件成功，软件的成长用户可以看到，而当开发人员重构系统时，用户早已经放心睡觉去了。
敏捷开发的概念范围
“敏捷”仅仅是一个形容行动迅速，反应灵活的形容词，放在开发这个动名词前，作为修饰和约束，以区别其他的软件开发方式。所以敏捷开发关注的是软件开发活动中原则和方法，甚至都不包含软件的构架设计实现的具体过程，更不是什么我们如何用软件提高工作效率，如何重构等，即使有这些内容，也仅仅是一小部分，不能影响到整个方法。更不是什么诸如“身手敏捷”中的“敏捷”，或者他敏捷地躲过敌人的子弹，然后开始还击。
软件开发方法的研究，是提高软件工程的质量和开发能力为主要目的，强调软件开发管理中特性、资源和时间三个要素的平衡统一，并试图以之协调软件工程整个生命周期中的各方面关系。
敏捷的约束
总结了一些敏捷的方法，我们开始确定敏捷适合范围，以及商业模式，管理方式。
传统的软件工程，以需求规格为最终的验收标准，需要在一定时间，一定投入的条件下，以提交物的方式交付给用户。这些都是要写进合同，甚至可以作为呈堂证供，可以经得起法官的审判的。但是到了敏捷的宣言中，客户合作更胜于合同，就是说，我们在有合同约束的项目中，是无法完成敏捷开发的，我们必须以严格的目标管理，进度管理进行过程跟踪，发现问题和风险及时跟进解决，以期在确定的时间内完成合同要求的目标。
既然合同约定了目标，那么这个目标就是不能随意变化的。一旦用户发现有需求有问题，就要进入复杂的需求变更流程，甚至可能重新签订合同。既然需求规格变化这么困难，那前期的制定工作一定要非常谨慎，所以才会有更多的项目因为没有需求定义而迟迟无法开始。
敏捷的快捷就在于，他的开发可以很快跟上需求的定义，即使需求没有完成，哪怕刚刚一个要点，或者不全面，也可以开始敏捷开发。结果是，可能开发出来的东西不是用户想要的，开发失败，也可能是开发的结果激发了用户的需求，用户有依据去完善他的需求，证明他的需求，使其有了更完整，全面的需求，这时，敏捷开发也会及时跟进，最终达到完美的系统。
从这个意义上讲，敏捷的不单是开发团队，敏捷的也是用户。如果用户没有尝试过敏捷，敏捷团队可以通过传道的方式传授给他，如果用户尝试过敏捷，敏捷团队可以让用户的敏捷更加有效。
这里的商业模式，传统软件工程一般是预付款方式，没开发前，有预付款，开发过程中，用户需要在某个里程碑付一部分，验收后付一部分，售后保证时间后，再付一部分。由于每次启动付款程序都是一个非常规行动，所以讨要付款是软件商业活动中一个很费脑筋的事情。
敏捷开发的商业模式，一般是以小时报价。这种计时付费的方式而不是看结果付费的方式，保证了开发团队可以随时应对需求的变化，而不以合同为约束。用户需求的不确定，是通过付更多的计时付费来解决的，你有钱，随时都可以变。
敏捷项目报价模式，小时报价还是固定价格？
所以在敏捷开发项目中，小时报价会成为主流的报价模式，而固定价格会成为敏捷的失败之源。
按小时报价的好处还在于付费的周期固定，及时用户和开发团队觉得不满意，都可以在这个周期内停止，即使有损失，也不会太大。
作为固定价格的项目，首先固定价格的评估是以开发目标为基础的，但是用户对于需求的提供往往不是真正的需求规格，而是一个业务需求，需要有人根据业务需求评估出项目的开发成本，以推算报价。这个需求分析和评估需要一定的时间和经验，而且评估的准确性也差距非常大，虽然可以通过系数方式缓冲，但往往报价偏低，而往往报价偏低却得到了用户的认可，给项目的开始带来了隐患。系统的需求分析其实也是需要许多工作量的，这个用户一般不会付费，这样往往在节省人力的情况下，评估工作也是质量不高。一旦在规定时间内不能完成项目目标，而前期的付费有消耗掉，这个项目可能就要失败了。
固定价格可以采用敏捷开发吗？那需要在传统的合同中进行约束，其提交物不是一个确定的目标，而是一个时间范围内的成果，这样，可以使用固定报价，每周期付费，到时间就停止。
还有一种就是固定价格增大缓冲时间，可以增加2倍时间进行报价，即使超过评估的也有时间在后续的缓冲时间端完成。
敏捷可以确定开发截止日期吗？
如果可以确定开发截止日期，那么敏捷项目可以固定价格吗？
敏捷可以固定需求开发吗？
敏捷和软件工程
敏捷和软件工程各种方法的关系
敏捷和CMM，敏捷过程可以通过CMM/ISO认证吗？
CMM是软件能力的成熟度模型，而不是指需要使用UP或瀑布开发或迭代开发，从CMM的级别说明上看，只要一个开发团队，总结出一些开发方法，并固定到一定的流程，就可以通过一个CMM级别。比如CMM2，要求是可管理的，简单地说，只要有人去按一定的规范管理开发过程，就可以通过；而CMM3，是可定义级的，就是将开发过程中的包括的要素进行标识定义，并有效管理，减少混乱，就可以通过。
CMM的实质也是比较简单，他基于开发团队经验总结，并将经验分解整理为多个步骤或者关键点，并将这些固定在一个过程管理中，以期望下一个项目能像以往成功项目那样继续成功。
至于CMM中实施瀑布开发，还是迭代开发，还是敏捷开发，都是开发团队自己的事情，你可以有文档，也可以没有文档，你可以有每日Standing Meeting，也可以没有，只要你的过程能保证下一个项目成功。
而敏捷开发提倡个体和交互胜于过程，但是还是有很多敏捷团队有自己的过程，如每日立会（Standing Meeting），工作日报等，他们认为过程是可以保证开发的顺利进行，可以促进交流。所以说，敏捷理论和原则在实践中，必须落实到可操作的活动中。
至于说认证的问题，并不是敏捷开发理论所要涉及的。
认证是一种商业活动， 两个互不相识的商业组织，第一次合作时，由于需要了解对方，或者一方（甲方）对另外一方（乙方）了解。了解的方式有很多中，时间成本和风险都有很多差异，其中由一个可信的第三方提供某些能力证明的方式被认为是一种简单有效的方式，甲方无需为这种了解支付更多费用，而乙方为了获得更多商业机会，自己投入成本取得第三方认证，也是容易接受的。
所以，敏捷的认证也是属于第三方认证，只要甲方认可敏捷，认可颁发证书的第三方机构，以及认证的过程，当然也可以给乙方以商机。
这个第三方机构可以是CMM/ISO组织，也可以是一个新的认证机构，CMM/ISO这样的组织有一定历史，信任度比较高，如果他们增加一些认证类别，自然可以很快得到响应。
敏捷团队
敏捷团队的建设
敏捷团队的热情从何而来。
敏捷团队需要项目经理吗？
敏捷团队需要构架师吗？
敏捷团队的梯队模型
敏捷团队成员如何晋级。