一个工具还是一套工具更适合 Scrum？ [关闭]答案

【问题标题】：Is One Tool or a Suite of Tools Better for Scrum? [closed]一个工具还是一套工具更适合 Scrum？ [关闭]
【发布时间】：2009-12-15 14:04:57
【问题描述】：

生日，

编辑：多年来，我们在多个不同规模的项目中都非常成功地使用了 Scrum。事实上，我们的团队使用经典的 Scrum 方法为 BBC 开发了成功的 iPlayer 项目。

在使用各种工具组合之后，一些高科技，一些低技术，在这些项目中，我们现在希望尝试采用合适的工具套件。我们的经理在某种程度上试图强制采用一套用于 Scrum 的工具。

我查看了 SO 问题“Best Scrum tools”，大多数人似乎都推荐：

一套低技术解决方案，例如白板、便利贴、索引卡等，或
一种尝试尽可能多地满足流程要求的整体工具，例如Agilo、Mingle、ScrumWorks、目标流程等。

我们的团队目前正在评估几种不同的 Scrum 工具。但是，我们正在考虑选择一个单一的整体工具，例如敏捷。

所有“一站式”解决方案都有其优点和缺点，而严肃的企业型解决方案是最合适的选择。但都有一些缺点。

在阅读了 SmartBear 上的“Peer Code Review: An Agile Process”论文后，我开始怀疑我们是否试图在“最合适”的基础上强制采用工具。

我认为你可以参考一些 Scrum 开发过程的参考资料，比如说

用户故事、史诗和主题，以及
必须使用知名 SCM 的代码库，例如SVN、Hg 等。

然后，如果我们将其作为所用工具的共同参考点，那么我们将能够使用一组工具来处理 Scrum 流程的不同方面，而不是尝试强制使用单个工具。有点像将方形钉子强行插入圆孔。

通过这种方式，只要您同意共同的参考点，您就可以使用多种工具，每一种工具都比单一工具套件中的单个组件更好地发挥作用。

这是更明智的做法吗？

我上面提到的两个参考点是否合适，或者它们是工具会合点的更好选择？

干杯，

【问题讨论】：

标签： scrum collaboration

【解决方案1】：

对此的敏捷答案是“视情况而定”。尝试一些东西，如果它对你的团队有用，坚持下去，适应/改变。

解释：推荐使用低技术工具的主要好处是迫使人们从椅子上下来、四处走动、进行交谈和互动并参与团队的进步。然而，我个人的经验是，采用取决于团队成员的确切组成和态度。如果整个团队不喜欢移动/同意便利贴，请不要继续使用；试试别的。尽管我经常看到“卡住”的团队表现出这种抵抗力。你最终会得到一个彩色的 Scrum 板，上面有只有 Scrum 管理员才关心的便利贴。

西装/管理层首选高科技工具，主要是因为他们可以按几个按钮并准备好报告。另一方面是巨大的/定期的数据输入以保持同步。现在使用敏捷项目管理工具，进展（或缺乏进展）更加明显（早期），因此我会在未来打赌更多。如果你的管理层已经选择了一个“组织范围的标准”，那么你就会坚持下去。

目前我正在尝试使用一个共享电子表格，其中包含此 sprint 的故事/任务列表以及计算的燃尽图。这张纸在 scrums 期间投影在墙上 + 如果有人想查看它，请放在网络共享上。更新由 SM 在每日例会期间完成。

【讨论】：

@Gishu，BBBIIIIIIIIGGG +1 关于西装喜欢高科技工具的观点，因为它们与报告香肠工厂捆绑在一起！很多很多的报道！伊皮！
@Gishu，我忘了补充一点，作为 Scrum 工具，我们几乎已经从 Excel 中挤出了所有的东西。我们有几个聪明的男孩，他们编写了大量代码来扩展 Excel 的 Scrum 能力。
@Rob：所以我的下一个问题是：缺少什么？您无法使用电子表格或您已经用尽的任何选项来做什么？

