团队规模与流程开销的关键点是什么？

Question

团队成长的哪个阶段必须大幅改变？一个孤独的编码器可以逃脱源控制和大脑。试图将大型预包装软件运送到本地和国际市场的团队必须更加合适。

如果您在“流程”中经历了一次大的转变：团队的流程是否已成功地与当前成员一起更改，或者团队本身是否主要由流程更改的时间取代？改变的重要方面是什么？有些不必要吗？

Answer 1

你会发现很难得到一个定量答案。这实际上取决于项目的“广泛”程度。如果有一个简单的子系统可供使用，任何超过1个人都会导致人们踩到别人的脚趾。如果您以某种方式拥有一个包含8个隔离子系统的项目，那么您可以让8个开发人员没有问题。更有可能的是，您将有几个不同程度相互依赖的子系统。哦，无论你使用什么过程，所有这一切都是正确的。

选择您想要使用的流程类型（螺旋，Scrum，瀑布，CMM等），以及您想要实现的流程的重量级是另一个问题，而且很难。这主要是因为人们试图采用在建筑施工，工厂工作或其他与软件无关的行业中的流程，并将其应用于软件开发。

在我看来，麦康奈尔写了关于软件过程的最佳书籍，尽管他的书本身都不是过程书本身。

Answer 2

如果记忆能正确地为我服务，那么任何超过五个人的事情都会让事情变得冒险。在此之后，团队之间的通信路径数量变得非常大。

（2人= 1路，3 = 3路，4 = 6路，5 = 10路等）。

我作为IT团队的最后三个地方经历了一次巨大的流程变革。是的，你会失去人，也许是一些更好的人。并不是说他们固执并试图坚持旧的方式，只是这样的改变会引起大量的压力。有最后期限可以达到，并且需要满足质量要求。人们会对他们应该做什么过程感到困惑，许多人会回到“旧方式”。 （我承认，我也对此感到内疚。）

成功的关键是慢慢地，小步骤。人们需要花时间了解流程为何变化以及流程如何受益。这是巨大的，如果你没有花时间去做这件事，那就不会成功，而关键人物最终会放弃引发动荡。

绝对记住的一件事是，最终一些营业额是好的。它带来了新的想法和具有不同（有时更好）技能的人。你不应该试图迅速改变对人的改变，但它们也不应成为障碍。如果他们不同意正在发生的事情，他们应该尝试与人们一起制定流程或离开。我在第一份工作中学到的真正开眼界之一是，实际上每个人都可以更换。有人最终能够介入统治。

Answer 3

根据我的经验，这种转变恰好发生在您需要管理的那一刻。如果没有一些总体协调功能，很难获得8位以上的开发人员，无论是团队领导，任务分离还是老式管理。我亲眼目睹的现实是，即使是最优秀，最有才华，最受欢迎的开发人员，当你同时达到8岁以上时仍然需要协调。

当你越过那个边界时，有一个不连续的过程。然而，它不一定是灾难性的。最好的方法是让团队尽可能采用尽可能多的正式流程，以便所有必要的行为和基础设施到位。我认为这在任何情况下都是良好开发的代名词，所以即使是单独的开发人员也应该拥有它（源代码控制，单元测试和编码标准都是我所谈论的例子）。如果你采用这种方法，那么当它发生时的升级过程并不像一个严格的协调那么激动。

您添加的每个开发人员都需要加入已经存在的流程。当你达到8（或者无论数字对你来说是什么）时，你会发现你的团队会议有点过于宽松和冗长，个性开始发挥作用，将活动分开更有效。在那一刻，你的老板（或者如果你是老板，你）需要指定一名或多名协调员来分配和控制工作。

如果你坚持你的流程，这个过程（应该）也会扩展。如果有必要，团队可以细分，或者你可以派出团队执行任务。无论您为项目管理选择何种方法，无论是否敏捷，这种方法都有效。

一旦你达到4或5个团队，即30-50人，那么你几乎肯定会需要那些对自己唯一的任务是协调的人感到高兴的人。

如果你现在很小并且考虑或期望复杂性转变，那么请确保在开始增加更多员工之前立即确定基本流程。

HTH祝你好运

Answer 4

很大程度上取决于项目人员，集成点等。即使是单个编码人员也应该拥有代码管理工具，并且需要与客户或“老板”进行交互。从经验来看，一旦有超过2人，我看到了一个变化，然后可能增加了50％。如果团队由项目团队组织，专注于产品的分离部分，则随着团队规模的增加，开销增长不会呈指数级增长（项目与矩阵组织）。