逃离方法牢笼

关键点

• 解释什么是方法牢笼，解释它的副作用，包括权威、方法战争和之字形路径的概念，以及为什么它是“世界上最愚蠢的事情”。
• 采用本质（Essence）标准，基于公共基础（common ground）来处理方法，从而逃离方法牢笼。
• 团队可以让实践更容易传授、学习、改变和比较；有了针对日常工作的指引，团队可以更容易地应用实践、激励团队工作；团队可以从实践库中挑选实践组成整套方法。
• 管理者能让组织活动在根本上从技艺转变为工程学科；管理者能使组织获得持久学习的能力，随着团队经验增长，组织的实践库也会持续改进；管理者得到了评价已有项目进展和健康度的工具，这种工具独立于所使用的方法。
• 产业可以实现产业级的敏捷，从技艺升华为工程学科。

背景

世界开发软件已经超过 50 年了。软件几乎改变了我们生活的所有方面，我们的生活已经离不开软件。迄今为止，软件产业是非常成功的。我们似乎可以乐享其成，继续现有的发展路线。

然而，这种表象之下并非一片歌舞升平：我们有太多失败的试验、所有领域的质量都很差、成本过高、速度过慢等等。显然，我们需要更好的工作方式，或者换句话说，我们需要更好的方法。

这不是什么全新的视角。过去 50 多年以来我们一直在寻找更好的方法。在某些方面，我们开发软件的方法与过去相比已经彻底不同；另一些层面上我们基本在原地踏步。以整个产业来看，我们在走一条之字形路线，从一种范式或方法迁移到另一种范式或方法，如此往复。这很像是时尚产业引领时装潮流的路线。每次迁移到新的方法都是一件成本高昂、令人沮丧的事情。之所以会有高昂的成本，因为这意味着重新培训软件开发者、团队和他们的领导。有些情况下甚至需要重写已有的软件来更好地与新软件协作。而之所以会令人沮丧，是因为经验丰富的开发者感到自己不得不重新学一遍已经掌握的内容。

公司，尤其是大型公司，意识到好的方法能带来竞争优势——尽管他们需要的不止于此。他们还意识到，要先向组织详细解释和说明，然后才能让方法贯彻执行下去。此外，他们知道一种方法难以适应所有情况，所以需要很多方法。

这里方法是在开发软件时的一种指引，告诉我们需要做的各种事情。这些事情有技术层面的，诸如应对需求、应对代码、实施测试等；也有人力层面的，诸如创建良好协作的团队、创建高效的项目，或者提升人员的能力、评估指标等。2013 年我们有了一项有趣的发现：虽说世界上有数量如此众多的方法，但似乎所有的方法都不过是由一些“小方法（mini-method）”组合而成的，而这类“小方法”不过是几百种而已。这些“小方法”通常被称作是“实践（practice）”。
本文中方法这一术语也可以指代其它的一些相关概念，诸如流程、方法论、方法框架，当然这些概念严格来说含义是不太一样的。

1. 什么是方法牢笼

我们来看一下大规模敏捷所使用的四种知名的方法（也叫方法框架）：大规模敏捷框架（Scaled Agile Framework，SAFe）、大规模专业 Scrum（Scaled Professional Scrum，SPS）、规范敏捷交付（Disciplined Agile Delivery，DAD）和大规模 Scrum（Large Scale Scrum，LeSS）。

(点击放大图像)

图1 四种知名的大规模敏捷方法概览

它们都很流行，全球各地有众多组织使用它们。它们为组织用户提供价值的方式既有重叠之处，也有各自的独特途径。重叠意味着它们包含相同的实践，独特意味着它们有自己的特有实践，差异就来自于此。如果组织应用了其中一种方法，那么用户通常对其它选择会一无所知。

那么问题出在哪里？

1. 它们都是完全一体化，非模块化的。

多数方法（不仅限于上文谈到的这四种）都是一体化的，也就是说它们没有设计成模块的形式。这样我们就不能简单地将一个模块替换掉，同时让其他实践不受影响。

然而，我们需要的是一个可复用模块的库，库应该随着用户经验的增长而不断升级。鉴于每种方法只是一系列实践的组合，我们需要的是可复用的实践。团队和团队的团队（teams of teams）应该能从库中匹配、组合自己需要的实践并加以合成，从而轻松定制自己的个性方法。

2. 它们都有各自独立的展现风格。

每种方法都有自己独有的特定结构，使用独特的风格和术语来描述其实践。方法的所有者在描述自己方法的重要概念时不会遵循任何标准。结果，各个方法的实践之间都无法兼容。

3. 它们有许多共同点，这些共同点却难以发现。

此外，虽然每种方法都有一些独特的实践，它们彼此之间还是存在很多共同点。每种方法都“借鉴”了其它方法的实践，并“加以改进”。于是，这些共同点被隐藏在了新的术语和“新”的功能背后。这里用引号是要指出，其实真相并非只是“借鉴”，也不是总有“改进”。甚至由于原来的实践被错误理解或重新集成，从而经常会导致歪曲或困惑。类似地，“新”功能也不是什么全新的设计，而不过是过去已有实践的进化或分支的新名称（“新瓶装旧酒”）。