【解决方案2】：

我个人可以推荐目标进程，http://www.targetprocess.com/

通过使用这个工具，我学到了很多 SCRUM。

【讨论】：

@espenk，您是否发现该工具需要很长时间才能根据您的团队的喜好进行设置和配置？
@espenk 你没有学习 Scrum，你学习了目标流程（这是在学习新流程时不使用工具的第一大理由）。
Rob：不，在 IIS 服务器上安装非常容易。它带有一个安装程序。
Pascal：我明白你的意思，但是从使用 Excel 文档来完成未完成的任务的情况来看，这是一个非常酷的解决方案。我不喜欢仅仅阅读它们来学习新东西，我发现在实践中使用它要好得多。但我同意学习完美的 SCRUM 最好不要使用工具
帕斯卡是对的。从一个工具开始是不好的。 targetprocess.com/blog/2010/10/…

【解决方案3】：

你现在在做 SCRUM 吗？你做过很多次迭代吗？

如果没有，那么我建议您可能还不知道您需要什么。 SCRUM 可以从白板或电子表格开始，如果您认为它很有价值，则可以使用工具。

【讨论】：

@Matt，哎呀。添加了关于 Scrum 体验的编辑。 +1。顺便说一句，正如 Ken S. 所说，它的拼写是 Scrum，就像 Rugby 中的单词一样，而不是 SCRUM，它意味着一个首字母缩略词。 (-:
SCRUM 与 Scrum - 技术上是正确的，但由于某种原因，它在我看来仍然是错误的 - 无法告诉你为什么！ :-)
@Matt，TMT 的！太多“三字母缩写词”四处飘荡，这就是原因！ (-:

【解决方案4】：

你在改编中听起来比我们走得更远。几年来，我一直在尝试将我的团队转移到敏捷流程中，并且我们在这方面做得越来越好。我们过去使用过一些企业级工具。主要来自Rational。他们似乎总是把本应简单的程序过于复杂化。对我们来说，获得最简单的工具来满足需求似乎正在发挥作用。大量白板，为任何需要的人自发站立会议。 CVS 和带有 lunt 的自动构建脚本（移至 Hudson）。 Jira 为所有项目管理带来乐趣。我们确实能够提高生产力并降低成本。我们是一个小团队，大家都在同一个地方。

【讨论】：

@Mark，Rational 和它所有的 RUP 风格都是重量级的过程。正如 Ken Schwaber 所说，“Scrum 是一种理性的选择。” (-:
让重量级产品以敏捷的方式工作可能是个问题。但实际上没有理由不能将 RUP 过程中的短迭代称为敏捷。这就是说我们放弃了整个事情，因为它对我们不起作用。由于问题是关于 Scrum，你是对的。我更多地谈论的是我们的敏捷过程的旅程和工具，该过程现在更像是 Scrum。

【解决方案5】：

我们当前的 Scrum 工具有什么问题？

这是一个很好的问题，在这里可能不会问，因为管理层可能只是有钱可以花钱，他们想购买一些闪亮的大工具包，以表明他们关心团队并希望事情变得更好。并不是说想把钱花在一个问题上是一件坏事，但我们至少可以聪明地这样做吗？

【讨论】：

我所看到的是，“销售”发生在一个非常高的水平。一些“敏捷顾问/专家”公司将其出售给管理层，承诺通过精心排练的幻灯片来提高 nX 生产力 -演示。然后将工具推给开发人员。
当然，购买不是在开发人员的意见下完成的，他们可能会说这会好还是不会好，对吧？自组织团队可能会说：“嘿，我们需要一点帮助！”并听取他们的意见，而不是试图把东西塞进别人的喉咙里。

【解决方案6】：

我推荐 JIRA Greenhopper，因为它有一个计划板、一个任务板和一个燃尽图，似乎符合所有 SCRUM 概念

【讨论】：