过去 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 给出最终的交付物。
这里存在几个问题：
- 故事点估算的交付周期几乎不起作用，很少会按时交付。
- 所有人都显得很忙碌，工程师总是在写代码，修 bug，对于项目价值以及原因并不理解。
- Sprint 不停的冲刺，团队很少能够审视过去做过的项目是否真的有价值。
- Sprint 目标确定后，极少有空间去修复技术债务。
- Sprint 开始的时候，往往技术方案还不是很确定，Sprint 冲刺的过程中存在着大量的不确定性。
- 如果项目出现风险，导致无法在 Sprint 结束的时候上线，结果就是延期到下个 Sprint，完全不够敏捷。
- 设计师应该在 Scrum 中的哪个阶段参与？如何参与？
过去，我们在 Scrum 的框架中打了很多补丁，效果并不理想，反而徒增了许多工作量。当时我们并没有意识到或许换一种工作流可能就可以很好的解决。其实也不用替换掉整个工作流，只需要少许改动就可以解决很多问题，这个改动就是在 Cycle1 之间引入了 Cooldown。我们参考 Basecamp 的 Shape Up 方法，并结合自身实践，将 Cycle 的长度设置为 3 周，在 Cycle 与 Cycle 之间增加 1 周的 Cooldown。
Cycle 中要做的事情与 Sprint 并没有太大的变化，主要是关注交付。我们保留了每天早上的站会，花 5–10 分钟来同步项目进展，主要目的是发现风险点。如果开发的过程中发现了新的不确定因素，团队成员会在站会上提出来，如果影响到项目的交付，我们会尝试调整项目的 Scope，或者安排更多的人力。风险确认之后，我们也会发布 Linear 的 Project Updates，内容会同步到 Stakeholders 所在的 Slack Channel，确保所有人都了解项目情况。
持续冲刺最大的问题就是很少去反思之前做过的项目，开发也没有时间去做性能优化，解决技术债，而这些问题在 Cooldown 中都有一定的缓解。在 Cooldown 中，我们主要关注以下事项：
- 回顾上上个 Cycle 的结果：分析每个项目是否达成了预期的目标。
- 制定下个 Cycle 的计划：结合之前项目的经验和数据，制定下个 Cycle 的计划。
- 明确方案和拆分任务：确定下个 Cycle 的计划后，开发团队会进行技术调研，确定技术方案 ，然后根据方案拆分出开发任务。
- 评估开发任务的故事点：开发会对每一个具体的开发任务给出相应的故事点，根据整个项目的故事点总数，我们可以预估下个 Cycle 的交付物。
- 优化和修复：优化上个 Cycle 中出现的问题，或者修复 Bug，为下一个 Cycle 的顺利进行做准备。
整个 Cooldown 从周一到周五大概会这样安排大概是这个样子：
周一：开会的一天
周一大部分时间都在「开会」。主要在做的事情实际上就是回顾之前的项目，然后计划下个项目。
1. 回顾会议
回顾会议由产品经理来同步上上个 Cycle 交付的项目的数据。通常我们的项目分成两种：一种是功能交付；另一种是试验一些新的想法。前者通常关心的是用户使用情况；我们团队做的比较多的是后者，后者我们会将每个项目的结果分成 3 种：
- 符合预期（Validated）：即项目结果达成了我们最初设定的指标，并总结原因。
- 不符合预期（Invalidated）：即项目结果没有达成最初设定的指标，然后分析原因可能是什么。
- 没有结论（Inconclusive）：这个比较复杂，虽然指标可能符合预期或者不符合，但因为有其他因素的干扰，导致无法判断是否是因为这个项目导致的结果。
同样，针对 3 种结果，也会有 3 种不同的行动项：
- Validated：通常下一步行动是进一步优化，或者进行规模化。
- Invalidated：则会进一步讨论是否需要继续，或者放弃。通常一个项目会对应一个目标，而达成目标的方式通常有很多种，每一个项目通常我们会选择其中一种来做尝试，如果这种方法被证实为无效，我们可以会继续评估是否这个目标还值得去做，如果值得，那么再考虑其他方式。而如果已经没有新的想法了，则暂时放弃。有些放弃的项目也会需求下线之前的项目，清理代码。
- Inconclusive：与 Invalidated 的类似，不同的是当中有试验初期未被考虑的因素出现，这个因素对试验的结果产生了一定的影响。那么无论结果是符合预期还是不符合，都不能作为确定的事情，我们需要考虑这个新的因素后重新设计试验，然后重新评估项目是否还有机会成功，如果有，那么稍微调整下再继续观察。如果考虑到新的因素之后，原有的项目已经无法奏效，那么就像相当于是 Invalidated 了。
2. Planning 会议
Planning 主要是产品经理向团队介绍接下来一个 Cycle 的目标和方案。我个人很喜欢 Shape Up 中写 Pitch 的方法，不过对于并不是所有产品经理都能够写出合格的 Pitch，因此也暂时没有在团队内部推广。Planning 实际上会过 3 种项目：
- 产品经理原本安排在下个 Cycle 要做的事情。
- 回顾议会中，如果有提出新的想法，产品经理也可能会安排到下个 Cycle 中。
- Linear Triage 中所有的项目：Cycle 的过程中如果有任何新的想法，通常都会先进入 Triage 中，每次 Planning 的时候我们都会一条一条的 Walkthrough，如果决定不做的就会直接 Cancel 掉，决定要做的就会尝试安排到下个 Cycle 中。如果 Cycle 没有空余的时间，则会 Snooze 推迟到下下个 Cycle 再讨论。
3. Retrospective 会议
这个是从 Scrum 中延续下来的会议，这个会议与项目无关，主要关注的是团队协作流程中的问题。通常会议上我们会收集团队成员的反馈，大家回顾项目进行中碰到的阻力，跨团队协作、文档、做事方式等等，把所有认为不合理的地方都记录下来。会议中我们会讨论这些问题，并且商讨出一个可行的解决方案写入下个 Cycle 的行动项目 。会议结束后，每个行动项目都会有一个 Owner 来追踪。实际上，我们现在的项目运作流程就是在这个会议中讨论出来的。
周二到周四：Shaping
这几天相当于 Shape Up 中的 Shaping 过程（虽然并不完全相同），Shaping 主要达成几个目标：
- 目的是明确交付项目所需的具体内容，也就是 Definition of Done。
- 明确投入的成本，也就是 Shape Up 中提到的 Appetite。在《RICE 框架》中有提到一种衡量 ROI 的方法，讲道理应该遵守这种规则来设定 Appetite。
- 分析技术可行性，调研技术方案。
- 然后拆分技术任务，并评估点数。
对于开发来说，Planning 的项目可以分成两种状态：
- 我们知道怎么做，整个项目基本确定，需要用到的数据、服务、设计都是比较确定的。
- 项目看起来具备可行性，但还没有具体的实施方案，其中又可以分成以下几种状态：
- 不知道用什么技术来实现；
- 知道用什么技术来实现，但对该技术不熟悉；
- 技术都比较了解，但是有外部依赖性，可能需要依赖外部团队。
对于 2.a 和 2.b，工程师首先会调研技术方案，技术方案调研完成的标准是用简单的脚本构建了原本的需求，其中的代码质量可能无法到达 Ready for Production 的水平，但是基本的流程跑通了，也大概知道有哪些坑以及要做什么事情。确定这些之后就可以对项目进行拆解。
2.c 产品经理和工程师也会找对应的团队去沟通，如果其他团队可以在 Cycle 内提供支持，那么首先要做的就是协商接口协议和大致的时间，然后各自按照协议进行开发。团队确定协议后也会先拆解项目。
也时候也会出现一种情况，就是到 Cooldown 结束的时候也没确定技术方案。这个时候有两个选择：
- 暂停该项目，等待下个 Cycle 的时候再决定是否要继续，因为成本比较高。
- 把技术调研本身作为一个任务放进 Cycle 中，这种情况下该项目通常不会作为交付目标，而是如果有空余时间才会去做。
把技术调研放进 Cycle 的另外一个问题是 Story Point 无法确定。我们之前有出现过整个 Cycle 都是在做调研，尝试过很多方案，最终还是没有找到合适的方案。最大的问题是没有制定一个「止损」，我们现在通常会给一个固定的时间来做技术调研，通常是 1–2 天，如果 2 天之后没有任何进展，可以会先暂停调研，转而投入更确定的项目中。
Shape Up 中有个 Hill 的概念，技术调研就像是在爬一个山坡，爬到山顶意味着技术调研已经结束，方案已经很明确了。Linear 没有向 Basecamp 的 Hill 的概念，所以我们为进入 Cycle 中的调研任务定了一些规则。由于调研任务很难评估时间，所以我们会在调研任务一开始的时候确定一个最大时间，也就是根据项目本身的价值，我们最多还愿意投入多少的时间来做技术调研，通常是 1–3 天。然后我们每天会评估前一天调研的情况，通常在最大时间达到的时候会有几种结果：
- 方案已经明确：这是最理想的情况，接下来就是做任务拆解，但不一定需要在这个 Cycle 进行开发。
- 方向已经明确，但具体的技术细节还要在调研：这种时候我们通常会在给出 1 天的时间，一天之后在进入这个评估流程。
- 方向依然不明确：这种时候我们会暂定调研，转化把人力投入到已经确定的项目中。
周五：评估故事点的艺术
周五也是 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 组件，但是你一眼看上去就知道这玩意非常复杂，起码得 3、5 天才能搞定。
再说一个拆任务的粒度，通常我们希望是越细越好，所有的故事点就是针对最小粒度的任务做的。举个例子，前面提到的 复杂的带动画的 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 好过什么都不交付。
举个例子，例如我们的项目是做注册登录，目标就是让用户可以&#...