4. 每种方法都有自己的管理者，也就是权威

权威决定自己的方法中应该集成哪些实践，有些情况下还会从其他方法中“借鉴”和“改进”实践，从而扩展自己的方法。方法反映的是其权威的特定观念、偏好和经验，而非我们开发社区的经验集合。方法应该复用团队或组织在应对特定的挑战和目的时总结出的最佳实践，而不是由置身事外的某个权威来决定应该选择哪些实践。

5. 每种方法都有自己的品牌，且往往注册了商标和产权保护。

还有些权威发现用户喜欢其他方法的实践，于是被迫“借鉴”它们并“改进”可以被复用的部分。但反过来说，这种方式并不会增进与其他权威之间的协作氛围。考虑到其他权威为自己的方法投入的时间和资本，他们必定会全力保护自己的地盘不受影响，最终会导致方法之间的战争。

无论方法是公开的还是自创的，采用一种方法就意味着困在一套体系中。方法会使用独有的风格来呈现，虽然使用了很多通用的实践，但没人知道这些实践其实很常见。创立品牌的权威还会保护自己的方法，使其难以被复用。方法也无法简单地从通用的实践库中复用实践。总而言之，我们困进了方法牢笼。使用某位的权威的方法时，也就会局限于他们的决策方式范围之内。需要澄清的是，我们并不是说权威在有意地把用户困在方法牢笼里；他们只是在沿用我们的产业一直以来的做法，因为我们不知道有更好的方案。

这样，一旦你采用了一种方法，你就会困在由其权威控制的方法牢笼中了。Ivar Jacobson 是本文的作者之一，他曾是一位权威，管理着“统一流程”这座牢笼。他意识到这是“世界上最愚蠢的事情”（当然指的是软件世界），这种现象对任何产业都毫无益处，尤其是软件工业。最近其他人也表达了类似的观点，参见附录 [0]。

作为软件专业人员，我们应该阻止这种荒唐的趋势。我们希望有着创意实践想法的人们能共同协作，一起为世界带来可复用的实践库。我们想要这些人服务整个产业，而不是被迫创立独立的方法品牌。

方法可以是潜规则，人们心照不宣；也可以是明规则，规则细致程度各异。世上的很多软件都是用潜规则方法开发的。使用潜规则方法的组织通常不会察觉方法牢笼的困境，可他们却经常因为无法阐释自己的方法，进而难以轻易改变，于是就困进了方法牢笼。

2. 方法的历史与方法牢笼

自从我们开始开发软件并采用公开发布的方法，方法牢笼就出现了。此外，方法牢笼还有一些的副作用亟待消灭，其中三项最严重的负面影响是：对权威的依赖、方法战争和之字形路径。本段主要回顾方法是如何形成方法牢笼的历史及其副作用。我们会从两个角度进行分析：生命周期与实践。

很多组织并没有意识到自己陷入了方法牢笼，原因也很简单。他们没有意识到问题的存在，因为他们并不知道还有什么选择。对他们来说这些问题太抽象，除非存在其解决方案。曾几何时用户不知道软件可以用组件来搭建，比如说 java bean。
类似地，他们也不知道要掌握需求需要用例或用户故事，等等。然而，一旦他们意识到这些，开始使用新的方法，他们就能看到其价值所在。类似地，一旦他们发现自己可以从一个通用的实践库中组建出自己的方法，他们就不会再回头了。

品牌化的方法造成方法牢笼的现象是很容易理解的。然而，组织自行发展出的方法也会导致相同的结果，只是没那么显而易见罢了。那么敏捷方法呢？如今多数敏捷方法的描述都比较简洁。但是它们也面临相同的问题，不支持复用、不支持混合和匹配实践，没有实践库等等。我们支持简洁、着重于要素的描述，但描述应该在有需要时扩充更多细节。

2.1 权威，方法战争和之字形路径

为什么说依赖权威是不好的？

1. 我们都知道依赖单一的方法 / 权威是有风险的。对于大公司来说，公司满足客户需求的道路上，不受他们控制的外部个体却扮演如此重要的角色，这种风险是难以接受的。没有哪种方法能真正囊括不同的工作场景及产业、不同的公司及其雇员所引出的无数变量。
2. 依赖权威是在拿组织的未来竞争力和适应力，以及组织的生存与发展在下赌注。一旦如此，以后就是方法权威来决定方法牢笼是否该逐渐进化，该怎样进化。如果你不喜欢权威的做法，或者权威的想法不适合组织的蓝图策略和相关需求，你也无能为力。因为你已经困进了方法牢笼，除非你愿意忍受迁移到另一座牢笼所要承担的花费与痛苦。

一场方法战争正在弥漫着硝烟。这场战争在 50 年前就已经打响，至今仍未结束。用个调侃的说法，我们可以给它取名为五十年战争，比欧洲在 17 世纪早期的三十年战争还要长（另外三十年战争也是一场“宗教战争”）。没有迹象表明这场战争会自行终结。

之所以这是一场战争，是因为一直以来方法之间都难以比较。我们还没有能作为通行参照的一套公共基础（common ground）。不同的方法使用不同的术语，本来意义相同的术语被装点上微小的差异，而这些差异被严重夸大了。接近但并非同型异义的术语则非常难以对比。权威与追随者们谈及自己的方法时会使用宗教化、充满狂热的用语，结果让理性的对比和评价更为困难。由于不同的方法不会基于同一个标准平台，对比和理性地讨论方法变成了不可能的任务。

