¿Por qué lo llaman amor cuando quieren decir sexo? Popular película noventera es española, comedi
a, según dicen no muy buena, dicho sea de paso, dirigida por Manuel Pereira y protagonizada por Verónica Forqué y Jorge Sanz.
Os aseguro que no recuerdo el argumento de la película, no sé ni siquiera si llegué a verla. Pero no dejo de recordar ese título cuando participo en algunos proyectos software. En muchos.
Y, no, no os hagáis ilusiones, lo de recordar el título durante los proyectos no viene motivado por las dos palabras que más resaltan en el mismo. No. Vienen por el símil que me viene a la cabeza con la agilidad: Por qué lo llaman amor “Agilidad” cuando quieren decir sexo “Cascada”.
No dejo de encontrarme situaciones como la siguientes:
– Nosotros seguimos la metodología ágil Scrum. El cliente nos pidió, y así hicimos, que antes de comenzar el proyecto le diéramos una estimación, requisitos cerrados y precio fijo.
– Ya, pero… ¿eso es ágil? ¿con un contrato cerrado? ¿con el peor enemigo del software?
– Nosotros seguimos una metodología ágil. Pero no hacemos pruebas unitarias ni refactorizamos. No, no podemos hacerlas por tiempos. Además, no las paga el cliente.
– Ya, pero… ¿eso es ágil?
– Nosotros seguimos una metodología ágil. Verás, hacemos Sprint, normalmente de varios meses.
– ¿De varios meses? ¿normalmente?
– Si hay veces que un Sprint es de 2 meses, otro de tres, depende, según avanza el Sprint vamos viendo…
– Ya, pero… ¿eso es ágil?
Lo dicho, si no haces nada de lo que recomindan las buenas prácticas ágiles… ¿por qué lo llamas ágil? ¿Por qué lo llaman amor “Agilidad” cuando quieren decir sexo “Cascada”?
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Gran Post Javier….Ya del testing Agile ni hablamos…:)
Hola Javier, soy seguidor tuyo no recuerdo bien desde cuando, te felicito por tus artículos que son muy interesantes y que de alguna manera nos sirven de guía a nosotros los incautos que nos adentramos en el mundo de las TICs. El motivo es para preguntarte acerca de que manera entonces lograr contratos que sean ágiles que como mencionas no solo basta con seguir los tipos de organización ágil como scrum, y como vemos los clientes no tienen los recursos o el conocimiento para seguir los contratos ágiles. En pocas palabras ¿De que manera podemos sensibilizar al cliente o cambiarle el paradigma?
De nuevo Felicidades por tu blog y exito!!
Saludos
Gracias Santiago 🙂
Yo creo que la mejor manera de convencer es dando confianza, si alguien ve que mes a mes, por ejemplo, sprint a sprint, que le van mostrando funcionalidad real incorporada al prototipo no creo que prefiera volver al cascada típico sin cambios posibles y viendo resultados a muchos meses.
Saludos
Hola Javier, interesante tema, como siempre.
El problema del contrato, pliego de concurso, precio cerrado,.. no reside en los informáticos es la forma de trabajar en la empresa. A finales de noviembre, hay que cerrar los presupuestos de todas las divisiones (entre ellas SSII) para el próximo año. Eso quiere decir que debes hacer una estimación proyecto a proyecto de lo que vas a costarte. Después en diciembre te lo aprueban o no. Por este motivo, debes lanzar concursos para adjudicación de los proyectos a precio cerrado (evidentemente siempre hay un pequeño margen +- 15% admisible). ¿Cuándo vas a hacer una obra grande en tu casa no pides presupuesto?, pues el software igual.
Hola Vicente,
Ciertamente, así es como suelen trabajar las empresas grandes. Lo cual no evita una paradoja, ¿si no tienen cerrados y claros los requisitos del software a construir cómo pueden cerrar los presupuestos? Si, efectivamente puedes cerrar los requisitos (o casí cerrarlos, como en el caso de las casas y las obras)… pues todo correcto, proyecto cerrado y cascada, buena solución.
Pero me da que hay mucho proyecto que cierra tiempos y dinero con requisitos a medio cerrar, y ahí empieza el problema, y la realidad acaba haciendo saltar los proyectos por donde vemos día si y días no: calidad bajisima (porque se estimo menos tiempo o presupuesto), software a medio hacer, software con partes que no se usan, presupuestos que se disparan, incidencias correctivas que realmente son software sin terminar, etc. No obstante, para este último caso se puede aplicar el pago por tiempo, por horas, por bolsa de horas, etc., aunque sea algo que a los clientes no les gusta nada.
Saludos