Project management scrum中的愿景和产品待办事项之间有什么区别？

不是真的在找书。我看到了很多参考资料和链接。我现在不能买。我一直在网上阅读，看视频，等等。到目前为止，有一件事我还不明白。愿景（问题的解决方案）和产品待办事项之间的区别。从我所读到的，我认为这是用户故事，但我不确定

网上有没有任何东西以线性方式显示从愿景/概念到最终的所有步骤

谢谢你的指点

---

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

用户故事，并就什么是必要的，什么是不必要的进行大量协商

很多谈判

在建筑方面也有很多来回。Scrum需要一个稳定的、经过验证的体系结构。但是，总有升级和增强。这些如何适应积压工作？这是产品所有者、技术人员和（在某种程度上）用户/购买者之间的政治博弈

这个过程本质上是非线性的

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

这些特性中的任何一个都可以作为“核心”，用于决定哪些内容进入待办事项列表以及以何种顺序进入待办事项列表。最终，某种物质成为原子核，混合物结晶。有时，成本、进度或风险是不可接受的，所以你将其加热，找到另一个核心，看看它是否在新的核心周围结晶

顺便说一句，每次冲刺后都会发生再结晶，这使得它更不线性

---

编辑。“稳定可靠的体系结构”

问题：谁为学习新架构付费

答:哈哈。没有好的答案。所以，在进行开发冲刺时，要注意你学习了多少体系结构知识

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

创建架构的时间和成本对您的第一次冲刺有什么影响

您必须将架构开发纳入第一个sprint中，从而拖延时间

假设您决定实现一个灯堆栈。您不知道是使用unix PHP、Perl还是Python。所以你选一个。比如Python。你保证四周内第一次冲刺。因此，您需要花3周时间与kabillion add one模块和框架进行斗争。3周后，你认为你有了一个工作的技术堆栈，但你没有承诺的sprint

你耽搁了吗？如果是这样，每个人都会问你的配速是否正确，并开始将所有其他短跑的时间加倍

你什么也不送吗？如果是这样的话，如果最后除了基础设施什么都没有，那么冲刺又有什么意义呢

您可以更改、修改和增强基础架构——在可管理的部分中。但要构建一个全新的体系结构、验证各个部分、培训每个人并开发最佳实践需要时间。很多。而这段时间不应该——实际上——作为创建可交付产品的冲刺时间来收费。这是开销时间

---

编辑。工具

规则1。敏捷过程不使用很多复杂的工具和过程。这就是为什么我说这个过程需要很多“谈判”。让你高效的东西

规则2。别想太多。就这么做吧

大多数人说——用最强烈的方式——使用5“x8”纸卡，然后把它们贴在墙上。认真地没有工具。只有简单的纸、记号笔、胶带和空白的墙壁空间

请阅读以下内容：

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

我们使用用例（不是用户故事），但工具是相同的。从某种意义上说，用例是一个具有更多细节的用户故事。但是用例名称可以概括参与者如何与系统交互；交互通常可以用清晰、简单的名词和动词来概括，这与用户故事非常相似

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

我不使用电子表格，因为——尽管GUI光彩夺目——我发现它有点麻烦。我觉得有必要编写一个电子表格提取器，将待办事项从一个开放的Office组织文件转换为ReStructuredText（RST）。与电子表格相比，我更喜欢RST——纯文本标记

这都是旷日持久的谈判。每一次谈话都会使一切发生变化。这就是敏捷方法的要点。快速冲刺，然后就下一次冲刺的方向进行协商

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

---

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

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

---

下面是一张图表：

您可以从将愿景分解为一系列史诗开始。这些可以作为需要完成的工作的“大石头”的优先列表存在于您的待办事项列表中

当你开始计划每一个sprint时（或者更早一点），你可以将史诗分解成用户故事并对它们进行优先级排序

愿景（问题的解决方案）和产品之间的区别是什么