【问题标题】:Infrastructual user story problem基础设施用户故事问题
【发布时间】:2010-10-31 23:57:00
【问题描述】:

“我们需要显示与当前文档相关的引号。”

这个用户故事将导致我们的许多子系统被修改,它或多或少是 4-5 个冲刺长度。将其拆分为子故事是不可能的,因为修改没有商业价值。但是,在第 5 个 sprint 中,会有商业价值。

你有什么建议?我们将如何创造商业价值,在每个 sprint 中向我们的客户展示它,并让我们的客户在每个 sprint 中优先考虑工作?

【问题讨论】:

    标签: infrastructure user-stories


    【解决方案1】:

    让您的团队创建完成“显示报价”故事所需的任务。
    使这些足够细粒度,以使其中几个可能适合冲刺。
    将所有这些都放在一个单独的待办事项列表中。
    让团队(而不是客户)优先考虑此积压工作,并将高度连贯的任务聚集成块。
    这些块作为“减少完成'显示报价'所需的工作量的 x%”,或类似的公式来量化该项目将在实现目标的预期进展方面带来的好处,进入项目积压工作。

    【讨论】:

    • 谢谢彼得。您的建议实际上与将故事分组为主题相同。我真正要问的是如何提供商业价值,展示这种价值并让我们的客户优先考虑。随着 sprint 之间的持续工作,我们使我们的 PO 没有优先级。这有悖于敏捷性。
    • 在您的问题中,您说“将其拆分为子故事是不可能的,因为修改没有商业价值”。我的第一反应是质疑这一点,但我认为这不公平,并将您的立场视为对原子商业价值的正确解释。任何子部分的商业价值都是 0,只有当整体到位时,工作才会产生 >0 的价值。假设我认为除了创造衍生价值之外别无选择,作为迈向未来价值点进展的指标,除了里程碑交付没有其他迹象。
    • 另请参阅 stackoverflow.com/questions/961654/… ,您可能会考虑将该部分本身视为非敏捷子项目。
    【解决方案2】:

    生日,

    为了让您的用户故事更具描述性,您可以添加:

    • 执行此用户故事的用户类型,以及
    • 您想对当前用户故事执行此操作的原因。

    也许可以尝试使用模板:

    作为“用户类型”,我想要“某个目标”,以便“某种原因”。

    用于您的用户故事。

    例如,您的用户故事可能会最终变成:

    作为一名故事作者,我需要在当前文档中显示我正在使用的其他文档的引用,以便可以正确地归因任何引用。

    然后,这将分解为几个更细粒度的用户故事。

    • 创建用于存储引号及其来源的数据库
    • 交叉引用数据库开始在其主题下存储引号以帮助将来进行搜索。
    • 正在开发的新文档的编辑器需要能够生成和附加参考书目。

    通常,如果您不能将用户故事分解为单个 sprint 块,则表明用户故事太大。使用上述模板有助于减少这种情况。

    HTH

    干杯,

    【讨论】:

    • 谢谢罗伯。这不是我的问题的答案,您在这里描述的是一种主要由 Mike Cohn 描述的标准,它们很容易在网上找到。这些也适用于功能性故事。但我需要的是关于系统的非功能性故事或约束。
    猜你喜欢
    • 2019-01-29
    • 2015-10-07
    • 1970-01-01
    • 1970-01-01
    • 2014-06-16
    • 2016-04-26
    • 1970-01-01
    • 2023-03-20
    • 2011-06-19
    相关资源
    最近更新 更多