unity击败计数_关于“击败”团队目标的思考

unity击败计数

肖恩（Shaun）对“ 测量周期时间，而不是速度”的评论表明，一个团队最好同时测量周期时间和速度。 为什么？ 有两个原因：

• “击败”最后一个冲刺目标
• 协助采购订单预测何时完成。

让我们研究这些想法。

阐明故事点

为什么还要烦恼故事点？ （如果您没有阅读原始想法，如Essential XP中的“卡片，对话，确认”，请这样做。）

我们在卡片上写一个故事，可能只是一个短语。 对话充实了故事的内容， 并帮助我们了解了复杂性。 然后，我们可以创建验收标准和测试，以便获得我们理解的确认 。 现在，我们了解了意图，并有了接受标准。

当团队一次只从事一个项目时，估计故事点就很有意义。 为什么要讲故事？

• Points帮助团队成员讨论了故事的复杂性，所有测试的工作量以及这些故事问题。
• 积分帮助团队成员区分较小，中等和较大的故事。
• 假设迭代对团队有效，我们可以使用点数作为估算迭代中可以完成的工作的方式。

尤其是现在，越来越多的团队倾向于从事各种工作，而不仅仅是一个产品的故事，我发现故事点不再有用。 我发现很难比较功能集或产品中的故事点。 除非您有一天或更短的故事，否则我从未见过它们正常化。

注意输出点。 完成的故事就是结果 。

胜过产出

目前，输出度量非常有用。 但是，输出并不总是为客户提供价值。 （示例：我将日常步伐用作输出指标。我的日常步伐很有用，但并不是创造健康所需要的全部。）

此图表显示了两种度量的消耗：累积故事点（6）和完成的故事数（2）。

这些观点很有趣，还不够。 为什么这个团队只能在迭代的最后完成两个故事？ 那很有趣。

故事完成是结果。 他们为某人提供价值。

如果要增加迭代中的故事点数，我希望您也增加迭代中的故事数。 否则，您将在玩敏捷时间表游戏 ：速度倍增，每个人都编写自己的故事或我们能做更多。

当然，您可以做更多的事情。 点是输出。 您要完成更多的工作吗？ 那些完成的故事就是结果。

您可以使用故事点进行预测吗？

请阅读“ 估计和预测”以了解我最喜欢的故事点规模：1，太大，没有任何线索。 （Pawel Brodzinski开发了这种比例尺。）在那篇文章中，Larry Maccherone说计数故事和故事点同样有效。 我的经验是，计数效果更好。 因此，将采取循环时间措施。

我还要问您需要什么样的估计？ 那是一个完全不同的讨论。

我在“ 创建成功的敏捷项目”中写过关于如何估算周期时间和计数故事的文章。 我在《 预测不可预测》中写了关于估计的文章 。

也许您不相信我所说的故事点并不能增强您的预测能力。 在这种情况下，请考虑进行实验。 对于接下来的两次迭代（因此您有足够的数据），请跟踪以下项目：

• 您在迭代中提交的每个故事的故事点数。
• 这些要点代表的故事数。
• 您在迭代中完成的故事数。 （我建议如上所述在燃尽时跟踪此数据。）
• 每个故事花费了多长时间（周期时间）。
• 迭代结束时您有多少WIP（进行中的作业）？ 那是未完成的工作。 您不能声称已完成任何要点。 您不会得到部分荣誉。

现在，您有足够的数据来查看对以下问题的答案：

• 对团队进行故事统计和指向故事是否都有效？
• 当您关注周期时间时，您的行为是否发生了变化？
• 收集此数据时，您的WIP是上升还是下降？

我不知道你会发现什么。 这就是为什么这是一个实验。

击败以前的数据感觉怎么样？

我没有忘记感觉良好的部分。 因为点是输出，所以我建议团队跟踪其在制品和周期时间而不是速度。 （有关累积流程图，请参阅团队未在Sprint中完成工作时：3的见解和完成工作提示 。）

当我指导各个级别的团队时，我要求他们专注于他们想要的结果。 并且，在周期时间上要达到这些结果。 因此，我向经理询问他们的决策时间 。 决策很重要-经理的决策使其他人可以实现自己的目标。

您的团队可以减少周期时间越多，他们对自己的感觉就越好。 他们更快地创造成果。

哪些措施很重要？

就故事点而言，速度是一种输出指标。 当然，这可能是一个很好的迹象，表明团队有麻烦或团队设法进行了协作，或者团队在自动化构建或测试方面的努力得到了回报。

速度不是结果。

什么结果对您的团队重要？ 寻找一种方法来衡量这些结果，看看是否可以更快地实现这些结果。 这就是您实现团队目标的方式。

（肖恩，感谢您提出一个很好的问题！）

午餐后附录：我忘了这么说：故事要点是持续时间的替代，而不是日期。 如果需要日期，请使用循环时间。 如果您想预测工期，我仍然认为周期时间是更有价值的工具

翻译自: https://www.javacodegeeks.com/2019/09/thinking-about-beating-teams-goal.html

unity击败计数