作为敏捷软件开发的纲领性文件，《敏捷宣言》全文有着紧密的内在联系，全文都很重要。不过但凡几句话放在一起，对于特定的环境、特定的读者，总有个优先级可排。对于中国软件业大多数企业、大多数从业者，《敏捷宣言》里哪一句是最重要、最需要认真对待的？

我看到有些搞敏捷的同行弄得很玄虚，说《敏捷宣言》不止是中间的这四句，一定要把上下那几句话也拉上一起看。我觉得吧，这话虽然形式逻辑上没什么错，但是呢，这本来就是一个宣言性质的文本，作者非常刻意地把这四句话工工整整摆在正中间，重点在哪里、强调什么，是很明显的事。非要说“不能只看中间四句话”，这个说好听点叫眉毛胡子一把抓分不清主次，说难听点就叫装x，不值得提倡。

那么中间四句话里面，对于中国的同行，哪一句更重要呢？我认为，在讨论软件开发方法的时候，首先得把软件顺利地开发出来，而这件看起来很基本的事，对于国内很多同行来说都还有很多挑战。所以我的观点，在中国这个行业普遍水平上，应该首先关注《敏捷宣言》的第二句：

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

因为当你真正开始关注“可工作的软件”，你才能真正理解，敏捷的若干实践，为什么是今天这个样，应该关注什么要点。比如说，需求应该怎么拆解？站在“可工作的软件”这个角度，答案就会很清晰：不能按照“谁来开发”拆，应该按照“给用户提供什么价值”来拆。因为只有用户能用、能创造价值的功能，才是“可工作的软件”。于是很自然地，一个单体Web应用上硬拆出什么前端需求后端需求，甚至恨不得还拆出个数据库需求，这就是反敏捷的瞎搞。正确的需求拆解方法，一定是“纵切蛋糕”，每一个需求单元拆得再小，也是能够独立发布、独立创造价值的。

既然需求单元长成这样了，项目管理应该关注什么要点？从“可工作的软件”的角度出发，项目管理要管的就一定是如何把小块的需求流动起来，尽快、尽可能频繁地把小块需求交付给用户去使用，因为这才是每周、每天的工作真正体现为“可工作的软件”。把软件开发的各个阶段（分析、设计、开发、测试）拆开一段做完再做下一段，天天盯着人员工作量是否饱满，放在“可工作的软件”这个视角下一看就是很明显的错误做法。正如我经常问的那个问题：当“项目进度60%”的时候如果马上把项目停下，你能得到什么？是已经具备60%功能、能够实现60%用户价值的可工作的软件吗？还是只有一堆文档没有任何软件可用？这个问题，就是《敏捷宣言》第二句最直观的表现形式。

既然项目是以这种方式运作，软件的变更应该如何进行？很明显，你就不能指望一块代码写完测好以后就再也不去动它。你就得接受这个现实：功能是一点一点加上去的，代码是不断反复修改的，并且任何人都有可能修改任何一块代码——如果没有“集体代码所有制”，如果划分代码责任田，每人负责一块代码，那么需求的“纵切蛋糕”就会变成一句废话，并且项目管理也无法开展，因为整个项目的进展无可避免地就会绑死在最瓶颈的那块代码、那个人。

既然已经确定代码要反复修改、大家都能改，那么软件的质量要如何保障？答案是清晰且唯一的：不可能靠人肉回归测试来保障质量，必须依赖全面、可靠、快速的自动化测试来构建软件质量的安全网。测试部的小姑娘可以忍受每两周做一次人肉回归测试，但是再缩短周期就是人类极限了。（这也解释了为什么国内大多数敏捷团队最多能做到每两周一次发布，无法再缩短发布周期。）只有基于全面、可靠、快速的自动化测试开展持续集成，才有可能保证被反复修改的软件一直处于可工作的状态。并且也只有具备了全面、可靠、快速的自动化测试，程序员才有勇气不断重构代码，保障软件的内部质量处于良好的、允许反复修改的状态。

如上所述，只要抓住了《敏捷宣言》的第二句，对于需求管理、项目管理、配置管理、质量保证这4项软件开发的基础能力，应该怎么做都是一目了然的。敏捷有没有做对，只要拿“可工作的软件”为准绳来量一下，基本上是清清楚楚的。应该怎么去改进，答案也是明明白白的。当然了，难免有一些人、一些组织，总想绕着圈子走，不去碰那些最核心、最根本的能力问题。这些人和组织绕了半天圈子以后，你会发现，哎，他们真的就得到了一堆面面俱到的文档，而“可工作的软件”，还是老样子。这就叫求仁得仁。