曾几何时，我们有一大堆不同的标记方法来描述软件工程中的元素。之后，在 1997 年我们有了统一建模语言（Unified Modeling Language，UML），以一种标准取代了所有不同的标记，标记战争结束了。标记只是方法的一个层面，所以我们需要在其他所有层面上应用类似的标准。这种标准应该满足我们对方法所有的差异性需求。

软件产业走的是一条之字形路径，从一个范式、方法迁移到下一个范式、方法。

1. 每次重大的范式迁移，比如从结构方法到对象方法，从对象方法到敏捷方法，产业都基本上会抛弃自身对软件开发的所有认知，然后用和过去几无关联的术语从头来过。旧的实践被弃之如敝屣，新的实践招摇登台。这种新旧交替对软件产业来说代价沉重，培训、教练和建立工具都花费不菲。
2. 每次重要的新技术潮流到来时，例如面向服务架构、大数据、云计算、物联网等，方法创作者都会“重新发明轮子”。他们创造出新的术语和实践，但其实本可以复用已有的内容。此类花费不像第一点所提到的那样昂贵，因为有些变化并不是影响全局的基础性改变，影响也没那么大（比如云计算）。但它们仍然会带来显著而愚蠢的浪费。

此类大趋势每次发生时都会有很多方法参与竞争。比如说，90 年代早期曾有大约 30 种面向对象的方法互相竞争。问题在于所有这些方法都面临五种导致方法牢笼的问题。当然这对最后胜出的方法的创造者来说是优势，即便这不是他们有意为之。

我们必须结束这种之字形路线。

2.2 生命周期和方法牢笼

计算行业早年使用过的方法中有一种是瀑布流方法。曾有上百种类似的方法公开发布。其中最流行的有有结构分析和设计技巧（Structured Analysis and Design Technique，SADT）、结构分析 / 结构设计（Structured Analysis/Structured Design，SA/SD）与信息工程（Information Engineering，IE）。它们在 60 年代到 2000 年之间非常成功。

瀑布流方法受建筑项目管理实践影响颇深，其口号是“设法像市政工程师建造桥梁一样开发软件”。这些方法将软件开发项目分解为一系列阶段，比如需求、设计、集成（编程）和检验（例如测试和 bug 修复）。

到了 2000 年左右，瀑布流方法越来越多地被迭代方法取代，后者最早由 Barry Boehm 的 Spiral Model of Softwared Development and Enhancement（软件开发与改进的螺旋模型）提出，包括诸如 RUP、DSDM 等方法。迭代法之后由敏捷实践，诸如 XP 和 Scrum 等进行了简化，并更广泛地流行起来。早前提出的四种方法：SAFe、SPS、DAD 和 LeSS，都应用了迭代生命周期。

当然，所有这些方法都伴随着方法牢笼，我们还是依赖权威，继续无休止的方法战争。

2.3 实践和方法牢笼

自从有了软件开发，我们就在为让我们的项目走上正轨而努力。一开始，我们努力的方向是编程，因为写代码是我们显然该做的事情。其它要做的事情都是临时性的。我们并没有真正的条例来指引我们编写需求、进行测试、配置管理，完成其它诸如此类的重要事项。

软件工程的历史上有三段主要的时期（年份不是精确值）：

• 1960-1980：结构方法时代，
• 1980-2000：对象方法时代，
• 2000 至今：敏捷方法时代，

结果不同时期间，产业是在走之字形路线。将来我们可不想再走这种路线，再迎来什么时代了。

结构方法时代

这一时期最流行的方法，诸如 SADT、SA/DT、IE 等，都将功能流程逻辑与数据设计区分看待。这种做法在当时有理可循：因为那时的计算机就是那样设计的，程序逻辑和数据存储结构相互分离。这些方法应用在所有软件开发类型中，包括“数据处理”和“实时”系统（当时的普遍称谓）。这种功能 / 数据分离方式的价值自然体现在贴近现实（也就是硬件）的设计——编程与设计数据的方式各自分离。当时的系统难以发展，更难安全地改动，这成了那一代方法的“阿克琉斯之踵”。

对象方法时代

下一场范式变迁始于 80 年代早期，发源于新的编程模式——面向对象编程。变迁的导火索是一种新的编程语言，名为 Smalltalk。Smalltalk 背后的关键思想历史更久，早在 1967 年就被 Simula 语言支持。1990 年左右，对象思想的一种改进开始被广泛接受。带有良好定义的接口，可以相互连接并组建系统的组件，开始成为广泛应用的架构风格。多数现代方法背后的主导思想依旧是组件。

伴随对象和组件，全新的方法家族出现了。人们认为过去的方法和实践已然过时，遂弃之不用。很多情况下，取而代之的实践似曾相识，但有一些显著的区别和全新的术语体系，所以几乎无法追溯它们的源头。新的潮流诞生了。90 年代早期有大约 30 种面向对象的方法公布。它们有许多共同点，但因为各自的创作者都发展出了自己的术语和标志，很难判定它们之间的相似之处。

