¿Por qué separar el trabajo de mantenimiento del trabajo de desarrollo?

Question

Trabajo en una empresa donde el mismo equipo realiza el mantenimiento que da vida a una pieza de software.

Muy a menudo escucho sobre organizaciones que tienen un equipo de mantenimiento separado o un programador de mantenimiento. Lo que me pregunto es, ¿cuál es el razonamiento detrás de esto?

Además de deshacerse del 'código antiguo' para los mortales menores, ¿hay alguno?

Las lecciones aprendidas de mantener su propia "basura" son de mucho mayor valor? ¿No es la reparación de defectos mucho más efectiva cuando la realizan aquellos que los causaron?

¿Me estoy perdiendo alguna razón real por la que podría ser beneficioso tener un equipo de mantenimiento separado?

Answer 1

El concepto que viene a la mente para describir esto mejor es " paliza ." Esto es esencialmente los costos de cambio que ha asociado con el trabajo de mantenimiento y el trabajo de desarrollo. Esta es probablemente la razón más importante para separar las responsabilidades. Otros incluyen permitir a los programadores junior o de nivel de entrada la oportunidad de mojarse los pies y mantener a sus desarrolladores más experimentados produciendo artículos de mayor valor.

Ahora, al mismo tiempo, creo que hay algún valor en un desarrollador que escribió una aplicación que tiene que admitirlo. Primero, encontrarán rápidamente problemas en su código de los que pueden aprender. En segundo lugar, pensarán en la mantenibilidad y calidad del código, ya que deben admitirlo.

Ejemplo de paliza en la vida real:

Se le ha asignado un proyecto de desarrollo de 1500 horas y también es responsable del mantenimiento de los sistemas y el soporte para sus últimas 3 aplicaciones. Durante este nuevo proyecto, se le interrumpe 7 veces por semana en promedio para admitir estas 3 aplicaciones. Cada vez que comienzas a trabajar en las otras 3 aplicaciones, pasas 20 minutos para concentrarte en el problema. Después de solucionar el problema, pasas 20 minutos volviendo a pensar en el código que tocaste por última vez en tu nueva aplicación. Este es un costo total de 40 minutos por interrupción o 280 minutos por semana. Esto significa que perdió 2.67 horas de productividad en la semana solo al cambiar para admitir estas aplicaciones.

Answer 2

He estado trabajando en un equipo ágil durante más de un año. Creo que realmente no importa en el caso de un producto en vivo (con eso me refiero a los clientes que usan solo las últimas versiones). Pero supongamos que tiene varias versiones de su producto en el mercado y debe admitir cada una de ellas.

Tome la Microstation de Bentley por ejemplo. Es una aplicación de diseño para 3d (arquitectura, diseño de plantas, rieles, puentes, carreteras, etc.). Ahora digamos que tenemos v8, v9, v10 en el mercado. Tienen diferentes características y el formato de archivo ha cambiado significativamente en las versiones. Pero los proyectos son tan grandes (o los clientes son tan importantes) que tienes que admitir clientes v8 y clientes v9 mientras también desarrollas cosas v10. Por lo tanto, es necesario que la empresa tenga un equipo de mantenimiento (o tiempo) asignado a versiones anteriores. Además, generalmente estos equipos se denominan equipos de personalización si su producto admite la personalización y el escenario mencionado anteriormente.

Answer 3

El problema es más práctico, supongo:

• el código antiguo ha sido escrito por personas que ya no están en la empresa o equipo;
• el código antiguo fue escrito por desarrolladores externos;

Es muy común en muchas empresas tener una base de código que los codificadores originales ya no mantienen porque ya no están allí. Si la base del código es lo suficientemente grande, alguien tiene que mantenerla actualizada para que se llamen mantenedores.

Si puede evitar este caso, bien por usted, pero asegúrese de que siempre sea temporal.

Answer 4

No diré que estoy de acuerdo con la práctica, pero en muchas organizaciones se contratan consultores para que escriban software en forma breve y apresurada, después de lo cual los proyectos se entregan a los programadores internos para que los "mantengan". La razón es que puede traer a alguien que sea más hábil sin capacitación y luego hacer que incluyan "transferencia de conocimiento". a las personas que trabajarán para mantener intacto un software.

En resumen, la mayor parte del tiempo se hace por razones políticas / poco prácticas.

Answer 5

Creo que la motivación detrás de dividir los equipos de mantenimiento y desarrollo de funciones es mantener las cosas funcionando sin problemas: si el equipo de desarrollo de funciones sigue teniendo que detener lo que están haciendo para manejar una corrección de errores, entonces el proyecto se detendrá. Tener un equipo de mantenimiento separado liberaría al resto de los desarrolladores para mantener el proyecto / producto en cuestión en el futuro.

Answer 6

Mi primer trabajo fue mantener algunos módulos de software, cuyos desarrolladores originales se habían mudado a algún nuevo proyecto.

Supongo:

• Hace que el nuevo desarrollo sea más predecible, más fácil de programar: porque los desarrolladores no están suspendidos para solucionar algunos problemas de mantenimiento desconocidos por adelantado

• Oportunidad para capacitar a nuevos desarrolladores (por ejemplo, yo)

Además, el código que mantenía no era "basura" - era software de telecomunicaciones, una red de conmutación de paquetes temprana, que se había implementado en clientes como Bell, etc. Estaba bien diseñada, bien escrita, comprobable (conjuntos de casos de prueba automatizados), mantenible, muchos archivos de registro, algunos diseños documentación ...

... el subtítulo de su OP parece ser, "¡Hombre, este código apesta! Desearía poder obtener el desarrollador original, y frotar su nariz: que lo aprendería! & Quot;

Entonces, cuando el código ya está bien escrito, ese argumento (enseñar a los desarrolladores originales) no es aplicable.

Cuando digo que estaba haciendo "mantenimiento" Esto era algo así como el desarrollo de nuevas características, pero de características muy menores ... por ejemplo, interoperabilidad con nuevos dispositivos de clientes que interpretaban las especificaciones del protocolo de una manera ligeramente inusual.

[Analizaría y diagnosticaría el problema, y ??codificaría una solución; y una persona de control de calidad agregaría un nuevo caso de prueba correspondiente al conjunto de pruebas automatizadas.]

Answer 7

Una ventaja que puedo ver es que hay al menos otra persona en la organización que es responsable de entender el código lo suficientemente bien como para arreglarlo. Además, esta persona tendrá una agenda diferente en mente y puede revisar el código desde la perspectiva del mantenimiento, si se le presentan revisiones de diseño / desarrollo (lo que debería ser).

Además, "mantenimiento" puede referirse a una gran cantidad de actividades, tales como implementación, configuración, copia de seguridad, etc., que definitivamente deben ser manejadas por un equipo diferente.