问如何在Scrum中创建任务？

EN

这取决于谁关心这些任务。

在对Scrum非常陌生的团队中，开发人员可以将故事拆分到任务中，以获得更好的估计想法，协作工作等。因此，开发人员喜欢的任何东西都应该是前进的方向。通常，开发人员更喜欢将任务放在卡片、白板或靠近工作区的东西上，但有些开发人员确实更喜欢电子系统。我发现移动卡片或在黑板上写字的行为给人一种对任务或故事的承诺，所以我更喜欢这样。

有时，项目经理更喜欢有任务，这样他就可以看到一个故事是否完成了65%，等等。

每次我看到这种情况，结果都是总理斥责开发人员说他们没有完成他们的故事，或者说，“昨天已经完成了85%！你怎么可能没有完成呢？”这在新团队中经常发生，开发人员通常更喜欢先做简单的部分，或者他们还不知道如何将自己的工作与其他人的工作相结合。

问题是，这些任务毫无价值可言！只有通过提供故事才能获得有用的反馈，即使它们不代表完整的功能，而只是对系统进行切片。任务本身只对迭代有价值，直到故事完成，所以不需要历史记录。重视任务的项目经理往往以部分完成的故事告终，没有什么可以发布或展示的。

出于这个原因，我会尽量不重复我的录制工作的任务，而只是让开发人员自己制作任务，并将它们放在他们想要的任何地方。在工作耗尽时，手动计算任务数非常容易。

我不同意之前的答案，即这些任务没有任何价值。我自己更喜欢电子方法，比如：-日历:他们不仅会说需要做什么，而且还会说什么时候和需要多长时间-任务列表:就像传统的待办事项列表一样。-范围项目:将范围电子表格中的项目转换为可交付成果。

将物理任务放在卡片上(尝试过)或在LLP中的白板上(这样做了一段时间)在技术上更好，因为您总是能够快速获取信息。然而，如果你的开发团队是分布式的，特别是当PM在世界的另一个地方时，你最终将不得不以电子方式复制数据。任务本身增加了开发屋的价值，因为它们提供了关于某些任务需要多长时间的良好历史数据。这些信息在构建未来项目的范围矩阵时非常有价值，因此会影响成本计算和交付时间。附带的好处是，您将能够通过历史趋势看到哪个资产(即开发人员)能够执行以及效率如何。例如，如果你给一个开发人员一个数据库任务去做，而他们的效率很低，那么下一次你就会知道数据库任务应该交给其他人，或者在项目之间的停机时间，资产应该花时间来升级数据库技能。

历史任务记录是如此重要，以至于有时客户会要求查看任务以及他们花了多长时间来验证“账单”。当客户按开发机构的每小时工作费率收费时，他们希望对所花费的每一小时(或其中的一部分)负责。我们过去常常在这些表格上填写任务和持续时间，以便与发票一起发送给客户；有时他们会对此提出质疑。