关于需求分析:万字长文用户故事拆分终极指南-IDCF

本指南内容

一、为什么故事拆分很重要
二、什么样的用户故事才算是失当的故事？
2.1 用户故事格局
2.2 失当的故事应遵循 INVEST 准则
2.3 用户故事是垂直切片
三、故事拆分流程图
步骤 1：筹备好要拆分的故事 / 个性
步骤 2：套用拆分模式
3.3 步骤 3：评估拆分成果
四、Cynefin 和故事拆分
五、练习故事拆分
六、垂直切片和规模化
6.1 是否应该让 100+ 的人去开发一个产品？
6.2 规模化垂直切片的基线

一、为什么故事拆分很重要

从优先级最高的、工作量较小的用户故事开始开发，能够让产品团队继续输入高价值的产物，并取得高质量的反馈。许多团队都在致力将较大的用户故事和个性（feature）拆分成失当的小故事，然而他们没有从业务的垂直切片来拆分，而是从整个技术架构的的角度，拆分出了很多看起来更像研发工作（Task）或组件（Component）的故事，最终导致他们未能体验到小故事应有的价值或反馈。

侥幸的是，故事拆分是一种能够在较短的工夫内学会的技能。咱们曾经看到，团队仅需几个小时的练习和一些简略的工具，就能够从挣扎中解脱进去，疾速地拆分故事。稍后，咱们将介绍如何组织这种练习。

二、什么样的用户故事才算是失当的故事？

在探讨拆分用户故事之前，咱们须要确保咱们对什么样的用户故事才算是失当的故事、以及能够将哪些内容拆分为故事有一个独特的了解。

首先，让咱们看下用户故事的定义：用户故事是从用户的角度形容零碎行为的变动。它形容的是用户想通过零碎做的事件，或者心愿零碎为他们做的事件，而这些事件当初的零碎里还没有。

顺便说一下，请留神，用户故事位于计划域（solution space）而不是问题域（problem space）。它不是一个人想在某个中央实现一个工作的形容（就像 JTBD[Job to be Done，待实现的工作]一样），而是一个人想要在你的零碎中实现某件事情的形容。JTBD 在问题域中能够与客户产生很好的共鸣，而用户故事能够很好地将客户的共鸣转化为对软件系统的一系列扭转，同时在整个交付过程中放弃客户的视角。

2.1 用户故事格局

你可能常常会看到以如下特定格局书写的用户故事：

• 作为角色
• 我想要性能或口头
• 以实现价值或指标

或者有的是这样：

• 为了价值或指标
• 作为角色
• 我想要性能或口头

该模板的长处在于它要求你答复用户故事中的三个问题：

• 它是给谁（WHO）应用的？
• 他们想要做什么（WHAT），或者让零碎做什么，而这些性能当初都还没有？
• 他们为什么（WHY）要这样做？

不过，重要的不是模板，而是答复这三个问题。

实际上，咱们很少会用残缺的模板来写故事。无论是在便签纸的顶部还是在在线项目管理工具的题目字段里，一个写着“WHAT”的简短题目都会是比拟好的抉择。“WHAT”由题目提供，而“WHO”通常由产品愿景或版本指标提供，它形容了外围指标客户。如果故事是为该指标客户筹备的，咱们就不反复撰写了，咱们只有在为非核心指标客户撰写用户故事时，才把“WHO”加上。最初，咱们将确保在在线工具的“详细描述”或相似的字段中，或者在便签纸上用较浅的字体写明“WHY”。

因而，如果咱们要做一个公共图书馆的网站，并且图书馆的读者是咱们的默认用户，则咱们不会这样来书写用户故事：

• 作为图书馆的读者，
• 我想按书名搜寻一本书，
• 以便我能在搜寻后果中毫无烦扰地找到我想要的书。

咱们会这样来写：

• 按书名准确查找
• 因为我晓得我想要的具体书籍，所以我不心愿在搜寻后果中呈现烦扰

有时咱们会遇到将独自的研发工作或架构组件伪装成用户故事的状况。即便你应用了诸如“作为开发人员，我想要一份数据库关系图，以便我能理解数据库的构造”这样的神奇形容，它依然只是一个开发工作。

2.2 失当的故事应遵循 INVEST 准则

几年前，极限编程先驱 Bill Wake 提出了一个很好的首字母缩略词，用来示意一个失当的用户故事应具备的 6 个要害属性：INVEST。让咱们来挨个看一下：

