唇枪舌战故事点 | 第15期

践行者第15期直播回放来啦！

一、唇枪舌战故事点

二、干货实录

Q1：老师你们在做完故事点估算后，会悄悄在心里换算成人天或工时吗？

单冰老师：

我不会，但这是不能避免。有的人确实会在背后去转换，但是不建议这么做。

邓志国老师：

我在报价的时候会，因为要估算人天费用。

牟晓东老师：

以身作则，不会。我会引导大家回忆最初选择了什么作为基准故事。当团队有了故事点的意识时，就会自发地提议更换故事作为故事点，这个是比较有意思的。我回想起我们在Sprint会上的一些情景，虽然这些情景可能不符合标准答案，但我相信它们确实存在。昨天，我的团队刚刚进行了一次回顾会，采用了开放空间的方法。在这个过程中，我想到了开放空间的四个原则：“来的人都是对的，该结束时就结束。”我认为，作为敏捷教练或Scrum Master，在一定阶段中，我们需要具备容错的能力，允许一些错误的出现。当我们慢慢了解到故事点的好处后，我们自然而然会纠正这些错误。当然，在某些特殊情况下，我们也不能完全避免错误的发生。例如，我们要开一个18人的会议，如果开一个小时的话一个人天就没有了。在这种情况下，我认为也是可以接受的。因为估算的准确性并不是最重要的，存在一定的误差是可以接受的。这是我的个人观点。

Q2：老板要用点数在团队之间横行比较怎么办？

邓志国老师：

这种观点体现出的是一种控制文化，这种文化并不适用于敏捷，敏捷适合的文化是协作和创新层面，在控制和竞争这个层面，敏捷的土壤是不存在的。这种做法就是试图在一个不合适的土壤中去培养一个敏捷团队，我觉得本身就是矛盾的，应对这种情况，我建议：“Change your organization or change your organization.（要不改变你的组织，要不换一个组织）”

牟晓东老师：

支持邓老师的观点。这种团队间的竞争，表面上是让大家卷起来，以提高公司的利益。但事实证明，不论从长期还是短期来看，它是会降低绩效的。团队之间开始了这种对比之后，短期内，各个团队内部会把关注点放在任务身上了，表面上看团队的凝聚力确实会增强。但是这种团队间长期的敌意是对绩效是有非常严重的损害的，即使后期团队间已经分出胜负，但这种损害依然存在。

单冰老师：

我觉得如果遇到了这样的情况，你要向上管理，需要与老板良好沟通，帮助老板认清团队现状，理清老板的真实需求。

邓志国老师：

我不认同这种团队间的比较，因为每个团队的基准不同，大家做的项目也不同。因此，我们要弄清楚老板这样做的目的是什么。如果他提出所谓的团队之间横行比较只是他的想法，而不是他的需求，那么这个时候，我们要问老板几个Why，这样才能知道老板真正想要什么。

Q3：QA的工作建议估算到故事点里吗？

牟晓东老师：

为什么不呢？如果你的DoD定义了要测试通过，如果你不去估算它，那这就不是一个真实的工作量了。

邓志国老师：

其实，你根本不需要考虑QA的工作。你只要根据DoD考虑团队能完成多少个故事点，这其中已经包含了QA的工作，以及开发和测试的工作，不需要再单独考虑。

Q4：产品建立初期，故事点一般很难有参考物，这个问题该如何 处理呢？

邓志国老师：

首先需要准备一个足够数量的故事点（20-50个左右），因为数量越大越容易估算。其次，将故事点进行分类，将相似的两个放在一起，比它们小的放在左边，比它们大的放在右边，这样形成了一个队列。一般情况下，可以将第二个故事点作为1，然后将第0个故事点作为1/2。如果数量太少，只有3个故事点就可能直接跳到5，这时你还需要考虑后面的故事点是3还是5。如果数量比较大，就会呈现出一定的分布规律。

牟晓东老师：

其实，团队情况不同，应用的方法也不同。第一种情况是团队一开始只有一两个经验丰富的成员，后来团队逐渐扩大规模。那在第一个Sprint期间，我们会以这个专家完成任务所需的人天数作为基准。第二种情况是团队成员的经验水平相当且没有特别权威的人，我们可以使用达成共识的人天数作为基准。到了第二个迭代，我们已经有了一定的经验，可以更好地选取一个故事。

单冰老师：

刚才两位老师提到的方法非常实用。一种是增加样本数量，另一种是寻求权威专家的指导。在我们的实际项目中，这两种方法我们都会采用。此外，我们还会进行迭代，并逐步增加新的样本。随着样本量的增加，我们将有更多的参照物，从而逐渐扩大我们的故事点样本库。

Q5：请问您们的团队在编写需求时，是采用用户故事、需求规格、功能点或多个形式相结合的方式呢？

