问题标签 [scrum]

虽然 Scrum 在理论上很容易，但在实践中却很难，我想听听你对完成的定义；即您的产品必须经过哪些关口（单元测试、代码覆盖率 > 80%、代码审查、负载测试、perf.test、功能测试等）才能将产品标记为“完成”

嗨，我是 Scrum 方法的新手，正在寻找一些帮助以适应环境，并想知道是否需要一个存储桶来跟踪开发人员和 QA 花费在部署、错误修复和重新测试上的时间。似乎它可能对图表产生重大影响。

我正在阅读 Marc 和 Laura Sewell （亚马逊链接）的《软件架构师的职业》一书，它让我想知道软件架构师是否是旧的非敏捷 BDUF 方法的一部分。

软件架构师在敏捷方法中是否有一席之地？我对 Scrum 特别感兴趣。

顺便说一句，我目前是一家大公司的 Unix 应用程序架构师。

干杯，

抢

我确信成为 Scrum Master 可以真正为我所遵循的流程增加价值，但是我相信我正在处理的应用程序领域的背景有助于更好地为项目完成计划和调度

我们在规划在线网络项目时有不同的步骤：

1) 信息架构

• 提供用户故事
• 提供线框

2) 设计

• 使用线框开发一个漂亮的设计

3) 发展

4) 测试

我知道敏捷工作需要专门的团队。但是在项目结束之前不可能有一个专门的 IA。因为这些项目是小型开发人员在不同的团队中工作。当您知道 50 个小项目和 20 个新项目使用不同的资源时，您如何规划资源？

是否有一个有用的工具可以帮助做到这一点？

这是另一个试图弄清楚 Scrum 在现实生活中如何/应该如何工作的问题。这是我遇到的一个典型场景：

注意：下面不使用术语“产品所有者”。那是因为真正的“产品负责人”——在这种情况下是产品经理——不会做出最终决定。DB Lead 在决定应用程序如何与 DB 交互时对许多事情有最终决定权。QA 对事物的外观/工作方式有自己的想法 - 并且他们的想法作为错误输入，并且通常（每个人）都希望被这样对待。

1. 产品经理写了这样一个故事“X 用户需要一个页面来做 Y”。
2. 在 sprint 计划会议上，故事被添加到 sprint backlog 中。
3. 一些可怜的开发人员抓住（或分配）了这个故事。
4. 开发人员询问产品经理“您希望页面是什么样的”。
5. 产品经理（如果有的话）说：“嗯，好吧，它需要收集 A、B 和 C。”
6. 开发人员开始对它应该是什么样子进行最佳猜测。
7. 开发人员尝试将页面连接到存储过程并询问数据库领导一些问题。DB 负责人说“Page 也需要 D 和 E。不应该需要 B”。
8. 开发人员进行更改并提交。
9. QA 说“我认为 E 令人困惑”。
10. 开发人员必须努力让 QA、DB 负责人和产品经理就最终页面的内容达成一致。

我的理解（根据我们对 scrum 的学习方式）是开发人员有责任充实页面的需求。在我们的环境中，如上所示，这给开发人员带来了令人沮丧的体验，并且在等待获得所有权力以就需求做出统一决定时浪费了大量时间。

有时可能需要数小时才能确定 2 小时任务的要求！与 1 人相处已经够难的了 - 3 人就更难了！

我知道这是反 Scrum，但在我看来，产品经理、数据库主管和 QA 团队应该在计划会议之前开会，并讨论要添加到 sprint 的任务的细节。（开发人员很少考虑任何输入，当我们在会议中尝试这样做时，可能需要一整天 - 不是开玩笑 - 才能为积压中的所有项目列出所有细节。）

有没有人处理过这个？有什么建议么？我不想啰嗦太久，所以如果您需要更多详细信息，请告诉我。

谢谢！

我敢肯定，我们所有人都不得不在某个时间点与远程办公人员打交道，而我现在面临的情况是，我的新项目将有一个“核心”团队，其中包括办公室工作人员和一些异地远程办公人员。不想重复过去的错误，我真的很想知道人们过去尝试过哪些方法来有效地将远程办公人员整合到敏捷流程中，即 Scrum。

