问题标签 [scrum]

我们现在在几个项目中使用 Scrum 并取得了不同程度的成功，我现在有一个与文档相关的查询。

在 Scrum 中，您显然有产品待办事项（“应用程序从调出用户正在使用的最后一个文档开始。”）和 sprint 任务待办事项（“实施忘记密码屏幕”）。但是，在我看到的所有示例中，这两个项目在细节方面都相当高水平（被设计成贴合便利贴）。

那么，细节在哪里呢？假设客户对库存管理屏幕有一些非常具体的要求，或者有一个复杂的 API 需要在后端集成，这是在哪里记录的，如何以及谁捕获这些信息？它是否与积压工作分开，但以即时或其他方式填充？

编辑以提高清晰度

Scrum 建议您将开发拆分为多个 sprint。每个冲刺都是固定的持续时间。在每个 sprint 结束时，您都会询问客户是否应该发布该软件。如果他们说是，您将执行发布冲刺，在此期间您会​​连续执行所有您想做但成本太高的任务，例如外部用户测试、性能负载测试和签核、刻录 CD（如果相关） ，编写以用户为中心的文档等

在我当前的项目中，我们刚刚完成了我们的第一个发布冲刺。我们发现我们失去了 scrum 的很多优势，例如烧毁（因为很多事情都是在修复微小的调整或暂时从站点中删除安全性以便进行负载测试），一个明确的目标是要完成多少工作接下来完成等等。基本上，发布任务太接近消防，无法通过普通的 scrum 工具轻松跟踪。

在发布冲刺期间，其他人使用了哪些方法，您发现应该避免哪些陷阱？

引用维基百科：

Scrum 由 ScrumMaster 促进，他的主要工作是消除团队交付 sprint 目标能力的障碍。ScrumMaster 不是团队的领导者（因为他们是自组织的），而是充当团队与任何分散注意力的影响之间的缓冲。ScrumMaster 确保按预期使用 Scrum 流程。ScrumMaster 是规则的执行者。”

在此基础上工作，以及大多数企业一次运行 2-3 个项目的事实，SM 需要完成哪些实际工作任务来填补全职工作？或者，这不是一份全职工作，而且那个人还做其他事情，比如开发、销售等？

有没有 SM 有什么要分享的？

谁能给我一些关于如何阅读累积流程图的提示。我不确定它告诉我什么样的事情。

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

我们公司正在努力实施它，并确保我们跳过了篮球。

这两个问题都是关于“完成意味着完成！”

1) 为已经/有的任务定义“完成”真的很容易 - 明确的测试验收标准 - 完全独立 - 最后由测试人员测试

应该如何处理以下任务： - 架构设计 - 重构 - 一些实用程序类开发

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

作为示例功能实现是一种二进制 - 它已完成（并通过所有测试用例）或未完成（不通过某些测试用例）。

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

那么，问题是您如何为此类内部任务定义“完成”？

2) 调试/错误修复任务

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

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

我知道这通常是瀑布模型的问题。但是，我认为很难摆脱它（尤其是对于相当大的变化）。

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

在这种情况下，如果我这样做，通常这个任务与其他所有任务相比都是巨大的，而且很难将它划分为较小的任务。

我不喜欢这种方式，因为这个庞大的单体任务。

还有另一种方法。我可以创建较小的任务（与错误相关），将它们放在积压中，确定优先级并将它们添加到活动结束时的迭代中，当我知道错误是什么时。

我不喜欢这种方式，因为在这种情况下，整个估计都会变成假的。我们估计任务，随时将其标记为完成。我们将使用新的估计打开新的错误任务。所以，我们最终会得到实际时间 = 估计时间，这绝对是不好的。

你怎么解决这个问题？

问候，维克多

您使用什么软件来管理 Scrum 软件开发？

到目前为止，我们已经尝试过 Tackle 和 VersionOne（都是免费的），它们都很好，只是很难跟踪正在进行的工作。例如，如果我有一项我估计需要 8 小时才能完成的任务，我已经完成了 4 小时的工作，还剩 4 小时，该任务总是报告为还剩 8 小时，直到它被标记为完成，此时它下降到零。

我想使用一种工具，使我能够在每周结束时在团队 WIP 中进行准确的工作，并查看该工作对截止日期以及已完成的任务产生了多大的影响。

感谢您的输入！

显然我们使用 Scrum 开发方法。一般是这样的：

开发人员为了完成他们的任务而苦苦挣扎。通常，这些任务需要大部分 sprint 才能完成。QA 缠着 Dev 发布他们可以测试的东西，Dev 最终在 sprint 结束前一两天向 QA 抛出了一些错误的代码，剩下的时间用来修复 QA 发现的错误。QA 永远无法按时完成任务，sprint 很少能按时发布，Dev 和 QA 在 sprint 结束时的日子过得很痛苦。

当可发布的开发任务占据了 sprint 的大部分时间时，scrum 应该如何工作？

感谢大家参与讨论。由于这是一个非常开放的问题，似乎没有一个“答案”——下面有很多很好的建议。我将尝试总结我的一些“带回家”的观点并做出一些澄清。

（顺便说一句 - 这是放置这个的最佳位置还是我应该把它放在“答案”中？）

思考/行动的要点：

• 需要确保开发人员的任务尽可能小（细化）。
• Sprint 长度应根据平均任务长度适当调整（例如，1 周任务的 sprint 应至少为 4 周）
• 团队（包括 QA）需要努力提高估算的准确性。
• 考虑并行进行单独的 QA 冲刺，但如果这对团队最有效，则可以抵消
• 单元测试！

如今，Scrum 是相当流行的 dev.process 并且经常项目经理突然获得新头衔（Scrum Master）。然而，它不应该只是一个新的标题，而是新的习惯和新的范式。你的 Scrum master 有哪些坏习惯？

在规划新系统开发的最初阶段，遵循哪种开发模式似乎至关重要。我一直坚信经典瀑布（或混合瀑布/迭代原型）是大中型项目的最佳方法。似乎一旦项目达到一定规模，敏捷/XP/Scrum 范式就无法解决复杂的需求、大型团队、多个子系统之间的复杂性、文档需求、人员变动等，等等

这种敏捷方法在系统规模、团队规模、LOC 等方面的限制是什么？

我听说很多公司表现得好像他们很敏捷，但他们所做的唯一敏捷的事情就是 Scrum 流程。这足以被认为是敏捷的吗？单独使用 Scrum 似乎是一个糟糕的经理更频繁地召开更多会议的完美借口。我应该厌倦这样的公司吗？