IT人员在DevOps时代进行规模调整--一个DevOps团队将如何以及何时扩大规模？

Question

考虑到DevOps实际上允许IT人员缩减规模，并在所有自动化过程中做更多的事情，那么这有什么限制呢？

也就是说，什么是经验法则--如果可以的话--你会知道你需要更多的人，尽管自动化的快速发展速度和引入了RPA (机器人过程自动化)？

注意:这是关于整个IT部门的员工规模与您的业务规模、结构和功能之间的关系(单个团队的大小由双份比萨队概念定义)。

Answer 1

直接和立即将团队从其DevOps转换中获得的收益应用于缩小团队规模并不是一个好主意。在最好的情况下，你将失去团队在未来做任何这样的改进的动力。但最有可能的是你会失去那支球队的大部分/全部天赋。

相反：

• 允许团队欣赏他们所经历的困难转换的好处，这样他们就可以将信息传播给您的其他团队，这些团队将不得不通过(或已经在努力地)进行转换。
• 专注于提供更高质量的产品/服务，以更快的速度-在同一个团队-这是可能的，因为转变。
• 在很多情况下，你的业务会因为转型而加速--很快你就会更有可能需要雇佣人员-- IMHO最好使用你已经拥有的经验，而不是教育新员工。
• 允许自愿减员为你工作，并有效地降低你的工作进度。

但通常情况下，DevOps转换的发生速度往往不够快，无法满足上述选择:)

现在扩大/扩大。

理想情况下，DevOps转换应该大大提高sw开发和交付过程的可预测性。您应该能够非常精确地判断您现有团队的能力:在一定的时间内，您的现有团队能够完成多少质量的sw/服务。

当你需要做更多的事情，或者比当前团队的能力做得更好/更快的时候，你需要扩大团队的规模。确切的细节来自于您在日常活动中使用的任何过程/方法，可能是一些敏捷变体(也请参阅我的组织需要采用敏捷软件吗？Dev.在采用DevOps之前？)。

显然很容易:雇佣更多的人来处理泛滥的活动。如果你担心你能以多快的速度让他们上船，并以预期的速度处理溢出的工作:根据预测，提前开始招聘。

然而，现实可能会比这更困难一些。扩展软件产品/服务或支持它的开发过程和工具并不一定是直截了当的，即使对于一个授权了DevOps的组织也是如此。

当涉及到可伸缩性时，我最喜欢的例子之一是最弱的DevOps链接:持续集成。如果CI构建失败了，就不可能有交付/部署(在CD上下文中某种程度上破坏了“连续”术语)。

仅仅因为某支球队很高兴地使用CI，取得了不错的结果，但这并不意味着如果团队规模翻倍，也会发生同样的情况。不，结果可能是毁灭性的--交付过程可能会陷入停顿(在极端情况下)。我正试图用传统CI系统中的拥塞来解释这一点(免责声明:我是拥有引用页面并为这个问题提供解决方案的公司的创始人)。

另一个例子可以是，例如，正在使用的版本控制系统(，VCS )：随着存储在存储库中的软件的发展，它的更改历史也在发展，这就推高了VCS系统的限制，有时超出了可接受的性能水平。切换到更可伸缩的VCS系统或将代码库拆分为多个存储库可能是解决此问题的一种方法。

但是，随着软件产品/服务的发展，开发过程和支持它们的工具的发展，从根本上说正是成熟的DevOps团队所做的。在团队的升级/退出策略中，也需要考虑到这些因素。

考虑到这一点，如何才能，实际上，减少到只是增加团队规模，以涵盖执行上述战略所需的额外工作量。