我有两个关于Scrum的相关问题。
我们公司正在努力实施它，并确定我们正在跳过篮球。
这两个问题都是关于“完成意味着完成！”
1）为任务/事件定义“完成”非常容易 - 明确测试验收标准 - 完全独立 - 最后由测试人员测试
对于以下任务应该怎么做： - 架构设计 - 重构 - 一些实用程序类开发
它的主要问题是，它几乎完全是内部实体 并且没有办法从外面检查/测试它。
作为示例功能实现是一种二进制 - 它已经完成（和 传递所有测试用例）或者没有完成（不要通过一些测试用例）。
最让我头疼的是要求其他开发者进行审核 那个任务。但是，它的任何方式都无法提供明确的方法来确定 完全没有完成。
那么，问题是你如何为这些内部任务定义“完成”？
2）调试/错误修正任务
我知道敏捷方法不建议执行大任务。至少 如果任务很大，则应将其划分为较小的任务。
假设我们有一些相当大的问题 - 一些大模块重新设计（到 用新的替换新的过时架构。当然，这项任务是分开的 在几十个小任务上。但是，我知道最后我们会有 相当长的调试/修复会话。
我知道这通常是瀑布模型的问题。不过，我想 它很难摆脱它（特别是对于相当大的变化）。
我应该为调试/修复/系统集成分配特殊任务 等等？
在这种情况下，如果我这样做，通常这个任务比较大 其他一切都很难将它分成较小的任务。
我不喜欢这种方式，因为这个巨大的整体任务。
还有另一种方式。我可以创建较小的任务（与bug相关）， 将它们放在积压中，确定优先级并将它们添加到最后的迭代中 当我知道什么是错误时，活动。
我不喜欢这种方式，因为在这种情况下，整个估计就会变成 假。我们估计任务，标记它随时要求完成。我们会的 用新估计打开bug的新任务。所以，我们最终会结束 实际时间=估计时间，这绝对不是好事。
你如何解决这个问题？
此致 维克多
答案 0 :(得分：4)
对于第一部分“架构设计 - 重构 - 一些实用程序类开发”这些从未“完成”，因为你随时执行它们。分片。
你想要做足够的架构来获得第一个版本。然后，对于下一个版本，再多一点架构。
重构是您如何找到实用程序类（您不打算创建实用程序类 - 您在重构期间发现它们）。
重构是您在发布之前根据需要分段进行的操作。或者作为一大块功能的一部分。或者在编写测试时遇到问题。或者当您无法通过测试并需要“调试”时。
在项目的整个生命周期中，这些东西的一小部分都是一遍又一遍地完成的。他们并不是真正的“候选人”，因此他们只是在获得发布的过程中完成的冲刺（或部分冲刺）。
答案 1 :(得分：0)
“我应该为调试/修复/系统集成等分配特殊任务吗？”
与使用瀑布式方法的方法不同，其中没有任何方法可行。
请记住，您正在逐步构建和测试。每个sprint都经过单独测试和调试。
当您找到候选版本时，您可能希望对该版本进行一些额外的测试。测试会导致错误发现，导致积压。通常这是高优先级的积压，需要在发布之前修复。
有时集成测试会发现错误，这些错误会成为低优先级的积压，在下一个版本发布之前不需要修复。
发布测试有多大？不是特别的。你已经测试了每个sprint ...... 不应该太多惊喜。
答案 2 :(得分：0)
我认为，如果内部活动对应用程序有益（scrum中的所有积压项目都应该有），那么就可以实现好处。例如，“设计架构”过于通用，无法确定活动的好处。 “用户故事A的设计架构”标识了您的活动范围。当您为故事A创建架构时，您已完成该任务。
同样应该在实现用户故事的背景下进行重构。 “重构客户类以启用多个电话号码以支持故事B”可以在Customer类支持多个电话号码时识别出来。
答案 3 :(得分：0)
第三个问题“一些大模块重新设计（用新的替换新的过时架构）。当然，这个任务分为几十个小任务。但是，我知道最后我们将有相当长的调试/修复“。
每个sprint都会创建可以发布的内容。也许它不会，但可能是。
所以，当你进行重大的重新设计时，你必须一次吃掉一小块大象。首先，看看最高价值 - 最重要的 - 对用户的最大回报，你可以做，完成和发布。
但是 - 你说 - 没有这么小的一块;每件作品都需要进行大规模的重新设计才能发布。
我不同意。我认为你可以创建一个概念架构 - 当你完成它将会是什么 - 但是不能立刻实现整个事物。相反，您可以创建临时接口，桥接器，胶水，连接器，这将完成一个sprint。
然后修改临时接口，桥接和粘合，以便完成下一个sprint。
是的，你已经添加了一些代码。但是，您还创建了可以测试和发布的sprint。完整的Sprint和任何一个可以作为候选版本。
答案 4 :(得分：0)
听起来你模糊了用户故事和任务的定义。简单地：
用户故事增加了价值。他们是 由产品所有者创建。
任务是为创建该任务而开展的活动 值。他们是由他们创造的 工程师的
您指出用户故事的关键部分是说它们必须具有明确的验收标准，它们是独立的，并且可以进行测试。
架构，设计，重构和实用程序类开发是任务。他们是完成用户故事所做的。每个开发商都可以为这些设置不同的标准，但在我们公司，至少有一个其他开发人员必须查看代码（结对编程，代码阅读，代码审查）。
如果您的用户故事是“重构类X”和“设计功能Y”，那么您的轨道错误。在编写代码之前可能需要重构X或设计Y，但这些可能是完成用户故事“创建新的登录小部件”所必需的任务。
答案 5 :(得分：0)
我们遇到了与“幕后”代码类似的问题。我的意思是“幕后”，没有明显或可测试的商业价值。
在这些情况下，我们决定将代码部分的开发人员定义为真正的“用户”。通过创建开发人员可以使用和测试的示例应用程序和文档，我们获得了一些“完成”的代码。
通常使用scrum，您可能会寻找一段使用一段代码来确定“已完成”的业务功能。
答案 6 :(得分：0)
对于重构等技术任务，您可以检查重构是否真的完成，例如调用X不再有任何f（）方法，或者没有更多的foobar（）函数。
对团队和团队内部也应该有信任。为什么要查看任务是否实际完成？你有没有遇到有人要求完成任务的情况而不是？
对于你的第二个问题，你应该首先努力将其分解为几个较小的故事（积压项目）。例如，如果您要重新构建系统，请查看新架构和旧架构是否可以共存时间将所有组件从一个组件移植到另一个组件。
如果真的不可能，那么这应该与其余的sprint backlog项目分开进行，并且 not integrated 在“完成”之前完成。如果sprint在项目的所有任务完成之前结束，那么您必须估计剩余的工作量并重新进行下一次迭代。
以下twenty ways to split a story可以帮助您制作几个较小的积压项目，这是推荐和最安全的方式。