• I 代表 INDEPENDENT（独立的）。这意味着一个失当的故事可能足够的独立，它能够不必思考技术依赖就能够排定优先级。有时，这意味着须要临时提供一些 Mock 数据或接口，以便能够独立测试故事，让你在我的项目的晚期就能更快地取得价值或升高危险。
• N 代表 NEGOTIABLE（可协商的）。一个失当的故事会为做什么、如何做等细节留下协商的空间。当然，随着协商的进行、更多细节的敲定，故事的可协商性就会升高。
• V 代表 VALUABLE（有价值的）。每个故事都应该为用户减少一些可见的价值增量。现阶段这仿佛是不可能的，因为你的 Product Backlog 里可能有大量的技术组件和基础架构的工作，这些技术工作伪装成了用户故事，但这并不能间接为用户减少价值。随着你故事拆分技能的一直成长，你能更好地找到能间接提供价值的、短小的性能切片。

（故事并不需要独自提供足够的价值来间接公布。你可能须要积攒多个故事，能力从有价值转变为可销售。我喜爱最小可销售个性（MMF，Minimum Marketable Features）作为故事的容器。）

• E 代表 ESTIMABLE（可估算的）。一个失当的故事应该定义到足以让团队可能估算它的工作量，这个工作量个别是绝对于一个基准故事所做的绝对估算。
• S 代表 SMALL（短小的）。教训通知咱们，对于一个已排序的 Product Backlog，你应该可能将优先级最高的 6 到 10 个故事排入下一个 Sprint 中。这样做既能常常取得反馈和治理危险，同时也不须要治理太多的故事。不过这个故事数量只是一个倡议，它会随着 Sprint 长度、团队规模、团队速率等因素按比例缩放。
• T 代表 TESTABLE（可测试的）。咱们应该有方法晓得咱们曾经实现了某个故事。它不能只是一个含糊的冀望，而须要是零碎行为的具体变动。

当然，这些属性之间存在着肯定的互斥关系。比如说，随着故事的规模变小，使其变得独立且有价值的难度就会变大；随着故事的可协商性变大，其可估算和可测试的难度就会变大。

不过侥幸的是，不同的属性在不同的工夫起次要作用。例如在进入 Sprint 打算后，更重要的是故事要短小、可估算和可测试。这时咱们依然须要故事有肯定的独立性、可协商性和有价值，但这些属性这时曾经变得不那么重要了。而在 Product Backlog 中的故事，状况恰恰相反。

2.3 用户故事是垂直切片

在提到失当的故事时，你常常会听到垂直切片（vertical slice）这个词。这是失当的故事在软件架构方面的要求。

• 垂直切片是指“一个能给零碎行为带来变动的有价值的工作项，它可能要涉及多个架构层级（architectural layers）来实现这个变动”。当你把这个切片（slice）称为“实现”时，该零碎对于用户而言显然更有价值。
• 程度切片（horizontal slice）与垂直切片刚好相同，它是指“对一个组件（component）或架构层级（architectural layer）进行更改的工作项，它须要联合其余组件或架构层级的扭转，能力对用户交付可感知的价值”。

咱们来看一个非常简单的零碎架构，这里有 UI 层、业务逻辑层和长久层。你的零碎可能比这更简单，但它可能至多蕴含这三层。

（零碎架构示意图）

要想取得 INVEST 的大部分属性，故事必然会波及这 3 个架构层级。如果不进行某些 UI 的扭转、逻辑的扭转、长久存储的扭转，咱们可能就无奈交付价值。因而，故事就是零碎的一个垂直切片。

有时候，这些垂直切片十分宽。当咱们进行故事拆分时，咱们将探讨如何在较宽的垂直切片中找到较薄的垂直切片。然而到目前为止，咱们只须要晓得故事应该在必要时逾越架构层级来提供价值就足够了。

许多刚组建的麻利团队会尝试依照架构层级来拆分故事：一个故事用来实现 UI，另一个故事用于更新数据库等等。尽管这个故事可能也很小，但在独立性和价值交付上是失败的。当团队以垂直切片的形式拆分时，他们将会失去如下收益：

• 使 Backlog 的价值明确
• 进行更多对于价值的对话
• 有助于防止意外地建设低价值的变更
• 更快取得价值
• 更早取得更高质量的反馈
• 更容易看到束缚和待办，并能做出相应的响应
• 交付价值时变得更加可预测（因为可工作的软件是进度的首要度量规范）

