关于Scrum的两个问题[关闭]

我有两个关于 Scrum 的相关问题。

我们公司正在努力实施它，并且我们确信我们正在跨越障碍。

这两个问题都是关于“完成意味着完成！”

1）对于正在/已经完成的任务定义“完成”真的很容易 - 明确的测试验收标准 - 完全独立 - 最后由测试人员进行测试

对于以下任务应该做什么： - 架构设计 - 重构 - 一些实用程序类的开发

它的主要问题是它几乎完全是内部实体 并且无法从外部检查/测试它。

例如，功能实现是一种二进制的 - 它已经完成（并且 通过所有测试用例）或者未完成（不通过某些测试用例）。

我想到的最好的事情就是请另一位开发人员进行审查 那个任务。然而，无论如何，它都没有提供明确的方法来确定 是否完全完成。

那么，问题是如何定义此类内部任务的“完成”？

2) 调试/错误修复任务

我知道敏捷方法不建议承担大任务。至少 如果任务大，则应将其划分为较小的任务。

假设我们有一些相当大的问题 - 一些大模块重新设计（以 用新的架构替换新的过时的架构）。当然，这个任务是分开的 处理几十个小任务。然而，我知道最后我们会拥有 相当长的调试/修复会话。

我知道这通常是瀑布模型的问题。不过，我认为 很难摆脱它（特别是对于相当大的变化）。

我应该为调试/修复/系统集成分配特殊任务吗 等等？

在这种情况下，如果我这样做，通常这个任务与 其他一切都很难将其划分为较小的任务。

我不喜欢这种方式，因为这是一个巨大的整体任务。

还有另一种方法。我可以创建更小的任务（与错误相关）， 将它们放入待办事项中，确定优先级并在最后将它们添加到迭代中 活动，当我知道有什么错误时。

我不喜欢这种方式，因为在这种情况下，整个估计将变成 伪造的。我们评估任务，随时将其标记为完成。我们会 使用新的估计打开错误的新任务。所以，我们最终会得到 实际时间=预估时间，这肯定不好。

你怎么解决这个问题？

问候， 胜利者

对于第一部分“架构设计 - 重构 - 一些实用程序类开发”，这些永远不会“完成”，因为你是边做边做的。分成碎片。

您想要做足够的架构来启动第一个版本。然后，对于下一个版本，需要更多的架构。

重构是您查找实用程序类的方式（您并不是要创建实用程序类——而是在重构过程中发现它们）。

重构是在发布之前根据需要分段进行的事情。或者作为一个大功能的一部分。或者当您在编写测试时遇到困难时。或者当您难以通过测试并需要“调试”时。

在项目的生命周期中，这些事情的一小部分会被一遍又一遍地完成。它们并不是真正的“发布候选者”，因此它们只是在发布过程中完成的冲刺（或冲刺的一部分）。