在团队成长的哪个阶段必须处理急剧变化？一个单独的程序员可以摆脱源代码控制和大脑。一个试图将大型预打包软件运送到本地和国际市场的团队必须有更多的准备。
如果你在"流程"中经历了一次大的转变：团队的流程是与当前成员一起成功改变的，还是在流程改变时团队本身基本上被取代了？哪些重要方面发生了变化，有些是不必要的？
你会发现很难得到定量的答案。这实际上取决于项目的"广度"。如果有一个简单的子系统需要处理，任何超过一个人都会导致人们踩到别人的脚。如果你有一个项目有8个独立的子系统，那么你可以有8个开发人员，这没有问题。更有可能的是，您将拥有多个子系统，它们在不同程度上相互依赖。哦，不管你使用什么流程，所有这些都是真的。
选择你想要使用的流程类型（螺旋式、scrum、瀑布式、CMM等），以及你想要实现的流程版本的权重，是另一个问题，这很困难。这主要是因为人们试图采用建筑施工、工厂工作或其他与软件完全不同的行业的流程，并将其应用于软件开发。
在我看来，麦康奈尔写的是关于软件过程的最好的书，尽管他的书本身都不是过程书。在那之后，团队之间的通信路径变得非常多。
（2人=1条路径，3=3条路径，4=6条路径，5=10条路径，依此类推）。
我在IT团队的最后三个职位经历了巨大的流程变化。是的，你会失去一些人，可能还有一些更好的人。这并不是说他们固执，试图坚持旧的方式，只是这样的变化会造成巨大的压力。要达到最后期限，还要满足质量要求。人们会对他们应该做的过程感到困惑，许多人会回到"旧的方式"
成功的关键是慢慢来，循序渐进。人们需要花时间来理解为什么这个过程会发生变化，以及它对他们有什么好处。这是巨大的，如果你不花时间这样做，它就不会成功，关键人物最终会辞职，引发混乱。
需要绝对记住的一件事是，最终一些营业额是好的。它带来了新的想法和具有不同（有时甚至更好）技能的人。你不应该试图强迫人们迅速改变，但他们也不应该成为障碍。如果他们不同意正在发生的事情，他们要么尝试与制定过程的人达成中间立场，要么离开。我在第一份工作中学到的一个真正令人大开眼界的东西是，在现实中，每个人都是可以替代的。总有一天会有人掌权。
根据我的经验，这种转变恰好发生在您也需要管理的时刻。如果没有一些全面的协调功能，无论是团队领导、任务分离还是老式的管理，很难获得8名以上的开发人员。我所看到的现实是，即使有最优秀、最有才华、最受欢迎的开发人员，当你同时工作超过8人时，你仍然需要协调。
当你越过边界时，这个过程中有一个不连续的步骤。然而，这不一定是灾难性的。对于团队来说，最好的方法是在规模较小的时候尽可能多地采用正式流程，以便所有必要的行为和基础设施都到位。我认为，无论如何，这都是良好开发的代名词，所以即使是唯一的开发人员也应该拥有它（源代码控制、单元测试和编码标准都是我所说的例子）。如果你采取这种方法，那么当它发生时，过程中的步骤与其说是一次震动，不如说是一种严格的协调。
你添加的每一个开发人员都需要加入已经到位的流程。当你达到8时（或者无论数字是多少），你会发现你的团队会议变得有点过于松散和冗长，个性开始发挥作用，将活动分开更有效。在那一刻，你的老板（或者你，如果你是老板的话）将需要任命一个或多个协调员来分配和控制工作。
如果你坚持你的流程，这个流程（应该）也会扩大。团队可以进行细分，也可以在必要时组织团队执行职能任务。无论您为项目管理选择了什么方法，无论是否敏捷，这种方法都能起作用。
一旦你有4到5个团队，即30-50人，那么你几乎肯定需要那些对自己的唯一任务是协调感到满意的人。
如果你现在很小，正在考虑或期待复杂性的转变，那么在开始增加员工之前，一定要立即确定你的基本流程。
HTH和好运
这在很大程度上取决于项目工作人员、集成点等。即使是一个程序员也应该有一个代码管理工具，需要与客户或"老板"互动。根据经验，我看到了一个变化，一旦超过2个人，然后可能会增加50%。如果团队由项目团队组织，专注于产品的解耦部分，则开销的增加不会随着团队规模的增加而呈指数级增加（项目组织与矩阵组织）。