咱们还能够持续说上来，但这些应该曾经能够给你一些启发了。当咱们一起坐下来，写下咱们在胜利的麻利团队中看到的各种习惯，以及各个习惯之间的关系时，咱们发现垂直切片简直与所有其余习惯无关，或至多与局部习惯无关。

看看 Product Backlog 中的故事，有些是你最近实现的，有些是未来要做的。依据 INVEST 规范评估每一个故事，找出垂直切片和非垂直切片的故事。而后，看看你是否能够改良这些故事。

三、故事拆分流程图

为了不便咱们更好地领导团队，Richard 创立了一个故事拆分流程图，该流程图介绍了咱们在帮忙团队拆分故事时要问的问题。

（用户故事拆分流程缩略图）

让咱们别离看一下图中的三个步骤：

步骤 1：筹备好要拆分的故事 / 个性

（筹备待拆分的故事）

首先要确保你要拆分的故事 / 个性满足 INVEST 规范（短小的（Small）除外）。大多数状况下，有价值的（Valuable）是问题所在。当人们把他们认为是“不可拆分”的故事带给咱们时，它们其实是伪装成故事的开发工作或架构组件。如果你不从减少价值的角度动手，就无奈将其拆分并取得价值增量。在这种状况下，下一步就是将非故事（non-story）与其余程度切片联合起来，这样，它们才能够独特代表一个价值增量。接下来，是不是切片太大了？如果是的话，就能够开始拆分了。

步骤 2：套用拆分模式

（套用拆分模式）

模式 1：按工作流程步骤拆分

（按工作流程步骤拆分）

这是我的客户在创立一个内容管理系统的故事：

作为内容管理员，我能够将新闻公布到公司网站。

听起来故事并不大——直到咱们深入研究了发布新闻的工作流程。后果发现，仅仅是把一个几句话的新闻公布到公司网站上，就须要编辑和法律部门的批准，以及在预公布网站上做公布前的最终审核。像这样的 6 -10 个故事不可能在一次迭代中实现。

在这样的工作流程中，最大的价值往往来自于结尾和结尾。两头的步骤会减少增量价值，但并不独立。所以先构建简略的端到端案例，而后再增加两头步骤和非凡案例，成果会很好。

新的故事包含：

• …我能够间接将新闻公布到公司网站上。
• …我能够在发布新闻前做一下编辑审核。
• …我能够在发布新闻前做一下法律审核。
• …我能够在预公布网站上查看新闻。

…我能够将一篇新闻报道从预公布网站公布到正式网站。

但有时，整个工作流程都很重要，你不能只从结尾和结尾开始。在这些状况下，寻找一个贯通整个工作流的薄薄的切片。兴许它反对最常见的状况；兴许你能够硬编码或以其余形式简化工作流中最容易了解的局部，而后你能力摸索更简单的局部。

无论哪种形式，最显著的拆分——从头到尾按功能模块一步一步执行——都是谬误的形式。查看我的 80/20 产品所有权课程的这段摘录，理解更多对于为什么这种拆分是谬误的，以及如何应用其余两种办法。

模式 2：按不同的业务规定拆分

（按不同的业务规定拆分）

这个故事中暗藏着一些同样简单的故事，这些故事应用不同的业务规定来实现同一件事：

作为一个用户，我能够应用灵便的日期规定搜寻航班。

深入研究“灵便的日期规定”，会发现有好几种不同的业务规定，每个规定都能够独自成为一个失当的故事：

• “日期 X 和日期 Y 之间的 N 天”。
• “12 月的某个周末”。
• “日期 Z 的前后 N 天”。

模式 3：按次要工作拆分

（按次要工作拆分）

有时，一个故事能够拆分为几个局部，其中大部分的精力会去实现第一个局部。例如这个信用卡领取的故事：

作为用户，我能够用 VISA、MasterCard、Diners Club 或 American Express 领取机票费用。

这个故事能够再拆分为四个故事，每种信用卡一个故事。然而，在解决第一个故事的时候就要建设起信用卡交易的基础架构；减少更多的信用卡类型时这方面的工作就会绝对较小了。咱们能够估算第一个故事的规模大于其余三个故事，然而如果产品负责人起初扭转了优先级，咱们就必须记得要扭转咱们的估算。相同，咱们能够如下述所示，推延决定哪种卡的类型先被实现：

