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

我们公司正在尝试实施它，并确保我们正在超越目标。

这两个问题都与"完成意味着完成！"有关。

1)为/已执行的任务定义"完成"确实很容易
明确的测试接受标准
完全独立
最后由测试人员测试

应该执行哪些任务，例如：
架构设计
重构
一些实用程序类的开发

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

作为示例，功能实现是二进制形式，它已经完成了(并且
通过所有测试用例)或者未完成(不要通过某些测试用例)。

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

因此，问题是如何为此类内部任务定义"完成"？

2)调试/错误修复任务

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

假设我们有一些很大的问题，需要对大型模块进行重新设计(
用新的替换过时的体系结构)。当然，这个任务是分裂的
处理数十个小任务。但是，我知道最后我们将有
相当长的调试/修复会话。

我知道通常是瀑布模型的问题。但是，我认为
很难摆脱它(特别是对于很大的更改)。

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

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

由于这项庞大的任务，我不喜欢这样。

还有另一种方式。我可以创建较小的任务(与错误相关)，
将它们放在待办事项列表中，确定优先级，最后将其添加到迭代中
活动时，我会知道是什么错误。

我不喜欢这种方式，因为在这种情况下，整个估算将变成
伪造的。我们估算任务，随时将其标记为完成。而且我们会

使用新的估算值打开新的错误任务。因此，我们最终会得到
实际时间=估计时间，这绝对不好。

你怎么解决这个问题？

解决方案

问候，
胜利者

对于第一部分"架构设计重构一些实用程序类的开发"，它们永远都不会"完成"，因为我们可以随时进行操作。在碎片。

我们只需要做足够的架构就可以发布第一个版本。然后，在下一个发行版中，将增加一些体系结构。

重构是找到实用程序类的方式(我们并未着手创建实用程序类，而是在重构过程中发现它们)。

重构是我们在发布之前根据需要分批进行的工作。或者作为重要功能的一部分。或者在编写测试时遇到困难时。或者，当我们无法通过测试并需要"调试"时。

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

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

与采用瀑布方法的方法不同，实际上没有任何效果。

请记住，我们正在逐步构建和测试。每个sprint均经过单独测试和调试。

当我们找到候选发行版时，我们可能需要对该发行版进行一些其他测试。测试导致错误发现，从而导致积压。通常，这是高优先级的积压，需要在发布之前进行修复。

有时集成测试会发现一些漏洞，这些漏洞已成为低优先级的待办事项，无需在下一个版本之前进行修复。

这个发布测试有多大？不是特别的。我们已经测试了每个冲刺...应该不会有太多的惊喜。

我认为，如果内部活动对应用程序有好处(scrum中所有积压项目都应具有)，那么就可以实现好处。例如，"设计体系结构"太笼统而无法识别活动的好处。 "用户案例A的设计体系结构"确定了活动范围。为故事A创建架构后，该任务就完成了。

重构同样应该在实现用户故事的背景下进行。当客户类别支持多个电话号码时，"重构客户类别以使多个电话号码能够支持故事B"是可以确定的。

第三个问题是"一些大模块的重新设计(用新的过时的体系结构替换新的过时的体系结构。)当然，此任务分为数十个小任务。但是，我知道最后我们将进行相当长的调试/修复。"

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

因此，当我们进行重大重新设计时，我们必须一次只吃一小块大象。首先，查看最高的价值-最重要的-最大的回报给我们可以做，做得到和释放的用户。

但是-你说-没有那么小的一块；每件作品都需要进行大规模的重新设计，然后才能发布。

我不同意。我认为我们可以创建一个概念性的体系结构-完成后将会是什么-但不能一次实现整个过程。相反，我们将创建临时接口，网桥，粘合，连接器，以完成一次冲刺。

然后，我们修改临时接口，桥接和粘合，以便完成下一个冲刺。

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

• 用户故事增加了价值。它们是由产品所有者创建的。
• 任务是为创造价值而开展的活动。它们是由工程师创建的。

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

我们说出用户故事的关键部分必须具有明确的接受标准，它们是独立的，并且可以进行测试，从而钉牢了它们。

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

如果用户案例是"重构类X"和"设计要素Y"，那么我们走错了路。在编写代码之前，可能必须重构X或者设计Y，但是这些可能是完成用户故事"创建新的登录小部件"所必需的任务。

我们使用"幕后"代码遇到了类似的问题。我的意思是"幕后"，没有明显或者可检验的商业价值。

在那种情况下，我们决定将那部分代码的开发人员定义为真正的"用户"。通过创建供开发人员使用和测试的示例应用程序和文档，我们获得了一些"完成"的代码。

通常，尽管使用Scrum，我们会寻找一种使用一段代码来确定"完成"的业务功能。

对于重构等技术任务，我们可以检查重构是否确实完成，例如调用X不再具有任何f()方法，或者不再具有foobar()函数。

对团队和团队内部也应该有信任感。我们为什么要查看任务是否实际完成？我们是否遇到有人声称某项任务已完成但不是这样的情况？

对于第二个问题，我们应该首先真正地将其分解为几个较小的故事(待办事项)。例如，如果我们要重新架构系统，请查看新架构和旧架构是否可以共存时间将所有组件从一个移植到另一个。

如果确实不可能做到这一点，则应与其余的sprint待办事项分开进行，并且在"完成"之前不进行整合。如果sprint在项目的所有任务完成之前结束，则我们必须估算剩余的工作量并为下一次迭代重新计划。

段落数量不匹配