我们如何解决故事点可能引起的感性问题？

Question

我在许多公司工作，每当开发过程被票务系统跟踪时，就有一个相关的大问题:质量和感知。

当开发人员完成12分时，他(她)将被视为团队中的超级明星，但还有更多的地方被忽略:其他人(可能是公司中的许多人)会遇到、试图复制和报告bug。然后，还将有8至12点，或更多，找出原因，并解决它。

所涉及的总分可能是26到32分或更多。此外，如果工作一开始就很混乱，就会累积技术债务，随着时间的推移，技术债务可能会累积并成倍增加。

同时，如果一个人完成了6分，但他或她是坚实的，他或她将被视为一个滞后，谁可以首先被解雇或下岗。而且，有用的东西，有时人们不欣赏，有时就像你每次准时给孩子们提供一顿饭，孩子们会认为这是理所当然的，而如果有时候饭不能按时送到，如果你这次准时送餐，孩子们会非常感激。

我认为沟通只是有点帮助，因为在经理或其他开发人员的心目中，它仍然是:一个人完成了12分，而另一个人只完成了6分。

我们如何解决这个质量和感知问题？

Answer 1

用个人完成的故事点数来衡量个人，是对标准的滥用。这不是“故事点”的目的；“故事点”的目的是建立整个团队的平均速度。这是一个团队度量，而不是单个度量。

故事点是对一个故事完成有多难的任意度量。这是一种承认，我们都很难估计。准确估计完成一项任务所需的时间需要无所不能:您需要知道涉及到多少细节，这需要完善的规范，并且您需要知道您的团队将如何响应该级别的细节。准确估计这类任务所花费的工作量很容易超过完成这些任务所需的时间。

因此，我们不给任务分配天数、小时或分钟，而是分配“故事点”。故事点提供了一个水平的间接，不约束你时钟时间。在我们的商店里，一个故事点大约相当于两个小时，但这并不一定意味着完成了12个故事点的人花费了24个小时，或者另一个完成了6个故事点的人做的工作更少；这意味着我们的四人团队每周能完成大约80个故事点。这就是我们的速度。

因为这个速度是基于整个团队的，所以它是一个合理一致的度量标准，因此可以依赖它来衡量在给定的sprint中可以完成的工作量。

Answer 2

我赞同罗伯特·哈维在他的回答中所说的话。一个人不应该“看上去像一个超级明星”，根据他们完成的故事点数。开发人员的评级不应以任何方式由故事点驱动。如果他们没有在这个指标上被评级，那么他们就不会被“诱惑”去人为地膨胀它。罗伯特的答案的问题在于，虽然它正确地指出这是滥用故事点，但它除了隐含的“不要做这件事”之外，几乎没有提供关于如何纠正这个问题的指导。如果你不能做出这个决定，这是没有帮助的。

为了不让自己回答一个可笑的宽泛的问题，我将主要集中在故事要点上。我还将重点关注更多的战术反应，因为听起来你更像是一个承包商，而不是一个长期雇员。此外，我将重点关注团队成员能做什么，而不是经理能做什么。最后，我倾向于使用Scrum术语，但是没有必要使用Scrum，甚至是敏捷方法。

第0步:确保确实有问题。如果系统似乎在工作，也许你就是错了，认为需要改变。

考虑到你认为需要改变，首先，一定要与团队和管理层讨论故事要点的正确用途。如果完成的故事点数是晋升、加薪和解雇决策中的一个重要因素，那么团队成员将很难改变他们的行为，因为在这种情况下，这样做可能是不合理的。在这种情况下，您需要指出以这种方式将故事点作为管理度量的问题，并提出替代方法和/或度量。如果你有业务数据的话，就把它带来。

这将导致下一个方面:颠覆(不正确)对故事点的解释，将其作为一个单独的度量标准。应该已经发生的各种因素都会给这种解释蒙上明显的阴影。例如，故事很可能在冲刺过程中易手，因此涉及到多个开发人员:那么谁能获得“荣誉”呢？对于QA来说，这种情况至少应该发生一次。对编程或代码评审以及设计会议也会使单个人难以完全获得信用。应该鼓励这种做法。开发人员“拥有”一个故事的想法应该被劝阻(这并不是说你不应该跟踪谁正在处理一个故事)。故事不应该被分配，直到有人开始处理它们。这也应该是一个完全合理的行为，一个团队成员说“故事A的结果比我们想象的更复杂，有人能拿我已经完成的B故事吗？”

如果你至少被团队认可为“更好”的开发人员(团队通常对成员的实际优点有很好的了解)和/或你实际上是团队的领导者，那么慷慨地承认他人对你所写故事的贡献，并强调自己对“你的”故事的贡献。强调优先顺序而不是故事点数，即使在冲刺中也是如此。虽然sprint中的故事应该按照最有效的顺序来处理，但是您仍然应该倾向于更高优先级的故事。通过你的言行，你应该告诉大家，完成更高优先级的故事比用更多的故事点完成故事更重要。根据定义，更高优先级的故事对业务更重要，根据定义，更多的故事点只意味着更难实现，而不管对业务的价值如何。通常，您应该强调优化业务价值。

在短跑回顾(或类似的)中，应该坦率地讨论故事是被高估了，还是被低估了，以便在将来改进评估。如果已经完成的故事点仍然分配给单个开发人员，那么团队成员之间的巨大差异应该被看作是评估的失败(特别是结合团队对其成员的相对技能的理解)。如果质量不佳的结果通过，那么这是一个失败的过程。应坦率地讨论这一问题，并应采取措施减轻这一问题。也就是说，“点名”通常是没有意义的，因为至少必须有两个人参与，编写糟糕代码的人和编写代码的人( person QAing )，最终都是整个团队的失败。在Scrum环境中，这可能意味着您需要调整您的“完成定义”，或者确保您遵守它。然而，低质量的工作不一定是质量差的工作。质量是一种成本/效益的权衡，你肯定会过于保守。

Answer 3

为了解决你所描述的更大的问题--如何归功于团队中的每一个人，而不仅仅是修复这个问题的最终编码器--我认为你希望有一些系统能够公开奖励每个人，并专注于团队的沟通和进步，比如：

• 让所有团队成员站起来，参加每周的敏捷会议。
• 强调所有人的贡献，而不仅仅是程序员
• 对所有团队成员的尊严和尊重，不论其职位如何
• 有趣的时候人们可以更好地了解彼此
• 回顾期间是否有所有团队成员在场？
• 让所有队员坐到一起
• 每周小组会议
• 经常安排1:1's在团队内，也在团队和级别之间
• 雇用优秀的工人，但不雇用自以为是的摇滚明星。

对于大多数公司的员工来说，这也是一个合理的期望:在那些公司中，有很多人不编码，但对企业来说仍然是必不可少的。你的问题的关键部分似乎集中在如何给予这样的人信任。