Me uní a una empresa de desarrollo de software hace aproximadamente un año. Hay un par de equipos que trabajan en diferentes productos, sin embargo, hay una serie de bibliotecas comunes que todos los equipos deben usar. De hecho, mi equipo mantiene una biblioteca específica que uno de los otros equipos integra en su producto.
El problema general es que no existen procesos bien definidos de mantenimiento de software dentro de la empresa. La mayoría de las bibliotecas comunes están mal documentadas, las personas eliminan el código en lugar de desaprobarlo (lo que rompe el código que depende de las bibliotecas) y no hay registros de cambios en su lugar. La política es que los proyectos deben actualizarse a las versiones más recientes de la biblioteca lo antes posible; sin embargo, puede haber múltiples actualizaciones durante un solo día, o una sola actualización puede tardar fácilmente medio día.
No soy miembro del personal senior de la empresa, sin embargo, tengo algo de experiencia en mantenimiento de software y OSS, y estoy pensando en plantearle este tema a mi gerente con la esperanza de que pueda escalarlo aún más. Creo firmemente que los buenos procesos mejorarán la calidad del software que creamos y ayudarán a reducir el estrés innecesario entre los equipos. ¿Debería hacer eso? ¿Hay algo que deba considerar al prepararme para la conversación con mi gerente? ¿Hay alguna forma en que mi iniciativa pueda resultar contraproducente?
Cualquier cosa puede resultar contraproducente. Pero tu enfoque es el correcto. Me refiero a documentar lo que se está haciendo en la empresa y proporcionar/mantener la compatibilidad con versiones anteriores son cosas buenas. Lo único que puedo sugerirte es que empieces despacio y con mucho tacto. Su jefe o un amigo cercano de él podría ser el mantenedor de esa base de código, o podría haberlo escrito en un momento en el pasado, sin tener en cuenta el mantenimiento y fue encalado todo el tiempo. Ahora, un recién llegado, "yuppie de tiro caliente" en sus ojos, está tratando de enseñarles cómo hacer su trabajo. Si este es el caso, no se tomará a la ligera. Aunque sabrán que es la forma correcta de hacerlo, se resistirán y pondrán un obstáculo tras otro, tratando de explicar, lo que dijiste que no se debe hacer.
Pero en la mayoría de las empresas de software bien estructuradas, sus sugerencias sonarán como música para los oídos de la gerencia. Pero en ese caso, prepárese para asumir el papel de mantenedor principal, que será un gran sumidero de tiempo, mientras allana el camino hacia niveles superiores en la escala corporativa, si hace un buen trabajo.
Muchos de los problemas que comenta son debilidades signifcativas en la gestión de cambios y/o el proceso SDLC.
No hay procesos bien definidos para mantener el software dentro de la empresa.
¿Cómo realiza un seguimiento de los cambios que se han realizado en el software,
especialmente en el entorno de producción, si existe uno en su
empresa?
Dado que no se utilizan registros de cambios, ¿cómo rastreará un cambio realizado y determinará si el cambio está autorizado y no es malicioso?
¿Cómo rastrea los cambios hasta los usuarios que los realizaron? Porque si no puede hacerlo, ninguna persona puede ser responsable si un cambio interrumpe una funcionalidad crítica.
La gente elimina el código en lugar de desaprobar el código antiguo . Esta es una muy mala práctica como sugieres. ¿Qué sucede si una versión falla y debe revertirse? Sin un código de trabajo antiguo al que volver, existe el riesgo de interrupción del negocio debido a la incapacidad de recuperarse de una falla/desastre.
¿Qué dice el proceso SDLC, ya sea WaterFall o una versión de Agile, sobre cómo se procesan los cambios de código? ¿Existe una función de control de calidad que aplique técnicas de desarrollo adecuadas?
Preste atención a cómo funcionan los procesos relacionados en su empresa. . Dado lo descuidada que es la gestión del cambio en su empresa, estoy dispuesto a apostar fuerte a que los procesos relacionados no son mejores. Algunas preguntas en las que vale la pena pensar, suponiendo que su empresa sea madura:
También debe reconocer que si su empresa es una empresa que cotiza en bolsa en el mercado de valores de los Estados Unidos, está sujeta a la Sección 404 de la Ley Sarbanes Oxley - SOX , si el proceso en cuestión afecta los informes financieros de alguna manera. Sarbanes Oxley: la sección 404 exige que la gerencia asuma la responsabilidad personal sobre la idoneidad de los controles internos en su empresa. La alta gerencia puede ir y haber ido a la cárcel si es declarada culpable de informar erróneamente de manera fraudulenta sobre los controles internos.
Trabajo en Auditoría de TI y mi trabajo es exactamente traer los problemas que menciona en su puesto a la atención de la gerencia para su resolución. Mi sugerencia es que discuta con su gerente que los procesos actuales presentan riesgos significativos para la empresa en términos de interrupción del negocio, integridad del sistema y satisfacción del cliente. Si eso falla, plantee el problema a la función de Auditoría Interna de su empresa, si tal función existe en su empresa, y está autorizado a hablar entre departamentos.
En resumen, si después de su presentación a la gerencia y aún no se realizan mejoras, probablemente debería pensar en buscar otro trabajo ya que este entorno de desarrollo es perjudicial para su crecimiento.
Creo firmemente que los buenos procesos mejorarán la calidad del software que creamos y ayudarán a reducir el estrés innecesario entre los equipos. ¿Debería hacer eso? ¿Hay algo que deba considerar al prepararme para la conversación con mi gerente? ¿Hay alguna forma en que mi iniciativa pueda resultar contraproducente?
Mire lo que usted mismo escribió sobre su empleador:
No hay procesos bien definidos para mantener el software...
Las personas eliminan el código en lugar de desaprobarlo...
No hay registros de cambios en su lugar...
Los proyectos deben actualizarse a las versiones más recientes de la biblioteca lo antes posible...
Puede haber múltiples actualizaciones durante un solo dia...
Esto no es solo programación de vaqueros; incluso los vaqueros siguen las reglas. Esto es programación de bandidos de rango abierto, donde no hay reglas apestosas, ni procesos apestosos, ni administración de configuración apestosa, ni control de versión apestoso. Nada más que arrojar el código. Esta es una organización llena de gente que no necesita insignias apestosas.
Una organización de desarrollo de software que en 2016 no se molesta en usar ni siquiera los sistemas de control de versiones más básicos no quiere procesos. Período. Las personas que terminan trabajando para tales organizaciones lo hacen por una razón. No quieren que los molesten con ninguna de esas "cosas del proceso", incluso si les ayudaría.
Así que sí, hay muchas formas en que su iniciativa puede resultar contraproducente.
bobrodes
Remojar