从 Scrum 到 Linear Method：重塑我们的开发流程

过去 5 年，我们团队一直都在使用 Jira 来实践 Scrum。Jira 的难用是众所周知的，但作为产品经理我也理解为什么 Jira 这么难用。2B 尤其是面向大型企业客户的产品，最终形态都是像 Jira 或者 Salesforce 那样。体验极差，但是灵活性非常高，面对大型客户，每家公司都有自己的工作流，这种定制的工作流本来就不够 SaaS，所以为了满足这种需求，产品只能做到非常灵活，一个极端就是直接提供 API，让客户自己随便玩。但是并非所有人都有了编程经验，于是不会编程的用户便想要一些简单的规则引擎，规则引擎本身是一个非常复杂的任务；但规则引擎并不难解决所有问题，总会有一些高级用户会提出来为什么不增加这样或那样的规则，甚至为什么不直接增加一个可以运行代码的节点。灵活性不是一个简单的问题。不过这是另一个话题了。

但对于我们团队来说，我们不需要非常灵活的东西，他会让事情变得复杂，我们只需要简单的看板，可以统计 Velocity，可以无限嵌套子任务的工具。某次网上冲浪期间发现了 Linear，但一开始并没有直接使用，我的第一印象是“这不就是一个速度更快、更简单的 Jira 吗”，并不觉得有什么颠覆性的东西。一年之后我又无意间读到了 Linear Method，然后才开始入坑，也才慢慢理解了 Linear 背后设计意图。Shape Up 也是同理，只是 Basecamp 的理念可能过于先进，我到现在也没有完全吃透。

在使用 Linear 的同时，我们结合 Linear Method 和 Shape Up，对我们的开发流程进行了重塑，尝试解决我们在 Scrum 中遇到的问题。实践了快一年，并非所有的问题都得以解决，但我个人的感受是整体项目的交付速度提升至少有 20%。有必要总结一下我们这一年的经验。

在使用 Jira 和 Scrum 的时候，开发团队每 2 周进行一个 Sprint，每个 Sprint 的最后一天我们会做 Sprint Review 和 Retrospective 以及 Planning。Sprint Review 就是把团队的交付的内容和 Stakeholders 同步，通常我们会测试环境 Demo 即将上线的新功能。Demo 完成后 Stakeholders 会提出一些问题或者建议，随后是 Retro，主要是回顾团队协作的情况。紧跟着就是 Planning，产品经理讲述下个 Sprint 的项目。Planning 之后是 Grooming，开发团队对项目进行拆解，将每个项目拆分成开发任务并评估出故事点，评估完成后 Scrum Master 会根据团队过去的 Velocity 给出最终的交付物。

这里存在几个问题：

1. 故事点估算的交付周期几乎不起作用，很少会按时交付。
2. 所有人都显得很忙碌，工程师总是在写代码，修 bug，对于项目价值以及原因并不理解。
3. Sprint 不停的冲刺，团队很少能够审视过去做过的项目是否真的有价值。
4. Sprint 目标确定后，极少有空间去修复技术债务。
5. Sprint 开始的时候，往往技术方案还不是很确定，Sprint 冲刺的过程中存在着大量的不确定性。
6. 如果项目出现风险，导致无法在 Sprint 结束的时候上线，结果就是延期到下个 Sprint，完全不够敏捷。
7. 设计师应该在 Scrum 中的哪个阶段参与？如何参与？

过去，我们在 Scrum 的框架中打了很多补丁，效果并不理想，反而徒增了许多工作量。当时我们并没有意识到或许换一种工作流可能就可以很好的解决。其实也不用替换掉整个工作流，只需要少许改动就可以解决很多问题，这个改动就是在 Cycle¹ 之间引入了 Cooldown。我们参考 Basecamp 的 Shape Up 方法，并结合自身实践，将 Cycle 的长度设置为 3 周，在 Cycle 与 Cycle 之间增加 1 周的 Cooldown。

Cycle 中要做的事情与 Sprint 并没有太大的变化，主要是关注交付。我们保留了每天早上的站会，花 5–10 分钟来同步项目进展，主要目的是发现风险点。如果开发的过程中发现了新的不确定因素，团队成员会在站会上提出来，如果影响到项目的交付，我们会尝试调整项目的 Scope，或者安排更多的人力。风险确认之后，我们也会发布 Linear 的 Project Updates，内容会同步到 Stakeholders 所在的 Slack Channel，确保所有人都了解项目情况。