90 年代后半叶，对象管理组织（OMG，参见 omg.org）觉得是时候至少为软件的描绘方式，也就是开发中使用的标记发展一套标准了。由此创建了一个工作组来开发这一标准。最终的成果就是统一建模语言（Unified Modeling Language，UML）。它几乎消灭了除了统一流程（以统一软件工程（Rational Unified Process)，即 RUP 的方式来进行宣传）以外的所有方法。统一流程在 2000 年左右统治着软件开发世界。这又是一次重蹈覆辙，因为其他许多方法有一些有趣、有价值的实践，本可以作为统一流程实践的补充。然而，统一流程开始流行，其他一切都被认为是过时的，于是被抛弃。对，我们曾经就是这么愚蠢。

敏捷方法时代

敏捷运动，一般简称为“敏捷”，是现在软件开发领域最流行的趋势，被全世界追随。敏捷运动将重心从技术实践转移出来，让团队、工作和人员走向了前台和中心。

听起来不可思议，过去年代应用的方法并没有多关注人力要素。所有人都当然明白软件是人力开发的，但很少有著作谈及，怎样激励和授权人们开发出色的软件。最成功的方法论著作也在这一主题上沉默不语。当时人们基本上认为不管怎样，这是管理学的任务。敏捷创造了很多新的人力实践，诸如自组织团队、结对编程和每日站会。

考虑到敏捷对开发者权力的影响，很容易理解敏捷在最近的潮流中广泛流行的现状。此外，鉴于敏捷对软件开发的正面影响，无疑它值得成为最新的趋势。另外，即便一些敏捷实践被其他更好的实践所取代，敏捷作为一种哲学和态度不仅会是一时风尚。它会伴随我们直到可见的未来。

总结

虽然不同的时代贡献了各自的知识和经验，其中许多都是每个时代特有的产物，但每个时代最终都演变为少数权威主导的方法战争。

3. 逃离方法牢笼该做什么准备

我们用了很大功夫来搞明白应对软件开发方法时错在何处（见 [1] 和 [2]）。然而，一旦我们意识到了“世界上最愚蠢的事情”，很容易就能指出终结它的关键所在，就是找到一种通用的语言，使用通用的术语，简言之公共基础（common ground）。由此我们就能在探讨和应用实践与方法时使用它。于是在 2009 年，SEMAT 社区诞生，宗旨是“重建软件工程……[1] 包含一种内核，其具备广泛认同的元素，可以被扩展以适用特定需求”[3]。

我们需要找到一种公共基础

多数方法包含（或暗示）一个生命周期、一些技术实践和人力实践。这样我们就有了一些共同点。然而它们是隐藏起来的，难以发现，因为不同的权威使用不同的词汇和语言来描述它们。于是我们要找的公共基础包括一种词汇和语言体系。我们称这类词汇为内核（kernel），这种语言为内核语言。

公共基础 = 内核 + 语言 = 本质（Essence）

从内核开始

鉴于内核是用来帮助描述方法和实践的，内核应该包括一些“事项”，这些事项是所有方法中都存在或应该提及的。本质上来说，在我们开发软件的过程中，有哪些事项是我们总会涉及、总会运作、总会产出的呢？我们 SEMAT 志愿者团队（有来自于全球的约 20 名成员）在研究内核的过程中，认为这些被称作“共通内容”的事项应该满足：“无论所开发的软件规模大小，或参与开发的团队规模大小、风格如何，都会应用到这些事项”。“本质上它提供了一种独立的实践框架，用于讨论、探究我们已有和需要的实践。内核的目的在于提出对软件开发核心内容的共识。”

2010 年，作为寻找内核的努力的一部分，SEMAT 的三位创始人（Ivar Jacobson、Bertrand Meyer 和 Richard Soley）撰写了一篇愿景宣言 [4]。我们三人明白，需要凭借标准和原则才能确定内核的内容。我们首先确定了一些内核元素的选取标准（更详细的标准解释参见 [4]）。

内核元素应该是：** 通用（universal）、显著（significant）、相关（relevant）、精确定义（define precisely）、可执行（actionable）、可评估（assessable）且全面（comprehensive）** 的。相关的意思是“对所有软件工程师都可用，无关工程师背景与使用的方法论（如果有）”；全面的意思是“应用于所有内核元素；它们必须反映软件工程的本质，为软件工程团队的关键实践、模式和方法提供蓝图”。

为寻找内核，我们还定义了下列关键的基本原则（参见 [4]）：高质量（quality）、简洁（simplicity）、理论化（theory）、务实和可扩展（realism and scalability）、可解释（justification）、可证伪（falsifiability）、前瞻视角（foward-looking perspective）、模块化（modularity）和自我发展（self-improvement）。理论化的意思是“内核应该基于稳固而严格的理论基础”；务实和可扩展是说“内核应该应用于实践项目（包括大型项目），并且基于已有或可行的技术条件”；自我发展是说“内核应该具备自我进化的机制”。

