我有两个关于 Scrum 的相关问题。
我们公司正在努力实施它,并确保我们跳过了篮球。
这两个问题都是关于“完成意味着完成!”
1) 为已经/有的任务定义“完成”真的很容易 - 明确的测试验收标准 - 完全独立 - 最后由测试人员测试
应该如何处理以下任务: - 架构设计 - 重构 - 一些实用程序类开发
它的主要问题是它几乎完全是内部实体,无法从外部检查/测试它。
作为示例功能实现是一种二进制 - 它已完成(并通过所有测试用例)或未完成(不通过某些测试用例)。
我想到的最好的事情是请另一个开发人员审查该任务。但是,任何方式都没有提供明确的方法来确定它是否完全完成。
那么,问题是您如何为此类内部任务定义“完成”?
2) 调试/错误修复任务
我知道敏捷方法不建议执行大任务。至少如果任务很大,应该将其划分为较小的任务。
假设我们有一些相当大的问题 - 一些大的模块重新设计(用新的架构替换新的过时架构)。当然,这个任务分为几十个小任务。但是,我知道最后我们将进行相当长的调试/修复会话。
我知道这通常是瀑布模型的问题。但是,我认为很难摆脱它(尤其是对于相当大的变化)。
我应该为调试/修复/系统集成等分配特殊任务吗?
在这种情况下,如果我这样做,通常这个任务与其他所有任务相比都是巨大的,而且很难将它划分为较小的任务。
我不喜欢这种方式,因为这个庞大的单体任务。
还有另一种方法。我可以创建较小的任务(与错误相关),将它们放在积压中,确定优先级并将它们添加到活动结束时的迭代中,当我知道错误是什么时。
我不喜欢这种方式,因为在这种情况下,整个估计都会变成假的。我们估计任务,随时将其标记为完成。我们将使用新的估计打开新的错误任务。所以,我们最终会得到实际时间 = 估计时间,这绝对是不好的。
你怎么解决这个问题?
问候,维克多