我的第一个担心是远程办公人员将是第一个打破“每日 Scrum”例行程序的人。而且，正如人性经常发生的那样，一旦它被打破，就很难恢复并使人们重回正轨。Scrum 建议对错过或迟到每日 Scrum 的人实施小而有趣的“惩罚”，例如向一个罐子捐赠几美元，该罐子以后将用于为最终项目聚会购买一箱啤酒或其他东西。这显然是难以在线执行的事情。

远程办公的另一个大问题是“眼不见心不烦”的问题。除了使用网络摄像头/Skype/电话会议之外，人们还有哪些其他技巧可以让团队尽可能紧密地联系在一起？

另外，如何与来自不同时区的远程办公人员打交道？目前，我们很幸运没有遇到这个问题，但这绝对是未来某个时候的可能性。其他团队是如何处理这个问题的？

我们一直在尝试 Scrum，但现在正在尝试将其形式化为我们自己的敏捷应用程序开发版本。以下是我们当前流程的工作方式。就目前而言，它有两个主要缺点。想了解您是否有类似的方法，以及社区是否对我们目前遇到的障碍有任何实用技巧。

• Scrum 团队 = 4 名开发人员、2 名 QA、1 名技术作家、1 名 PO（PM）、1 名 Scrum Master（Engg Dir）
• 发布 = 3 个 Sprint
• 冲刺 = 2 周

PO 和客户创建用户故事和相关验收标准的产品积压。
每次迭代开始时的 1 周 Sprint 计划

• 第 1 天# 估算 Sprint 积压并就优先级达成一致
• 第 2-5 天# Scrum 团队讨论故事并处理 Sprint 待办事项中每个故事的详细信息（获取故事的详细信息、流程（如果有）、确定要应用的 UE 指南、UI 项目/字段/小部件的详细信息及其如果需要任何特定的行为，了解验收标准并创建测试）
• 2 周 Sprint，每天 15 分钟 Scrum
• 重复 3 周周期

我们在这方面遇到的两个主要缺点是：

1. 在春季计划周中讨论的细节没有被有效地捕捉并在 wiki 上得到记录。由于在 Scrum 中捕获此类细节没有标准格式，因此在日常 Scrum 中经常浪费时间，或者需要后续会议来进一步了解故事细节。在 sprint 计划中为功能相当复杂的产品捕获故事细节的最佳方法是什么？大多数问题似乎都与 UI 有关，开发人员无法在没有详细模拟的情况下决定如何布局屏幕/字段。
2. 当团队处于 sprint 周期时，您如何预测来自客户的关键漏洞。目前，开发人员必须被拉出来支持这些突然出现的红色帐户问题，从而扰乱了冲刺。

关于我们如何改进这一点的任何意见？

我不喜欢重复努力。然而，我确实发现在物理卡片墙和在线“计算器”（Excel、一些 scrum 工具）或在线卡片墙（例如 Mingle）上跟踪敏捷迭代进度是有好处的。

我发现团队空间中的实体卡片墙提供了与卡片状态的内在联系……当你完成某件事时物理移动卡片提供了一种在线无法复制的满足感。我能感觉到这张卡片……人们可以看到我走到墙上移动一些东西。

在线工具提供了远程共享和计算进度的强大功能（例如，在 Mingle 中，您可以使用内置工具从真实数据中自动计算燃耗或燃耗，从而节省大量手动执行这些操作的管理时间）。

我很好奇敏捷从业者是否像我一样维护两个跟踪媒体，你如何向那些说“我可以在网上做......为什么我想在卡片墙上做”的人展示物理墙的好处反而？”。

我在一家设计机构的技术部门工作。我们使用 XP 来管理我们部门的软件开发。我被要求做一个简短的介绍，描述 Scrum 以及它是否适合在更广泛的背景下管理客户项目工作。

Scrum 将应用于包含图形设计师、信息架构师、内容编辑、用户体验工程师、网页设计师和软件开发人员的跨职能团队。

Scrum 能为这种团队带来什么好处？