此外，愿景宣言 [4] 还规范了内核应有的属性：独立于实践（practice independence）、独立于生命周期（lifecycle independence）、独立于语言（language independence）、简洁（concise）、可伸缩（scalable）、可扩展（extensible）、有正式定义（formally specified）。可伸缩的解释是内核既应该支持最小的那些项目，包括那些一人为一位客户开发系统的情况；也应该支持最大的项目，包括那些有着层层系统、层层团队和层层项目的情况。可扩展是说内核应该具备增加实践、细节，扩展范围的能力，还可以增加生命周期管理，将自身变为定义域，或者将软件开发任务集成到更大的项目中。

SEMAT 团队依据这些标准、原则和属性来寻找内核。

其次是语言

为了解释内核的共通内容及实践和方法，我们需要一种语言。单单用英文是不够精确的，所以我们需要使用一种带有句法和语义的规范语言。

这种语言必须为其目标用户所设计，这些用户是软件开发工程中的专业开发者。这种语言应该允许有能力的实践者创建和改进实践，同时无需再学一种高级语言。

这种语言应该满足四种基本用途：描述、模拟、应用和评估。引自 [4]：“阶段的概念在内核语言中相当重要，阶段代表着工作进程。”

上面提到的愿景宣言详细描述了这种语言的需求。例如，“语言应该为开发者社区设计（不仅面向流程工程师和学术需求）”，这是很重要的一项需求，目的是获得比现在使用方法的场景更直观、更紧密的用户体验。另一个需求例子是语言应该提供“验证机制，用于评估一个项目在声称自己需要应用某个已知的方法元素时……是否有必要，而不是简单的在嘴上说说。”

我们需要的不仅是内核，我们需要实践和方法

内核和内核语言的角色是基于公共基础来描述实践和方法。于是要描述大量方法，就需要一种有用的公共基础。我们需要在实践和模式的定义上取得共识。比如我们谈到：“实践是方法的一种单独考虑。例如……迭代开发、基于组件的开发”，“每种实践，除非被特别定义为持续活动，都有着明确的开始和结束”，还有“每种实践都为利益相关者带来明确的价值”。

基于这些原则、价值观和需求的组合，SEMAT 团队得以获知该怎样逃离方法牢笼。

4. 怎样逃离方法牢笼

从想法到可见的结果有漫长的距离。首先我们需要有一个公共基础。

4.1 本质，软件工程的公共基础

作为对“世界上最愚蠢的事情”的回应，Ivar Jacobson International（IJI）在 2006 年开始探索逃离方法牢笼的路线。2009 年 SEMAT 社区创立，2011 年这一任务被移交给了 OMG，后者最终提出了软件工程共同基础的一项标准，称为本质（Essence）[5]。

2014 年本质标准得到了认可。虽说本质不算是那种“来自宙斯额头的闪光”（译注：古希腊神话中，智慧与战争女神雅典娜是从主神宙斯的额头中跳出而诞生的），但也是基于愿景宣言精心设计的 [4]。

米开朗琪罗的话也给了我们启示：“每一块大理石中我都能看到一尊栩栩如生的雕塑，形态和动作完美无瑕。我只有推倒禁锢着它们的重重围墙，才能让其他人亲眼目睹我所见的美妙景象。”我们认为，我们应从大堆方法的混沌中找出本质，换言之：“我们正在从重重压迫之下解放本质。”

圣埃克苏佩里（译注：童话《小王子》作者）说过：“所谓完美，并非是没有好处可增补，而是指没有多余之处可删减。”我们在讨论内核中应包含什么、排除什么的时候，使用的方法非常保守。为内核增添元素很容易，要删去它们却要困难得多。

所谓要素化的实践或方法（Essentialized practice/method）是用本质描述的，描述的重点是要素。这不是说要改变实践或方法的意图。要素化的带来了显著的价值。我们社区可以从不同方法中收集实践来创建实践库。团队可以从很多方法中匹配和混合实践，进而获取自己需要的方法。如果你有新实践的点子，只需要精炼这个实践并提交到实践库，以供他人选择；你不需要“重新发明轮子”来发明自己的方法。这样一来实践就从一体化的方法中解放出来，进而打破了方法牢笼，让公司和团队走向开放的世界

4.2 使用本质

我们不会大谈本质背后的整个理论，而是会展示一项基于本质描述的实践以说明其用法。这里本质被用作展示实践的平台。

作为本质实践的例子，我们以用户故事作为描述的对象。这里我们称之为用户故事要素。下表 2 有 14 张卡片（无需细读），列举了该实践的关键要素。

(点击放大图像)

图2：要素化实践的案例：用户故事实践

我们这里不是要描述整个实践，而是告诉读者要素化的实践大体的特征。

随后，我们挑选出几张有代表性的卡片，稍后作简单说明。

(点击放大图像)

图 3: 从用户故事要素实践中选取的 5 张卡片

用户故事要素（概览卡片）——从以下方面概述了这一实践：

• 简要描述我们为何（收益）、何时（适用性）可能使用该实践
• 内容列表，列举实践所有元素中被命名的元素标记（每种元素由自己的卡片来描述）。

注意颜色是用来直观地区分实践的适用范围的。这里不同颜色的含义是：

