Scrum。处理将引入架构更改的低优先级故事[关闭]答案

【问题标题】：Scrum. Dealing with low prioritized stories that will introduce architecture change [closed]Scrum。处理将引入架构更改的低优先级故事[关闭]
【发布时间】：2011-01-16 13:55:09
【问题描述】：

今天在大学里我们有一个 Scrum 练习练习（模拟创建软件解决方案的整个过程），我想出了一个不太理解的问题。

假设我们已经定义了我们的故事并给它们一个适当的优先级。还有一个没有什么优先级的故事……也许会在最后的冲刺中完成。

问题是，如果这个故事给我们的解决方案设计带来了巨大的架构变化怎么办？例如，对于独立应用程序，您将不得不采用客户端-服务器架构，仅因为这个故事。

在我看来：以某种方式标记哪些故事肯定会完成（在某个特定的时间），哪些故事很重要，但何时不重要，这不是很自然的事情，所以团队将他们牢记在心，并在设计他的解决方案时做出更好的决策。或者你是如何处理这个问题的？如果有问题。

提前致谢！请原谅我可能很蹩脚的问题。

【问题讨论】：

我从您的回答中了解到，我们的故事优先级错误。我的印象是优先级是主要针对客户需求的功能，但看起来我错了。感谢您的帮助！
优先级 IS 主要是产品所有者对产品成功的重要性概念的功能。如果产品负责人认为客户端服务器架构不是那么重要，那么它不是。如果它是必须的，那么产品所有者就错了。如果他们认为技术债务不够重要，可以先做，你就不必担心技术债务。
我投票结束这个问题作为题外话，因为这个问题更多的是关于发展规划和项目管理，而不是一个特定的编程问题。

标签： project-management agile scrum development-process

【解决方案1】：

虽然优先级主要取决于客户的愿望，但情况并非完全如此。可能有一些技术方面是团队确定必须更早完成的项目。例如，选择 ORM 可能对客户来说意义不大，但从团队的角度来看，它可能是一个重要的设计决策。

在我目前涉及 CMS 的项目中，我们曾多次出现这些问题，其中必须及早解决国际化等问题，但这不一定是明智之举，因为后来会有一些变化，例如引入另一家公司的软件处理一些可能会影响我们的某些代码的翻译。

编辑：The Technical Debt Quadrant 也可能有助于调查此类风险，以了解如果最终故意受到债务的重创，您可能会遇到什么。

【讨论】：

【解决方案2】：

问题是，如果这个故事给我们的解决方案带来了巨大的架构变化怎么办？例如，从独立应用程序中，您将不得不转到客户端-服务器架构，仅因为这个故事。

我不认为你的例子是现实的，这样的功能必须以某种方式成为产品愿景的一部分，你不能在最后一个不太重要的故事中发现这样的变化，必须在之前的某个时候考虑到最后的冲刺和最后的故事。换句话说，我同意@fuzzy 和@Eric 的观点：

如果故事不重要且有风险，则很可能永远不会实施。
如果故事很重要并且有风险，那么它很可能不是那么低优先级（即错误的优先级）。

【讨论】：

这种事情在现实世界的项目中时常发生。拿一些 MMO 服务器软件，或者 Twitter 或 Facebook 之类的东西。他们不得不在生命后期进行重大的可扩展性设计，这非常昂贵。
@Zan Lynx：可扩展性更改是一个不好的例子。这只是降低风险的练习，而不是功能要求。如果你计划大规模，你就会冒险：你花了很多钱希望你的产品会被大量使用。也许不是，钱被浪费了。如果你不为巨大的技能做计划，那同样是有风险的——你不会花很多钱，并希望你能预见到增长。如果你不这样做，你就会遭受“成长的痛苦”，这可能会限制你的产品的使用。但这一切都是不可预见的。一个不好的例子。
@S.Lott：我认为我的示例直接解决了 Pascal 的答案。帕斯卡认为这个例子不现实。我认为是，出于你给出的原因。大的可扩展性更改既是大的架构更改和低优先级的故事。
@Zan 首先，我不认为 Twitter 或 Facebook 是“经典”的商业案例。其次，我认为可扩展性无法与 OP 的示例相媲美（缩放与完全不同的范例）。第三，我不是说架构不进化，我是说像OP提到的那样的功能需求不能在最后一个sprint的最后一个故事中发现（如果 OP 知道它会发生，“客户端-服务器”应该是愿景的一部分）。
是的，我想我明白了。无论客户优先考虑某些故事，如果它们对解决方案的设计似乎很重要，我都应该牢记它们。

【解决方案3】：

这似乎是一个Last Responsible Moment 问题。

如果参与的每个人都肯定这是一项要求，并且会影响架构，那么将其置于最后一个 sprint 是不明智的。

更可能的情况是它可能是必需的。如果您调整您的设计以尽早适应它，那么您将通过多个冲刺来维持这种复杂性，以支持可能永远不会添加的功能。（业务需求变化。）

通过灵活、解耦的设计（例如通过TDD 演变而来的设计），可以保持随时间变化的成本相对平稳。

【讨论】：

感谢这篇有趣的文章

【解决方案4】：

因为你说：

在最后的 sprint 中完成，也许。

我倾向于同意毛茸茸的棒棒糖（以及我的 +1）。

但是，如果您知道必须完成某些事情，但它被放置在最后，如果它可能会对架构产生重大影响，那么它只是在错误的位置。

您可以将任务拆分为分析和实施，尽早进行（影响）分析以确定是否真的会产生架构影响，然后根据分析结果适当安排实施。

【讨论】：

【解决方案5】：

如果它必须完成并且涉及到大量的架构更改，那么它可能不应该是低优先级。

我唯一能看到它应该被归类为低优先级的情况是，是否可以完全放弃它，或者推迟它是否可以接受，即使它会在路上花费更多（比如产品需要完成并推出，以便以后有更多资金用于它）

【讨论】：

【解决方案6】：

在 $$$ 的现实世界中，优先级较低的事情可能永远不会完成。如果他们有一个高风险因素，这在现实世界中意味着更多的风险和低优先级，他们肯定不会完成。在您的情况下，如果您知道它肯定会完成，那么在您的设计会议中，只需确保您的设计能够轻松适应所需的更改，并且尽可能少地处理当前故事。

【讨论】：