为什么将维护工作与开发工作分开？

Question

我在一家公司工作,该公司由同一个团队进行维护,为一个软件带来生命.

我经常听说组织有一个单独的维护团队或维护程序员.我想知道的是 - 这背后的原因是什么？

除了将"旧代码"抛弃给较小的凡人之外,还有吗？

从维护自己的"垃圾"中汲取的教训价值更高？当那些导致它们开始的人完成时,修复缺陷是否更有效？

我错过了为什么有一个单独的维护团队可能有益的任何真正原因？

Answer 1

想要最好地描述这个概念的概念是" 颠簸".这实际上是与维护工作和开发工作相关的转换成本.这可能是分离责任的最大原因.其他方面包括允许初级或初级程序员有机会弄湿他们,并让更有经验的开发人员生产更高价值的产品.

现在同时,我认为开发人员编写一个必须支持它的应用程序有一些价值.首先,他们将很快在代码中找到可以学习的问题.其次,他们会考虑代码的可维护性和质量,因为他们必须支持它.

真实生活捶打示例:

您已被分配了一个1500小时的开发项目,并且还负责系统维护和最近3个应用程序的支持.在这个新项目中,您平均每周被中断7次以支持这3个应用程序.每当您开始处理其他3个应用程序时,您花费20分钟就可以解决问题.解决问题后,您需要花20分钟时间将您的思维包裹在最近在新应用中触及的代码中.这是每次中断40分钟或每周280分钟的总费用.这意味着在切换到支持这些应用程序时,您在本周损失了2.67小时的工作效率.

Answer 2

我已经在敏捷团队工作了一年多.我认为在实时产品的情况下这并不重要(我指的是仅使用最新版本的客户).但是说你在市场上有几个版本的产品,你必须支持它们中的每一个.

以Bentley的Microstation为例.它是3d的设计应用(建筑,工厂设计,铁路桥梁等).现在假设我们在市场上推出了v8,v9,v10.它们具有不同的功能,文件格式在版本上发生了显着变化.但是项目非常庞大(或者客户非常重要),你必须支持v8客户端和v9客户端,同时还要开发v10.因此,公司必须拥有分配给以前版本的维护团队(或时间).此外,如果您的产品支持自定义和上述方案,通常这些团队称为自定义团队.