敏捷宣言概览
犹他州（Utah）的雪鸟城（Snowbird）是一个不太可能发生软件革命的地方，它位于盐湖城外约25英里的地方，一点都不像硅谷：既不以阳光和温和的气候闻名，也不是什么科技创新中心，更没有那么多充满热情的企业家。但就在这里，一个滑雪胜地，一群具有反叛性的软件开发人员于2001年2月聚集在一起，经历了为期三天的讨论，他们制定并签署了行业历史上最重要的文件之一：敏捷宣言。
英文版：
代码语言：txt复制We are uncovering better ways of developing software by doing it and help others do it. Through this work we come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documents
Customer collaboration over contract negotiation
Responding to changes over following a plan
That is, there is value in the item on the right, we value the items on the left more.中文版：
代码语言：txt复制我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此，我们建立了如下价值观：
个体与交互 优于 流程与工具
可工作的软件 优于 面面俱到的文档
客户协作 优于 合同谈判
响应变化 优于 遵循计划
也就是说，尽管右项有其价值，我们更重视左项的价值以上内容出自敏捷宣言：http://agilemanifesto.org/
我身边不少同仁对敏捷宣言中间的四句较为熟悉，往往最容易忽略了前后两句，久而久之，使得一些后来者曲了解敏捷宣言的精髓。而我恰恰觉得敏捷宣言的首、尾很重要。
第一句告诉我们敏捷方法论并不是凭空而谈，它源自于截止目前的实践积累，但它有可能没法直接解决你现在所面临的问题，所以不必将其神话论，盲目跟随。你要做的是，明晰敏捷的核心，挖掘和定义清楚问题，循序渐进地在组织中引入敏捷，并且在实践中不断去探索更好的方法。
也就是说，尽管右项有其价值，我们更重视左项的价值 这一句起到画龙点睛，敏捷方法论源于实践，它应回归实践，帮助我们解决实际问题，而不是一个框住我们思维的框架，沦为思想牢笼。所以在实践中，我们应该以开放的心态去接受右项的价值，并在探索中借用左项来帮助团队提升效率。而不是一味着否定一边而神话另一边。我们应该时刻警惕这一点。
敏捷宣言解读
以人为本
我相信没有比面对面交流更高效的沟通渠道了
一个人在团中的战斗力巅峰状态一定是在受到足够的尊重和信任的前提下产生的，尊重和信任激发个人内心的责任感和使命感，激发了个体的潜能。从团队角度出发，我们应该充分尊重每个人，激发个体的斗志给与他们所需要的环境和支持，并且相信他们能够完成任务，在团队内部建立彼此的信任。从个人角度出发，我们应该具备相当的专业能力，拥有较强的自管理能力，并不断提升自己，增强挑战困难和暴露问题的勇气。
基于互相信任的前提，敏捷提倡自治的全功能团队。在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色（能力），团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值在团队内部快速流动并得到验证，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。
有了个体与交互，我们是否可以摒弃一切流程与工具呢？答案当然是不可以！
这里举一个我曾经的真实经历：
- 公司不同的角色分布在不同的部门。需求部门的分析师在前期会花上一个月甚至更久的时间跟客户讨论需求，编写详细的需求分析文档（开发人员和设计人员不参与）。
- 需求文档被部门经理审核通过之后，项目管理系统进行提交。
- 我拿到需求分析文档进行功能开发，设计部门根据需求文档设计原型界面。
- 后期的开发过程中，当我需要一个icon的时候，我不得不在系统中提交申请，并由设计部门的项目经理审批后，设计师才开始设计。
- 功能开发完成后，在预先的发布时间内，由项目经理授权将软件提交给测试部门，测试部门开始测试。
- 测试人员在系统中通过Bug跟踪来反馈测试结果，后期开发人员和测试人员的交互主要发生在Bug跟踪系统上。这就好比，两个人在使用邮箱在交流一个紧急的Bug。
- 等待和返工成了后期开发的家常便饭，更低效的是，返工的时候需要反向走流程。另外，整个过程从需求分析到交给测试团队历时了大半年之久。
在上述流程中，每个部门各自为政，好处是每个人在小黑屋里能专注、"高效"地做出一个用于被审批的中间产物，坏处是缺乏整体视角，很可能是以最高的效率做了一件错误的事情（效率低下的终极定义）。层层审批流程在重量级的项目管理和Bug跟踪工具下似乎运行得很良好，却扼杀了及时沟通和调整的时机，制造了彼此之间的隔阂、大大增加了成本浪费，于组织、于个人都无益。
所以，我们要摒弃这种重流程和重工具，提倡轻量级流程和轻量级工具，而这些流程和工具又在促进个体交互。比如，我们在日常工作中会使用Trello、Jira、Keynote等工具。
价值导向
可工作的软件最终交付物，是我们追求的核心价值，以价值为导向也是我们每个职业人力所能及在做的事情。在交付价值的同时，如何看待过程中的文档呢？可能就仁者见仁智者见智了。
提到文档，"敏捷神教徒"会跳出来指责并排斥一切文档，他们提倡开发人员应基于口头讨论后便开工，以最快的速度将业务功能实现，这是一种极端的思想，曲解了其含义。
为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。
在Scrum体系中，产品待办列表和Sprint待办列表就属于轻量级的文档。前者涵盖了产品的业务价值，后者包含了指导团队进行迭代开发的最优先的业务需求，并且在团队内形成知识共享，促进沟通协作。这类文档不应当省略。
在开发过程中，交互设计原型也是一种轻量级文档，交互设计师交付可以尽早地跟团队和客户进行确认验收的核心业务场景的原型，快速收集反馈。而不是一开始就将产品的所有功能界面进行分块，然后在内容、视觉、交互上设计到非常精美的程度。
以上两类文档都能够为团队中的个体交互提供基础支撑，大大的提高团队的协作效率。要不然，所有人都基于自己脑海里的信息去交流，很可能置身战场（舌战）的感觉。
除了以上促进价值交付的文档，还有如下几类文档也是有价值，甚至不避免的：
- 作为交付物的一部分，比如用户手册，安装指南等。
- 软件发布受法律监管强制要求的文档。
- 帮助新成员快速获取项目上下文的文档。
- 记录重要会议和重要决策的文档，以便回溯。
回到实际项目中，有一类文档会引起较多争议，比如：Troubleshoots、开发规范、交接文档、系统架构图等，这类文档更多是从项目管理的角度出发。而维护这些文档往往会提高管理成本，这是一个博弈的过程。怎么权衡也是需要根据不同的项目情况来定，我们要警惕的是盲目排斥一切文档，心中拿捏一杆秤：文档所创造的价值高于管理它的成本，它就值得去做。
客户团队
2015年，我去ThoughtWorks新加坡Office参与一个银行系统的交付。当时从中国区调遣人员过去支援，一来因为那边人员相对较为紧缺，二来因为跟客户关系处理得有些不妥，那边同事不愿意介入。近三个月的时间，软件成功交付上线了，但从销售那得知项目款很难要回来，后来我才知道这个项目一开始没有签下合同...感慨对优于合同谈判践行得不错！
当然这是个反例。为了避免误解，我们需要从两个视角去对待合同：商务视角和交付视角。从商务视角，企业与企业合作需要法律的保障，所以正常情况下需要有一份合法的合同作为保障，这种不常见的问题更多出在管理上（新加坡总经理后被更换了）。
我们更多从交付视角来出发。ThoughtWorks作为一家专业软件服务提供商，我们的终极目标是帮助客户实现他们真正想要的价值。基于业务从来都是捉摸不定的前提，在开发的过程中我们不可能固守一张死合同，遇到需求变更就谈判，面红耳赤最终只能关系破裂，导致双输。
我们提倡客户团队，客户也作为团队的一分子，跟客户建立信任的合作关系取代敌对的谈判关系。因为需求的变化往往来自客户，这背后往往也是因为不确定的业务模式导致。让客户参与进来可以在开发的过程中尽早的发现变化，从而尽早采取解决方案，避免更多的浪费，保证交付朝正确的方向前进。协作的前提是信任，客户直接参与能够让客户更清楚当前的交付状况，增强客户的信心以及对我们的信任，切忌采取合同互怼的下下策。
如果不能让客户成为团队的一分子，就要尽可能在其他的方面多做工作，比如提高Showcase频率，提高跟客户Catchup的频率，提供一个软件环境让客户始终能够在用我们交付的系统，等等。
另外，客户参与可以提升客户的责任感，从而避免客户不负责任的需求变动。
拥抱变化
在我看来，这一点道出了敏捷的精髓。我曾经给敏捷下过定义：通过高效的协作，获取快速的反馈，以便尽早做出调整，从而减少浪费，交付更大的价值。
敏捷初衷并不是让我们更快速地交付软件，敏捷一词很容易让人们产生望文生义的联想：敏捷就是迅速，就是快。当我们在看两个武功相当的高手过招（非太极）的时候，除了眼花缭乱的动作（出手极快，咏春拳唯快不破），更核心的点是他们能够根据对手的出招来快速采取应对招式。回到敏捷软件开发，开发速度快慢与否取决于团队成员的能力以及团队协作的默契度等因素，所以不一定所有的敏捷团队开发速度都会很高。而她真正的威力在于，当面临业务需求变更的时候，敏捷开发方式让我们能够更早、更快的做出响应。响应变化的能力才是她的核心竞争力，而她恰恰巧妙了抓了业务复杂性和不确定性的核心属性。
敏捷团队的交付速度有可能在某些特定迭代比瀑布团队更慢，但需求发生变更时（通常一定会发生），响应变化的敏捷交付团队很早就做出了调整，而遵循计划的瀑布团队极有可能是一条道走到黑，最终交付一个让客户想哭又哭不出来的四不像。从最终价值成果来看，敏捷开发实践显然更容易帮助我们实现价值最大化。
如果说我们做任何事情的终极目标是实现价值最大化，那么敏捷的终极目标就是通过提升响应力来最小化浪费，从而最大化价值。敏捷的开发团队能够更快速响应业务需求的变化，敏捷的企业组织能够更快速相应市场的变化。
变化一词很好的描述了软件开发的本身属性，业务需求的不确定性给了敏捷软件开发方法用武之地。而对于流程非常稳定不变的工作，比如富士康某条成熟的iPhone生产线，遵循计划恐怕是更佳的选择。
写在最后
敏捷虽好，不要盲从，更不要迷信
敏捷开发方法有她的优势，也有她的门槛。市面上存在不少有形无神的伪敏捷组织。他们天天站会，甚至，他们也模仿Scrum搞了个3355，但他们仍然苦于对变化的龟速响应。
我认为敏捷更像一种文化价值的认同，相比于形式，更重要的是团队对敏捷价值观的理解和认同，以及指导他们做出日常行为是否体现了尊重、勇气、开放、承诺、专注、反馈、简洁这些核心价值观。在一个敏捷的团队中，每个成员都应该拥有持续改进的心态，他们会不断学习理解敏捷宣言的内涵，会不断提升自己的专业技能，并能够结合团队实际情况采取因地制宜的敏捷实践。
Posted by 袁慎建@ThoughtWorks
版权声明：自由转载•非商用•非衍生•保持署名 | Creative Commons BY-NC-ND 4.0
原文链接：https://sjyuan.cc/understand-agile-manifesto-deeply/
