逃离方法牢笼

关键点

• 解释什么是方法牢笼，解释它的副作用，包括权威、方法战争和之字形路径的概念，以及为什么它是“世界上最愚蠢的事情”。
• 采用本质（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）。

(点击放大图像)

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

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

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

(点击放大图像)

图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 u0026amp; 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.

关于作者

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

查看英文原文：Escaping Method Prison\

---

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

\

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

来源：糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