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

StackOverflow https://stackoverflow.com/questions/1907690

  •  19-09-2019
  •  | 
  •  

题

你好，

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

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

我看过这个问题“最佳 Scrum 工具“大多数人似乎都推荐：

  1. 一套低技术含量的解决方案，例如白板、便利贴、索引卡等，或
  2. 一个试图尽可能满足流程的整体工具，例如Agelo、Mingle、ScrumWorks、目标流程等

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

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

读完论文后“同行代码审查：敏捷流程“在 SmartBear，我开始想知道我们是否试图在“最适合”的基础上强制采用一种工具。

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

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

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

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

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

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

干杯，

有帮助吗？

解决方案

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

解释：建议使用低技术工具的主要目的是迫使人们离开椅子、走动、交谈和互动并感受到参与团队的进步。然而，我个人的经验是，采用取决于团队成员的具体组成和态度。如果整个团队不喜欢四处走动/不同意便利贴，就不要继续；尝试别的东西。尽管我经常看到“陷入困境”的团队表现出这种抵制。你最终会得到一个彩色的 Scrum 板，上面有只有 Scrum Master 关心的便利贴。

高科技工具受到诉讼/管理层的青睐，主要是因为他们可以按几个按钮并准备好报告。另一方面是巨大/周期性的数据输入以保持同步。现在有了敏捷项目管理工具，进展（或缺乏进展）变得更加明显（早期），因此我未来会押注更多。如果您的管理层已经选择了“组织范围的标准”，那么您就只能坚持下去。

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

其他提示

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

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

你现在在做SCRUM吗？你已经做了很多次迭代了吗？

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

听起来你在改编方面比我们走得更远。几年来，我一直在努力让我的团队转向敏捷流程，而且我们在这方面做得越来越好。我们过去使用过一些企业级工具。主要来自理性。他们似乎总是使本应简单的程序过于复杂化。对于我们来说，找到最简单的工具来满足需求似乎是有效的。有很多白板，可以为任何需要的人举办自发的站立会议。CVS 和带有 lunt 的自动构建脚本（转移到 Hudson）。Jira 带来所有项目管理的乐趣。我们确实能够提高生产力并降低成本。我们是一个小团队，所有人都在同一位置。

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

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

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top