问题标签 [scrum]

几年前，我参与了一个全新的项目，在那里我们进行了极限编程。我也看到很多人提到 Scrum 方法论。

有人能告诉我 Scrum 和 XP 之间的主要区别吗？

有谁知道是否有 TFS 插件可以以适合在 Scrum Board 上使用的格式打印我们的 sprint backlog 项目，而不是我们必须手动写出来？

在过去的两年里，我曾在两个使用敏捷/Scrum 方法的不同团队中工作，两个团队都渴望改进他们处理软件开发的方式。在第一个团队中，我们可以很容易地说服我们的产品负责人花时间进行内部工作，例如改进构建系统、设置更好的集成测试、制定更好的发布策略等。现在 PO 也愿意给我们时间，但是他更加推后，这是合理的，因为他也必须完成他的事情。

无论如何，我现在的问题是，其他团队如何处理这个问题？您是否创建了一个改进故事并在计划期间将其放在桌面上，或者您是否为此类事情保留“桶”时间？根据您的经验，说服产品负责人花时间进行改进有多难？毕竟，所有这些改进都会使团队受益，但不会直接或立即使产品所有者/企业受益。

我在一个 10 人的团队中，正在处理一个不太理想的产品所有者的大型遗留代码库。我们的积压工作非常糟糕，大型史诗经常打破我们的冲刺。该团队还为完成的定义而苦苦挣扎——一些成员虔诚地编写单元测试，而另一些成员则没有，有时取决于可用的时间。

所以，我看到了一些有趣的燃尽模式，我想知道其他人看到了哪些模式以及它们的含义。

模式一：

• 正面解释：“一切都好。”
• 负面解释：“好得令人难以置信。到底发生了什么？”

模式二：

• 正面解释：“这比我们想象的要容易得多，让我们引入更多故事。”
• 否定解释：??

模式3：

• 正面解释：“起初不确定这项工作，后来发现比我们想象的要容易。”
• 负面解释：“进展不够，我们停止编写单元测试以按时‘完成’。”

是否有人将 Scrum 和 Sprint 用于基础设施。

我正在为永远不会完成的 Sprint 的概念而苦苦挣扎，即网络增强项目。

还有关于如何将项目时间建立到产品待办列表的任何建议，以便我可以理智地检查资源在 sprint 中是否被过度使用。

这是最好的教程、书籍、软件和实践，可以在没有经验的情况下以敏捷的方式启动和管理一个基于 .net 的新开发项目。哪种方法更容易采用 XP|Scrum？

在我们的 Scrum 板上，任务从“待办事项”开始，转到“进行中”，当您完成任务后，它们会转到“待验证”，然后才进入“完成”。“待验证”列是当您完成一项任务时，其他人可以查看、测试和评论它。

事实证明，这有助于错误、更好的代码等。

对于有类似做法的人：在开发人员解决了评论/错误之后，您是否再次验证它，或者您是否假设问题已经解决并将任务移至“完成”？

我希望这很清楚，并想听听您的想法。

似乎 Scrum 和敏捷测试/断言在今年变得流行起来。例如，诺基亚测试 Scrum。我认为进行这样的测试根本不是一个好主意。你怎么看？

我们使用Trac作为我们的错误跟踪/开发/wiki 系统，我想知道是否有人有经验并使用了一些 Trac Agile/Scrum 插件或功能？你有什么推荐的吗？

或者将 Trac 票证复制为死树用户故事索引卡和手绘燃尽图会更好吗？

请注意，我在这里发现了一个类似的问题。尽管它专门针对 Scrum。他们推荐Agilo。有人试过Agilo吗？

我们有一个软件产品，可以根据客户的需求和更通用的路线图发展。

因为我们处于 SCRUM 项目环境中，所以经常会出现新功能进入产品的情况，然后我们面临以下选择：

• 在已经发布的分支中实现此功能（那么，实际上并不是拥有分支的重点）
• 建立一个新分支 - 但是我们每三周就有一个分支，它不再是可维护的了

不发布新功能不是一种选择，客户不想等待一个长期的里程碑计划来获得他们想要的功能，而且在客户端模块中移动功能并不总是可行的——有时我们需要改变产品的核心...

考虑到这些限制，有没有人对好的做法有任何反馈？