深度解读敏捷宣言

敏捷宣言概览

英文版：

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.

中文版：

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此，我们建立了如下价值观：

个体与交互 优于 流程与工具
可工作的软件 优于 面面俱到的文档
客户协作 优于 合同谈判  
响应变化 优于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值

以上内容出自敏捷宣言： http://agilemanifesto.org/

我身边不少同仁对敏捷宣言中间的四句较为熟悉，往往最容易忽略了前后两句，久而久之，使得一些后来者曲了解敏捷宣言的精髓。而我恰恰觉得敏捷宣言的首、尾很重要。

第一句告诉我们敏捷方法论并不是凭空而谈，它源自于截止目前的实践积累，而它有可能没法直接解决你现在所面临的问题，所以不必将其神话论，盲目跟随，说不定将来会有更高效地方式，核心是我们应不断在实践中去探索。

也就是说，尽管右项有其价值，我们更重视左项的价值 这一句起到画龙点睛，敏捷方法论源自于实践，回归实践，它应该能够帮助我们解决实际问题，而不是一个框住我们思维的框架，沦落为思想牢笼。所以在实践中，我们应该以开放的心态去接受右项的价值，并在探索中借用左项来帮助团队提升效率。而不是一味着否定一边而神话另一边。我们应该时刻警惕这一点。

敏捷宣言解读

个体与交互 优于 流程与工具

我相信没有比面对面交流更高效的沟通渠道了

一个人在团中的战斗力巅峰状态一定是在受到足够的尊重和信任的前提下产生的，这能够激发个人内心的责任感和使命感，也就激发了潜能。从团队角度出发， 我们应该充分尊重每个人，激发个体的斗志给与他们所需要的环境和支持，并且相信他们能够完成任务 ，在团队内部建立彼此的信任。从个人角度出发，我们应该具备相当的专业能力，拥有较强的自管理能力，并不断提升自己，增强挑战困难和暴露问题的勇气。

基于互相信任的前提，敏捷提倡自治的全功能团队。在工作形式上，整个团队平时坐在一起工作，从物理空间上创造了更加便捷面对面的沟通机会。在团队职责上，团队内部具备完成软件交付的角色（能力），团队所有人对软件的质量负责，开发过程由团队内部把控，业务价值团队内部快速流动，在任何环节都能及时获得反馈。同时，每个角色都更容易从全局视角去思考软件，避免了传统部门墙模式下的视角割裂和协作障碍。

有了个体与交互，我们是否可以摒弃一切流程与 工具 呢？答案当然是不可以！

这里举一个我曾经的真实经历：

1. 公司不同的角色分布在不同的部门。需求部门的分析师在前期会花上一个月甚至更久的时间跟客户讨论需求，编写详细的需求分析文档（开发人员和设计人员不参与）。
2. 需求文档被部门经理审核通过之后，项目管理系统进行提交。
3. 我拿到需求分析文档进行功能开发，设计部门根据需求文档设计原型界面。
4. 后期的开发过程中，当我需要一个icon的时候，我不得不在系统中提交申请，并由设计部门的项目经理审批后，设计师才开始设计。
5. 功能开发完成后，在预先的发布时间内，由项目经理授权将软件提交给测试部门，测试部门开始测试。
6. 测试人员在系统中通过Bug跟踪来反馈测试结果，后期开发人员和测试人员的交互主要发生在Bug跟踪系统上。这就好比，两个人在使用邮箱在交流一个紧急的Bug。
7. 等待和返工成了后期开发的家常便饭，更低效的是，返工的时候需要反向走流程。

在上述流程中，每个部门各自为政，好处是每个人在小黑屋里能专注、”高效”地做出一个用于被审批的中间产物，坏处是缺乏整体视角，很可能是以最高的效率做了一件错误的事情（效率低下的终极定义）。层层审批流程在重量级的项目管理和Bug跟踪工具下似乎运行得很良好，却扼杀了及时沟通和调整的时机，制造了彼此之间的隔阂、大大增加了成本浪费，于组织、于个人都无益。所以，这些是我们尽量要摒弃的。

所以我们要摒弃的是这种重流程和重工具的做法，提倡轻量级流程和轻量级工具，而这些流程和工具又在促进个体交互。比如，我们在日常工作中会使用Trello、Jira、Keynote等工具。

可工作的软件 优于 面面俱到的文档

