En mis cursos suelo decir a los asistentes que en el mundo de la gestión y desarrollo software tenemos que aprender dos lenguajes, uno, el que usamos y escuchamos normalmente, y otro… la traducción a lo que realmente se quiere decir.
No podemos cambiar la manera que tiene todo el mundo de llamar a las cosas. E incluso si llamásemos a las cosas por su nombre real mucha gente no nos entendería. Pero esto no evita que sepamos a que realmente nos estamos refiriendo cuando llamamos a las cosas de otra manera.
Con lo anterior, y para que sepas a que me estoy refiriendo, he querido dejar en este post las que en mi opinión son las 8 frases más populares que usamos en el día a día, pero que, a su vez… son incorrectas.
1. “Metodologías ágiles”.
Frase muy común, pero prácticamente ninguna “metodología” ágil es una metodología… son meta-metodologías, “framewoks” o conjuntos de buenas prácticas. De ahí que las “metodologías” ágiles no se apliquen al pie de la letra y que tengan, “por definición”, que ser adaptadas a cada empresa”.
2. “Usas CMMI o ISO 15504”. En foros de calidad en procesos software es una frade de lo más normal, pero, sin embargo, carece de sentido. No tiene sentido porque CMMI, bueno, concretamente sería CMMI-Dev, es un modelo de procesos (donde vienen procesos como requisitos, medición, validación, etc.) e ISO 15504 es una norma de evaluación de procesos (donde viene cómo se audita, cómo se asigna una “puntuación” a un proceso, etc.). Cuando decimos “Usas CMMI o ISO 15504” realmente queremos decir “CMMI-Dev o ISO 12207”, pero todos nos entendemos.
3. “Metodología Lean”. En línea con el caso anterior, Lean son principios a aplicar a nuestro proceso productivo, no una metodología.
4. “Tenemos el certificado CMMI”. No existe un certificado CMMI, en CMMi solo te puedes evaluar, y certificado y evaluación… no son lo mismo. Para más información te recomiendo aquel post de ¿Tu empresa se ha certificado o se ha evaluado en un nivel de madurez software?
5. “Usamos un ciclo de vida iterativo, es decir, ágil”. Que los proyecto ágiles utilicen un ciclo de vida iterativo, normalmente iterativo e incremental (te dejo este post por si quieres ampliar el tema), no implica que todos los proyectos que utilicen un ciclo de vida iterativo sean ágiles, porque para ser ágil, sin extenderme mucho, las iteraciones deben ser cortas en tiempo y el equipo, normalmente, es auto-organizado.
6. Metodología Cascada. Continuando con las metodologías, Cascada no es una metodología, es un ciclo de vida.
7. Metodología UML. No existe ninguna metodología UML, porque UML es un lenguaje de modelado, otra cosa son las “metodologías que usan UML”.
8. “El software está probado al 70%”. Cámbiese el 70 por cualquier otro número. Realmente estamos diciendo que “hemos ejecutado el 70% de los casos de prueba”. El número de “cosas a probar” en una aplicación es típicamente infinito, y un % de infinito no tiene sentido, como contábamos en aquel post de que es imposible asegurar que una aplicación software no va a fallar.
Como siempre, ayuda a difundir el conocimiento compartiendo en twitter, etc. Y lo que de verdad ahora estaría bien es que si alguno tenéis mas frases del estilo… las comentemos en la sección de comentarios.
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
Pingback: Bitacoras.com
Hola Javier,
lo primero felicitarte por tu blog que es completísimo. Te sigo desde hace un mes y va para largo. En mi proyecto actual, lo pactado con el cliente cuando decimos algo como «El software está probado al 70%», se refiere a que los casos de prueba ejecutan un 70% de las líneas de código y de hecho tenemos un % firmado que debemos cumplir, aunque como tu bien dices, el número de casos a probar es infinito. En mi opinión lo que mejor resultado nos da es el feedback que da el cliente con cada iteración y los bugs que se obtienen de utilizar la aplicación en el mundo real, sin eso, probar sólo las líneas de código no sería suficiente.
Un saludo,
Alberto Almagro
Gracias Alberto!
Totalmente normal lo que haceis con el cliente.
Vamos hablando!
Es una buena recopilación de frases Javier.
Una de las frase que siempre me ha gustado mucho es: «las pruebas unitarias y las de integración son lo mismo, venga nos las saltamos y directamente a las pruebas de usuario».
Todo esto en el contexto de una metodología clásica y en un proyecto que lleva retraso.
Saludos.
Sí, lo de saltarse pruebas es un clásico 🙂
Javier, interesante post, muchas verdades expuestas. Mi aportación respecto al punto 8. Yo he utilizado esa expresión, para referirme a la cobertura que teníamos de test unitarios. Métricas automáticas obtenidas con un plugin de maven, en el contexto de CI. “El software está probado al 70%” en nuestro contexto hubiera querido decir que las pruebas unitarias automatizadas, lanzadas por el servidor de integración continua, cubrían el 70% del código fuente. De hecho, nuestro ratio era cercano al 80%.
Saludos. Alberto Morales.
Alberto,
Se entiende perfectamente el mensaje 🙂 sin que dejen de ser curiosas ciertas expresiones.
Saludos