• 黄色卡片——该颜色的本质代表解决方案领域的关注点，表明这一实践与我们开发的软件系统和 / 或其需求有关。
• 绿色卡片——该颜色的本质代表客户领域的关注点，表明这一实践同我们应对商务 / 客户的方式相关，例如关系到机会和利益相关方。
• 灰色卡片——这种本质代表三种领域的关注点。第三种领域以蓝色表示，关系到驱动力。用户故事要素实践没有蓝色领域的卡片。

还要注意，这个例子中用户故事要素所强调的两个关注点（解决方案与客户），是和驱动力空间（包括团队和管理工作的方式等关注点）明显区别开来的。其实际影响在于，这一实践可以同任意数量的其他管理实践同时应用。这些管理实践主要用于蓝色的驱动力空间，诸如用时间盒（timeboxed）、Scrum 风格的工作管理方法，或者是持续流形式、看板风格的方法。

客户团队（模式卡片）——为相关的元素如何建立关联，和／或元素之间如何进行交互提供指导的模式，以下列形式给出（本例子中）：

• 文字描述。概括这一模式所提供的引导内容的要点。
• 命名的联系。展示这一模式主要关联哪个或哪些元素——这个例子中关联的是用户故事元素。
• 参考链接。链接命名的参考或资源卡片——后者则引出一个或更多的指针，指向更多引导或信息的资源。资源卡片是图 2 中描述实践的 14 张卡片之一。

可以使用不同层次的细节来描述要素化的实践，即可简单也能具体。这个实践中的卡片所提供的信息不会太多，具体来说不会多到让新手级的团队也能成功应用实践。历史告诉我们：

• 再多的纸上流程也不足以让新手无需专家支持就取得成果。
• 写的东西越多，人们越不想看。
• 与其“借鉴和重写”其他人的言论，结果让支持引导文档愈加冗长，不如简洁地引用原文出处。

像这样的要素化实践遵循的原则是，新手团队需要专家教练的支持才能取得成果。这些卡片可以是专家教练使用的工具，用来帮助团队接纳、适应和评估团队实践，或者是专业团队的相同工具。

最后补充一点，使用可浏览的 HTML 图像进行电子化展示时，关联和参考链接都是可以点击浏览的，其它卡片上面的链接元素也是同理。

寻找用户故事（活动卡片）——以下列方式（这个例子中）为团队指引工作方向：

• 活动的描述。
• 指出活动要成功执行所需的权限和权限的级别。例如，卡片要求利益相关方权限为 2 级，分析权限为 1 级（它们都由本质内核定义，可以直接用可浏览的 HTML 或电子卡片的形式调用）
• 指出活动运作的空间。例如，“它能帮助我们做什么事情”（通用内核“活动空间”，这里又称“理解需求”）
• 指出活动到达最终状态时表现的目的。这个例子中会定义一个用户故事，用一张故事卡片来展示与用户故事关联的价值。

注意活动是很重要的，因为没有活动就没有成果。值得一提的是那么多传统方法给读者灌输大堆理论，却并没有真正满足他们的需要，并没有明确建议他们到底应该做什么！

用户故事（阿尔法）是我们应对的一个关键。我们需要改进它，其改进成果也是项目的一个重要的进程指示。阿尔法可以被看作是我们希望在看板上流动的内容，以如下方式描述：

• 自身的内容和用途的概述
• 内容进展的一系列状态，这里分别是定义、开发就绪、完成。（可以看作是看板的候选栏，当然团队也可以根据自身的工作实践加入其它的中间状态）。
• “父”（内核）阿尔法，所有的用户故事都关联到父层级（这里指的是需求）。

故事卡片（工作产品卡片）给出的建议涉及实际的物品，我们应该产出这些物品以使要素信息浮出水面。这里用户故事方法的一个关键定义（常被遗忘）属性是，我们用一些非常有局限的“设备”（目录卡或电子设备）来打造收集关键信息的机制，从而判断我们应该在软件系统中添加哪些内容。工作产品卡片这里以如下方式定义：

• 概述
• 我们以哪些层级逐渐解释细节。这个例子中我们开始会确保我们已经获取并关联了相关的价值，然后我们继续下去，到某些层面上列出接受度的标准。细节的第三层级概述告诉我们是否获取关联的会话，例如在分散的团队中使用一套电子工具进行会话。
• 工作产品描述的阿尔法，这里也就是用户故事。

组合在一起

现在我们已经解释过了用户故事要素实践中的一些代表性卡片类型，其它卡片就不再赘述，因为道理是类似的（这也是使用简单、标准化的语言来表述实践指引的好处之一）。

现在我们知道了这些卡片的含义，我们还要在更高层面上理解整个实践的运作方式。这些卡片给我们提供了所需的一切线索，从而理解元素之间如何适配以呈现端到端的故事，也就是哪些活动产出哪些元素。不过这里有必要做一次总览，以不同行动的端到端流程进行说明。

(点击放大图像)

图 4: 展示活动之间端到端流程的状态进程矩阵

• 首先我们需要找到用户故事。这会在初始的定义状态中引入一个或多个用户故事，每一个故事用一张故事卡片记录，卡片上的信息刚好足以确保用户故事的价值得到表达。
• 基于故事到故事的原则，我们找出下一步要完成的用户故事，使用准备用户故事的活动来处理它，使之为开发做好准备。这一步还包括在故事卡片上列出权限标准，同时我们可能还要获取一些支持会话。这一行动中我们还要详尽说明关联的测试样例。
• 最后一步行动关系到我们怎样去接受用户故事。完成这一步后用户故事就会实现完成状态。