持续冲刺最大的问题就是很少去反思之前做过的项目，开发也没有时间去做性能优化，解决技术债，而这些问题在 Cooldown 中都有一定的缓解。在 Cooldown 中，我们主要关注以下事项：

1. 回顾上上个 Cycle 的结果：分析每个项目是否达成了预期的目标。
2. 制定下个 Cycle 的计划：结合之前项目的经验和数据，制定下个 Cycle 的计划。
3. 明确方案和拆分任务：确定下个 Cycle 的计划后，开发团队会进行技术调研，确定技术方案 ，然后根据方案拆分出开发任务。
4. 评估开发任务的故事点：开发会对每一个具体的开发任务给出相应的故事点，根据整个项目的故事点总数，我们可以预估下个 Cycle 的交付物。
5. 优化和修复：优化上个 Cycle 中出现的问题，或者修复 Bug，为下一个 Cycle 的顺利进行做准备。

整个 Cooldown 从周一到周五大概会这样安排大概是这个样子：

周一：开会的一天

周一大部分时间都在「开会」。主要在做的事情实际上就是回顾之前的项目，然后计划下个项目。

1. 回顾会议

回顾会议由产品经理来同步上上个 Cycle 交付的项目的数据。通常我们的项目分成两种：一种是功能交付；另一种是试验一些新的想法。前者通常关心的是用户使用情况；我们团队做的比较多的是后者，后者我们会将每个项目的结果分成 3 种：

1. 符合预期（Validated）：即项目结果达成了我们最初设定的指标，并总结原因。
2. 不符合预期（Invalidated）：即项目结果没有达成最初设定的指标，然后分析原因可能是什么。
3. 没有结论（Inconclusive）：这个比较复杂，虽然指标可能符合预期或者不符合，但因为有其他因素的干扰，导致无法判断是否是因为这个项目导致的结果。

同样，针对 3 种结果，也会有 3 种不同的行动项：

1. Validated：通常下一步行动是进一步优化，或者进行规模化。
2. Invalidated：则会进一步讨论是否需要继续，或者放弃。通常一个项目会对应一个目标，而达成目标的方式通常有很多种，每一个项目通常我们会选择其中一种来做尝试，如果这种方法被证实为无效，我们可以会继续评估是否这个目标还值得去做，如果值得，那么再考虑其他方式。而如果已经没有新的想法了，则暂时放弃。有些放弃的项目也会需求下线之前的项目，清理代码。
3. Inconclusive：与 Invalidated 的类似，不同的是当中有试验初期未被考虑的因素出现，这个因素对试验的结果产生了一定的影响。那么无论结果是符合预期还是不符合，都不能作为确定的事情，我们需要考虑这个新的因素后重新设计试验，然后重新评估项目是否还有机会成功，如果有，那么稍微调整下再继续观察。如果考虑到新的因素之后，原有的项目已经无法奏效，那么就像相当于是 Invalidated 了。

2. Planning 会议

Planning 主要是产品经理向团队介绍接下来一个 Cycle 的目标和方案。我个人很喜欢 Shape Up 中写 Pitch 的方法，不过对于并不是所有产品经理都能够写出合格的 Pitch，因此也暂时没有在团队内部推广。Planning 实际上会过 3 种项目：

1. 产品经理原本安排在下个 Cycle 要做的事情。
2. 回顾议会中，如果有提出新的想法，产品经理也可能会安排到下个 Cycle 中。
3. Linear Triage 中所有的项目：Cycle 的过程中如果有任何新的想法，通常都会先进入 Triage 中，每次 Planning 的时候我们都会一条一条的 Walkthrough，如果决定不做的就会直接 Cancel 掉，决定要做的就会尝试安排到下个 Cycle 中。如果 Cycle 没有空余的时间，则会 Snooze 推迟到下下个 Cycle 再讨论。

3. Retrospective 会议

这个是从 Scrum 中延续下来的会议，这个会议与项目无关，主要关注的是团队协作流程中的问题。通常会议上我们会收集团队成员的反馈，大家回顾项目进行中碰到的阻力，跨团队协作、文档、做事方式等等，把所有认为不合理的地方都记录下来。会议中我们会讨论这些问题，并且商讨出一个可行的解决方案写入下个 Cycle 的行动项目 。会议结束后，每个行动项目都会有一个 Owner 来追踪。实际上，我们现在的项目运作流程就是在这个会议中讨论出来的。

周二到周四：Shaping

