Project management 敏捷-处理已经实现的特性不断变化的需求

在最近与我的客户的一次会议上，我们发现我们遗漏了用户故事的一个细节，这个细节之前已经实现了好几次迭代

新需求不仅是一个附加功能，而且改变了行为

最初的用户故事如下所示： “可以查看XYZ”

然而，新的请求是这样的： “可以查看XYZ，但如果是B，则XYZ必须看起来像ABC”

我应该认为这是一个bug还是一个新的用户故事，还是我应该重新打开旧的用户故事并编辑它来解释新的请求？

---

什么是“最佳实践”，每种方法的优缺点是什么？

好吧，既然这是一个新的需求，就把它当作一个新的特性请求。绝对不是虫子

编辑：由于不清楚是谁遗漏了您或客户的详细信息，您可以采取两种方式。如果你忘记了，那就是你的错误。如果客户忘记告知，则视情况而定。如果这是一个小补丁，你可以重新打开旧故事。如果有很多工作要做，那就做一个新的

另外，你怎么做真的重要吗？关键是要按照客户的要求实施，而不管您的内部术语如何

---

（来源：）

我会编辑旧故事来记录修改。否则，你可能会在新故事和旧故事之间产生矛盾

如果客户改变主意，这很难被视为缺陷（或bug）

---

实事求是：评估、计划并实施

一个Bug，一个新用户故事，重新打开旧故事。。。这真的很重要吗？在任何情况下，您的客户都要求提供当前未实现的功能。所以，只要你能估计它的大小，只要他能确定它的优先顺序，你如何称呼你捕获需求的方式其实并不重要

---

因此，除非您必须处理特定的合同约束，否则只需选择一个解决方案，估计其规模，并让客户对其进行优先级排序（就我个人而言，我会创建一个新的用户故事）。

我认为这应该算作旧故事。您的团队应该报告由于这些不断变化的需求而导致的吞吐量（速度）降低，特别是在原始功能尚未发布的情况下

：）好的，但是我应该把它变成一个新的用户故事吗？谢谢，非常好的解释！这样，如果我忘记了功能（->我这边缺少描述），或者如果我的客户喜欢忘记告诉我他们想要什么，我也可以跟踪：-）我将在下一个24小时内标记正确答案问题是：跟踪是否有价值？如果没有，那就是浪费。是的，确实如此，我学会了如何处理他们，何时提出正确的问题等等：-）好吧，他们没有改变主意，他们只是忘了告诉我（见上文，我编辑了问题以澄清这一点）好的，谢谢你的澄清。但我坚持要记录它，特别是因为你似乎以电子方式维护这些故事（重新打开并编辑）。否则，你的故事之间可能会有矛盾。谁在乎一个开放的故事与一个完成/结束的故事是否有矛盾？记录这一矛盾纯粹是“遮掩你的屁股”，这是在以前的浪费基础上增加更多的浪费。对我来说，这听起来并不是真正的精益/敏捷。在一个纯粹的敏捷环境中，这是正确的。但我们不知道这里的上下文——似乎这些故事不是保存在索引卡上，而是保存在电子文档中。如果以任何方式使用本文档，最好更新最初的故事。它是关于“最佳实践”的，即每种方法的优缺点（添加到问题中），感谢您的想法最佳实践是满足客户、欢迎更改、交付可工作的软件，等：）如果你做了重大的用户故事修改，你将失去可追踪性。特别是如果“新”用户故事无法实际实现（低优先级、重写等），而旧的实现仍然会存在。