关于Scrum的两个问题

Question

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

我们公司正在努力实施它,并确定我们正在跳过篮球.

这两个问题都是关于"完成手段完成!"

1)很容易为任务定义"完成" - 明确的测试验收标准 - 完全独立 - 最后由测试人员测试

应该如何完成以下任务: - 架构设计 - 重构 - 一些实用程序类开发

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

作为示例,功能实现是一种二进制 - 它已完成(并通过所有测试用例)或未完成(不通过一些测试用例).

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

那么,问题是你如何为这些内部任务定义"完成"？

2)调试/错误修复任务

我知道敏捷方法不建议做大任务.至少如果任务很大,它应该分成较小的任务.

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

我知道这通常是瀑布模型的问题.但是,我认为很难摆脱它(特别是对于相当大的变化).

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

在这种情况下,如果我这样做,通常这个任务与其他一切相比都是巨大的,并且很难将它划分为较小的任务.

我不喜欢这种方式,因为这个庞大的巨型任务.

还有另一种方式.我可以创建较小的任务(与bug相关联),将它们放在积压中,确定优先级并在活动结束时将它们添加到迭代中,然后我将知道错误是什么.

我不喜欢这种方式,因为在这种情况下,整个估计将变成假的.我们估计任务,标记它随时要求完成.我们将使用新估计打开bug的新任务.因此,我们最终会得到实际时间=估计时间,这绝对不是好事.

你怎么解决这个问题？

此致,Victor

Answer 1

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

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

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

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

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