这几天相当于 Shape Up 中的 Shaping 过程（虽然并不完全相同），Shaping 主要达成几个目标：

1. 目的是明确交付项目所需的具体内容，也就是 Definition of Done。
2. 明确投入的成本，也就是 Shape Up 中提到的 Appetite。在《RICE 框架》中有提到一种衡量 ROI 的方法，讲道理应该遵守这种规则来设定 Appetite。
3. 分析技术可行性，调研技术方案。
4. 然后拆分技术任务，并评估点数。

对于开发来说，Planning 的项目可以分成两种状态：

1. 我们知道怎么做，整个项目基本确定，需要用到的数据、服务、设计都是比较确定的。
2. 项目看起来具备可行性，但还没有具体的实施方案，其中又可以分成以下几种状态：
3. 不知道用什么技术来实现；
4. 知道用什么技术来实现，但对该技术不熟悉；
5. 技术都比较了解，但是有外部依赖性，可能需要依赖外部团队。

对于 2.1 和 2.2，工程师首先会调研技术方案，技术方案调研完成的标准是用简单的脚本构建了原本的需求，其中的代码质量可能无法到达 Ready for Production 的水平，但是基本的流程跑通了，也大概知道有哪些坑以及要做什么事情。确定这些之后就可以对项目进行拆解。

2.3 产品经理和工程师也会找对应的团队去沟通，如果其他团队可以在 Cycle 内提供支持，那么首先要做的就是协商接口协议和大致的时间，然后各自按照协议进行开发。团队确定协议后也会先拆解项目。

也时候也会出现一种情况，就是到 Cooldown 结束的时候也没确定技术方案。这个时候有两个选择：

1. 暂停该项目，等待下个 Cycle 的时候再决定是否要继续，因为成本比较高。
2. 把技术调研本身作为一个任务放进 Cycle 中，这种情况下该项目通常不会作为交付目标，而是如果有空余时间才会去做。

把技术调研放进 Cycle 的另外一个问题是 Story Point 无法确定。我们之前有出现过整个 Cycle 都是在做调研，尝试过很多方案，最终还是没有找到合适的方案。最大的问题是没有制定一个「止损」，我们现在通常会给一个固定的时间来做技术调研，通常是 1–2 天，如果 2 天之后没有任何进展，可以会先暂停调研，转而投入更确定的项目中。

Shape Up 中有个 Hill 的概念，技术调研就像是在爬一个山坡，爬到山顶意味着技术调研已经结束，方案已经很明确了。Linear 没有向 Basecamp 的 Hill 的概念，所以我们为进入 Cycle 中的调研任务定了一些规则。由于调研任务很难评估时间，所以我们会在调研任务一开始的时候确定一个最大时间，也就是根据项目本身的价值，我们最多还愿意投入多少的时间来做技术调研，通常是 1–3 天。然后我们每天会评估前一天调研的情况，通常在最大时间达到的时候会有几种结果：

1. 方案已经明确：这是最理想的情况，接下来就是做任务拆解，但不一定需要在这个 Cycle 进行开发。
2. 方向已经明确，但具体的技术细节还要在调研：这种时候我们通常会在给出 1 天的时间，一天之后在进入这个评估流程。
3. 方向依然不明确：这种时候我们会暂定调研，转化把人力投入到已经确定的项目中。

周五：评估故事点的艺术

周五也是 Cooldown 的最后一天，在下周一的时候就会直接进入 Cycle 中， 因此周五最主要的事情就是确定下个 Cycle 的交付物（Scope）。 最初我们按照 Scrum 的 方式来评估点数，整个评估过程需要所有参与的工程师 一起，所有人 同时评估一个项目，评估的结果通常会有些出入，有些人的点数多，有些人认为的少，然后讨论为什面会有出入，通常是一些背景知识的差异，或者有些人想到一些 边缘情况，所有信息都聊清楚之后，最终达成一致。这种方法的结果是没有问题的，但是效率非常低下，因为每一个项目大家都要讨论很久，结果就是一个点数评估要好几个小时才能完成。

我们的解决方案是制作了一个评估点数的标准，每种类型的任务都有相对应的点数，例如对于前端来说，最简单的需求莫过于改文案，所以一个改文案的 Issue 就是 1 个 Story point；比改文案稍微复杂的就是改个 CSS 属性，改颜色，调整字号什么的，它比改文案复杂的点在于有时候你的修改可能不生效，CSS 覆盖什么的，所以可能会需要找一下在哪里改。以此类推，我们使用斐波那契数列来制作了一个 Cheatsheet 帮助工程师评估每个 Issue 的点数。整个项目的点数就是把所有 Subtask 的点数加起来。

