agile - 关于 Scrum 的两个问题

Question

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

我们公司正在努力实施它，并确保我们跳过了篮球。

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

1) 为已经/有的任务定义“完成”真的很容易 - 明确的测试验收标准 - 完全独立 - 最后由测试人员测试

应该如何处理以下任务： - 架构设计 - 重构 - 一些实用程序类开发

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

作为示例功能实现是一种二进制 - 它已完成（并通过所有测试用例）或未完成（不通过某些测试用例）。

我想到的最好的事情是请另一个开发人员审查该任务。但是，任何方式都没有提供明确的方法来确定它是否完全完成。

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

2) 调试/错误修复任务

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

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

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

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

在这种情况下，如果我这样做，通常这个任务与其他所有任务相比都是巨大的，而且很难将它划分为较小的任务。

我不喜欢这种方式，因为这个庞大的单体任务。

还有另一种方法。我可以创建较小的任务（与错误相关），将它们放在积压中，确定优先级并将它们添加到活动结束时的迭代中，当我知道错误是什么时。

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

你怎么解决这个问题？

问候，维克多

Answer 1

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

您想要做的架构刚好足以让第一个版本继续运行。然后，对于下一个版本，更多的架构。

重构是您找到实用程序类的方式（您并不打算创建实用程序类——您在重构期间发现它们）。

重构是您在发布之前根据需要分块执行的操作。或者作为一大块功能的一部分。或者当您在编写测试时遇到问题。或者当您无法通过测试并需要“调试”时。

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

Answer 2

听起来您正在模糊用户故事和任务的定义。简单地：

• 用户故事增加了价值。它们是由产品所有者创建的。

• 任务是为创造价值而进行的活动。它们是由工程师创建的。

你指出用户故事的关键部分必须有明确的接受标准，它们是独立的，并且可以测试。

架构、设计、重构和实用程序类开发都是任务。它们是为完成用户故事所做的工作。每个开发商店都可以为这些设置不同的标准，但在我们公司，至少有其他开发人员必须查看过代码（结对编程、代码阅读、代码审查）。

如果您有“重构类 X”和“设计功能 Y”的用户故事，那么您就走错了路。在编写代码之前可能需要重构 X 或设计 Y，但这些可能是完成用户故事“创建新登录小部件”所必需的任务。

Answer 3

我们在“幕后”代码中遇到了类似的问题。我所说的“幕后”是指没有明显或可测试的商业价值。

在这些情况下，我们决定将那部分代码的开发人员定义为真正的“用户”。通过创建开发人员可以使用和测试的示例应用程序和文档，我们有一些“完成”的代码。

但是，通常使用 scrum，您会寻找一个使用一段代码来确定“完成”的业务功能。

Answer 4

第三个问题“一些大模块重新设计（用新的架构替换新的过时架构）。当然，这个任务分为几十个小任务。但是，我知道最后我们会有相当长的调试/修复会话。”

每个 sprint 都会创造一些可以发布的东西。也许不会，但可能会。

因此，当您进行重大重新设计时，您必须一次吃一小块大象。首先，看看你可以做、完成和发布的最高价值——最重要的——对用户的最大回报。

但是——你说——没有这么小的一块；在发布任何东西之前，每件作品都需要进行大规模的重新设计。

我不同意。我认为你可以创建一个概念架构——当你完成时它会是什么——但不能一次实现整个事情。相反，您创建临时接口、桥梁、胶水、连接器来完成一个 sprint。

然后修改临时接口、桥接和粘合，以便完成下一个 sprint。

是的，您已经添加了一些代码。但是，您还创建了可以测试和发布的 sprint。完整的 Sprint，任何一个都可以成为候选版本。

Answer 5

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

与您使用瀑布方法所做的方式不同，但实际上没有任何效果。

请记住，您正在逐步构建和测试。每个 sprint 都单独进行测试和调试。

当您获得一个候选版本时，您可能希望对该版本进行一些额外的测试。测试会导致错误发现，从而导致积压。通常这是需要在发布之前修复的高优先级积压工作。

有时集成测试会发现在下一个版本之前不需要修复的低优先级积压问题。

发布测试有多大？不是特别的。您已经测试了每个 sprint...不应该有太多的惊喜。

Answer 6

我会争辩说，如果内部活动对应用程序有好处（scrum 中的所有积压项目都应该有），那么好处就实现了。例如，“设计架构”过于笼统，无法识别活动的好处。“用户故事 A 的设计架构”确定了您的活动范围。当您为故事 A 创建架构时，您就完成了该任务。

重构同样应该在实现用户故事的背景下进行。“重构客户类以启用多个电话号码以支持故事 B”是当客户类支持多个电话号码时可以识别为已完成的事情。

Answer 7

对于重构等技术任务，您可以检查重构是否真的完成，例如 call X 不再具有任何 f() 方法，或者不再具有 foobar() 函数。

对团队和团队内部也应该有信任。如果任务真的完成了，为什么要复查？您是否遇到过有人声称某项任务已完成但未完成的情况？

---

对于您的第二个问题，您应该首先真正努力将其分解为几个较小的故事（积压项目）。例如，如果您正在重新构建系统，请查看新旧架构是否可以共存，以便将所有组件从一个移植到另一个。

如果这真的不可能，那么这应该与其余的 sprint backlog 项目分开完成，而不是在“完成”之前集成。如果 sprint 在完成该项目的所有任务之前结束，那么您必须估计剩余的工作量并为下一次迭代重新计划它。

这里有20 种拆分故事的方法，可以帮助处理几个较小的待办事项，这确实是推荐和最安全的方法。