scrum中的愿景和产品积压之间有什么关系？

Question

不是真的想看书。我见过很多引用和链接。我现在不能买。我一直在网上看书，看视频等。到目前为止我还没有得到一件事。愿景（问题的解决方案）和产品积压之间的关系。从我读到的，我认为这是用户故事，但我不确定。

网上有什么能以线性方式显示从视觉/概念到结束的所有步骤吗？

感谢您的任何指导。

编辑：在需求收集上，只需使用Excel？

Answer 1

用户故事和关于什么是必要的和什么是绒毛的很多谈判。

很多谈判。

在架构上也有很多来回反复。 Scrum需要一个稳定，经过验证的架构。但是，总会有升级和增强功能。那些符合积压的东西怎么样？这是产品所有者，技术人员和（在某种程度上）用户/购买者之间的许多政治争夺。

该过程本质上是非线性的。

这更像是结晶。你有一个解决方案，你开始写故事，你有技术愿景，你有一个具有一定技能和经验的团队。

这些功能中的任何一个都可以作为决定积压和订单顺序的“核心”。最终，某些东西成为核，混合物结晶。有时成本，进度或风险是不可接受的，所以你要加热它，找到另一个核，看看它是否可以在新核周围结晶。

顺便说一下，每次冲刺后都会发生再结晶，使其更加线性化。

---

编辑。 “稳定可靠的建筑”。

问题：谁支付学习新架构的费用？

答：哈哈。没有好的答案。因此，在进行开发冲刺时，要小心你做了多少架构学习。

如果您没有（a）工作的架构，并且（b）几乎团队中的每个人都可以表达，那么您将花时间组装该架构。

创建架构的时间和成本对您的第一个sprint有何影响？

你必须将架构开发纳入第一个sprint，推迟事情。

假设您决定实施LAMP堆栈。您不知道是否要使用PHP，Perl或Python进行unix。所以你选一个。像Python一样。而且你承诺在四周内第一次冲刺。因此，您需要工作3周才能使用kabillion add-one模块和框架。 3周后，你认为你有一个工作的技术堆栈，但你没有承诺的冲刺。

你推迟了吗？如果是这样，每个人都会问你是否已经适应了这个步伐并开始将所有其他短跑的时间加倍。

你什么都没有？如果是这样的话，如果除了基础设施之外你什么都没有，那么冲刺的重点是什么？

您可以在易于管理的部分中更改，修改和增强基础架构。但要建立一个新的架构，证明所有部分，培训每个人并开发最佳实践需要时间。很多。那个时间不应该 - 真的 - 被称为冲刺时间创造可交付产品。这是开销时间。

---

编辑。模具

规则1.敏捷流程不使用大量复杂的工具和流程。这就是为什么我说这个过程是很多“谈判”的原因。无论是什么让你富有成效。

规则2.不要过度思考。就这么做。

大多数人说 - 以最强烈的方式 - 使用5“x8”纸卡并将它们贴在墙上。认真。没有工具。只需简单的纸张，标记，胶带和空白墙空间。

阅读本文：http://www.agilemodeling.com/artifacts/userStory.htm

您可以使用电子表格收集用户故事（和史诗 - 必须分解的故事）。您可以为复杂性（故事点），成本，优先级和发布添加列，并将其用于项目管理。

我们使用用例（不是用户故事），但工具是相同的。在某种程度上，用例是预先提供更多详细信息的用户故事。但是用例名称可以总结一个actor如何与系统交互;通常可以用清晰，简单的名词和动词来概括交互，这非常类似于用户故事。

电子表格看起来很方便，因为您可以在每个sprint结束时重新排列行。您可以进行简单的计数和求和，以计算每项功能的成本以及它们何时到达。

我没有使用电子表格，因为 - 尽管GUI闪闪发光 - 我发现它有点麻烦。我觉得有必要编写一个电子表格提取器，将积压从Open Office Org文件转换为ReStructuredText（RST）。我更喜欢RST - 纯文本标记 - 而不是电子表格。

这是旷日持久的谈判。每次谈话都会改变一切。这就是敏捷方法的重点。快速冲刺，然后就下一个冲刺的方向进行谈判。

我们的积压是一个很大的RST文件。我们使用Sphinx发布所有文档，并且在RST标记中编写积压，用例，体系结构，设计等非常非常简单。

我们的冲刺只是一个大文档树的部分。它们用一些特殊用途的解释性文本字段装饰，用于主观事物，如估计完成日期和状态（正在处理中，已发布）。

Answer 2

  

愿景（问题的解决方案）和产品积压之间的关系。

无。从Vision开始，您只需创建产品Backlog（PB）。请注意，产品待办事项项（PBI）不需要全部细粒度，只需要最紧急的项目。因此，在开始时不要犹豫，创建粗粒度项目，您将“及时”将它们分解为细粒度PBI（此活动称为backlog grooming）。

使用这两个工件，您可以启动您的项目。正如Ken Schwaber所说：“启动Scrum项目所需的最低计划包括愿景和产品Backlog。愿景描述了项目正在进行的原因以及期望的最终状态。” （Schwaber 2004，p.68）

  

根据我的阅读，我认为这是用户故事，但我不确定。

说实话，我不确定我是否在这里关注你。根据定义，PB是PBI列表，因此创建PB意味着向PBI提供PB。现在，用户故事只是PBI的一种可能形式（Scrum不强迫您使用用户故事，它们不适合所有项目）因此，如果您决定使用这种形式，创建PB将意味着创建用户故事

  

网上有什么能以线性方式显示从视觉/概念到结束的所有步骤吗？

下面是Scrum框架最古老的插图之一：

  

在需求收集上，只需使用Excel？

这是我的建议。如果您需要样品，可以查看Henrik Kniberg的Index Card Generator。 Scrum backlog templates and examples处有更多模板和/或样本。

Answer 3

在定义需求之后出现积压。积压处于不断变化的状态，但最终还是需要完成的工作。

这是一张图表：link

Answer 4

你可以从将视觉分解为一系列史诗开始。然后，这些可以存储在你的积压中，作为需要贬低工作的“大石头”的优先列表。

当您开始计划每个sprint（或之前的一点）时，您可以将史诗分解为用户故事并确定其优先级。

Answer 5

Google'用户故事映射'。这是从功能/功能视图中理解问题的好方法，这是我向那些想要构建产品但不知道从哪里开始的人推荐的技术。输入是愿景陈述，输出是优先产品积压，加上模型本身。