我们在开发中使用scrum，我们经常为开发人员创建任务/票证，我想找到一种方法
记录它们。但我有一个被拒绝的问题，这是记录它们的一种方式。一种方式是写在
白板，另一种方式是写在敏捷项目管理工具（Pivotal Tracker）上，我认为他们
是重复的，哪个更好？
答案 0 :(得分：4)
这取决于谁在乎这些任务。
对于Scrum非常新的团队，开发人员可以将故事分成任务以更好地了解估算，协作工作等等。因此，无论开发人员更喜欢什么，都应该是前进的方向。通常开发人员更愿意将任务放在卡片，白板或工作区附近，但有些开发人员更喜欢电子系统。我发现移动卡片或写在板子上的行为给人一种对任务或故事的承诺感，所以我更喜欢这个。
有时候PM会更喜欢这些任务，这样他就能看出故事是否完成了65％等等。
每次我看到这一点，最终都会告诉开发人员，当他们说他们愿意或者说“昨天完成了85％时，他们没有完成他们的故事！你怎么能不完成它？”对于新的团队来说，这种情况发生了很多，开发人员通常更喜欢先做简单的工作，或者他们不知道如何将他们的工作与他人整合。
事情是，任务中没有任何价值！只有通过提供故事才能获得有用的反馈，即使它们不代表已完成的功能，只是通过系统切片。在故事完成之前，任务本身仅对迭代有价值，因此不需要历史记录。重视任务的PM往往最终得到部分完成的故事，没有任何东西可以发布或展示。
出于这个原因，我会尽量不为我的录音工作复制任务，只是让开发人员自己完成任务并将它们放在他们想要的任何地方。手动计算任务以进行烧毁很容易。
答案 1 :(得分：0)
我不得不同意先前的答案，即任务中没有任何价值。我自己更喜欢电子方法，例如： - 日历：他们不仅要说明需要做什么，还要说出可能需要花费的时间和时间 - 任务列表：就像传统的待办事项列表一样。 - 范围项目：将范围电子表格中的项目转换为可交付项目。
将卡上的物理任务（尝试过）或LLP中的白板（暂时做了一段时间）在技术上更好，因为您可以随时快速获取信息。但是，如果您的开发团队是分布式的，特别是当PM位于世界的另一个地方时，您最终将不得不以电子方式复制数据。任务本身为开发公司增加了价值，因为它们提供了关于某些任务需要多长时间的良好历史数据。这些信息对于构建未来项目的范围矩阵非常有价值，因此会影响成本和交付时间。作为附带好处，您将能够从历史趋势中看出哪个资产（即开发人员）能够执行以及效率如何。例如。如果您给开发人员一个数据库任务要做，而且效率低下，那么下次你应该知道数据库任务应该给别人或项目之间的停机时间，所述资产应该花时间升级数据库技能。 / p>
历史任务记录非常重要，有时客户会要求查看任务以及他们花了多长时间来验证“账单”。当客户按开发公司的每小时工作费率收费时，他们希望对花费的每小时（或其中的一部分）负责。我们过去用这些工作表填写任务和持续时间，并将发票一起发送给客户;有时他们会质疑它。