• …我能够应用一种信用卡类型（VISA，MC，DC，AMEX）付款。
• …我能够应用所有四种信用卡类型（VISA，MC，DC，AMEX）付款（前提是曾经施行了一种信用卡类型）。

这两个新的故事依然不是独立的，但依赖性会比为每一种信用卡类型编写一个故事要清晰得多。

模式 4：按简略 / 简单拆分

（按简略 / 简单拆分）

当你在打算会上探讨一个故事时，故事仿佛越来越大（”X 怎么办？”、” 你思考过 Y 吗？”），这时候你应该停下来，询问下大家：“最简略的版本是什么？”把这个简略的版本写成用户故事。你可能必须在现场定义一些验收规范以放弃简略。而后，把所有的变动和复杂性拆分成其它的故事。比方这个故事：

作为用户，我能够搜寻两个目的地之间的航班。

通过像上面的形式拆分变动来放弃简略：

• … 指定最大直达次数。
• … 包含左近的机场。
• … 应用灵便的日期筛选规定。
• … 等等。

模式 5：按不同类型的数据拆分

（按不同类型的数据拆分）

故事中的复杂性可能来自于解决数据的变动。例如，我以后正在开发的零碎须要对运输服务提供商所服务的天文区域进行建模。仅仅是解决简单的服务区域的地理学常识，咱们就可能烧掉整个我的项目的估算。当我讲完这个故事后：

作为用户，我能够依据行程的始发地和目的地来搜寻运输服务提供商。

与产品负责人探讨后发现，尽管咱们不须要成熟的 GIS，但对地理环境进行建模依然非常复杂。咱们停下来反思：“什么是‘足够好’的天文建模计划，以便咱们当初就能够构建其余高价值的性能？”咱们抉择了：

作为用户，我能够按行程的始发地（市）和目的地（市）搜寻运输服务提供商。

这在一段时间内是没问题的，直到咱们收集了更多的数据，发现有些服务提供商只服务于某些县城甚至乡镇。于是一个新的故事呈现了：

作为用户，我能够按行程的始发地（如市、县、乡 / 镇、街道）和目的地（如市、县、乡 / 镇、街道）搜寻运输服务提供商。

在查看新的服务提供商数据时，咱们还发现，有些服务提供商会反对出发地为繁多城市，但起点为周边任意多个城市的行程。这就引出了上面这个故事：

服务提供商能够为行程的始发地和目的地提供不同的天文区域。

这三个故事都是从原来的天文故事中拆分进去的。这里的区别是，咱们在构建最简略的版本后，及时增加了新的故事。但有些状况下，你在项目前期就能晓得数据的变动。典型的例子是零碎的本地化：

作为内容管理员，我能够用以下语言创立新闻：
英语
日语
阿拉伯语
等等……

模式 6：按不同界面拆分

（按不同界面拆分）

有时，故事的复杂性在于用户界面而非性能。在这种状况下，故事的拆分要从最简略的 UI 开始，而后再构建更易用或更富丽的 UI。当然，这些并不是独立的——如果你先做第二个故事的话，第二个故事实际上就是初始故事——但它依然能够是一种有用的故事拆分形式。

作为用户，我能够搜寻两个目的地之间的航班。

… 应用简略的日期输出。

… 带有精美的日历界面。

模式 7：提早性能优化

（提早性能优化）

有时，一个故事的根底性能实现可能并不难，然而须要花很多工夫在性能的优化上。如果你能够从较差性能的根底性能中学到很多常识，并且它对用户有肯定的价值（比方没有这个性能用户就无奈实现故事中的动作），在这种状况下，你能够把故事拆分为“使其能用”和“使其好用”：

作为用户，我能够搜寻两个目的地之间的航班。

…（只有性能实现就好，加载时显示一个“搜寻中……”的动画。）

…（加载工夫限度在 5 秒以内）。

模式 8：按不同的业务规定拆分

（按不同的业务规定拆分）

用户故事中的“治理”会涵盖故事的多个操作。这就为故事的拆分提供了一种天然的形式。比如说：

作为用户，我能够治理我的帐户。

… 我能够注册一个账户。

… 我能够编辑我的账户设置。

… 我能够登记我的账户。

模式 9：拆分出一个探针

