如何在Scrum中创建任务？

这取决于谁在乎任务。 在Scrum非常新的团队中，开发人员可以将故事分成任务以更好地了解估算，协作工作等等。因此，无论开发人员更喜欢什么，都应该是前进的方向。通常开发人员更愿意将任务放在卡片，白板或工作区附近，但有些开发人员更喜欢电子系统。我发现移动卡片或写在板子上的行为给出了对任务或故事的承诺感，所以我更喜欢这个。 有时PM会更喜欢这些任务，以便他可以看到故事是否已完成65％等。 每次我看到这一点，最终都会告诉开发人员，当他们说他们愿意或者说“昨天完成了85％时，他们怎么能完成它？”对于新的团队来说，这种情况发生了很多，开发人员通常更喜欢先做简单的工作，或者他们不知道如何将他们的工作与他人整合。 问题是，任务中没有任何价值！只有通过提供故事才能获得有用的反馈，即使它们不代表已完成的功能，只是通过系统切片。在故事完成之前，任务本身仅对迭代有价值，因此不需要历史记录。重视任务的PM往往最终得到部分完成的故事，没有任何东西可以发布或展示。 出于这个原因，我会尽量不为我的录音工作复制任务，只是让开发人员自己完成任务并将它们放在他们想要的任何地方。手动计算任务以进行烧毁很容易。     

我不得不同意先前的答案，即任务中没有任何价值。我自己更喜欢电子方法，例如：   - 日历：他们不仅要说明需要做什么，还要说出可能需要花费的时间和时间   - 任务列表：就像传统的待办事项列表一样。   - 范围项：将范围电子表格中的项目转换为可交付项。 在卡上（尝试过）或在LLP的白板上执行物理任务（在一段时间内做到这一点）在技术上更好，因为您可以始终快速获取信息。但是，如果您的开发团队是分布式的，特别是当PM位于世界的另一个地方时，您最终将不得不以电子方式复制数据。任务本身为开发公司增加了价值，因为它们提供了关于某些任务需要多长时间的良好历史数据。这些信息对于构建未来项目的范围矩阵非常有价值，因此会影响成本和交付时间。作为附带好处，您将能够从历史趋势中看出哪个资产（即开发人员）能够执行以及效率如何。例如。如果你给开发人员一个数据库任务要做，而且效率低下，那么下次你应该知道数据库任务应该给别人或项目之间的停机时间，所述资产应该花时间升级数据库技能。 如此重要的是历史任务记录，有时客户会要求查看任务以及他们花了多长时间来验证“账单”。当客户按开发公司的每小时工作费率收费时，他们希望对花费的每小时（或其中的一部分）负责。我们过去用这些工作表填写任务和持续时间，并将发票一起发送给客户;有时他们会质疑它。