project-management - 在 Scrum 中，愿景和产品待办事项之间有什么关系？

Question

关闭。这个问题不满足Stack Overflow guidelines .它目前不接受答案。












想改善这个问题吗？更新问题，使其成为 on-topic对于堆栈溢出。

3年前关闭。




Improve this question




不是真的在找书。我看过很多引用资料和链接。我现在买不到一个。我一直在网上阅读，观看视频等。到目前为止我不明白的一件事。愿景(问题的解决方案)和产品待办事项之间的关系。从我读到的内容来看，我认为这是用户故事，但我不确定。

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

谢谢你的任何方向。

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

Answer 1

用户故事和关于什么是必不可少的和什么是绒毛的大量谈判。

很多谈判。

在架构上也有很多来回。 Scrum 需要一个稳定的、经过验证的架构。然而，总是有升级和增强。这些如何与积压工作相适应？这是产品所有者、技术人员和(在某种程度上)用户/购买者之间的大量政治角力。

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

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

这些功能中的任何一个都可以作为“核心”来决定什么进入积压工作以及以什么顺序。最终，某些东西变成了原子核，混合物结晶了。有时成本、时间表或风险是 Not Acceptable ，所以你把它加热回来，找到另一个核，看看它是否在新的核周围结晶。

顺便说一下，每次冲刺后都会发生再结晶，这使得它的线性度更低。

编辑。 “经过验证的稳定架构”。

问题:谁为学习新架构付费？

答:哈哈。没有好的答案。因此，当您进行开发冲刺时，请注意您进行了多少架构学习。

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

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

您必须将架构开发纳入第一个冲刺，延迟事情。

假设您决定实现 LAMP 堆栈。你不知道是要 unix PHP、Perl 还是 Python。所以你选一个。像 Python。你 promise 在四个星期内进行第一个冲刺。所以你工作了 3 周，与 kabillion add-one 模块和框架苦苦挣扎。 3 周后，你认为你有一个有效的技术堆栈，但你没有 promise 的冲刺。

你延迟吗？如果是这样，每个人都会问你的速度是否正确，并开始将所有其他冲刺的时间加倍。

你什么都不送？如果是这样，如果最后除了基础设施之外什么都没有，sprint 的意义何在？

您可以以可管理的方式更改、修改和增强基础架构。但是要构建一个全新的架构、证明部分、培训每个人并开发最佳实践需要时间。很多。而这段时间不应该——实际上——被视为创造可交付产品的冲刺时间。那是开销时间。

编辑。工装。

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

规则 2. 不要想太多。去做就对了。

大多数人说 - 以最强烈的方式 - 使用 5"x8"纸卡并将它们贴在墙上。严重地。没有工具。只是简单的纸、记号笔、胶带和空白的墙壁空间。

请阅读:http://www.agilemodeling.com/artifacts/userStory.htm

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

我们使用用例(不是用户故事)，但工具是相同的。用例在某种程度上是一个预先包含更多细节的用户故事。但是用例名称可以概括参与者如何与系统交互；交互通常可以用清晰、简单的名词和动词来概括，这很像用户故事。

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

我不使用电子表格，因为——尽管 GUI 很炫——我觉得它有点麻烦。我觉得有必要编写一个电子表格提取器，将 Open Office Org 文件中的积压文件转换为 ReStructuredText (RST)。我更喜欢 RST——纯文本标记——而不是电子表格。

这都是旷日持久的谈判。一切都因每次对话而改变。这就是敏捷方法的意义所在。快速冲刺，然后协商下一个冲刺的方向。

我们的积压工作是一个很大的 RST 文档。我们使用 Sphinx 发布所有文档在 RST 标记中编写待办事项、用例、架构、设计等非常非常简单。

我们的冲刺只是大文档树的一部分。它们装饰有一些特殊用途的解释文本字段，用于主观事物，例如估计完成日期和状态(进行中、已发布)。