关闭。这个问题不符合Stack Overflow guidelines .它目前不接受答案。
想改进这个问题？将问题更新为 on-topic对于堆栈溢出。
4年前关闭。
Improve this question
我有两个关于 Scrum 的相关问题。
我们公司正在努力实现它，并确保我们跳过了篮球。
这两个问题都是关于“完成意味着完成!”
1) 为已经/拥有的任务定义“完成”真的很容易
- 明确的测试验收标准
- 完全独立
- 最后由测试人员测试
应该如何处理以下任务:
- 架构设计
- 重构
- 一些实用程序类开发
它的主要问题是它几乎完全是内部实体
并且没有办法从外部检查/测试它。
作为示例功能实现是一种二进制 - 它已经完成(并且
通过所有测试用例)或未完成(不通过某些测试用例)。
我想到的最好的事情就是请另一位开发人员进行审查
那个任务。但是，任何方式都没有提供明确的方法来确定
是否完全完成。
那么，问题是您如何为此类内部任务定义“完成”？
2) 调试/错误修复任务
我知道敏捷方法不建议执行大任务。至少
如果任务很大，则应将其划分为较小的任务。
假设我们有一些相当大的问题 - 一些大模块重新设计(
用新的架构替换新的过时架构)。当然，这个任务是分开的
在几十个小任务上。但是，我知道最后我们会有
相当长的调试/修复 session 。
我知道这通常是瀑布模型的问题。不过，我认为
很难摆脱它(尤其是对于相当大的变化)。
我应该为调试/修复/系统集成分配特殊任务吗
等等？
在这种情况下，如果我这样做，通常这个任务与
其他所有内容，并且很难将其划分为较小的任务。
我不喜欢这种方式，因为这个庞大的单体任务。
还有另一种方法。我可以创建较小的任务(与错误相关)，
将它们放在积压中，确定优先级并将它们添加到最后的迭代中
事件的时候，我会知道什么是错误。
我不喜欢这种方式，因为在这种情况下，整个估计将变成
伪造的。我们估计任务，随时将其标记为完成。我们将
为具有新估计的错误打开新任务。所以，我们最终会得到
实际时间=估计时间，这肯定不好。
你怎么解决这个问题？
问候，
胜利者
最佳答案
对于第一部分“架构设计 - 重构 - 一些实用程序类的开发” 这些永远不会“完成”，因为您可以随时进行。成片。
您想要做的架构刚好足以让第一个版本继续运行。然后，对于下一个版本，更多的架构。
重构是您找到实用程序类的方式(您并不打算创建实用程序类——您是在重构过程中发现它们的)。
重构是您在发布之前根据需要分 block 执行的操作。或者作为一大块功能的一部分。或者当您在编写测试时遇到问题。或者当您无法通过测试并需要“调试”时。
这些事情的一小部分在项目的整个生命周期中一遍又一遍地完成。它们并不是真正的“发布候选者”，因此它们只是在发布过程中完成的 sprint(或 sprint 的一部分)。
关于agile - 关于 Scrum 的两个问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/150447/