【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.

    这条价值观意味着，我们应该停止专注于定义和遵从“计划”（过程定义，甘特图表等），停止专注于预测和遵从预测；相反，我们应该专注于学习、了解和演进，建立一种强调自适应而非遵从的开发文化。