上篇解读了对于敏捷价值观的理解，这篇来聊一聊敏捷的12指导原则。关于敏捷宣言的12条原则的原始描述，大家可以参考官网：https://agilemanifesto.org/iso/zhchs/principles.html
1. 敏捷原则：我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
这个原则被放在12原则之首，也足以说明敏捷思想体系中对于强调持续交付价值的重要性。
这句话中有几个关键点：尽早和持续、有价值的软件、满足客户。
首先第一点：尽早和持续交付，强调的是尽可能早的、短周期的去交付，让客户在最短时间内以及高频次的看到团队的交付成果。维持这样交付方式及频率能够让客户更快的做出响应，基于交付结果来分析和评估，目前的软件是不是符合预期、需不需要调整，能够给与团队及时的反馈，帮助团队少走弯路，也帮助客户打造更符合实际要求的产品。
第二次，有价值的软件，这句话也非常重要。首先我们得判断什么是价值？对此团队应该有明确的认知，不同的客户/用户、不同的产品，面向不同的市场，大家所认知的价值是不是一致？我们需要在交付软件之前定义清楚价值的评判维度，这样才能避免无效的浪费，交付给客户的东西才是他真正想要的。
最后，满足客户是重点，我们给出的东西是不是能够满足客户要求，这就决定了我们的付出是否值得，当然满足客户不仅仅是在最后的结果，更重要的是在交付过程中和客户有频繁的互动和沟通，时刻把握客户的预期，最好的协作方式是客户能够和团队一起办公，时刻给出自己的反馈，便于我们及时调整，客户满意度也自然会得到提升。
所以，第一个原则强调的是，快速并有节奏的交付有价值的东西，从而满足客户要求。
2. 欣然面对需求变化—即使在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
这一原则强调的是拥抱变化。
相比于传统的开发模式，开发团队最不愿面对的就是需求变化，不但变，而是是一变再变，最要命的是在最后时刻还在变。
曾经听到一个段子：程序员小猿遭遇车祸不幸变成了植物人，医生都已经束手无措，家人也没有办法，急的团团转。后来公司同事来探望，在了解到情况后，熟悉小猿工作作风的一位同事，就在他耳边轻轻的说，“小猿，客户需求又变更了，还得你来改！”，小猿听到后立马坐了起来，低声嘟囔了一句：“MD，又改！”，家属和医生看到后连呼奇迹。当然这只是个段子，但也足以反映了程序员对于需求变更的深恶痛绝。
但是在实际工作中，这样的事情却经常发生，无法避免。那我们是不是可以换位思考，站在客户的角度来想一想，为什么他要提出变更？要么他觉得之前做的是错误的，需要立马修改；要么他认为当前的方案不够完美，还有更好的想法。总之来说，对于一个新需求、新想法来讲，客户的想法是随着他的认知和掌握的信息量发生变化的。
其实对于每个人来说，对于事物的认知往往都是需要一个过程的，产品开发也是一样，客户在刚开始的时候并不能给出明确的要求，而是在我们产品开发的过程中才会逐渐清晰，而且往往后期所提的需求是更具竞争力的，因为到了后期客户才真正明白他想要的是什么，所以我们要善于接受需求的变更，才能帮助客户提供更具竞争力的产品，给客户创造更大的价值。
既然我们无法阻止变更，那我们可以尝试抱着欢迎的态度去面对变更，也就是拥抱变化。
3. 要不断的交付可用的软件，周期从几周到几个月不等，而且越短越好。
这条原则和第一条关联紧密，在第一条原则里已经提到了尽早和持续交付有价值的软件，为什这一原则里又再次提到短周期交付呢？如果大家仔细对比，会发现着两条原则侧重点有所不同。
第一条强调的是通过尽早的交付有价值的软件使客户满意，而第三条的侧重点在于尽量缩短交付周期。哪为什么会强调短的交付周期呢？
从一般人的日常理解来分析，不管是在工作中还是生活中，如果有人给你布置了一项任务，是不是能够希望更早的看到结果。尤其是在软件开发这种复杂场景下，面临的不确定性更高，我们如何把这种不确定性降到最低，其实最好的办法就是尽快给出结果。当然，大家会觉得说不是所有的需求都能够在短时间内给出结果的，比如说要开发一套非常复杂的系统，不管怎么样，都需要半年甚至一年的时间才能完成，如何才能快速的拿出交付结果呢？
实际上，这里就涉及到了另外一个问题，就是我们如何把大需求拆小、如何把大问题化作小问题来解决。抛开拆分需求的技术角度，其实这条原则更强调的是一种思想、一种理念。试想如果我们能够把一个大块的需求拆分成若干小的需求去实现，一步一步的把结果都展现出来，那么最终的成果是不是离我们预期的要求符合度更高呢？其实不光是软件开发，做很多事情都是这样的，如果你能设定阶段性的目标，而且不断的通过交付结果来进行反馈，不断的进行调整，那么距离我们的目标和方向是不是就越来越近呢？反而如果你设定一个大目标，然后埋头苦干，等你觉得差不多了，再抬头看，发现我们原来在预定要去蟠桃会的路上，结果却走到了奈何桥，这个时候再后悔是不是有点晚了呢？
所以，对于软件也是一样，在开发的过程中，尽量拆解成小需求，缩短交付周期给客户去验证和反馈，从而确保我们的方向始终是正确的。
4. 项目过程中，业务人员与开发人员必须在一起工作。
这条原则的描述的很直白，也容易理解，就是大家坐在一起办公。哪这条原则背后又包含什么含义呢？仅仅是坐在一起办公就OK了么？显然并没有那么简单。
在传统的办公模式下，业务部门跟IT部门（也就是开发部门，我们通常称之为IT部门）是属于两个不同的职能体系，归属不同的职能线领导管理，所以大部分都是以各自的职能部门为单元在一起办公。那这条原则的提出就是针对原有模式下分开办公的弊端，也就是我们做起一起办公的好处，我觉得主要有2点：
1. 更好的信息沟通，敏捷的价值观里一直在强调面对面沟通胜过流程和工具，在这一原则里也得到了反映，业务和开发团队坐在一起首先就解决了面对面沟通的问题，提升了沟通效率。试想一下，一个很小的问题我们通过面对面5分钟能够解决的问题，却在邮件里讨论来讨论去，甚至半天都没有结果，而且也影响到手头正在做的其他事情，为什么我们就不能尝试走出一步面对面去面对面沟通呢？
2. 提升业务与团队的协作氛围，当业务和团队分开办公的时候，业务很难体会到团队为了目标所战斗的场面，为什么华为强调“让听见炮火的人来做出决策”，其实就是同一个道理，业务只有在现场才能感受到团队的工作氛围，更清晰的了解到开发每天的进展、遇到的困难，更容易感受到工作氛围，也会更容易站在彼此的角度去考虑问题，始终围绕一个目标在做事情。
因此，敏捷的这条原则就是在倡导业务人员能够和开发团队始终在一起办公，提升办公效率。
5. 激发个体的斗志，给他们以所需要的环境和支持，并相信他们能够完成任务。
这一条的核心强调的还是对人的尊重和信任，说到底软件开发的核心还是人。一起工作都是围绕人来展开的，所以在这条原则里，就重复体现了对人的关注和信任。
首先，我们要相信团队每个人的能力，他们都是我们达成目标不可或缺的一份子，当结果与目标还存在差距时，我们要相信每个人的潜能都没有得到完全发挥，所以要想办法去激发个人的潜能、激发斗志，让每个人都有信息投入到自己的工作中去。
当然，除了激励还不够，作为团队的服务型领导者，还必须给团队成员提供他们达成任务所需要的一切环境和支持，帮助他们达成目标。
对于一个团队来说，信任是协作的基石，团队的成败首先就是建立在人与人之间相互信任的基础上，有了信任，大家才能没有猜忌的做好自己的工作，并且要相信团队成员有能力能够完成自己的任务。
在敏捷开发过程中，团队的配合协作是非常重要的，首先我们要相信团队成员，相信他们是愿意为了团队的目标而努力，有能力完成当前的开发任务的。然后给予团队成员必要的支持，鼓励。而不是一味的传递压力。比如说，我们在刚开始组建开发团队的时候，会召集团队成员开一个小的kick off会议，在kick off会议上会让团队成员讨论团队的一些约定，也可以说是团队规则，一般我们会从团队协作、产品交付等等各方面去定的一些规则，而第一条就是“相信团队的每一个成员，都会为团队当前的目标而努力工作”，这是敏捷团队组成基本原则，这样才能够使团队成员之间互相信任，相互帮助，从而始终为同一个目标而工作。
所以，要想办法去激励团队成员，给与他们支持，相信他们能够完成任务。
6. 不论团队内外，最有效的沟通方法就是面对面的交谈。
这一原则很好的体现敏捷价值观里“个体和互动胜过流程和工具“，敏捷强调面对面沟通，因为面对面沟通是所有沟通方式中最高效的一种方式，大家可以通过面对面的沟通第一时间来解决问题。
从这句话的预置条件“不论团队内外”可以看出，敏捷模式下的面对面沟通是一种常态，不管是对内，在团队内部，还是说对外，和相关的干系人、客户，我们都寻求的是这样一种简介、高效的沟通方式，那就是面对面沟通。
相比较与传统的职能部门沟通模式，团队成员都是以自己的职能部门为单位一起办公，基于项目临时组建团队，物理环境上也没有坐在一起，之间的沟通方式，更多的是通过文档/邮件/即时通信/电话等这些方式，沟通效率会非常的低，尤其是文档和邮件。但是在敏捷中，站会和各种看板就是制造一个每天让团队开发人员面对面交流的机会，从而将团队沟通成本降低，减少因沟通造成的项目问题。
有研究发现，人们沟通中的信息只有7%是通过语言传递的，38%是通过我们的语气语调，55%是通过我们的身体语言。所以你会发现，即使在面对面沟通，我们还是要注意到表情、语音语调以及身体语言，更不用说其他沟通方式所带来的效率低下。
所以，最有效的沟通就是走出去，面对面交流。
7. 可工作的软件是衡量进度的首要指标。
第七条准则强调及时交付，但是交付产品的衡量准则是可以工作的软件，而不是其他一切过程产物。传统开发方式中，不同开发阶段的交付件可能不一样，立项阶段有MRD，需求阶段有PRD，开发阶段有SRD，测试阶段有方案文档等等，这些文档都是研发流程中重要的节点交付件，这就导致可能在相当长一段时间，客户无法看到我们的软件产品。而敏捷则强调交付一定是可以工作的软件，这样的话客户可以从一开始就看到我们的产品，对产品有一个直观的感受，从而可以不断的提出反馈和建立对团队的信任。
经历瀑布模式开发小伙伴，应该就会有这样的体会：为期一个6个月产品开发周期，其中前2个月都在做需求分析、需求规划，中间2个月做文档设计，提交了大量的文档，而到了后2个月才真正的启动开发产品，到最后一刻发布的时候客户才能看到能够工作的软件。而用了敏捷开发之后，从第一个月开始，每隔2周，都会交付一个小的增量给客户看，一开始可能不是很完善，但是到了后来越来越完善，客户的满意度也随着提升，而且会对你的产品也越来越有信心了。
这也是为什么敏捷理念里把可工作的软件作为度量交付进度的重要标准，Talk is cheap, show me the code，同样的道理。
8. 敏捷过程倡导可持续开发。发起人、开发人员和用户要能够长期维持稳定的开发步伐。
这条原则提到的可持续开发，一直是敏捷所强调的软件开发节奏。敏捷不只是一味强调快速交付，而是强调一个开发节奏，这个节奏能够让项目管理人员和客户对于这个团队有信心，就是我们交付给这个团队的开发任务，他们能够在固定的时间段里有连续产出，并且是保证质量的。
一个敏捷开发团队，一开始的交付能力是逐渐增长的，而PO往往希望团队能交付的产品越多越好，所以在每个迭代开始都安排了超过上个月迭代10%的工作，但是后来发现，团队交付能力在到达一定程度上无法再增长了，这个时候如果再增加任务的话，要不无法完成，要不完成不能保证质量，最后根据团队的交付能力评估，PO每个月只交给团队能够完成的任务，这样团队的交付能力刚好可以保证交付并且质量。
所以在经过长期的磨合后，发起人、开发人员和用户都建立一种共识，团队会以稳定的节奏向用户不断的交付可工作的软件，避免不同角色强行打乱团队的节奏，影响交付质量以及长期的合作关系。
因此一个稳定的、可持续的开发节奏是非常重要的。
9. 对技术的精益求精以及对设计的不断完善将提升敏捷性。
这一原则里包含了两点，一是追求技术卓越，二是不断完善设计（这里的设计既可以是产品方案的设计，也可以是技术架构的设计），这两者的不断改进都将促进团队敏捷能力的提升。
敏捷开发非常重视技术提升，这里包含2方面，一方面是团队人员技术能力的提升，因为它相信团队技术能力的扩展和提升能够提高产品质量，交付能力等，从而提高团队的敏捷性。另一方面是产品技术架构的优化，我们需要给开发团队足够的时间进行重构，重构使架构更加稳定从而维持更长的时间。
对于设计的追求，也是团队的目标之一，这里所谓的设计，并不仅仅局限于方案设计，更多的是一种广义上的设计，包括产品设计、方案设计、架构设计、业务设计等等。所谓对设计的不断完善并不是把原有的设计不断推到重来，而是在已有设计的基础上逐步进行优化，不断的去追求完美，由此可以知道好的设计是需要遵循可维护、可演进等方面的要求，否则将会在追求完美的过程付出很大代价，也容易导致浪费，范围得不偿失。
所以对技术和设计的卓越追求将从一开始就给团队和产品发展指明的方向。
10. 要做到简洁，即尽量最大可能减少不必要的工作，这是一门艺术。
简洁，只做需要做的事，这是敏捷的核心之一，在这条原则里就得到了很好的体现。
有一句话非常实用：交付刚刚好的系统。在产品不同发展阶段，如何明确用户的需求，交付刚好能满足客户需求的产品？在需求分析阶段，如何能够识别客户的核心需求，抓住客户的痛点，提供给客户最想要功能？在开发阶段，如何能够简化代码的设计、减少冗余，提供符合客户要求的系统？在测设阶段，如何涉制定测试策略、设计测试方案，交付满足用户质量要求的产品？这些都是要求我们在保持简洁的基础上尽量减少不必要的工作，而这一切并不是那么容易就能够达成的，需要大家在实践中不断的探索、去练习，才能更好的把握这个度。
不知道大家有没有注意过日本无印良品的产品设计，非常的简洁、简约，就拿它那个铅笔盒来说，简简单单的长方形设计，聚丙烯材质，盖子加盒子，非常的简单，没有其他乱七八糟的设计，但是也能够满足你的需求。
哪反过来在看我们敏捷团队，团队在刚开始运做一段时间后，总是发现有用户故事无法交付，后来发现是在分解用户故事的时候，加入了大量的健壮性，稳定性等功能，导致用户故事变大、变复杂。后来经过和客户沟通，知道了客户需要的核心功能，后来便决定在下个迭代只实现这些基本功能，结果发现按时交付能力就会大大提高。
所以说做到简洁是一门艺术，并不是我们想的那么简单。
11. 最好的架构、需求和设计出自于自组织团队。
这条原则在表达敏捷相信最好的架构、需求和设计都是出自自组织的团队。敏捷的目标之一就是能够打造一个自组织团队，该团队能够通过高效协作，完成需求分析，架构设计、开发交付、产品运维等工作。
对于自组织团队，首先要能够做到自我组织、自我管理，对于团队中的问题，我们能够自行做出决策，这样才是一个成熟的团队，如果达不到自组织的程度，那么对于团队的敏捷性将大打折扣。试想一下，我们推行敏捷核心的一点就是希望能够提升团队的响应力，如果事事都依赖于团队外部去做决策的话，响应力从而而来？
还有比较重要的一点就是对于自组织团队，更多会依赖团队的力量，群策群力来解决问题。如果去对比下敏捷团队中的一些关键活动就会发现，很多都是依赖团队协作的力量去解决的，比如计划会、评审会、梳理会、故事点集体估算等等，都是依靠团队来完成，更重要的是通过团队来达成共识，减少出错的概率、降低风险。
因此，自组织团队是架构、需求和设计的基础保障。
12. 团队定期地反思如何能提高成效，并相应地协调和调整自身的行为。
子曰：吾日三省吾身，说的就是个人如果需要提升，就需要不断地反省自己，对于团队来说，也是一样的，团队的成长和进步也需要不断的反省。
因此上，敏捷的最后一条原则就针对如何反省来提升成效。
如果我们仔细观察，就会发现在敏捷开发过程中，团队随时随地都在通过各种反馈来进行反思和回顾，一直都在实践着PDCA循环。
如果团队有进行结对编程，那么就是在践行秒级的代码反馈。
如果团队有坚持每日站会，那么就是在践行天粒度的开发进展反馈。
如果团队有定期开评审会、回顾会，那么就是在践行周粒度的迭代反馈。
如果团队有按照月度进行版发布，那么就是在践行月粒度的产品发布反馈。
……
等等，你会发现反馈的周期和范围都在不断扩大，因此需要改进的面也会越来越广。这点和精益思想里最求完美的理念不谋而合。所以在整个迭代周期里，通过各种各样的自我反思、团队反馈来不断的识别各种问题，并作出相应的调整和改进。
人无完人，金无足赤，对于团队来说也是一样，个人和团队的提升都需要不断的自我反思来进行完善。
其实定期反思不光是用在敏捷开发中，除了工作、生活学习中也被广泛的应用的。子曰“吾日三省吾身”，说的就是反思、自省的重要性，能够帮助我们不断的反省，提升自己。
以上，就是个人对于敏捷12原则的一些解读，这些原则理解起来并不难，难的是如何处处以其为指导原则，不断调整和优化我们的工作，如果想让组织快速提升对外部变化的响应、持续交付更稳定的产品质量，优化团队的协作、提升团队的战斗力，团队上下都需要好好理解并践行这些原则。当然，以上都是个人经验之谈，观点也难免会有所偏颇，也希望大家指出，多多探讨，共同进步。
网友评论