我见过一些团队会被所有做过的任务都进行归纳，然后给每种类型的任务都给一个固定的点数，每个点数下面 也都会链接到一些典型的任务上。这样做唯一的问题也是效率，回顾过去做过的所有任务并分类归纳并不是一件轻松的事情。对比我们现在的做法是，先定义一些我们经常被碰到任务，作为一个锚点，然后遇到新类型的时候，会临时评估一个点数，到 Cycle Retro 的时候我们会重新调整下点数标准。效果也很不错，从最开始到现在基本已经稳定，中间值有过一次比较大的调整，是因为有一些新的任务比我们定义的 3 个点大，但是比 5 个点小。于是我们把所有的 5 个点之后任务都统一往后挪了一位，对应的 Cycle Velocity 也给这膨胀了。

另外就是评估点数的标准描述上，最开始我们定义的锚点就是“1 点：修改文案”这种比较清晰的，但是对所有任务类型清晰的分类和归纳依然是个体力活，所有基本上在 3 个点往后的，如果实在难以分类，我们就用很模糊的语言来表达，有几个案例可以感受下：

• 5 个点有个类型是“写一个全新的、简单的 UI 组件”，意思是一个 Subtask 需要写一个之前没有的 UI 组件，但是这个组件很简单，简单就是一个很主观的词，但团队内部慢慢的就会达成共识，虽然没有文本说明。大家对简单的共识可能就有几个条件：没有动画、只有简单的交互（点击），甚至没有交互，所以大家一看到就知道这是一个简单的组件。
• 8 个点也有个标准是写复杂的新组件，复杂意味着可能有多个交互方式，内部元素也比较多，但是大概看一眼也都知道应该怎么写。
• 13 个点也有个写组件的，是复杂的带动画的 UI 组件：动画通常调试起来比较复杂，所以只是给一个组件加动画本身就是 5 个点。
• 21 个点同样有一个是创建新的

在说一个拆任务的粒度，通常我们希望是越细越好，所有的故事点就是针对最小粒度的任务做的。举个例子，前面提到的 复杂的带动画的 UI 组件，有些组件本身和动画并不耦合，这种时候就应该拆分成两个任务：1 个写复杂组件的任务（8 个点） + 1 个给组件加动画的任务（5 个点）；也有些组件 UI 和动画的耦合比较深，两个必须一起做才行，这个时候才会保留 1 个任务给 13 个点。

评估点数之后就是确定 Cycle 的 Scope，根据过往的 Cycle 数据我们已经大致知道在一整个 Cycle 中团队能够交付 600 个故事点，虽然每个人的数字都会有一些差异。但团队整体基本上就是在这个数字附近波动。在 Linear 中我们把所有要做的项目和任务都放进下个 Cycle 中就可以看到总体的点数了。通常为了预防一些未知的事情，我们会保留 20% 的冗余点数，也就是其中 80% 的点数是必须交付的，项目中有一些 Nice to have 的就会放在冗余里面，也就是能交付最好，如果有意外发生，不交付也行。

固定时间，动态范围

前面提到在 Scrum 中我们会遇到一个问题，如果 Sprint Goal 无法达成时应该怎么做？以前的做法是，那就延期到下个 Sprint 中。而在 Shape Up 中有一个原则我觉得可以非常好的解决这个问题：

Fixed time, variable scope.

在 Scrum 中我认为的一个 Sprint 的定义是至少一次的发布周期，Cycle 同样也是，每个 Cycle 3 周意味着 3 周内我们要进行至少一次发布。发布不是没做完就直接上线，而是功能是完整的，但可能体验不是很好，甚至在某些边缘场景中会有 bug 存在，并且 bug 是已知的，我们称之为 Release with bugs。最根本的原因就是 Cycle 就一定要交付，而且交付物是可用的，即使有 bug 也不影响主流程。这也符合 Agile 本身所推崇的持续交付。从客户和项目 Stakeholder 的角度来看也更容易接受，通常这两者，Cycle 结束交付相当于团队的一个 Commitment，如果时间到了没有交付，客户和 Stakeholder 会降低对团队的信任，无论如何解释，而如果交付了，但是带有 bug，这个时候大家都会表示理解，毕竟不是不能用。而 Cooldown 的过程中我们就会修补之前提到的问题。