邓志国老师：

我觉得这位同学可以先看一下敏捷宣言，敏捷宣言第一条是个体和互动高于流程和工具；第二条是客户合作胜过合同谈判。因此，你觉得写PRD是在鼓励个体和互动还是鼓励流程和工具呢？从这个价值观出发，去衡量行为，我到底该怎么做？我相信会有答案。

从我个人来说，我认为用户故事是一个占位符，它只是表明这件事需要团队解决。具体的解决方案需要在开始实施时一起讨论，确定怎么来解决这个问题。之前我见过的PRD，每个用户故事下面都写了不少于500字的详细描述。实际上，从精益的角度来说，一开始就写大量的PRD文档可能会造成后续的浪费。因此，从我个人来说，我不鼓励用户故事一开始就写很多，但是如果你的团队不鼓励个体和互动，那就只能这样了。

单冰老师：

团队为什么写用户故事？用户故事是在说：“我”作为什么人或者什么角色，“我”需要什么，要达到什么目的。

比如，有些产品经理讲一个用户故事时会直接告诉团队我们要改什么地方，要把这个改成那个。那么这是用户故事吗？并不是。虽然PO接到的是一个改什么的明确需求。但PO是可以问这个需求背后的用户故事是什么，用户是想要做什么，然后去跟团队沟通这个用户故事，具体怎么做如何实现那是团队的事情了，PO的最终目标是实现这个价值点。

有时候，如果PO讲述的不是用户故事，而是规格说明或者自己的想法，就很容易与研发产生分歧，很容易与研发撕扯，这样导致PO处于被动的位置。所以，产品经理一定要思考需求背后的原因，并挖掘这个需求背后的原因，为什么会有这个需求，这个需求要达到什么价值，这才叫用户故事。

牟晓东老师：

这个问题是没有标准答案的，需要根据不同的阶段，分不同的情况。两个极端我都遇到过，这两个极端也各有利弊。比如其中一个极端情况就是团队十分强调用户故事，要求所有的任务task也要按照用户故事模式去写，所以造成作为一个PO我想要什么？作为一个开发我想要一个什么？作为一个测试我想要一个什么。还有一个极端但我觉得是个好的例子：它规模化敏捷LeSS的要求。团队里也有PO，但是他写的需求特别简洁，具体的流程大概怎么做？工程师会直接去跟业务人员去沟通。这样做的好处在于：首先系统工程师劳动力被解放出来了；其次就是工程师对业务敏感度是非常强。

Q6：团队内部的前端和后端分别估算一个故事点，然后相加，这样估算可行吗？

牟晓冬老师：

我认为，一个团队很难达到团队内每个人的技能水平都能强的理想状态。敏捷开发倡导T字型人才，每个人都有自己的专长，这是比较现实的情况。因此，在这种情况下进行评估，故事点的好处就体现出来了。我们刚刚讨论了人天，即使所有人都是前端开发人员，每个人的人天也可能不同，更不用说前端和后端之间的技能差距。故事点的好处在于它能促进跨职能团队的合作。例如，我们可以先找一个基准故事，这个故事是大家都了解且通用的，再拿其他故事进行比较，通过比较大小来估算这个故事的规模。我认为这也是故事点的一个好处。利用人类大脑的本能，我们可以非常准确地评估相似物品的大小差异，而在软件行业进行评估时，我们也可以通过本能来大致估算相对大小，而不必拆分得过于细致。

单冰老师：

估算故事点能够帮助团队建立团队意识，让团队成员彼此之间相互了解，共同完成一个用户故事。无论故事点有多大，团队都是以整个用户故事为目标交付的。我们不是完美的，每个人都有自己的专长和侧重点，但我们的目标是价值交付，最终要交付可用的产品。因此，无论是前端、后端还是测试，我们需要聚集在一起共同完成一个故事。

还有另外一个问题：有些团队会将故事点和工时挂钩，导致混淆不清。实际上，一个人一天能够完成的工作量是有限的，但是故事点并不受时间限制。如果我们将时间固定死，就会变成绝对估算，而不能充分发挥个人潜力。因此，在估算故事点时，我们应该注重个人能力的提升，而不是仅仅考虑时间因素。随着迭代的推进，我们会发现团队的效率得到提升，因为我们的故事点数目也随之增加。这种了解是团队合作中非常重要的一环，因为研发人员可能在未来的几年内转变为测试人员，这是完全有可能的。

Q7：用户故事说明书有例子吗？ PRD 中要有用户故事吗？

邓志国老师：

我认为PRD的作用在于“甩锅”，划分责任界限。一旦我发布了PRD，开发人员就必须按照我的要求进行开发，否则责任在产品经理。如果开发人员按照我的要求进行开发，但用户不接受，那责任也在开发人员。这个过程完全是基于责任划分的一个机制。相比之下，用户故事的作用则在于促进合作。我提出一个需求点，产品经理、开发人员和测试人员一起合作，共同解决用户的问题。

