团队规模与流程开销的临界点是什么？

Question

在团队成长的哪个阶段，必须处理剧烈的变化？一个单独的程序员可以逃脱源代码控制和大脑的惩罚。试图将大型预打包软件运送到本地和国际市场的团队必须有更多的准备工作。

如果你经历了“流程”的大转变:团队的流程是否成功地与当前成员一起进行了更改，或者团队本身在流程更改发生时是否大部分都被替换了？有哪些重要的方面发生了变化，有哪些是不必要的？

Answer 1

根据我的经验，这种转变恰好发生在你也需要管理的时刻。如果没有一些全面的协调功能，无论是团队领导、任务分离还是老式管理，都很难获得8名以上的开发人员。我亲眼目睹的现实是，即使是最好的，最有才华的，最投入的开发人员，当你同时工作在8个以上的时候，你仍然需要协调。

当你跨越这一边界时，过程中会有一个不连续的步骤。然而，它不一定是灾难性的。对于团队来说，最好的方法是在它还很小的时候尽可能多地采用正式的过程，以便所有必要的行为和基础设施都到位。我认为这在任何情况下都是良好开发的同义词，所以即使是唯一的开发人员也应该拥有它(源代码控制、单元测试和编码标准都是我所说的例子)。如果你采用这种方法，那么当它发生时，过程中的步骤与其说是一次颠簸，不如说是一次严格的协调。

您添加的每个开发人员都需要在流程已经到位的情况下引入。当你数到8(或者其他任何适合你的数字)时，你会发现你的团队会议变得有点松散和冗长，个性开始发挥作用，划分活动更有效。在那个时刻，你的老板(或者你，如果你是老板)将需要指定一个或多个协调员来分配和控制工作。

如果你坚持你的流程，这个流程(应该)也会向上扩展。团队可以细分，或者您可以在必要时组织团队执行功能任务。无论您为项目管理选择的方法是敏捷的还是非敏捷的，这种方法都是有效的。

一旦你有了4个或5个团队，即30-50人，那么你几乎肯定会需要那些乐于接受他们唯一任务是协调的人。

如果您现在规模较小，并且正在考虑或期待复杂性的转变，那么请确保立即确定您的基本流程，当然是在您开始添加更多员工之前。

HTH和好运

Answer 2

你会发现很难得到一个定量的答案。这真的取决于项目的“广度”。如果有一个简单的子系统来工作，任何一个以上的人都会导致人们踩到其他人的脚趾。如果你有一个项目有8个隔离的子系统，那么你可以有8个开发人员没有问题。更有可能的是，您将拥有几个不同程度上相互依赖的子系统。哦，不管你使用的是哪种过程，所有这些都是正确的。

选择您想要使用的流程类型(螺旋、scrum、瀑布、CMM等)，以及您想要实现的流程版本的重量级，是另一个问题，而且很困难。这主要是因为人们试图将在建筑物建设、工厂工作或其他与软件完全不同的行业中工作的过程应用于软件开发。

在我看来，McConnell写的关于软件过程的书是最好的，尽管他的书本身都不是过程书。

Answer 3

如果我没记错的话，任何超过五个人的事情都会变得危险。在此之后，团队之间的通信路径数量变得非常多。

(2人=1条路径，3=3条路径，4=6条路径，5= 10条路径等等)。

我在IT团队的最后三个地方经历了巨大的流程变化。是的，你会失去一些人，可能还有一些更好的人。这并不是说他们很固执，并试图坚持旧的方式，而是这样的变化会造成大量的压力。有要达到的最后期限和对质量的需求。人们会对他们应该做的过程感到困惑，许多人会回到“老方法”上。(我承认，我也曾为此感到内疚。)

成功的关键是慢慢地、小步地走。人们需要时间来理解为什么这个过程正在改变，以及它是如何给他们带来好处的。这是巨大的，如果你不花时间做这件事，它将不会成功，关键人物最终将辞职并引发混乱。

绝对要记住的一件事是，归根结底，一些周转是好的。它带来了新的想法和具有不同(有时更好)技能的人。你不应该试图迅速地将改变强加给人们，但他们也不应该成为障碍。如果他们不同意正在发生的事情，他们要么尝试与制定过程的人达成妥协，要么离开。我在第一份工作中学到的真正让我大开眼界的一点是，在现实中，每个人都是可以替代的。总有一天，总会有人插手掌权的。