（拆分出一个探针）

一个故事之所以被大家认为工作量很大，可能并不是因为它的业务有多简单，也有可能是因为开发团队对其技术实现不太理解。在这种状况下，无论你怎么廓清故事的业务局部，都无奈将其拆分。先拆分一个有工夫盒限度的探针故事，以便解决开发过程中的不确定性，而后咱们能够决定是间接实现，还是应用上述的 8 种模式来拆分它。如果咱们不晓得上面的故事如何实现：

作为用户，我能够用信用卡付款。

那么，就把它分解成：

• 调研信用卡付款。
• 施行信用卡付款。

在“调研”故事中，验收规范应该是你须要答复的问题。调研要点到为止，能答复问题即可，做调研很容易走火入魔。

探针拆分模式放在最初解说，是因为它应该是你最初的抉择。你目前已知的常识可能曾经能够用来构建一些性能了，依照你已知的常识间接开始开发吧，随着我的项目的推动，这些问题很有可能会不攻自破。因而，在求助于探针模式之前，请尽所有致力应用后面八个模式之一。

元模式：找出复杂性并缩小变动

在咱们领导团队更无效地拆分故事的过程中，咱们发现了这些模式共有的元模式：关注复杂性，并通过它缩小变动。应用元模式的办法如下：

• 找出外围复杂性。最有可能让你感到诧异或者呈现问题的局部是什么？这个问题的答案往往取决于人们的集体爱好或行为习惯。有时，这是一个须要从新整合或有内部依赖的局部。
• 辨认出其中的变动。变动比拟多的货色是什么？业务规定、用户类型、接口、数据变动、实体等。
• 把所有的变动缩小到一个。在简单的局部中找到一个繁多的、残缺的切片。它可能是一个独自的场景，也可能是通过单个业务规定变动出的一系列场景。

大多数故事拆分模式只是确定变动的起源并将其缩小到一个的例子。

这种办法对于一个新事物的第一个切片特地好用，因为它直奔外围复杂性，并防止了任何可能会让工作变得更大的内容。

步骤 3：评估拆分成果

（评估拆分成果）

你可能会发现，有时你能够应用好几种模式来拆分同一个故事。那咱们应该抉择哪种拆分形式呢？我个别通过以下两个教训法令来判断：

抉择能让你升高优先级或扔掉一个故事的拆分形式。80/20 法令表明，用户故事的大部分价值来自于一小部分性能。当一种拆分形式揭示了低价值的性能，而另一种拆分形式没有揭示，这阐明后一个拆分形式在每个小故事外面都暗藏着节约。抉择能让你扔掉低价值性能的拆分形式。

抉择能让你失去更多等同大小的小故事的拆分形式。把一个 8 点的故事变成四个 2 点的故事的拆分形式比产生一个 5 点和一个 3 点的拆分形式更有用，因为它能让产品负责人有更多的自在来别离对这些拆分后的故事进行优先级排序。

可能须要屡次尝试能力找到最适宜你的故事拆分模式——你可能须要一直地试验能力找到正确的模式。

四、Cynefin 和故事拆分

（Cynefin）

Dave Snowden 的 Cynefin 模型是一种依据问题的复杂程度来思考问题最优策略的有用办法。咱们发现 Cynefin 十分有用，简直所有的工作坊都应用了它，有的是作为先决条件，有的是作为工作坊自身。如果你还不相熟这个模型，请查看咱们的概述。

Cynefin 每个畛域的故事拆分看起来都不一样。上面是具体拆分办法：

• 简略（Simple）– 只需构建即可。如果故事太大，找出所有的故事，先做最有价值的即可。
• 繁冗（Complicated）– 找出所有的故事，并首先做最有价值和 / 或最具危险的故事。
• 简单（Complex）– 不要试图找出所有的故事。找出一两个能提供一些价值的，并能教给你一些对于问题和解决方案的常识，构建这些故事，而后利用你所学到的常识去寻找其余的故事。
• 凌乱（Chaotic）– 先把手头紧急的事件解决吧，当初拆分故事可能并不重要。
• 失序（Disordered）– 拆分之前先弄清楚你在哪个畛域，免得采取谬误的办法。

最重要的细微差别在简单域（complex domain），从这里开始工作会让你疾速理解工作的内容。在这种状况下，试图找到形成原始大故事的所有小故事是没有意义的。找到一两个能够立刻开始学习的故事会更有效率。