作为买家，我自然也不喜欢这种交付方式，最明显的案例就是游戏行业，我们已经看到过很多刚发布的时候一堆问题， 然后慢慢改进的游戏，Cycberpunk 2077、无人深空这种。我的看法是 2C 产品最核心的就是体验，如果体验没有只有功能，这种产品市面上有大把，用户和玩家不需要这种；而在 2B 里面功能显然更重要一些，体验显然地位比较低，看看 Salesforce 和 Jira。另一方面 2B 涉及到的 Stakeholder 比较多，可能上下游的团队都已经准备好了，那么 Release with bug 显然好过什么都不交付。而拆解出什么是核心功能、什么是主流程对于产品经理显然有一些要求。

举个例子，例如我们的项目是做注册登录，目标就是让用户可以注册并且登录到我们系统中。往大了说就是一个账号体系，最终一定会非常复杂，但是 3 周内我们能做什么呢？最基本的邮箱注册和登录一定是要有的。找回密码呢？自然也非常重要，但不一定要体现在产品功能上，意思是你的 UI 上有“找回密码”这个按钮，但是用户按下之后是 Contact support，然后 Support 可以 联系开发团队后台修改什么的，虽然加到了人力成本，但是作为 Edge case 来说，风险可以接受。

其他问题

到这里，我们使用 Linear Method 最关键的部分就已经说完了，其实就是引入了 Cooldown，而 Cycle 当中做的事情和 Sprint 本身没有区别。

关于交付

这个时候可能有几个问题，同样是 4 周，我们现在的方法只有 3 周实在写代码，另外一周更多的时候是在写文档；而在 Sprint 中，代码就是文档，有 4 周的时间都是再写代码，前者交付的产品应该会比后者少才对。

话虽如此，直接写代码的前提是你的知道你要写什么，虽然 Agile 宣扬拥抱变化，但是需求天天改 Agile 祖师爷来了也没用。拥抱变化是指对趋势和方向的变化，即如果之前的路走错了，下一次改就行了，其核心是通过学习，不断的提升认知，不断了解什么是“正确”的方向，然后不断的调整；而不是天天改需求，改需求意味着根本不知道方向是什么，只是在原地打转而已。

延期的问题其实也是 Sprint 过程中经常发生不确定性，这些不确定性导致的延期。基本上这种不确定可以分成两类：

1. 需求的不确定
2. 技术方案的不确定

这两个问题在 Cooldown 的过程中都有一定程度的解决。但在 Cycle 进行了一半产品经理要改需求，这种事情也拦不住，我们还是回到最开始的原则「Fixed time, variable scope」，时间就这么多，要改动也是可以，但是改动后的版本也要能保证按期交付，交付后可以在打 Patch 来进一步优化。

如果说连方向都变了，整个项目都需要推倒重来，我到目前还没有这种经历，但是我们的预案是会立即停止 Cycle，重新进入 Cooldown 阶段，重新评估项目。这种情况发生的时候，相当于 Cycle 的目标已经发生了变化，那么继续原来的 Cycle 就是没有意义的。

关于故事点

Some teams try to attach estimates to their tasks or scopes to report status. The problem with estimates is they have a very different meaning depending on the nature of the work being estimated.

一些团队会估算任务或范围来做报告状态。估算的问题在于，它们的含义因所估算工作的性质而有很大不同。

Shape Up 并不使用故事点，转而使用 Hill 来作为状态，我并未尝试过这种方式，一方面在 Linear 中没有这样的概念，比较难以实施，另外所有人需要转变思路。我们也不确定这样做是否值得，我们唯一对故事点的抱怨是估算花费了太多的时间，而这个问题已被解决。有了故事点，很大程度上可以帮助我们更好的跟踪项目动态。

故事点的意义在于让我们可以知道团队在一个 Cycle 内的工作容量，从而预估交付物，给利益相关方承诺。虽然并不是完美，但就我们使用的情况来看，问题也不大。

以下是我们在不同时间团队的 Cycle Velocity，你可以看到故事点可能会随着 Cycle 的进行而波动，实际上就是中途发现了不确定。但是我们的交付进度（蓝色实线）基本上是贴着 Linear 的预测（蓝色虚线，只是线性的平均线而已）在进行，基本上说明项目没有问题。

