并行团队和scrum/敏捷

Question

我的公司在过去几年里有了很大的发展。直到几年前，我们还可以和一个敏捷团队一起工作，一切都很顺利。现在我们有了多个团队，所有的工作都是敏捷的，事情并不像我们所希望的那样顺利。

心理的主要问题之一是如何在团队中组织工作方法。

• 如果每个团队都有自己的工作方式(保存进度的Excel表格的类型，计算能力的方法，.)这些团队似乎四分五裂，似乎在竞争，而不是合作(并行开发类似的代码)。
• 如果所有团队使用相同的方法和工作流程，那么我们又有两种选择：
  • 管理层的“‘Forcing”方法似乎不正确，因为管理层不清楚敏捷/scrum方法应该如何工作(只有实际的团队知道这一点)。
  • 让团队提出改进建议，并将其“强迫”给其他团队，可能会改善竞争，而不是合作(团队将拒绝使用该方法，因为它来自另一个团队)。

有没有人有过多个团队以敏捷/scrum方式协同工作的经验？如何在不让团队“互相指责”的情况下促进团队合作？

Answer 1

从您的描述中，我们还不清楚团队实际上是否在单独的项目上工作--我想是的。

在理想情况下，我认为这应该主要由团队自己决定，但他们得出的结论大致相同(即使用敏捷)。特别是，如果团队中的杰出成员以前曾在单个敏捷团队中一起工作，那么他们很自然地就会带来他们尝试并证明起作用的实践。

然而，每个新团队必然会遇到自己的、或多或少不同的情况和挑战，因此，随着时间的推移，他们将与其他团队开发自己的流程略有不同。这是很好的，在一定的限度内。为了使管理人员的生活更容易，最好是同意并坚持一些常见的向管理报告的方式。但是，由于敏捷并不是以报告为主，我不认为这会对任何团队造成巨大的限制。

现在，如果一个团队想出了一个过程改进，那么对其他团队来说，了解它确实是很有用的--只要它也能解决他们的一些问题。因此，IMO最好的方法是保持团队之间关于回顾和流程改进解决方案的沟通，通过一些指定的团队成员(每个团队一名成员--例如Scrum Master)在每次冲刺后定期会面，讨论他们遇到的问题、他们尝试过的解决方案以及结果。

因此，如果A组讲述了一个问题，那么B组可能已经为它找到了一个工作解决方案，可以立即应用。或者，如果A组有解决同样问题的想法，那么C组可能已经尝试过类似的想法，并且获得了有用的经验，可以与A组分享等等。关键是，任何团队都最感兴趣的是解决他们的具体问题，因此最好从这个角度着手知识共享:使解决方案适应具体问题，而不是试图使过程适应想象中的“解决方案”。开发团队抵制后一种方法是很正常的，但前者则不然。

Answer 2

保存进度的它自己的Excel表类型

那应该会在那里引起一些警报。投资于一些项目管理软件可能是值得的。亚特兰西岛的套房很不错，而且可能是最受欢迎的。FogCreek (堆栈交换的创建者)也有一些不错的工具。不同的项目以不同的方式运行是很自然的。这往往是为了最好。然而，集中你的任务和正确地跟踪你的进度是至关重要的。