提到文档，”敏捷神教徒”会跳出来指责并排斥一切文档，他们提倡开发人员应基于口头讨论后便开工，以最快的速度将业务功能实现，这是一种极端的思想，曲解了其含义。

为客户交付可工作的软件是我们的核心目标，我们应该尽早交付可进行端到端测试的代码，该目标决定了我们不应该花过多精力在面面俱到的文档上，但这不代表我们要抵制任何文档。实践证明，轻量级的文档策略有助于团队高质量交付可工作的软件。

在Scrum体系中，产品待办列表和Sprint待办列表就属于轻量级的文档。前者涵盖了产品的本身业务价值，后者指导团队进行迭代开发，并且在团队内形成知识共享，促进沟通协作。这类文档不应当省略。

在开发过程中，交互设计原型也是一种轻量级文档，交互设计师交付可以尽早地跟团队和客户进行确认验收的核心业务场景的原型，快速收集反馈。而不是一开始就将产品的所有功能界面在内容、视觉、交互上分别切割，各个环节独立设计到非常精美的程度。

以上两类文档都能够为团队中的个体交互提供基础支撑，极大的提高团队的协作效率。要不然，所有人都基于自己脑海里的信息去交流，很可能置身战场的感觉。

回到实际项目中，有一类文档会引起较多争议，比如：问题备忘录、开发规范、交接文档、安装指南、系统架构图等，这类文档更多是从项目管理的角度出发。而维护这些文档往往会提高管理成本，这是一个博弈的过程。所以怎么权衡也是需要根据不同的项目情况来定，我们要做的是切记排斥一些文档，心中拿捏一杆秤：文档所创造的价值高于管理它的成本，它就值得去做。

客户协作 优于 合同谈判

2015年，我去ThoughtWorks新加坡Office参与一个银行系统的交付。当时从中国区调遣人员过去支援，一来因为那边人员相对较为紧缺，二来因为跟客户关系处理得有些不妥，那边同事不愿意介入。近三个月的时间，软件成功交付上线了，但从销售那得知项目款很难要回来，后来我才知道这个项目一开始没有签下合同…感慨对优于合同谈判践行得不错！

当然这是个反例。为了避免误解，我们需要从两个视角去对待合同：商务视角和交付视角。从商务视角，企业与企业合作需要法律的保障，所以正常情况下需要有一份合法的合同作为保障，这种不常见的问题更多出在管理上（新加坡总经理后被更换了）。

我们更多从交付视角来出发。ThoughtWorks作为一家专业软件服务提供商，我们的终极目标是帮助客户实现他们真正想要的价值。基于业务从来都是捉摸不定的前提，在开发的过程中我们不可能固守一张死合同，遇到需求变更就谈判，面红耳赤最终只能关系破裂，导致双输。

我们提倡客户跟我们在一起。需求的变化往往来自客户，这背后往往也是因为不确定的业务模式导致。让客户参与进来可以在开发的过程中尽早的发现变化，从而尽早采取解决方案，避免更多的浪费，保证交付朝正确的方向前进。协作就需要建立信任，所以有事没事就拿合同来互怼，肯定是下下策。

如果客户没法在一起工作，就要尽可能在其他的方面多做工作，比如提高showcase频率，提高跟客户Catchup的频率，提供一个软件环境让客户始终能够在用我们交付的系统，等等。

另外，客户参与可以提升客户的责任感，从而避免客户不负责任的需求变动。

响应变化 优于 遵循计划

在我看来，这一点道出了敏捷的精髓。我曾经这样定义敏捷： 通过高效的协作，获取快速的反馈，从而尽早做出调整，减少浪费

待续

扩展

1. 敏捷实践的TDD出自极限编程，它提供了一种强大的思维工具Tasking。而在实践中，人们在做Tasking时会从功能视角或者业务视角出发。开发人员往往更习惯功能视角。功能视角和业务视角，它俩的区别，犹如传统的开发流程和敏捷开发流程的区别。前者只有在各个不同功能模块的完成叠加之后去交付业务价值，后者每次都能够交付一个独立的业务价值，从而尽早、更快地为客户交付价值，获得客户真实有效的反馈，便于及时作出调整。

2. 很多开发者在讲到测试的好处的时候都会提到一点 – 测试即文档。这种说法无疑也是在强调可工作的软件的重要性。测试时可执行的文档，它代表了我们的业务价值

欢迎找我交流， 邮箱 |

ThoughtWorks 常年招聘DEV、UX、PM、BA、QA等角色，如果你对ThoughtWorks心动了，快来找我内推吧