如果蓝色实线距离蓝色虚线有比较大的距离，那么意味着项目可能会延期，这个时候项目的 Lead 通常会发布 Project Updates 来报告项目状态为 At Risk，此时我们会有几个预案：

1. At Risk：通常意味着增加人手可以解决，我们可以暂停优先级较低的项目，而让临时增加人手来解决。
2. At Risk：如果实在没有人手，那么再次思考 Scope 能否继续缩小。
3. Off Track：意味着没救了，无论如何 都不可能按时交付了。这个是最差的情况，我们也出现过 2–3 次。只能提前和 Stakeholder 沟通，达成一致。

关于设计

遗憾的是我们依然没有解决设计师应该如何参与的问题。理论上 Shaping 的过程就是设计师和工程师通常参与 Shaping，搞清楚要做什么，然而我很少遇到能和工程师配合很好的设计师。这不一定是设计师的问题，在一些公司，设计师是一种资源，需要的时候得去申请。这种情况下，设计师调过来也只是完成一些任务，他不会尝试去理解你的项目目标、背景、所处的状态，只是来完成任务而已。当然并不是所有人都这样，但毕竟能够深入理解项目并负责人的是少数。我的项目中尽量不使用设计师，多数时候与设计师沟通要消耗不少时间，有这些时间我自己都把 Demo 写好了。这其实是敏捷（Agile）的另外一层问题，在一个公司当中，只有一个团队和项目敏捷是不够的，外部资源总会成为 Blocker，解决的方案就是让整个公司、整个组织都变得敏捷起来。

我的多数项目中，我自己承担了设计师的角色，从设计师和开发的沟通来看，相比较使用 Figma，我更喜欢用 React 来做设计（直接写代码）。原因是很多时候 Figma 做不到我想要的效果，尤其是要做非常灵活的组件的时候，例如按钮的颜色继承父级组件的颜色，这种情况在 Figma 中需要设计师手动标记，而开发常常会忘记去看这些标记。

对我来说 Figma 还不够灵活，我的习惯是，在做设计的时候，第一版基本上是不会做组件的，先把页面画出来。随着页面的增加，会出现很多重复的组件，这个时候我才开始做组件，然后把页面上重复的地方全部替换成组件。随着项目继续推进，有些组件就需要根据一些参数/变量来自动调整，这个时候需要回去改组件，同时再调整所有用到该组件的地方，很多时候要把组件的宽高一个个全部调整一次，基本上就是个体力活。虽然在写代码也是相同的流程，但是代码的行为比 Figma 调整 Responsive 更加可预测，所以改动起来也会更容易。

在与开发的配合中，我尝试过两种方式，我们目前的几乎所有的项目都使用 Radix Theme 和 Tailwind：

第一种做法是，我会在 Shaping 的过程中会有一个草图（通常使用 ExcaliDraw），工程师就可以根据草图来直接开发，有些地方可能需要工程师自己发挥，因为有 Radix 组件，多数时候都不会太差。开发完成后，我会先验收功能，没有问题我会在对 UI 做一些微调，然后就可以上线了。

第二种做法是，我先写 UI 和交互，只设计前端的逻辑，以及一些 Mock 的数据，并没有真正和后端交互。然后工程师会在此基础之上加上后端的数据。这种流程比较复杂的时候，用代码直接开发 Demo 有另外一个好处，每一次开发完成后我自己会先用一次，总是会发现一些不合理的地方，然后重新调整。用 Figma 当然也可以做一些流程，模拟点击来尝试，但和真正在前端 Mock 数据来使用时完全不同的。

对于一些需要复杂流程的我会选择第二种，如果只是一个做内容展示的页面，则使用第一种。

回到正题，以上就是我们过去一年使用 Linear 并且结合 Shape Up 和 Linear Method 调整后的实践经验，其中不可避免地带有我们团队的历史因素，例如团队成员配合默契，使得 Story Point 的标准即使相对宽松也不会影响最终交付。我们没有完全投入到 Shape Up 或者 Linear Method 中，而是结合自身情况进行调整。没有必要为了改变而改变，只有当现有流程出现问题时，我们才会考虑引入新的方法。我们也深知，没有一套方法可以完美适配所有团队。最佳实践，唯有在实践中根据自身情况不断微调、优化才能得到。

1. Cycle 或者 Sprint 对我来说都是一个周期的单位。Linear Method 不适用 Sprint 是认为 Sprint 有冲刺和意思，而 Cycle 的重点是交付价值，而不是冲刺交付具体的工作量。我个人到无所谓。 ↩︎