有些人不喜爱这种办法，他心愿把所有的故事都列举进去，并确定大小，以便可能把故事记录到 Backlog 并估算工夫。但如果你真的是处于简单域（complex domain），这样做只会给你带来可预测性的错觉——理论的故事很可能会随着工作的推动而发生变化。最好对简单工作中固有的不确定性放弃通明。

五、练习故事拆分

就像咱们之前说过的那样，在较薄的垂直切片中工作是麻利软件开发的要害习惯。很多人都在致力寻找垂直切片，但其实这是一项非常容易习得的技能。团队只需 2.5- 3 个小时的练习，就能够从苦苦挣扎到疾速地辨认出其畛域中的个性和大故事的切片。当然，练习的品质很重要。上面是我举荐的做法：

• 在 1 - 2 周的工夫内安顿两到三次 1 小时的练习课程。邀请整个团队或至多能很好地联合业务和技术观点的组合。
• 为了筹备第一次练习，看看你最近几个月的 Backlog。抉择几个你曾难以拆分但当初曾经胜利实现的故事或个性。
• 用 Cynefin 的术语来说，这些已实现的个性当初是有序的（繁冗的或简略的），因为呈现了足够的秩序来实现它们。将来的工作很可能是简单和无序的。但当初这并不重要。在第一个练习环节中，你的指标是辨认出在你的畛域中使个性变大的起因。追溯已实现的工作是练习有效性的要害。
• 在第一个练习环节中，拿着你抉择的一个个性或故事，对照故事拆分流程图中的问题一起过一遍。假如这个个性尚未实现，也能够检测下你本人当初对它有多理解。
• 如果你应用其中一种模式找到了一个好的拆分形式，请不要停下来。持续浏览其余模式，并尝试找到另一种可能的拆分形式。
• 如果一次拆分不能产生足够小的故事，请尝试对拆分后的故事持续拆分。
• 大概 50 分钟后停下来。对于你筹备的个性或故事，应用流程图上的每种拆分模式后，请查看下各模式下拆分后的小故事。
• 如果你在这个环节没有找到适合的拆分形式，花点工夫让大家一起来头脑风暴一下。当这些拆分模式利用到你的个性或故事时，大家是否曾经达成了共识。
• 如果在第一次练习完结时，拆分已实现的个性仿佛很容易，那么你就能够尝试对后续的工作进行拆分了。如果不是，须要再反复下第一次的练习。在下次练习之前，找几个适合的个性，反复上述过程。
• 这样做的难点在于，它是一个“练习”。很多人只违心通过正式培训或在工作中边干边学来晋升能力，他们往往不违心花工夫用来做一些练习，尤其是练习拆分曾经实现的个性，因为这个流动不会有新的工作产出——比如说，它不会欠缺行将要做的 Backlog。但这方面的练习能够疾速晋升团队故事拆分的能力。千万不要跳过它。
• 通过 2 到 3 个这样的练习，你应该达到这样的水平，即对于工作中的每个个性，每个人都能疾速找出适当的拆分模式，并迅速拆分出适宜迭代的故事。

六、垂直切片和规模化

当你有 100+ 人在同一个产品上工作时，能够应用垂直切片吗？

当你有多个麻利团队开发同一个产品时，能够采纳这两种组织形式：个性团队（feature team）或组件团队（component team）。

个性团队的组织形式是，每个团队都有足够多的跨性能成员，以便能够在局部或全副产品上提供残缺的价值切片（即“垂直切片”）。依据产品的规模，个性团队可能会专一于产品的某些局部，无效地创立子产品，或者他们可能会实现整个产品中最重要的局部。

组件团队的组织形式是，每个团队专一于一个特定的组件、架构档次或技术方向。要想交付一个残缺的价值片段，须要协调多个团队的工作。