注意这一行动“链条”，也就是行动进展的状态，并不会约束整个流程。比如说，它并不意味着一条单向、顺序固定的流程。换言之，我们可以为不同的用户故事以不同的方式迭代不同的活动。应用其它实践时的方式可能是受约束的。例如，如果我们使用用户故事实践与 Scrum 相结合（流行的做法），我们可以在团队层面就以下规则达成共识：

• 开始第一个迭代之前寻找用户故事，但也可以基于临时的起点做这件事。
• 准备用户故事的活动要在第一个迭代之前实施，之后在每一个迭代中为用户故事做好下一个迭代的准备，以在迭代计划会议上使用。
• 一旦一个用户故事完成就接受它，这样在迭代回顾之前就完成这一迭代的所有用户故事。

在这一案例中，要素化实践的关键属性和优势体现在：

• 实践的范围被很好地限定了。它告诉我们怎样做好事情，却不会约束或限制我们的其它选项，我们可以在其它领域使用不同的实践（Scrum、看板等等）。
• 实践的描述非常简洁。上文很少提到这一点，但描述实践的卡片全部加起来只有大约一张 A4 纸的内容。
• 实践易获取、可互动。卡片可以用各种形式应用，包括以团队注释的形式实现立即可视化的工作，并自我评估本地实践和需优先改进的领域。
• 实践以简单、标准化的方式进行表达。只要理解了用户要素的 4 张卡片，其它来源的任何本质实践都很容易理解了。你并不会因为喜欢用户故事实践就困在这个方法牢笼里。你可以自由地徜徉在开放的市场上，挑选其它来源的任何实践。
• 实践“插入”本质标准内核，这样能确保它们与其它要素化的实践以完善的定义进行协作。
• 这一事实使任何实践的任何层面都可以立刻得到评估（我们的实践将活动加入本质内核的活动空间“理解需求”和“测试系统”，但不会加到其它 13 个本质内核的活动空间“集成系统”“部署系统”……中去）。所以如果这是我们应用的唯一实践，显然我们没有权限或定义的路径来做其它事情（这可能不是个问题，但的确是可见的事实）。
• 它包含所有的要素。你可能没在和其它很多东西打交道，但如果你不以这种方式处理这堆事务（或者在本地处理类似的事情，或者可能没有基于清楚明白、经过衡量的原因处理特定部分），那么你能有理由声称自己正在处理“用户故事”吗？
• 总体的规则和原则总结在此：

本质分为两种元素，一种是关于健康度和进程的元素，另一种是关于文档的元素。前者被称为阿尔法（Alpha），后者被称为工作产品（Work Product）。每个阿尔法都有一个生命周期，其中有一些阿尔法状态。工作产品是用来描述阿尔法的可见事物，用来印证阿尔法状态；工作产品是实践者在进行软件工程活动，诸如需求定义、设计模型、编程等事务时产出的内容。活动（Activity）是实现任何目标所需的事项，包括处理阿尔法、产出或升级工作产品。活动空间（Activity Space）管理活动。进行活动需要特定的授权（Competency）。模式是解决典型问题的解决方案。模式的一个例子是一个角色，也就是指出工作责任这一问题的解决方案。

用来单纯定义通用标准“公共基础“的本质，不会定义工作产品、活动或模式。因为它们都是与实践结合的。这种本质定义了 7 种包含状态的阿尔法，15 种活动空间和 6 种授权，它们都是实践无关的。
基于本质定义的实践引入了新的元素或标准内核元素类型的子集。

4.3 映射

4.2 部分我们展示了用户故事实践的要素化，但没有预先展示本质内核和语言。我们以“本质隐身模式”展示了实践，这种说法改编自 Paul McMahon。然而，要素化实践背后我们严重依赖本质。之前的例子中用户故事是需求这一内核阿尔法的子阿尔法。“寻找用户故事”活动分配在“理解需求”这一活动空间内，“准备用户故事”也是如此。“接受用户故事”则属于“测试系统”活动空间。

我们想要说明，就算没有冗长、对多数人来说令人生厌的本质介绍，我们也能很容易地理解实践。有很多文献和著作已经做了这件事情，参见 [6]-[10]。这样这里我们只要提及一些要点来帮助你理解即可。

当 SEMAT 志愿者设计本质以回应“怎样”逃离方法牢笼的话题时，我们尤其关注“条文的简化”，也就是说“内核应该只包含核心概念”。团队认为方法或实践的指引应该把重点放在要素上。

• 从经验来看，开发者很少有时间或兴趣阅读方法或实践的详细解释。学习要素使团队早在他们了解项目的一切内容之前就开始工作。
• 要素被定义为一种预览规则，代表专家拥有的所有项目的大约 5%。
• 一些团队和组织需要要素以外的更多内容，所以应该有不同级别的细节可选。

SEMAT 团队也清楚我们应该为传授实践的过程创造全新的用户体验。现在的方式是现实工作中几无帮助的书本和网页：书本只有死板的描述，没有动态的指导。我们找到一条与工作更紧密结合的方式，用游戏的形式激励现代的工作。如你所见，我们使用的是卡片。

