¿Qué hay de malo con los procesos actuales de ingeniería de software? ¿Qué se debe hacer para gestionar eficazmente la ingeniería de software?

Tengo 18 años de experiencia en gestión de desarrollo en compañías Fortune 500. Estoy hablando de grandes proyectos que tomarán más de seis meses para más de cinco personas. También estoy asumiendo a los efectos de esta respuesta que no hay problemas organizativos más amplios, que a menudo es el caso, pero la gente no quiere o no puede hablar de eso.

En mi experiencia, los mayores problemas no son con el proceso, sino con la evaluación estructurada del riesgo y garantizar que tenga una cobertura competente para cada una de las disciplinas de ingeniería de software.

El objetivo de la evaluación de riesgos es lograr que, sin importar el proceso que tenga, se concentre en las cosas correctas. Si tiene una lista de verificación de 5–6 aspectos clave en los que evalúa la salud del proyecto para cada una de las áreas de gestión, estimación, requisitos, diseño, desarrollo y garantía de calidad, entonces al menos su equipo tendrá alguna advertencia temprana si necesita para apuntalar algo.

También debe asegurarse de tener una representación competente para cada una de las áreas de gestión de procesos enumeradas anteriormente. La verdad es que la mayoría de los proyectos carecen de representación competente de una o más áreas. Entonces, incluso si tiene una representación competente para las otras áreas, probablemente esté en problemas si le falta una.

Por último, querrás a alguien que sepa cómo unir todo esto desde una perspectiva técnica. Por lo general, no se trata de un gerente de proyecto, sino de un arquitecto o desarrollador muy experimentado.

Lo principal que observo es tratar de forzar procesos de ajuste que necesitan previsibilidad en proyectos de software que no pueden tenerlo.

Hay una matriz de riesgo con el desarrollo de software.

En el extremo ‘sin problemas’, tenemos proyectos en solitario, utilizando una tecnología robusta familiar, con requisitos pequeños y desacoplados que usted ha codificado anteriormente en esa tecnología.

En el otro extremo, obtienes

  • Nuevo equipo
  • Sangrado de nueva tecnología
  • Nadie en el mundo ha implementado esto antes
  • Nadie en el equipo tiene conocimiento tecnológico.
  • Los requisitos están sujetos a grandes cambios.

En este último caso, las estimaciones de tiempo / presupuesto / complejidad simplemente no tienen sentido. Hay demasiadas incógnitas conocidas y una gran cantidad de incógnitas desconocidas.

Por lo tanto, cualquier proceso que tenga como objetivo asignar esto en una línea recta de progreso a la fecha límite ya ha fallado. Confíe en usted bajo su propio riesgo.

Otra área que veo que falta es en la gestión de personas. Se han realizado algunos buenos intentos para hacer que los ingenieros de software conecten piezas reemplazables conectables. No solo nunca he visto que eso funcione muy bien, sino que dudo que así sea como motivas a los seres humanos para que den su mejor rendimiento.

El mejor intento hasta ahora para solucionar esto ha sido los métodos ágiles y lean. Pero será interesante ver avances en eso.