我能够理解为什么现在很多团队要把PRD写得非常清楚，即使用户故事也要以PRD的方式来书写。我自己也是这样过来的，我作为一个开发者，我希望一次性把需求说清楚，这样我就不需要再去修改它。让我一次性编写代码还算比较容易，但让我不断修改代码，这可能会让代码变得混乱不堪，这对我来说是一个非常大的挑战。因此，我认为我们的技术实践能力很大程度上限制了我们必须以这种方式进行交付。敏捷开发一直强调高频次交付，但如果我们的能力无法做到这一点，那么这种方式并不完全不合理，而是技术能力和实践之间相互妥协的结果。

牟晓东老师：

如果你制定PRD的目的是需要一个规范借鉴，在这个组织环境下，你必须得用PRD，而你无法改变这一点。你应该使用什么样的用户故事格式，才能让所有人都清楚明白呢？虽然用户故事并不是Scrum强制要求的，但我认为这种做法也是可行的。

单冰老师：

PRD还是必须要有的，不能一下子就把它抛弃掉。但是，我非常同意两位老师所说的，PRD需要明确目标、分析产品和达成目标。因为这是PRD背后的原理。

Q8：用户故事牵扯了太多干系方，那用户故事实践该如何落地呢？

邓志国老师：

用户故事牵扯太多干系方，这本身就是个问题。我们把用户故事看作是交付价值的关键点，在鼓励个体和互动的情况下，如果干系人员无法互动，那么个体和互动就失去了意义。

我们鼓励个体和互动，但完成一个用户故事涉及到了四个干系人，他们分别在澳洲、北美和欧洲，他们的作息时间不同，从未见过面或交流过。显然，这种情况下无法鼓励个体和互动。在这种环境下，我们鼓励的是清晰地描述下一个人要做什么，然后提交文档。如果涉及到太多干系人，也就是说无法在一个团队内完成交付价值，那么如果组织不进行改变，很可能会出现别人给你一个文档让你去执行的情况。组织结构决定了行为方式，即使想要实现敏捷，也只能在自己的范围内实现，与他人合作则会受到限制。

单冰老师：

是的，在这种情况下，无论是写PRD还是用户故事，就会变成飞鸽传书，因为这仅仅是简单地传递信息而已，缺乏思考和价值。这并不是我们的产品经理或架构师所期望的。我们希望产品经理能够有自己的思想和观点，能够将客户需求和实际可行性相结合，从而体现出中间的价值，并将这个价值传达给团队，让团队共同努力实现交付。

邓志国老师：

我认为这里可能隐含了一个假设，就是团队害怕失败，没有人愿意承担责任，因此需要找一个与团队无关的人来做出决定。但实际上，一个害怕失败的团队很难变得敏捷，因为他们总是担心犯错被指责。

单冰老师：

有些产品经理在撰写需求文档时，往往使用机械化语言描述需要改进的内容和设计方案。然而，现在我们要求产品经理撰写用户故事目标和业务价值目标。这样做的目的是让产品经理思考为什么需要这样做，客户想要解决什么问题。有些产品经理可能会不问为什么，直接将需求传递给研发团队。他们可能会担心传递的信息不准确，因此会写出详细的需求规格。但是，我们希望产品经理能够提高自己的能力，思考为什么，了解背后的价值，选择最有价值的解决方案，而不是只满足研发团队的需求。因此，让产品经理撰写用户故事是为了提高他们的能力和思考深度。

牟晓东老师：

这个问题其实是两个价值观的转换，而不是说你应该怎么去把用户故事写好。

邓志国老师：

我有一个解决用户故事过于简单的方法。我们可以通过引入对话来让产品负责人、开发人员和测试人员一起讨论，共同形成一个验收测试列表。这个列表可以确保大家对于结果的标准是一致的。按照这个标准进行开发、测试和验收，就可以解决用户故事无法指导开发的问题。

Q9：产品要分析什么？达到什么？

产品要分析用户价值，达到目的是用最少资源交付最大用户价值。这个也就是我们所说的：正确地提出问题比解决问题更重要。

Q10：写用户故事从产品经理对业务引导价值的角度比较好理解，但问题通常出现在产品经理对开发时候，业务流程和逻辑要写到什么程度？

这个由你的团队状况决定。这里存在两个极端：一是产品必须面面俱到所有细节都写好，开发无脑按文档做，双方有严格的责任界限；另一种是产品只是写一句话，开发的时候怎么做，要产品、开发、测试等相关人员一起协商形成验收标准。当然，我作为敏捷价值观的实践者，我支持后者。实际情况中要根据团队情况循序渐进，在团队内达成一致后再改进。