我们还坚持“关注点的独立性”原则，应用在很多内容中。实践是独立的关注点，这些关注点可以通过合并操作组成各种方法。对于本质来说就是“合成”。内核也是一个独立的、更抽象的关注点，基于可以合成的实践，也是合并过的。

总之，本质使我们逃离了方法牢笼，因为它为所有方法的共同点设置了通行的描述，为谈论这一公共基础和所有实践设计了一套标准语言。这意味着我们可以自由地从我们选择的来源挑选要素化的实践，来源既可以是自己的组织内部也可以是外部。我们还可以自由将不同的实践混合、匹配，从而集众家之所长，而不必被局限在任何方法上。

5. 逃出方法牢笼

现在有很多公司都在要素化已有的方法。例如，塔塔咨询服务（TCS）提到：“TCS 与业界的所有核心伙伴，如 SAP、Oracle、微软等公司及 TCS 的客户紧密合作，并同这些公司的核心方法论团队协作，推动对要素标准的共同应用，并将这一理论标准变为实用标准。”

这些公司从一个实践库中获取可复用的实践。团队和组织可以从不同方法中混合和匹配实践，并找出适合自己的工作方式。如今，我们有基于要素描述的大约一百项实践。IJI 发展了 50 种实践，并公开了其中 25 种，贡献到一个实践库中。

这些公司正在逃离他们的方法牢笼。他们不再依赖权威，不再走之字形路径，而是走上了可持续的发展道路。对他们而言方法战争已经结束了。然而，他们所期待的不仅是逃离方法牢笼，而是有更大的愿景。他们正走在产业级别的敏捷道路上，将软件开发从一门技艺转变为工程规范，但依旧在软件开发和与其它方法协同方面保持敏捷。

要实现成功，我们仍然要依赖授权团队的成员，但这一过程会得到一套共享、规范的工程实践的支持。这些实践可以用不同的排列组合方式，在不同的技术领域和项目类型中复用。这使我们在所有项目中保持高水平的技艺，并以此应对未来无穷的挑战。

我们还需要组织的支持，组织要有开放的学习文化，能接受新的想法、用于试验。继续讨论就不在本文范围之内了，但可以参考一些文献（[8]-[10]）。

要素在学术世界也进展颇丰。全球的许多高校都在不同程度上教授要素。这里引述教授的言论“斯堪的纳维亚的最大技术院校之一，挪威科技大学在 2017 年春成功地向软件工程课程的 460 名学生教授了要素……要素使学生掌控他们的项目、工作方法和实践。我们终于超越了 Scrum 和看板……数据和成果说服了我，所以我以后的软件工程教学将由要素驱动。”

或许这一向要素迁移的运动对这些公司和学校来说是“世界上最明智的举动”。

附注

1. Hastie S., Linders B., McIntosh S., Ferreira R.M., Smith C. “ Opinion: What 2017 Has in Store for Culture & Methods ”.
2. Jacobson I., Meyer B. Methods need theory. Dr. Dobb’s Journal, 2009.
3. Jacobson I, Spence I. 2009. Why we need a theory for software engineering. Dr. Dobb’s Journal, 2009.
4. Jacobson I., Meyer B., Soley R. 2009. Call for Action: The Semat Initiative. Dr. Dobb’s Journal, 2009.
5. Ivar Jacobson, Bertrand Meyer, Richard Soley. “Software Engineering Method and Theory – a Vision Statement”, Feb 2010.
6. Object Management Group, “ Essence - Kernel And Language For Software Engineering Methods )”, November 2014.
7. Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence and Svante Lidman, “The Essence of Software Engineering: The SEMAT Kernel,” Communications of the ACM, Volume 55, Issue 12, December 2012.
8. Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence and Svante Lidman, 《软件工程的本质：运用 SEMAT 内核》, Addison-Wesley, 2013
9. Ivar Jacobson, Ian Spence and Pan-Wei Ng. “Agile and SEMAT: Perfect Partners”, Communications of the ACM, Volume 11, Issue 9, Oct. 2013
10. Ivar Jacobson and Ed Seidewitz, “A New Software Engineering,” Communications of the ACM, Volume 57, Issue 12, Pages 49-54. December 2014.
11. Ivar Jacobson , Ian Spence , Ed Seidewitz . “ Industrial-scale agile: from craft to engineering ”, Communications of the ACM: Volume 59 Issue 12, December 2016.

关于作者

Ivar Jacobson博士是软件工程之父，他的贡献包括组件架构、用例、UML 和 RUP。2005 年开始他致力于以灵巧、轻量、敏捷的方式来应对方法和工具，由此创造了本质标准内核和语言。他是 7 本影响重大的畅销书的主要作者。

Roly Stimson是经验丰富的 IT 顾问，从业 30 年来致力于应用软件方法来应对复杂的开发挑战。过去 15 年间他涉及了迭代、递增和敏捷方法。他参与了 IJI 基于内核的 EssUP 实践的开发、参与建立了 SEMAT 的本质标准，还参与开发了 IJI 的基于本质的要素和大规模敏捷实践。

查看英文原文： Escaping Method Prison

感谢张卫滨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。