1. 我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。
2. 我们欢迎需求的变化，即使到了开发后期。敏捷过程能够驾驭变化，为客户创造竞争优势。
3. 经常交付可以工作的软件 ，从几个星期到 几个月，时间间隔越短越好。
4. 在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。
5. 围绕斗志昂扬的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
6. 在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。
7. 可以工作的软件是 进度主要的度量标准。
8. 敏捷过程提倡可持续开发。出资人、开发者和用户应该总是保持稳定的开发速度。
9. 对卓越技术和良好设计的不断追求有助于提高敏捷性。
10. 简单——尽量减少工作量的艺术是至关重要的。
11. 最好的架构、需求和设计都源于自我组织的团队。
12. 每隔一定时间，团队都要总结如何更右效率，然后相应地调整自己的行为。
敏捷开发中提出了以上12条原则，这12条原则也是敏捷设计区别于其他设计模式的特征。我将在以后的笔记中对这12条原则分别进行整理和阐述。这12条原则中有一些部分是重叠的，笔记中的内容也不可避免的可能出现重复。本笔记中记录的也只是我一人之言，欢迎大家指正！今天我将着重阐述第一条原则：
我们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意
在这条原则中我看到这几个亮点：尽早、持续、有价值、使客户满意。
1）尽早，项目开始设计开发后，什么时间开始交付给客户第一个可用版本呢？尽早！那尽早到底是多早呢？这个问题敏捷开发中是有定义的，两个周！
2）持续，也就是说我们交付给客户的软件是一个连续的、周期性的。现在的软件升级周期很多都是固定的，其中一个主要的目的就是让客户能感受到我们存在，让客户看到我们一直在努力。
3）有价值，敏捷开发中指出我们每次交付的产品并不是一个全而不专的产品。我们一定交付的一定是一个切实解决客户问题的软件。也就是敏捷宣言中提高的“可以工作的软件”。
4）使客户满意，这是很多公司的口号，无数工作者为之奋斗的目标。可是我们发现客户真的不是很容易满意。我们做错了什么呢？有没有是我们前三点的问题呢？
回过头来我们看一下敏捷开发是如何推动产品研发方案的。这里我着重介绍和本节相关的几个概念
1）用户故事
为了项目能按照计划进行开发，让工作有序可依，对于每个项目我们都需要进行需求调研。这里的用户故事也是一种需求，但它又与我们平常做的需求调研不同。用户故事并不关注过多的细节，因为具体的细节会随着时间而不断的变化。用户故事是一种用来制定计划的工具，我们可以使用它并根据需求的优先级和估算代价来安排实现该需求的时间。但因为需要估算出时间，因此用户故事也并不是“实现权限管理”、“实现生产报表统计”这样的描述。它必须是确切的，可以进行度量的。
2）迭代计划
我们讲到的第一个概念“用户故事”，并不关系细节，而且细节是不断变化的。那我们是不是又一次将自己置身于不断的变化中呢？迭代计划就是解决这个问题的。每次迭代通常耗时为两周，这也是我之前说的尽早的时间。每次迭代都是一次小的产品支付。
一旦迭代开始，客户就需要同意不能修改本次迭代中的用户故事的定义和优先级别。这样就保证了我们在一次迭代中将不会再次面临着需求的变更。同时迭代对开发者的要求是迭代结束后必须提交规定的用户故事的产品。一旦无法开发完成迭代计划，需要对迭代中的故事在征求客户许可的前提下尽早进行调整。
开发管理者可以根据多次的迭代计划对开发速度进行统计，这样能更好的保证迭代周期内工作量的饱和和工作的按期完成。对于新组建的团队前期迭代需要有足够的预留时间，以保证能按期完成。
3）发布计划
大约6次迭代（约3个月）后，产品通常进行一次发布计划。它表示一次较大的系统功能交付。发布计划和迭代计划一样，需要提前与客户进行沟通确认，并制定严格的时间规划。
4）时间安排
这备份的结论主要来自于《人月神话》。对于项目开发时间规划和安排，《人月神话》中提出如下结论：
程序和产品的成本比为1:9（如下图，两个箭头都是表示x3）
软件任务的进度安排：1/3计划、1/6编码、1/4构件测试和早期系统测试、1/4系统测试
看了这些结论发现，也许我们之前真的对自己太自信了。
5）完整团队
那我们进行开发后，在用户故事中不明确的事情如何解决呢？这就需要有完整的团队。一个完整的团队中必须包含客户或能代表客户需求的人员。在系统实现中能进行实时沟通和交流保证对用户故事理解的正确性。
一个完整的开发过程初步勾画出来了，还有很多的部分需要进一步需要理解完善。以上几部分也基本上阐述了我们的第一条原则。这其中每一个小的部分又有很多需要学习和探讨的地方。我也是现学现卖，说的不对请多多指正。
以上介绍的几个概念中，重点就是用户故事。虽然上文中讲用户故事并不关心细节，但是用户故事是作为规划时间的方案之一，因此用户故事应该还是很详细的。试问我们的需求说明能准确的度量时间吗？如果不能，那用户故事就应该比我们的需求说明书更详细。书中指出用户故事并不一定需要完整记录，这应该是和敏捷软件开发宣言中的“可以工作的软件重于面面俱到的文档”一脉相承。当我认为文档还是必要而有效的手段。文档是我们与客户进行沟通交流的产物和留存，更是我们工作结果的展示。所以我认为文档是必须的！对于敏捷开发中一些文档要求，我想还是理解的问题吧！
敏捷开发过程中还有一些比较好玩的方法，基于Delphi估算原理的估算扑克。开发至于还可以打打扑克？当然不是了，这是一种民主性的估算方式。有兴趣可以看看奥。
第一个原则就介绍到这里，随着后面原则的介绍，敏捷开发的过程也将为我们展示其灵活性和优越性，让我们一起开始敏捷开发的学习吧！