不是真的在寻找一本书。我看过很多参考资料和指向它们的链接。我现在买不到一个。我一直在网上阅读，看视频等。到目前为止我还没有得到一件事。愿景（问题的解决方案）和产品待办事项之间有什么关系。从我阅读的内容来看，我认为这是用户故事，但我不确定。
网上有什么东西能以线性方式显示从愿景/概念到结束的所有步骤吗？
感谢您的任何指导。
编辑：在收集需求时，只使用 Excel？
【问题讨论】：
标签： project-management agile scrum
用户故事和大量关于什么是必要的和什么是无用的谈判。
很多谈判。
还有很多关于架构的来回讨论。 Scrum 需要一个稳定的、经过验证的架构。但是，总是有升级和增强。这些如何与积压工作相适应？这是产品所有者、技术人员和（在一定程度上）用户/购买者之间的大量政治角逐。
该过程本质上是非线性的。
这更像是结晶。你有一个解决方案，你开始写故事，你有一个技术愿景，你有一个具有一定技能和经验的团队。
这些功能中的任何一项都可以作为“核心”，用于决定哪些内容进入积压工作以及按什么顺序。最终，某些东西变成了原子核，混合物结晶了。有时成本或进度或风险是不可接受的，因此您将其加热，找到另一个原子核，看看它是否在新原子核周围结晶成可接受的。
顺便说一句，再结晶发生在每个 sprint 之后，这使得它的线性度更低。
编辑。 “经过验证的稳定架构”。
问题：谁为学习新架构付费？
回答：哈哈。没有好的答案。因此，在进行开发冲刺时，请注意您学习了多少架构知识。
如果您没有合适的架构 (a) 有效，并且 (b) 团队中几乎每个人都可以清楚地表达出来，那么您将花时间组装该架构。
创建架构的时间和成本对您的第一个 sprint 有什么影响？
您必须将架构开发整合到第一个 sprint 中，从而拖延时间。
假设您决定实施 LAMP 堆栈。你不知道是 unix PHP、Perl 还是 Python。所以你选一个。就像 Python 一样。你承诺在四个星期内进行第一次冲刺。因此，您工作了 3 周，为千亿附加模块和框架而苦苦挣扎。 3 周后，你认为你有一个有效的技术堆栈，但你没有承诺的 sprint。
你会拖延吗？如果是这样，每个人都会问你是否掌握了正确的速度，并开始将所有其他冲刺的时间加倍。
你什么都不送吗？如果是这样，如果你最后除了基础设施什么都没有，那么冲刺的意义何在？
您可以在可管理的部分中更改、修改和增强基础架构。但是要构建一个全新的架构、证明各个部分、培训每个人并开发最佳实践，都需要时间。很多。而且那个时间不应该——真的——被计为冲刺时间来创造可交付的产品。那是开销时间。
编辑。工具。
规则 1。敏捷流程不使用很多复杂的工具和流程。这就是为什么我说这个过程是很多“谈判”。任何能让你富有成效的东西。
规则 2。不要想太多。去做吧。
大多数人都说 - 以最有力的方式 - 使用 5"x8" 纸卡并将它们贴在墙上。严重地。没有工具。只是简单的纸、记号笔、胶带和空白的墙壁空间。
阅读：http://www.agilemodeling.com/artifacts/userStory.htm
您可以使用电子表格来收集用户故事（和史诗——必须分解的故事）。您可以添加复杂性（故事点）、成本、优先级和发布列，并将其用于项目管理。
我们使用用例（不是用户故事），但工具是相同的。用例——在某种程度上——是一个预先包含更多细节的用户故事。但是用例名称可以概括参与者如何与系统交互；交互通常可以用清晰、简单的名词和动词来概括，这很像用户故事。
电子表格看起来很方便，因为您可以在每个 sprint 结束时重新排列行。您可以通过简单的计数和总和来计算出每个功能的成本以及它们何时到达。
我不使用电子表格，因为 -- 尽管 GUI 很炫 -- 我觉得它有点麻烦。我觉得有必要编写一个电子表格提取器，将 Open Office Org 文件中的积压工作转换为 ReStructuredText (RST)。我更喜欢 RST——纯文本标记——而不是电子表格。
这都是旷日持久的谈判。每次谈话都会导致一切都发生变化。这就是敏捷方法的重点。快速冲刺，然后就下一个冲刺的方向进行谈判。
我们的积压工作是一个很大的 RST 文档。我们使用Sphinx 发布我们所有的文档，并且在 RST 标记中编写积压工作、用例、架构、设计等非常非常简单。
我们的冲刺只是大文档树的一部分。它们装饰有一些特殊用途的解释性文本字段，用于估计完成日期和状态（处理中、已发布）等主观信息。
【讨论】：
愿景（问题的解决方案）和产品待办事项之间有什么关系。
什么都没有。从Vision，您只需创建产品待办事项 (PB)。请注意，产品待办事项 (PBI) 不需要全部细粒度，只有最紧急的项目需要。所以，不要犹豫一开始就创建粗粒度的项目，你会“及时”将它们分解成细粒度的 PBI（这个活动被称为backlog grooming）。
有了这 2 个工件，您就可以开始您的项目了。正如 Ken Schwaber 所说：“启动 Scrum 项目所需的最低计划由愿景和产品待办列表组成。愿景描述了为什么要开展项目以及期望的最终状态是什么。” （施瓦伯 2004 年，第 68 页）
根据我阅读的内容，我认为这是用户故事，但我不确定。
说实话，我不确定我是否在关注你。根据定义，PB 是 PBI 的列表，因此创建 PB 意味着向其提供 PBI。现在，用户故事只是 PBI 的一种可能形式（Scrum 不会强迫您使用用户故事，它们并不适合所有项目）所以，如果您决定使用这种形式，创建 PB 将意味着创建用户故事.
网上有什么东西能以线性方式显示从愿景/概念到结束的所有步骤吗？
下面是最古老的 Scrum 框架插图之一：
在需求收集上，只使用 Excel 吗？
这是我的建议。如果您需要样品，可以查看 Henrik Kniberg 的Index Card Generator。更多模板和/或示例请访问Scrum backlog templates and examples。
【讨论】：
待办事项是在定义需求之后出现的。积压工作处于不断变化的状态，但最终还是有待完成的工作。
这是一张图表：link
【讨论】：
您可以先将愿景分解为一系列史诗。然后，这些可以作为需要完成的“大石头”工作的优先列表存在于您的积压工作中。
当您开始计划每个 sprint（或稍早一点）时，您可以将史诗分解为用户故事并确定它们的优先级。
【讨论】：
谷歌“用户故事映射”。这是从功能/特性视图理解问题的好方法，也是我向想要构建产品但不知道从哪里开始的人推荐的技术。输入是愿景声明，输出是按优先顺序排列的产品 backlog 以及模型本身。
【讨论】：