Un oxímoron, simplificadamente, viene de la combinación en una misma frase de dos palabras o expresiones de significado opuesto. Bien, si no conocías el termino seguro que se entiende mejor con algunos ejemplos: “silencio atronador” (si es silencio no puede ser atronador), “instante eterno”, “hielo abrasador”, “ladrón honrado”, “orden aleatorio”, “secreto a voces”, “soñar despierto”, etc. Bueno, ya sabes a lo que me refiero.
Aunque te pueda parecer raro, más allá de su uso en el lenguaje de uso típico de la calle, de la retorica y la poesía el mundo del desarrollo software también tiene sus oxímoron. El problema en nuestro caso es que es más difícil detectarlos, y caer en la cuenta de que son frases que ocultan cosas sin sentido.
Y no sólo tenemos oxímoron, también, e incluso siendo más difíciles de detectar, tenemos frases de dudosa veracidad, pero asumidas como ciertas, con el riesgo que ello, igualmente, conlleva.
Como ya sabes, y te he contado muchas veces, este quien aquí escribe tiene la suerte, y a veces el cansancio, de pasar por muchos sitios, empresas, equipos, charlas, etc. Y sin darme cuenta mi cerebro ha ido reteniendo una colección de curiosos oxímoron y frases de dudosa veracidad que hoy quiero compartir contigo, verás como es curioso el tema…
«Usamos Scrum con puntos función»
Esta es una frase curiosa. Los puntos función, sin perderme en definiciones, miden la cantidad de funcionalidad (se habla del tamaño funcional) partiendo de los requisitos. Típicamente, para calcularlos hay que tener los requisitos y estos, además, deben estar detallados y, normalmente, es usual, que se busque hasta que estén cerrados… ¿no eran todos los anteriores justo algunos de los elementos con los que no cuenta, y hasta caracteriza que no estén, un desarrollo ágil?
“Usamos un proceso ágil que se basa en cerrar antes de comenzar los requisitos”
Bueno, del estilo al anterior, si agilidad es “bienvenido el cambio”, “trabajar con requisitos cambiantes»… ¿cómo se puede cerrar los requisitos antes de empezar y decir que ese desarrollo es ágil? Yo no digo que no sea lícito, y que a algunos les funciones de maravilla, pero… ¿ágil?
“Planificar Sprints de Scrum con Diagramas de Gantts”
Nada impide poner en un diagrama Gantt, entiendo, los Sprint típicos de Scrum, pero, no sé… ¿pero qué sentido tiene? Aparte de que muchos pensemos que los diagramas Gantt pueden llegar a ser arma de destrucción masiva de proyectos, si lo suyo es que los sprint, o las iteraciones, duren el mismo tiempo, ¿qué tiene de valor ese diagrama de Gantt? ¿un montón de barras azules todas consecutivas de igual tamaño? No sé.
Ahora bien, no será que ese diagrama Gantt planifica al detalle un montón de fases y actividades que ya se acotan desde mucho tiempo atrás cómo van a ocurrir. No será que ya está diciendo los entregables que aparecerán en el futuro y por ello, asume requisitos cerrados. No será que estamos encajando un ciclo “predictivo” (el típico de un cascada) en un “adaptativo” (típico en agilidad) ¿No era uno de los objetivos de la agilidad la adaptación al cambio?
¿Requisitos cambiantes? ¿cómo se puede entonces planificar y acotar tanto el futuro usando un Gantt?
Puede ser lícito, pero… llamémosle desarrollo iterativo, o como queramos, pero no ágil o Scrum.
“Metodologías ágiles”
Esta ya ha salido por aquí en alguna ocasión. Frase muy común, pero prácticamente ninguna “metodología” ágil es metodología… son, casi por definición, meta-metodologías, “framewoks” o, más claramente, conjuntos de buenas prácticas. De ahí que no se apliquen al pie de la letra y que tengan, “por definición”, que ser adaptadas a cada empresa o equipo.
“Usamos un ciclo de vida iterativo, es decir, nuestro proyecto es ágil”.
También habrá salido por aquí en algún momento, que los proyecto ágiles utilicen un ciclo de vida iterativo con particularidades, normalmente, que este es iterativo e incremental (te dejo este post por si quieres ampliar el tema), que es de iteraciones cortas (típicamente semanas), que dentro de cada iteración las fases y actividades no necesariamente deben seguir la secuencialidad de típica de “mini cascadas” partidos en trozos (cosa que sí pasa en muchos ciclos de vida iterativos), etc., no implica que usar un ciclo de vida iterativo haga al proyecto ágil.
Pero es más, es que la agilidad implica más cosas, hoy en día asumimos que equipos auto-organizados, multifuncionales, un conjunto de valores concretos, una gestión particular, etc.
Terminando…
Bueno, no me quiero extender más, habría otros Oxímoron curiosos que podríamos destacar, como “PMP Ágil”, “CMMI Master”, “Metodología Cascada” (cascada no es una metodología, es un ciclo de vida), “Metodología UML” (ídem, UML es un lenguaje de modelado), “El software está probado al 70%” (realmente estamos diciendo que “hemos ejecutado con éxito el 70% de los casos de prueba”. El número de “cosas a probar” en una aplicación es típicamente infinito, ya sabes aquel post de que es imposible asegurar que una aplicación software no va a fallar), etc., pero los dejamos para otra.
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
Interesante todo el artículo, sin embargo el último punto me parece más interesante aún en el sentido cuando decimos que está probado 80% ó 90%. Cuando en verdad lo que se ha resuelto o se ha validado es bajo un porcentaje de unos casos de pruebas que se han definido. Es decir: que se han hecho las validaciones en los casos que podría fallar y en la que debería funcionar según los flujos que este debería hacer anteriormente documentados. Los error y pruebas que se pueden presentarse aunque no son infinitos, si son muy aproximados al infinito, por esta razón muy difícilmente por no decir imposible, podríamos decir que se ha probado completamente la funcionalidad de una aplicación sw.