在上篇文章中，我们重新理解了敏捷宣言，其中包括往往被人们忽视的前两句话。那么接下来这篇文章我们会看一下敏捷宣言的12原则。理解一下这12原则对敏捷开发在实践中的指导意义。
12原则作为敏捷开发对于软件开发流程的指导性纲领，其实是对敏捷宣言进行了具有实际操作意义的解释。下面是敏捷宣言12原则：
我们遵循以下准则：
1、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3、要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4、项目过程中，业务人员与开发人员必须在一起工作。
5、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7、可用的软件是衡量进度的主要指标。
8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9、对技术的精益求精以及对设计的不断完善将提升敏捷性。
10、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11、最佳的架构、需求和设计出自于自组织的团队。
12、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
第一条准则：讲明了敏捷开发的最高目标，就是尽早和持续交付有价值的软件来满足客户，这里我们要注意几个关键词，尽早，持续，有价值和满足，通过这几个词，我们实际上是可以理解第一条原则的意义，那就是将产品对于客户的价值放在首位，整个产品的交付和开发周期都是为了满足客户对于产品价值的满意度。这也是为了解决传统软件开发中没有将产品对于客户的价值作为产品开发的目标的问题而提出的，只有将产品价值作为软件开发的目标，才能保证团队理解开发工作的目标，这样团队和个人才能够不断调整自己，为了这个目标而去工作，才能保证产品的持续交付。
案例：某公司新建敏捷开发团队，但是并没有进行相关培训，团队开发人员不知道敏捷开发的意义，仅仅是感觉换了一种开发模式，对此非常抵触。后来经过培训，了解到敏捷开发核心意义，知道自己在团队中的角色，也对团队的目标统一起来，并且从功能开发的传统理念转变为价值交付中来，从而在后面的开发中，能够不断调整自己，为团队目标服务。
第二条准则：需求变更可能是软件开发人员最讨厌的，软件开发人员的理想状态应该是，设计、接口定义好了，然后我做好就行了，也就是“鸡犬之声相闻老死不相往来”。但是实际情况则是需求变更永远是存在的，所以敏捷开发提出来的这条准则是，既然我们无法阻止变更，那么我们就应该抱着欢迎的态度，看看能不能从需求变更中找到机会，化风险为机遇，从而制造更大的价值给客户。
案例：某公司在开发产品的时候，客户经常提出变更需求，要求改变软件功能，但是该团队成员始终保持耐心，和客户沟通，分析变更需求，将变更需求分类识别，最后使得其中部分变更取消，而部分变更导入到现有功能中，而且从变更中发掘了一些新的功能，为客户增加了盈利点。
第三条准则：传统软件开发流程中，因为有从需求分析-设计-编码-单元测试-集成测试-系统测试等控制流程的存在，而且各个流程可能由不同部门和团队来分担，导致内耗和效率较低，从而交付时间很容易不受控制，但是敏捷则希望软件团队能够不断持续的交付软件，也就是小步快跑的过程，让客户不断的看到项目进展，从而增强客户对于团队产品交付能力的信心和满意度。
案例：某通信企业，以前交付产品，往往都是到了release结束的时候，客户才能够看到能够工作的产品，这个时候发现问题，往往需要加班维护，客户和开发人员都苦不堪言。后来在接受了敏捷理论之后，将软件功能拆分成非常小的用户故事，每个迭代按优先级实现用户故事，同时也demo给客户看，客户每个迭代都能够看到产品在不断完善，同时也能够不断的进行反馈。用户满意度大大提升。
第四条准则：敏捷宣言中地调就强调协作和沟通，那么这条准则也是希望团队成员能够有一个适合沟通的环境，特别是业务人员，他们是接触客户的第一责任人，任何客户的需求都是通过他们传递给开发团队的，只有大家在一起不停的沟通协作，才能保证开发团队开发出来的产品真正是客户想要的。
案例：在传统开发模式中，需求经过市场人员--BA--system analysis--system engineer ---developer,而且期间可能通过文档来进行沟通，这个时候开发人员往往不知道客户真正需要的是什么，所以只能依照自己的理解去开发产品，这样的产品很难说是满足客户需求的。
第五条准则：在敏捷开发流程中，团队的组建是非常重要的，首先我们要相信团队成员，相信他们是愿意为了团队的目标而工作，有能力完成当前的开发任务的。然后给予团队成员支持，鼓励。而不是一味的传递压力。
案例：本人在组建敏捷开发团队的时候，会召集团队成员开一个小的kick off会议，在该会议上会让团队成员讨论我们团队的几条约定，而第一条就是“相信团队的每一个成员都会为团队当前的开发目标而努力工作”，这是敏捷团队组成基本原则，这样才能够使团队的成员互相信任，相互帮助，从而和谐统一的向一个目标而工作。
第六条准则：敏捷非常强调面对面沟通，因为面对面沟通是所有沟通方式中最高效的方法，大家可以通过直接的沟通第一时间把问题解决。
案例：邮件/视频/即时通信/电话/面对面沟通，其中文档和邮件是效率最低的方式，而在很多开发人员却非常喜欢用邮件进行沟通，虽然这样效率极低。而在敏捷中，站会和看板则是制造一个每天让团队开发人员面对面交流的机会，从而将团队沟通成本降低，减少因沟通造成的项目问题。
第七条准则：敏捷强调即时交付，但是交付产品的衡量则是可以工作的软件，传统开发方式中，不同开发阶段的交付可能不一样，导致可能在相当长一段时间，客户无法看到我们的软件产品。而敏捷则强调交付一定是可以工作的软件，这样的话客户可以从一开始就看到我们的产品，对产品有一个直观的感受，从而可以不断的提出反馈和建立信心。
案例：某通信企业开发一个产品，有6个月的周期，其中前2个月都在做需求分析，文档设计，提交了大量的设计文档，而到了后4个月才真正的开发产品，到最后一个月的时候客户才能看到一些工作的软件。而用了敏捷开发之后，从第一个月开始，每隔2周，都会交付一个小的功能给客户看，一开始可能不是很完善，但是到了后来越来越完善，客户也很惊讶，该企业能做到这样，而且也有信心了。
第八条准则：可持续开发，一直是敏捷强调的软件开发节奏。敏捷不只是一味强调快速交付，而是强调一个开发节奏，这个节奏能够让项目管理人员和客户对于这个团队有信心，就是我们交付给这个团队的开发任务，他们能够在多久完成，并且是保证质量的。
案例：一个敏捷开发团队，一开始的交付能力是逐渐增长的，而PO往往希望团队能交付的产品越多越好，所以在每个迭代开始都安排了超过上个月迭代10%的工作，但是后来发现，团队交付能力在到达一定程度上无法再增长了，这个时候如果再增加任务的话，要不无法完成，要不完成不能保证质量，最后根据团队的交付能力评估，PO每个月只交给团队能够完成的任务，这样团队的交付能力刚好可以保证交付并且质量。
第九条准则：敏捷开发非常重视技术提升，因为它相信团队技术能力的扩展和提升能够提高产品质量，交付能力等，从而提高团队的敏捷性。
案例：某敏捷团队由开发和测试人员组成，一开始开发只管开发软件，测试负责测试和自动化，但是后来发现由于测试人员较少，很多自动化功能无法完成，导致无法进行足够的自动化测试，发现了很多由于新代码导致原有功能被破坏的例子。后来团队经过协商，希望开发人员也能够承担一部分自动化工作，并且将这个作为团队和个人的工作考核之一，经过一段时间运行，发现所有的开发人员都能够进行自动化测试开发，而且基本上所有的测试工作都可以用自动化来进行，增加了团队工作效率，并且保证了产品质量。
第十条原则：只做需要做的事，这是敏捷的核心之一。有一句话，刚好最好。
案例：某敏捷团队在运行一段时间，总是发现有用户故事无法交付，后来发现是在分解用户故事的时候，加入了大量的健壮性，稳定性等功能，导致用户故事变大变多。后来经过和客户沟通，知道了客户需要的核心功能，后来便决定在下个迭代只实现这些基本功能，结构发现按时交付能力大大提高。
第十一条原则：敏捷相信好的架构设计是出自自组织的团队。敏捷的最终目标也就是打造一个自组织团队，就是该团队能够通过高效协作，进行需求分析，架构设计等工作。
案例：某通信企业，原来的设计架构都是有系统工程师来进行，但是系统工程师不在团队中，不实际编写代码，后来在运行中发现往往会出现一些设计问题，比如说不符合当前实现等。后来该企业让系统工程师和团队坐到一起，共同进行软件架构设计。经过一段时间，发现软件设计比以前好多了，出现的设计相关问题也少了很多。
第十二条准则：我个人认为回顾会议是敏捷活动中最重要的一个，因为只有通过回顾会议，找出团队需要保持的和不足之处，在下个迭代进行改进，才能够达到团队不断改进，不断前进，提供交付能力和缩短交付时间的目的。
案例：某大型企业，组建SCRUM团队，开始的回顾会议，大家畅所欲言，但是提出的问题就放在那里，也没有什么改进计划，或者是时间紧，就不管了，后来发现团队进步很慢，交付能力停滞不前。后来在SM的引导下，将回顾会议中发现的问题变成下个sprint的用户故事，让专门的人进行改进或者提高，经过几个迭代之后发现，这些问题解决之后，团队的交付能力大大提高，而且也进入了一个高效的开发状态。