Scrum的.处理将引入架构变更的低优先级故事

今天在大学里,我们进行了Scrum练习(模拟了创建软件解决方案的整个过程),我想出了一个不太明白的问题.

假设我们已经定义了我们的故事,并给予他们适当的优先级.并且有一个很少有优先权的故事......也许会在最后一次冲刺中完成.

问题是,如果这个故事为我们的解决方案的设计引入了巨大的架构变化怎么办？例如,从独立应用程序,您将不得不采用客户端 - 服务器架构,因为这个故事.

在我的观点中:以某种方式标记某些故事(在某个特定的时刻),某些关键要完成的事情,但是它们并不重要的时候是不是很自然记住它们并做出更好的决策来设计他的解决方案.或者你是如何处理这个问题的？如果是问题.

提前致谢!请原谅我可能蹩脚的问题.

1> 小智..：

---

在现实世界中,$$$就行了,优先级低的东西可能永远不会完成.如果他们有一个高风险因素,在现实世界中意味着更多的风险和低优先级,他们将无法确定.在您的情况下,如果您知道它将确保完成,那么在您的设计会话中,只需确保您的设计能够轻松地在当前故事中尽可能轻松地适应所需的更改.

2> Eric J...：

---

因为你说:

也许是在最后一次冲刺中完成的.

我倾向于同意模糊的棒棒糖(以及我的+1).

但是,如果有一些你知道必须要做的事情,但是它已被置于最后,如果它可能具有重大的架构影响,那么它就处于错误的位置.

您可以将任务拆分为分析和实施,并尽早进行(影响)分析,以确定是否确实存在架构影响,然后根据分析结果对实施进行适当调度.

3> Pascal Thive..：

---

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

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

如果故事不重要且风险很大,那很可能永远不会实施.

如果故事很重要且风险很大,那么很可能没有那么低的优先级(即错误的优先级).

---

@Zan Lynx:可伸缩性变化是一个不好的例子.这只是风险缓解的练习,而不是功能要求.如果你计划大规模,你就冒了风险:你花了很多钱,希望你的产品会被大量使用.也许它不是,浪费了金钱.如果你没有计划巨大的技能,那就像风险一样 - 你不会花很多钱,希望你能预测增长.如果不这样做,您将遭受"成长的痛苦",这可能会限制您的产品的使用.但这一切都是不可预见的.一个糟糕的例子.

---

这种事情一直发生在现实世界的项目中.拿一些MMO服务器软件,或Twitter或Facebook之类的东西.他们不得不在生命的后期进行大规模的可扩展性设计,这些设计非常昂贵.