一个工具还是一套工具更适合Scrum？

Question

天儿真好，

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

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

我看过SO问题“Best Scrum tools”，大多数人似乎也建议：

1. 一套低技术解决方案，例如白板，贴后，索引卡等，或
2. 一种单片工具，试图尽可能地满足该过程，例如Agilo，Mingle，ScrumWorks，Target Process等。

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

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

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

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

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

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

通过这种方式，假设您已经同意了您的共同参考点，您可以使用多个工具，每个工具都比单个工具套件中的单个组件更好地完成其角色。

这是一种更明智的做法吗？

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

欢呼声，

Answer 1

敏捷的答案就是“它取决于”。尝试一些东西，如果它适合你的团队，坚持其他适应/改变。

说明：建议使用低技术工具，以促使人们脱离椅子，移动，交谈和参与团队的进步。但我个人的经验是，采用取决于团队成员的确切构成和态度。如果整个团队不喜欢移动/同意发布它，请不要继续使用它;尝试别的。虽然我经常看到“卡住”的球队表现出这种阻力。你最终得到了一个多彩多姿的scrum board，它只有scrum master关心的帖子。

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

目前我正在尝试使用共享电子表格，该电子表格包含此sprint的故事/任务列表以及计算的burndowns。如果有人想要查看，则在scrums +放入网络共享时，此工作表将投影在墙上。更新是在SM的每日scrums期间完成的。

Answer 2

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

我只使用这个工具就学到了很多SCRUM。

Answer 3

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

如果没有，那么我建议你可能还不知道你需要什么。 SCRUM可以通过白板或电子表格开始，如果您认为它有价值，可以转移到工具。

Answer 4

然后我们在适应中继续发声。我一直试图让我的团队进入一个敏捷的过程几年，我们正在变得越来越好。我们过去使用过一些企业级工具。主要来自Rational。他们似乎总是过分复杂应该是一个简单的程序。对我们来说，获得最简单的工具以满足需求似乎是有效的。很多白板，自发站起来为任何人请求会议。使用lunt（移动到Hudson）的CVS和自动构建脚本。 Jira为所有项目管理乐趣。我们确实能够提高生产力并降低成本。我们是一个小团队，全都并列。

Answer 5

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

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

Answer 6

我推荐JIRA Greenhopper，因为它有一个计划板，一个任务板和一个燃烧图表，似乎击中了所有SCRUM概念