【IT168 专稿】
译序
Craig Larman 是近年来一直活跃在欧美敏捷软件工程核心圈中的一位大师，敏捷方法名著《敏捷迭代开发：管理者指南》（Agile & Iterative Development: A Manager's Guide）和《Scaling Lean and Agile Development: Thinking and Organizational Tools for Large Scale-Scrum》的作者，也是我的一位良师益友。
两年前国内某家知名大型软件企业找到我和Craig Larman，希望Larman 和我能够为其提供敏捷实施咨询。当时他们交给Larman 一份类似“标书”的 RFP（Request For Proposals），请Larman 提提建议。Craig 在这份 RFP 中发现了不少客户对于敏捷的误解，于是他在与客户的通信中陆续谈到了到底什么是敏捷，敏捷价值观的内涵，自我组织的团队、经验过程、非串行过程和跨职能团队等敏捷方法，敏捷过程的基本特征，以及大中型组织敏捷改进或实施的重点和难点。
我想，他的这些介绍尽管不长，却对于我们国内的读者、敏捷实践者来说具有重要的指导和参考价值，便于我们了解国外一线专家对于敏捷真正涵义的确切想法，澄清和纠正我们对于什么是敏捷的一些错误认识。在征得Craig 的同意之后，我对原文作了一些编译和注评，在此一并奉献给大家。
Note: texts below are extracted and compiled from informal email communications.
敏捷价值观
Scrum and agile is not a practice; it is a set of values that imply a deep understanding and learning by the leadership team, and then transformation of the culture and new behaviors by the senior management team based on the agile values.
Scrum 和敏捷不是某一种具体的做法，而是一组价值观，它们意味着管理团队的深入理解和主动学习，以及基于这些敏捷价值观，在高层管理团队主导下的企业文化和行为的一场变革。
4条敏捷价值观是：
1. Individuals and interactions over processes and tools（注重个人与协作，胜于过程与工具）
This implies a focus on the quality of empowered individuals, building great people with deep root-cause thinking skills, and on removing communication barriers, eliminating handoff and handover processes, eliminating separated functional teams, eliminating distributed teams, and so forth, and focusing on close communication and very close collaboration between product mgmt and R&D and business mgmt. And it implies that official defined processes and tools are not very important, and the belief that success comes primarily from a focus on defined processes (rather than individuals and interactions) is mistaken.
这意味着，我们应该专注于经充分授权的人员的质量，培养具备娴熟根源（root-cause）分析思维技能的优秀人员，排除沟通障碍，放弃传统的移交/转交式（handoff and handover）过程，避免分离的职能/功能团队，避免分布式团队 ... 等等，以及专注于密切的沟通，尤其是产品管理团队与研发团队、业务管理团队之间非常紧密的协作。这还意味着，官方指定的过程和工具其实并非如此重要，而那种笃信软件研发的成功主要来自于对既定过程（而非个人与协作）的专注是错误的。
注评：这条充分体现了敏捷开发以人为本的思想，而不是以过程或工具为本。关注现实以及您的团队成员的真实意见和想法，比关注强加在他们身上的所谓“权威”、“标准”过程更为重要。
2. Working software over comprehensive documentation（注重可用的软件，胜于详尽的文档）
此条不言自明。
3. Customer collaboration over contract negotiation（注重客户协作，胜于契约谈判）
A 'contract' in this context does not really mean a commercial contract (though that is part of it); rather, it is implies all forms of specifications, plans, requirements documents, etc. This value says that the belief that focusing on formalized specifications or plans and handing them off to others, and on focusing on conforming to these 'contracts' (plans, etc.) is a mistaken focus -- it will not primarily lead to success. Rather, in agile values we focus on close collaboration, learning and discovery, and a daily interplay between (for example) product mgmt and R&D. We stop focusing on plans, specifications, etc, and instead focus on collaboration, discovery evolution.
这里的“契约”（contract）不一定意味着一份真正的商业合同（当然，有可能是它的一部分），它可能包含各种形式的规约、计划、需求文档等等。本条价值观说的是，那种专注于正式的规约或计划，并把它们移交给他人，以及专注于遵从这些“契约”（计划等）的观念是错误的——它们往往不能导致成功。而在敏捷价值观当中，我们专注于紧密的协作，学习和探索，以及（比方说）产品管理与研发团队之间的每日交流。我们不再专注于计划、规约等等形式的契约，协作和发现、探索式的演进开发成为了新的重点。
4. Responding to change over following a plan（注重响应变化，胜于恪守计划）
This value implies that we stop focusing on defining and conforming to "plans" (process definitions, gant-chart schedules, etc) and we stop focusing on prediction and conforming to predictions; rather, we focus on learning and evolution, developing a culture that emphasizes adaptation rather than conformance.
这条价值观意味着，我们应该停止专注于定义和遵从“计划”（过程定义，甘特图表等），停止专注于预测和遵从预测；相反，我们应该专注于学习、了解和演进，建立一种强调自适应而非遵从的开发文化。
敏捷原则
关于12条敏捷原则中的一些重点：
* Self organizing teams（自我组织的团队）
This implies the end of command-and-control mgmt. Teams self-organize and define themselves how they work to fulfill the goals of the iteration, and that they define their own process (each iteration) that helps them towards their goals. In Scrum, no mgmt is allowed to inspect, track, manage, or measure how teams work within an iteration.
这意味着停止命令与控制式的管理。团队进行自我管理、自我组织，他们自行确定如何有效工作以实现迭代目标，自行定义所采用的过程（甚至通过每个迭代进行调整）以帮助其实现目标。在Scrum 方法中，不允许任何外部的管理者审查、跟踪、管理或者度量团队在一次迭代中是如何开展工作的。
注评：开发团队的自我组织和管理是Scrum 实施中的一大难点，我想可能国内有很多团队一时难以做到，这代表了一种更先进、更高级（或者说更大胆）的管理文化，是建立在大家充分信任的基础之上的。所以，我说只有技术技能、管理和文化各方面都很成熟的团队（比如那些先进领导企业中的）才能真正做到敏捷。
我听到不少朋友说，敏捷对人员技能水平的要求更高，这的确有点道理。
* Empirical process（经验过程）
This implies the end of defined processes, and instead a culture of "4 week processes created by each team" based on inspect and adapt culture. Each team defines, owns and evolves their own 4-week process. At the end of each iteration, they do a retrospective and define a new 4-week process. The entire process culture expresses the Toyota mindset emphasized by the Toyota CEO, "Challenge everything, all the time. Do not accept the status quo of existing process practices."
这意味着终结既定过程，取而代之的是一种建立在检验（inspect）和调整（adapt）文化之上的，“由每个团队每4周创造出一种新过程”的过程文化。每个团队可以定义、拥有和演进属于他们自己的4周过程。在每次迭代的终了，敏捷团队进行一次回顾，再制定出下一个新的4周过程。整个的这种过程文化体现了Toyota CEO所强调的丰田精神：“无论何时何地，挑战/质疑一切。绝不要满足于当前过程实践的现状。”
注评：实践是检验真理的唯一标准。
* The end of sequential life cycles（终结串型生命周期）
In agile methods there is no Requirements Phase, Testing Phase, Integration Phase. There is no handoff of a specifications from one group to another, etc.
在敏捷方法中，不再有需求阶段、测试阶段和集成阶段的划分，也不再有在制作完成一份规格说明后把它从一个部门转交/移交/递交到另一个部门的现象 ...
* Co-located cross-functional feature teams（同址的跨功能/职能特性团队）
that together do the analysis, development, and testing of customer-centric end-2-end features
通过共处一地（同址）的跨功能/职能特性团队，联合对以客户为中心的端到端需求特性进行分析、开发和测试。
注评：关于跨职能的特性团队，请参考Craig Larman 和Bas Vodde 撰写的新书Scaling Lean & Agile 中的样章Feature teams, PDF。
Agile thoughtleaders sometimes summarize all this as: you don't _do_ agile, you _be_ agile.
敏捷大师们把以上这些内容概括为：
不是做敏捷，而是发自内心地成为一个敏捷人。
Please note this is not my opinion; this is what 'agile' is officially defined as -- by the Agile Manifesto. if you engage a consulting group that is not focusing on these messages and insight, you have not met a group that really understands agile methods.
请注意，以上并不是我个人（Craig）的观点，这是 《敏捷宣言》 对于“敏捷”的官方定义。如果您遇到一家咨询机构，没有强调这些重要信息和思想，那么他们很可能不懂真正的敏捷方法。
大中型组织的敏捷实施
Agile is not a practice that a development team adopts, it is a fundamental change in mindset of how to work by the leadership. In terms of effort and time, this usually involves, for an organization of large and/or medium size, between 2-4 years of intensive change initiative, focusing primarily on working with the leadership and senior product and business management groups. Adopting agile involves large-scale re-education away from traditional practices and processes and mindset, involving thousands of people needing to go through a transformation of understanding and behaviors, large-scale education of thousands of people in the Scrum method (through the CSM and Product Owner trainings, etc), based on the agile and scrum values -- and for most benefit, the lean thinking principles as well.
敏捷并不是开发团队所采取的某一种、某一个具体的（实践）做法，它实际上是一种有关管理者如何更加有效地开展工作的根本性思维变革。在所投入的工作量和时间方面，对于大中型软件企业和机构，敏捷实施通常需要花上2-4年的时间以开展深入的变革，而工作的重点在于企业的高层领导和产品、业务管理部门的高级管理者。大规模敏捷实施涉及到开展转变人们的传统做法、过程和思维的大规模再教育，包括转变成千上万人员的观念和行为，以及基于敏捷、Scrum价值观和精益思维（lean thinking）原则，对其进行Scrum 方法的教育和培训（如通过 CSM 和 Product Owner 培训等方式）。
This is very different than what the RFP proposed, which implies the customer believes they understand what agile is, and the document implies 'agile' is viewed as a set of practices (rather than a set of values and mgmt behavior changes), and that 'agile' can be adopted by a development group (rather than senior mgmt) and in a few weeks (rather than in terms of years), and that it can be recorded in a book or guide (rather than in a deep change in mindset).
以上内容与客户的RFP 所反映的内容差距很大，后者表明客户以为他们理解了什么是敏捷。在客户的RFP 中，“敏捷”被视为一组具体的做法，而不是一组价值观和管理变革；“敏捷”可以仅仅由一个开发团队（而不是高层管理者）在几周（而不是在几年）之中成功实施；敏捷可以被记载在一本图书指南中，而非涉及到人们思维观念的深刻转变。
注评：敏捷思维、价值观比具体的敏捷做法更重要。
Clients who engage me or the other real agile thoughtleaders start from the viewpoint of "we don't really know what agile is. would you like to come and explain and guide us, and advise on next steps?" This is related to the 3rd agile value: "customer collaboration over contract negotiation." What is needed in a real agile transformation RFP is a focus on the senior mgmt wanting to learn -- a discovery process guided by good coaches of your leadership team. The RFP would indicate a focus on working primarily (to start with) the senior leadership teams and on learning/guidance.
邀请Craig 或者其他真正的敏捷专家提供帮助的客户们，通常一开始都抱有这样的态度和观点：“我们不知道什么是真正的敏捷，能否请您过来帮我们解释和指导一下，建议我们下一步应该如何做？” 这其实与敏捷价值观的第三条有关：“注重客户协作，胜于契约谈判”。一份真正的敏捷变革RFP 文件，应该把焦点放在期待学习的高层管理者身上 —— 领导团队在优秀教练的指引下，采取一种探索、发现式的工作过程，而变革工作应该主要先从高层领导团队的学习和指导开始。
参考资料
The Scrum Primer V1.1 (PDF) by Pete Deemer, Gabrielle Benefield, Craig Larman and Bas Vodde