让咱们看一个大型商业软件的具体例子：淘宝。(注：我不晓得淘宝的理论组织形式或技术是什么样的，然而这并不重要，我只是须要一个大家都相熟的软件产品来进行推理）。

淘宝有一个 APP。它通过某种通信协定与某种语言编写的后端进行通信。后端有一些流程解决的程序，比方搜寻商品、生成订单、领取订单以及跟踪物流信息等。

如果采纳组件团队构造，你会有 APP 团队，例如，他们能够对 APP 界面进行批改，但他们很可能依赖于后端团队对其零碎局部进行相应的批改。各个团队之间的协调将集中在确保他们的工作同步推动，以最终可能提供价值。

在个性团队的构造下，你可能会有一个团队或一组团队负责商品的搜寻模块，另一个负责订单模块，第三个负责领取模块等。这些团队中的每一个都领有 APP 和后端技能。在这种状况下，各团队之间的协调将集中于确保整个产品的设计和架构统一。

雷同的产品，团队以两种不同的组织形式，将失去两套不同的后果和协调计划。

所以，无关“垂直切片是否与规模相干”这个问题，答案取决于你的组织形式。组件团队是不以垂直切片的形式工作的。但组件团队能够围绕更大的垂直切片（如 MMF）协调工作，但在具体的工作项层面，组件团队无奈实现垂直切片所需的全副性能。构建组件团队无奈独立交付价值，但这种组织形式能够针对其余方面进行优化（通常是更容易进行架构调整或更高的研发人员利用率）。

个性团队与组建团队的收益刚好相同。他们旨在独立提供垂直切片，以便更疾速的交付价值、获取反馈，代价是须要明确地协调架构一致性。

个性团队与组件团队是 2 种次要的组织办法。当然，有些组织可能有轻微的差异或混合，并且会随着工夫的推移而变动。我以前写过这方面的文章，特地是在革新一个领有大型遗留产品的组织的状况下。

6.1 是否应该让 100+ 的人去开发一个产品？

当初，咱们心中还有一个更重要的问题，那就是：不论咱们是否能够在大型产品 / 我的项目中应用垂直切片（正如咱们所展现的那样，如果咱们以个性团队来组织，咱们是能够的），这么多人一拥而上，是否真的无效?

为单个产品 / 我的项目增加人员或团队，都会带来一些生产力和协调的开销：我的项目如果只有一个人，那么这个人的生产力简直是 100%；再减少一个人的话，咱们不会失去 2 倍的生产力，可能只会失去 1.8 倍的生产力（均匀每个人提供 90% 的生产力），因为这两个人须要花工夫用来进行工作的协调（每个人耗费 10% 的生产力用于协调）；减少到 3 集体的时候，生产力会失去再次晋升，这次有可能会进步到 2.4 倍（均匀每个人提供 80% 的生产力），相应的，协调的开销也会随着回升（每个人耗费 20% 的生产力用于协调）。而且，这种协调的开销会随着人与人之间分割的数量呈指数增长。

通过组建小规模团队，使每个人只须要与多数人协调工作细节，并尝试在团队之间进行分工，尽量减少依赖性，从而能在肯定水平上缩小协调的开销。但工作越简单，依赖关系就越难以预测，团队之间须要协调的可能性就越大。

因而，在某些时候，在我的项目 / 产品中再减少一个人或一个团队，不仅不能晋升生产力，还会给整个零碎带来协调开销的减少，最终导致整体生产力的降落。

（团队规模、价值减少和协调开销之间的关系）

团队规模的临界点到底落在哪里，在很大水平上取决于我的项目 / 产品的具体情况。但抛物线的形态至多应该让咱们对大型团队产生狐疑，并慎重考虑人员或团队的减少。

对于简单的工作来说尤其如此，因为很可能须要咱们在一个我的项目 / 产品上工作一段时间后能力理解真正的问题和解决方案。而在软件开发过程中，复杂性仿佛与价值高度相干。越是高价值的个性，我的项目 / 产品后期越可能发现不了。如果是一个新我的项目 / 产品，咱们在工作中很有可能会学到一些新常识，从而改善咱们交付的价值。

6.2 规模化垂直切片的基线

是的，你能够在每个细节层面和各种规模的工作上进行垂直切片，这样做很有价值。但在大规模的交付中，你须要非凡定的形式进行组织：以个性团队的形式，或者以某种强调性能交付的混合形式。而且，当你应用它时，须要考虑一下，你的需要是否真的须要如此大的规模。

起源：小船哥说麻利
作者：adoudou
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。

5 月每周四晚 8 点，【冬哥有话说】品质与测试专场。公众号留言“品质”可获取地址

• 0506 朱少民《如何最大化软件测试效力》
• 0513 陈琦《数据驱动测试》
• 0520 陈霁《没错，去 QA 是提高质量最无效的办法！》
• 0527 施慧斌《DevOps 实际之继续测试》