En la década de 1990, la industria de TI se vio afectada por la tasa de fallas notablemente alta de los proyectos de desarrollo de software: proyectos que se hicieron notorios por no cumplir con los plazos, sobrepasar sustancialmente los presupuestos, entregas defectuosas y clientes insatisfechos. Un puñado de líderes de opinión en la industria creía que estas fallas en los proyectos de TI podían atribuirse a tres factores clave: planificación excesiva, comunicación insuficiente y una sola entrega.

Planificación excesiva

Los proyectos de software de TI (Tecnologías de la Información) tradicionalmente comenzaban con la producción de una extensa documentación inicial, que incluía planes de proyecto, requisitos funcionales, especificaciones de diseño de sistemas y diseños arquitectónicos técnicos. Estos documentos, que a menudo tardaban meses en producirse (e incluso más en aprobarse), estaban destinados a garantizar que el software desarrollado se alinearía con los requisitos del usuario. En realidad, sin embargo, estos documentos solo sirvieron para proporcionar a los gerentes corporativos una falsa sensación de seguridad en el gasto de sus presupuestos de TI y para garantizar que el software entregado estaría sustancialmente desalineado con las necesidades continuas y cambiantes del negocio.

Los mayores problemas con las organizaciones que dependían de la documentación inicial fueron:

• La consiguiente falta de capacidad de respuesta a los cambios continuos en los requisitos de los usuarios, la demanda del mercado, la disponibilidad de recursos internos y las capacidades de las tecnologías subyacentes.
• La tendencia de las partes interesadas (por ejemplo, áreas de negocio y clientes) a:
• No articular claramente sus requisitos (que luego se dejaron a discreción del equipo del proyecto para interpretar)
• Quiere todo bajo el sol (lo que resulta en la pérdida de requisitos comerciales altamente críticos en un mar de requisitos extraños).

• La desalineación inevitable entre las descripciones de texto de las necesidades de los usuarios y el software resultante.

La conclusión es que los productos de software entregados para cumplir con estos documentos de diseño iniciales estaban destinados al fracaso, y las empresas estaban perdiendo millones en el proceso.

Comunicación insuficiente

El segundo impulsor abrumador del fracaso continuo de los proyectos de desarrollo de software en la década de 1990 fue la separación tradicional, y a menudo deliberada, entre las áreas comerciales que requerían el software y el personal técnico responsable de entregar la solución (es decir, desarrollo en un vacío).

Una vez que se habían finalizado los grandes documentos de diseño iniciales para un proyecto de TI, generalmente se entregaban al equipo del proyecto para su desarrollo. Luego, el equipo del proyecto fue enviado de regreso a sus escritorios (a menudo ubicados en una sección, piso o incluso edificio separado de las áreas comerciales), con una pila de papel y una fecha límite inmutable. La próxima vez que el equipo del proyecto interactuó con el área comercial fue cuando instalaron el software resultante en las máquinas de los usuarios para realizar las pruebas de aceptación.

Este aislamiento creó problemas inevitables con el software resultante porque:

• Los requisitos del usuario se habían dejado a la interpretación de los miembros del equipo del proyecto sin el beneficio de comprender el contexto comercial
• La inevitable desconexión entre el concepto bidimensional propuesto en la documentación y la manifestación de ese concepto en pantallas tangibles con las que el usuario podría interactuar
• No se tuvo en cuenta los cambios en los requisitos comerciales que pueden haber ocurrido entre el momento en que se consultó al usuario por última vez y los meses (ya veces años) que siguieron antes de que se instalara el software resultante en su sistema.

Todos estos factores dieron como resultado la entrega de software que con frecuencia no estaba alineado con las necesidades de los usuarios comerciales e incluía flujos de trabajo inadecuados, errores del sistema, fallas críticas de diseño y funciones que rara vez (o nunca) usaba la empresa. Además de esto, no había presupuesto restante ni recursos disponibles para abordar ninguno de los problemas.

Una sola entrega.

Los proyectos de desarrollo de software en la década de 1990 dependían en gran medida de las metodologías de gestión de proyectos en cascada, donde las etapas de análisis, diseño, desarrollo, prueba y entrega se realizaban en serie, lo que requería la finalización completa de una actividad antes de que pudiera comenzar la siguiente. 

El uso de metodologías en cascada en estos proyectos significaba que el diseño de software no podía comenzar hasta que se completara todo el análisis de requisitos, las pruebas de software no podían comenzar hasta que se completaba el desarrollo de software y el software no se entregaba a los usuarios hasta que se habían completado todas las etapas anteriores. sido completado

Este uso de enfoques en cascada en la industria de TI tenía como objetivo reducir el riesgo comercial en la entrega de proyectos al requerir que cada paso se completara a satisfacción de la gerencia antes de incurrir en gastos adicionales. En realidad, los enfoques en cascada aumentaron significativamente el riesgo de fracaso del proyecto de TI al:

• Exigir una gran documentación inicial (con todos los problemas relacionados)
• Desalentar la capacidad de respuesta a los requisitos cambiantes a medida que evolucionaba el proyecto
• Crear silos de propiedad que redujeron la comunicación entre los miembros del equipo del proyecto (silo se refiero a los grupos especialistas, developer, testers, que por naturaleza no tienen la necesidad de comunicación con otros grupos .

Quizás el impacto más arriesgado de estos enfoques en cascada fue el retraso de la entrega de resultados comerciales tangibles hasta el final del proyecto, el punto en el que los problemas en el software son más evidentes y los cambios en el software son más costosos.

En lugar de permitir que la organización administre los gastos y los riesgos a lo largo del proceso de desarrollo de software, los ejecutivos se enfrentaron a una propuesta de todo o nada: seguir invirtiendo recursos en un proyecto de TI fallido, de modo que se pueda recuperar al menos algo de valor de la inversión anterior. – o finalizar el proyecto a mitad de camino y no recibir ningún beneficio tangible para la organización. El enfoque de entrega todo a la vez a menudo dejaba a estos ejecutivos sin otras opciones.

Por supuesto, hubo otros factores que influyeron en la alta tasa de fracaso de los proyectos de desarrollo de software en la década de 1990, incluidas las limitaciones tecnológicas y la falta de disponibilidad de recursos técnicos calificados. Sin embargo, los tres problemas descritos anteriormente (planificación excesiva, comunicación insuficiente y una sola entrega) eran factores que estaban bajo el control de la organización para cambiar.

Para combatir el fracaso generalizado de los proyectos de TI, un grupo de líderes de pensamiento innovadores comenzó a desarrollar estrategias y prácticas diseñadas específicamente para abordar estos tres problemas. Es su visión, junto con las contribuciones de muchos otros que siguieron, lo que ha dado como resultado las metodologías ágiles comprobadas e impulsadas por el valor comercial que se utilizan en todo el mundo hoy en día.

Con esto como base, te recomendamos adentrarte en el método Scrum con el curso Scrum Desde Cero.

Fuente:

Everything you want to know about Agile

How to get Agile results in a less-than-agile organization

JAMIE LYNN COOKE