FogBugz中的"基于证据的计划"很有趣，但是如何结合敏捷方法来使用它呢？

解决方案

回答

我问过FogBugz的人同样的事情，因为例如在XP中，我们会以IET(理想的工程时间)提供估算值。他们的答案是要与我们提供估算的方式保持一致。

回答

正如eed3si9n所说，如果我们对EBS的估算保持一致，FogBugz将为我们解决这一问题。

至于更一般的说，FogBugz如何适合敏捷方法，我们最好的选择是将冲刺作为迷你释放。创建一个Sprint，并将我们希望为该Sprint实现的案例添加到该发行版(或者里程碑)中。如果要进行为期一周的冲刺，请给它一个结束日期，例如一周后。然后，EBS可以对其进行跟踪，并告诉我们是否按计划进行。

"报告"部分中的图形还将显示燃尽图。术语有所不同，因为FogBugz并非仅敏捷，而是提供了信息。

我们想查看完成冲刺的预期时间是保持稳定还是向前发展。如果情况稳定，那么我们将步入正轨，燃尽率达到目标。如果它正在蔓延，那么我们将失去基础，并且冲刺将被延迟。是时候把事情转移到下一个冲刺，或者弄清楚为什么搞砸了估计:)

本质上，我认为这是一个燃尽图而不是燃尽图，但是它为我们提供了相同问题的相同答案。我要准时完成吗？我还有什么要做？

Atalasoft的Lou Franco也为此撰写了出色的文章。帕特里克·奥特曼(Patrick Altman)也有一篇文章。

更新：固定到Altman文章的链接

回答

我们开始将FogBugz用于技术团队的几乎所有工作：文档，错误报告，管理任务。随着时间的流逝，我们逐渐获得了更多的敏捷性。

我所做的工作是创建一个称为"产品待办事项列表"的发行版，并在将来指定任意发行日期。我将FogBugz字段的"版本"更改为"优先级"，以便我们可以按优先级排序。为了管理产品积压，我大量使用Areas对用户故事进行分类。区域可以是主题或者史诗。每个迭代都是FogBugz中的一个发行版。

现在，我们最近开始使用的一件事是故事点，而不是用于估计产品积压的理想任务日。 FogBugz无法理解故事点的度量单位，因此令人困惑，在FogBugz中，我们的产品待办事项列表中的1 SP被报告为1天。如果有任何混淆，这可能很危险。但是我们的团队很小。我没有使用FogBugz中的内置报告工具，但是如果可以的话，这将是很好的。

因此，我所有的Story Point和Velocity计算都是在Excel中的FogBugz之外完成的。目前看来还不错。我们正在使用索引卡来跟踪任务，这些索引用于用户故事和便利贴，作为办公室中董事会的任务。看看Kniberg撰写的《沟槽中的Scrum和XP》这本书对我的决定产生了影响。实际上，有一个很大的板子可以解决我们早上要看的所有事情，Scrums确实很有帮助。

我确实认为FogBugz中的历史估算历史和报告非常出色。这对计划扑克世界有用吗？我认为至少从团队的评估历史来看是可以的。

由于产品Backlog中的用户故事通常会随着迭代计划会议而不断发展(敏捷计划)，因此，如果对案例进行维基风格的编辑，而不是使用描述线程，那就太好了。

有传言称，下一个主要版本将更加支持敏捷流程，因此非常期待看到它提供的功能。

编辑：
FogBugz 7现在可以更好地管理产品"项目"积压订单了。看一看！

http://www.fogcreek.com/FogBugz/blog/post/Scrum-Friendly-Features.aspx

回答

以下是在计划中包括故事点的一些建议：

当我们将故事输入FB7时，我们可以作为案例，并在我们创建的名为"故事点"的新自定义字段中包含来自Planning Poker的故事点数(下面如何操作)。然后，当我们处理该故事时，可以根据需要将其进一步细分为子案例，还可以输入完成每个子案例所需的估计时间(估计时间将累加到故事中(顶部)案例的"估算"字段，以及基于提要证据的计划/燃尽图)

在FogBugz安装中，有两件事需要考虑修改，以反映敏捷命名法。

(1)开箱即用的FB分类"功能"最像"故事"。但是我们可以更改类别名称，并在"管理">"工作流程">"自定义类别"中添加新名称。以下是有关此内容的其他信息：

http://www.fogcreek.com/FogBugz/docs/70/topics/plugins/CustomWorkflow.html?isl=174457

(2)要捕获故事点，我们可能需要在"案例"对话框中创建"自定义字段"。这是通过随附的"自定义字段插件"完成的。有关更多信息，请访问isl = 174461.

请注意，对于"自定义字段"，我们还可以为"故事"添加一个文本编辑框，该编辑框将始终显示在"案例"对话框标题中(无论其下方的案例活动历史记录有多长。)