逃离方法牢笼

关键点

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

背景

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

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

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

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

1. 什么是方法牢笼

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

(点击放大图像)

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

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

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

(点击放大图像)

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

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

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

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

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

• 实践的范围被很好地限定了。它告诉我们怎样做好事情，却不会约束或限制我们的其它选项，我们可以在其它领域使用不同的实践（Scrum、看板等等）。
• 实践的描述非常简洁。上文很少提到这一点，但描述实践的卡片全部加起来只有大约一张A4纸的内容。
• 实践易获取、可互动。卡片可以用各种形式应用，包括以团队注释的形式实现立即可视化的工作，并自我评估本地实践和需优先改进的领域。
• 实践“插入”本质标准内核，这样能确保它们与其它要素化的实践以完善的定义进行协作。
• 这一事实使任何实践的任何层面都可以立刻得到评估（我们的实践将活动加入本质内核的活动空间“理解需求”和“测试系统”，但不会加到其它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种，贡献到一个实践库中。

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

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

要素在学术世界也进展颇丰。全球的许多高校都在不同程度上教授要素。这里引述教授的言论“斯堪的纳维亚的最大技术院校之一，挪威科技大学在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.

查看英文原文：Escaping Method Prison\

\

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