对于Scrum来说，一种工具或一套工具更好吗？

Question

G‘’day，

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

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

我看过"最佳Scrum工具“这个问题，大多数人似乎都建议：

1. 一套低科技解决方案，如白板、贴子、索引卡等，或
2. 一个单一的工具，试图满足尽可能多的过程，如Agilo，Mingle，ScrumWorks，目标过程等。

我们的团队目前正在评估几种不同的Scrum工具。然而，我们正在考虑选择一个单一的单块工具，例如Agilo。

所有的“一站式”解决方案都有其优点和缺点，严重的企业级解决方案是最好的选择。但都有缺点。

在阅读了SmartBear上的论文“SmartBear”之后，我开始怀疑我们是否试图在“最佳匹配”的基础上强制采用一个工具。

我想你可以拿几件Scrum开发过程中的参考制品，比如说

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

那么，如果我们把它作为所使用的工具的公共参考点，那么我们就能够使用一组工具来处理Scrum过程的不同方面，而不是尝试强制一个单一工具的组合，这有点像强迫一个方形钉钉进入圆孔。

通过这种方式，只要您已经同意了您的公共参考点，您就可以使用几个工具，每个工具都比单块工具套件中的单个组件能够更好地执行它们的角色。

这是否一个更明智的方法？

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

干杯,

Answer 1

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

说明:低科技工具的主要好处是迫使人们从椅子上下来，走动，交谈，互动，并感觉自己参与了团队的进程。然而，我个人的经验是，收养取决于团队成员的确切组成和态度。如果团队作为一个整体不喜欢在帖子上走动/达成一致意见，就不要继续，尝试其他的事情。虽然我经常看到“卡住”的团队表现出这种阻力。最后，你会得到一个彩色的scrum板，上面有帖子--只有scrum的主人才会关心它。

高科技的工具是首选的西装/管理层，主要是因为他们可以按几个按钮，并有现成的报告。另一方面是庞大的/定期的数据输入，以保持它的同步。现在，使用敏捷项目管理工具，进度(或缺乏进度)变得更加明显(早期)，因此我将在未来更多地押注于此。如果您的管理层已经选择了一个“组织范围的标准”，那么您就会被它困住。

目前，我正在试验一个共享的电子表格，它有这个sprint的故事/任务列表，再加上计算的烧毁。这张纸是在scrums期间投射到墙上的+如果有人想要查看的话，就把它放到网络共享上。更新是由SM在日常scrums中完成的。

Answer 2

就我个人而言，我可以引用目标过程，http://www.targetprocess.com/

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

Answer 3

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

如果没有，那么我建议你可能还不知道你需要什么。SCRUM可以先使用白板或电子表格完成，如果您认为它很有价值，可以转到工具上。