最近我在学习一些有关敏捷软件开发的知识，把里面的12项经典原则分享出来，可以查询，可以反省，可以进步，可以参考，也可以纠正。
好了，言归正传。
1、我们最优先要做的是通过尽早的，可持续的交付有价值的软件来使客户满意
规划迭代故事时必须按照优先级安排，为客户先提供最有价值的功能。通过频繁迭代能与客户形成早期的良好合作，及时反馈提高产品质量。敏捷小组关注完成和交付具有用户价值的功能，而不是孤立的任务。以前我们都用需求规格说明书或者用例来编写详细的需求，敏捷使用用户故事来罗列需求。用户故事是一种表示需求的轻量级技术，它没有固定的形式和强制性的语法。但是有一些固定的形式可以用来参考还是比较有益的。敏捷估算中使用了这个模板：“作为【用户的类型】，我希望可以【能力】以便【业务价值】“。使用基于用户故事的需求分析方法时，仍可能需要原型和编写文档，只是工作重点更多的转移到了口头交流。
2、即使到了开发的后期，也欢迎改变需求。敏捷过程通过变化来为客户创造竞争优势。
这是一个关于态度的声明。敏捷过程的参与者不惧怕变化，他们认为改变需求是好的事情，因为那些改变意味着团队已经学到了很多如何满足市场需要的知识。
敏捷团队会非常努力的保持软件结构的灵活性，这样当需求变化时，对系统造成的影响是最小的。我们学习一些面向对象的设计原则和模式，这些内容会帮助我们维持这样灵活性。
3、经常性的交付可以工作的软件，交付的间隔可以从几周到几个月，交付的时间间隔越短越好。
经常性的交付可以工作的软件，这种做法就像一个人要减肥一样，减肥的时间间隔可以是几天，也可以是一周，在这个时间间隔内，均匀、并且努力的做运动，在饮食上也加以控制，这些运动和饮食上的控制必须是真实的、有效的，每个时间间隔可以观察一下自己的变化，通过不停的迭代，每个迭代都是有效的，几个周期下来就会看到自己的变化。软件也是具有同样的道理，我们每次交付的都是可以工作的软件，就算有什么问题，也可以及时修复，而且工作量也不是很大，对后面的迭代也不会产生多大的影响。如果我们按周期去交付，时间周期越很长的话，软件里面可能就会积累大量的功能，出问题的可能性也会增大。
交付时间间隔越短，粒度越细，而且每个阶段交付的都是可以工作的，客户就会看到软件的变化，也会提出他们的意见和建议，对于我们而言，修改和增加的成本也可以控制在一个很小的范围，同时也会增加客户的满意度。这个时间间隔要具体情况具体分析，制定符合自己团队的时间间隔。
4、在整个项目开发期间，业务人员和开发人员必须天天在一起工作。
为了能够以敏捷的方式进行项目的开发，客户，开发人员以及涉众之间就必须要进行有意义的、频繁的交互。只有大家在一起，才会有充分的沟通，才会有对系统的深入了解，对需求的更好的把握，对软件的交付也奠定了基础。如果 项目需求发生了变化，也可以更及时的响应变化，避免变化的延迟和项目的延期。
5、围绕被激励起来的个人来构建项目。给他们提供所需要的环境和支持，并且信任他们能完成工作。
在敏捷项目中，人被认为是项目中取得成功的最为重要的因素。所有其他的因素------过程、环境、管理等等---都被认为是次要的，并且当它们对于人有负面影响的时候，就要对它们进行改变。
例如：如果办公环境对团队的工作造成阻碍，就必须对办公环境进行改变。如果某些过程步骤对团队的工作造成阻碍，就必须对那些过程步骤进行改变。
6、在团队内部，最具有效果并且最具有效率传递信息的方法，就是面对面的交谈。
就像人谈恋爱一样，一定是面对面的谈，这样谈的才彻底，才会明明白白。在敏捷项目中，人们之间相互进行交谈。首要的沟通方式是交谈，也许会编写文档，但是不会企图在文档中包含所有的项目信息。敏捷团队不需要书面的规范、书面的规划或者书面的设计。团队成员可以去编写文档，如果对于这些文档的需求是迫切并且意义重大，但是文档不是默认的沟通方式。默认的沟通方式是交谈。
7、工作的软件是首要的进度度量标准。
工作的成绩不是看你加了多少班，来的多么早，走的多么晚，更不会看你帅不帅，而是看你做的软件的质量，软件的可以工作部分的总和是多少。敏捷项目通过度量当前软件满足客户需求的数量来度量开发的进度。它们不是根据所处的开发阶段、已经编写的文档的多少或者已经创建的基础结构代码的数量来度量开发进度的。只有当30%的必须功能可以工作的时候，才可以确定进度完成了30%。
8、敏捷过程提倡可持续的开发速度。责任人，开发者和用户应该保持一个长期的、恒定的开发速度。
敏捷项目不是50 米短跑；而是马拉松长跑。团队不是以全速启动并试图在项目开发期间维持那个速度；相反，他们以快速但是可持续的速度行进。
跑得过快会导致团队精力耗尽、出现短期行为以致于崩溃。敏捷团队会测量他们自己的速度。他们不允许自己过于疲惫。他们不会借用明天的精力来在今天多完成一点工作。他们工作在一个可以使在整个项目开发期间保持最高质量标准的速度上。
9、不断的关注优秀的技能和好的设计会增强敏捷能力。
高的产品质量是获取高的开发速度的关键。高的产品质量里面包含高的代码质量，良好的规范，结构稳定的架构设计。当有新的需求或者变化的时候，按软件设计原则去修改东西，或者说是增加东西，改动最少，牵扯最少，测试和维护成本都会降低。有这样的高品质的产品，才更容易面对变化，迎接变化。保持软件尽可能的简洁、健壮是快速开发软件的途径。因而，所有的敏捷团队成员都致力于只编写他们能够编写的最高质量的代码。他们不会制造混乱然后告诉自己等有更多的时间时再来清理它们。如果他们在今天制造了混乱，他们会在今天把混乱清理干净。
10、简单----使未完成的工作最大的艺术化-----是根本的。
敏捷团队不会试图去构建那些华而不实的系统，他们总是更愿意采用和目标一致的最简单的方法。他们并不看重对于明天会出现的问题的预测，也不会在今天就对那些问题进行防卫，避免过分设计，过分分析、过分架构。相反，他们在今天以最高的质量完成最简单的工作，深信如果在明天发生了问题，也会很容易进行处理。
11、最好的架构、需求和设计出之于自组织的团队。
任务不是从外部分配给单个团队成员，而是分配给整个团队，然后再由团队来确定完成任务的最好方法。
敏捷团队的成员共同来解决项目中所有方面的问题。每一个成员都具有项目中所有方面的参与权力。不存在单一的团队成员对系统构架、需求或者测试负责的情况。整个团队共同承担那些责任，每一个团队成员都能够影响它们。
团队不是一个人的团队，要共同解决问题，是分享解决方案，分享设计思路。团队成员也有角色分配，任务和责任，做自己适合做的事情，做对的事情。
12、每隔一定时间，团队会在如何才能更有效的工作方面反省，然后相应的对自己的行为调整。
敏捷团队会不断地对团队的组织方式、规则、规范、关系等进行调整。敏捷团队知道团队所处的环境在不断地变化，并且知道为了保持团队的敏捷性，就必须要随环境一起变化。
好了，写完了，上面有些自己的领悟，自己的看法。虽然现在有很多这样或者那样的方法论供大家学习和实践，但是在工作中大家还是会出现各种问题。之所以出现这样的问题，就是团队的管理人员没有能更好的理解敏捷的思想，有时候更错的是把里面的一条或者几条拿出来，作为项目的开发和管理的准则，这样必然会出现问题。个人感觉，上面的12条原则是一个有机成的整体，不可分的，不能单独拿出一个来评论，那样就会走入歧途，找不到真理的所在。每个原则又与其他的原则的是相辅相成的，我们应该把每一天熟记于胸，在项目中多多使用，多多体会。