写故事卡的好过程是什么?

时间:2008-10-24 21:19:37

标签: agile requirements extreme-programming

我们正在为下一个项目定义故事卡。

  • 我们很清楚客户想要通过研讨会
  • 我们有一份业务需求文档,将由他们签字。

我们定义故障的过程如下

  1. 我们采用客户想要的功能并撰写故事
  2. 我们与团队进行了简短的设计讨论
  3. 然后我们确定对卡的估计
  4. 如果卡超过3天,我们会进一步分解,并从第2步开始重新开始
  5. 不幸的是,客户希望估计整个项目需要多长时间,因此我们需要预先定义所有故事。

    这需要一段时间,而且可能非常耗尽

    可以使用哪些其他方法来定义故事卡? 这可以采取其他什么方式来收集故事卡上的要求?

    编辑:

    1. 这不是我们第一次这样做,这是正常的过程
    2. 客户是内部客户
    3. 我对您如何编写最终编码的卡片
    4. 感兴趣

6 个答案:

答案 0 :(得分:4)

您无法知道何时完成所有工作并仍然遵循敏捷流程。即使您非常努力地估计所有内容,工作量越大,您的错误百分比就越大。对于中等规模项目的大多数估计最终减少2倍,而大型项目最多可减少10倍。

相反,我会要求客户提供功能目标日期。谈话是这样的:

你:你什么时候需要这些功能?

(C)ustomer:你什么时候可以送他们?

你:让我们首先构建边界。如果我在10年内交付了所有这些功能,那会为时已晚吗?

C:当然。

你:如果我明天交付了所有这些功能,那么这会很快吗?

C:当然。

你:从现在起1年后呢?

C:现在还为时已晚。

你:3个月?

C:这有点太晚了,更像是2个月。我们必须准备好在1月份与我们的管理团队一起使用。

你(想):啊哈!

您:我们无法在2个月内提供所有这些功能。我想我们可以在1个月内提供这4个故事,并在下个月提供这3个故事。

C:我们真的需要1月份的特色X.

你好:如果我们添加功能X,我们需要删除一个功能。你不需要哪个?

C:我们只能处理Y部分的一部分。

你:好的。我们将采用此列表并进行更详细的估算。

C(想):哈!我得到了我想要的东西!

我一遍又一遍地发现估计和计划“一切”的根本原因是他们希望承诺按日期交付某些东西。通过目标日期工作得更好,因为它:

  1. 强迫客户帮助进行权衡

  2. 揭示估计的真正原因

  3. 减少要估算的事物数量。

  4. 帮助确定哪些功能对哪个冲刺很重要。

答案 1 :(得分:2)

我建议我们称之为“发布计划游戏”。它与你为迭代所做的非常相似,但是,我们在更高的层次上做了。也就是说,我们将采用用户想要的特定版本的功能或功能点集,并估计我们将方式关闭。然后,您可以将所有这些估算值一起添加,以便根据您当前的信息大致了解您何时可以交付产品。

这应该让你的顾客知道什么时候你要发布,但你仍然需要坚持你需要一点但是需要摆动,因为,就像你的客户一样,你无法预测未来(或者至少我可以'吨)。

答案 2 :(得分:1)

对于发布计划(这似乎是你想做的事情),我不打算将这些小故事打破。无论如何,发布计划的准确性会降低(因为事情会随着时间的推移而变化),因此使用不太准确的单位进行估算是有意义的。

我们通常使用规划扑克,其中13或21是一个故事需要拆分之前允许的最大值。对于发布计划,我们在“ideal days”中估算“理想小时”中的迭代计划。适合我们。

答案 3 :(得分:0)

您打算如何向客户发布应用程序?你在做增量交付吗?或者这是初步可交付成果的计划吗?

我建议将开发分解为两到三周的冲刺,然后为每个冲刺添加一个额外的一周进入交付预算,为自己买一些额外的时间......以防万一客户改变他们对某个功能的想法(他们会)。这有望使估计最终交货日期更容易......

如果您可以说服您的客户,您应该逐步提供,那么您会发现随着规范的变化,您将创建更少的冗余故事。此外,您不必进行太多的前期工作,随着开发的进展,您可以在开发过程中编写下一批故事。

我希望这会有所帮助。

答案 4 :(得分:0)

我通常只会提前提问故事。我试着看看我是否可以将它们分类到至少一个数量级。我根据标题的数量和估计的速度/标题给出一个非常粗略的估计。我通常会让客户将标题分解为(1)现在需要,(2)需要但可以等待,(3)这些都很好。

我首先解决群组(1)并提供足够的信息将其分解为一组版本。在这一点上,我通常可以通过使用更详细的信息来提供更好的估计来提供每个标题的估计。我只计划小组(1)的故事。如果有太多组(1)故事适合发布,我们将其分解为多个连贯的发布/迭代。

当我们从第2组故事开始大约一个月后,我再次与客户坐下(在一个更有针对性的计划会议中,通常与他们交谈),开始这个过程小组(2)故事。

随着项目的进行而添加的故事会被放入正确的组中并根据该组进行处理 - 如果它是当前版本,则需要使用足够的详细信息,如果以后,只需将标题作为占位符。

我做的另一件事是确保客户理解这是一个合作过程,我们最终会得到他们想要的东西。他们可以选择何时停止 - 即使董事会上还有故事。只要我提供他们关心的价值,我们就会不断发展。他们需要相信我正在为他们做正确的事并努力工作。我需要相信他们会尽快向我提供他们想要的最佳信息。

答案 5 :(得分:0)

如果你想要忠实于XP那么我会建议你去here并阅读发布计划和迭代计划之间的区别。在准备开始编码之前,不应该进行单独的任务估算。

故事!=任务。故事被分解为任务,然后你做&lt; 3天的估计。估算故事更加开放,您应该能够确定最适合您和您的团队的故事估算阈值,并在您完成一段时间之后。 (IE <1周,2周,> 2周等)

估算中最重要的部分是跟进实际花费的时间,并对估算过程进行调整。 XP就是反馈。