Como ya comenté en pasadas entradas, hoy vamos a hablar del parasitrón Agile. Ya hemos comentado en otras entradas que una de las principales características de este elemento es la implementación de una metodología por la propia metodología en sí y no por los beneficios que produce. Para nuestro amigo es mejor decir que es Agile que entender qué pretende esta metodología.
Primero deberíamos entender nosotros mismos ¿Qué es Agile? no sea que compartamos más de lo que creemos nuestro elemento de estudio. Creo que, para entender Agile, es de obligada lectura leer el manifiesto Agile https://agilemanifesto.org/. Este manifiesto expone 12 principios que deben seguir las metodologías Agile, porque Agile en sí misma no es una metodología concreta; estas podrían ser CRUM, Kambas, etc.
"Nuestra máxima prioridad es satisfacer al cliente a través de una entrega temprana y continua de software valioso"
El parasitrón Agile entiende este principio como poner fechas. Así que gestiona por fechas. "Esto", que nadie sabe muy bien qué es, tiene que estar para el martes, aquello para el miércoles y lo demás para el jueves.
Desde pequeños hemos aprendido las fechas, estas son importantes y todo el mundo las entiende por ello, todo el mundo está capacitado para gestionar por fechas y las fechas son inamovibles. Da igual cómo se estimen y qué se realice en ese proceso. Una fecha es una fecha y, si no entregas en la fecha, te has retrasado y si entregas en la fecha todo está bien. La consecuencia de esto suele ser que se entrega en fecha software basura que parece que funciona ya que nos preocupa más la fecha que la calidad de lo entregado. Este es el mundo de los desarrolladores de código del "copy paste" donde, si funciona para el martes todo da igual, lo importante es la fecha.
Aquí la clave es el "software valioso", este termino debe significar que tenga valor, hoy y también que lo mantenga en el tiempo, ¿No?, pues para el parasitrón va a ser que no.
"Bienvenido a los requisitos cambiantes, incluso llegando tarde al desarrollo. Los procesos ágiles aprovechan el cambio para dar ventaja competitiva del cliente."
La norma de este departamento Agile es que, una vez que comienza el sprint no se pueden cambiar los requisitos, aunque en el proceso de desarrollo se descubra una forma mucho eficiente de hacer esa funcionalidad que represente una mejora para nuestros clientes. Un requisito es un requisito y no se puede estar cambiando. Firmado : El parasitrón director de Software.
Pues no, no es así, en los sprint pueden aparecer cambios y lo mejor quizá es que no aparezcan, pero eso se obtendrá por la madurez del equipo, entendiendo por madurez la evolución natural de no repetir siempre los mismos errores, y no por unas normas que contradicen los principios mismos del Agile. Los parasitrones son muy de poner normas para poder saber con una evaluación simple qué está bien y que está mal. Pero el mundo es mucho más complicado que un simple "si cumple la norma bien, si no la cumple mal"
La situación cuando alguien quiere cambiar algo en un sprint suele ser parecida a esta....
"Entregue software de trabajo con frecuencia, desde un par de semanas a un par de meses, con preferencia a la escala de tiempo más corta."
Este principio nuestro elemento lo suele cumplir muy bien, esto de las fechas lo domina, el problema es qué se entiende por entregar. Entregar debe ser: "listo para que el cliente lo use", lo que significa que cada 2 semanas se realizan despliegues en producción. ¿Cómo es posible si para pasar algo a producción tenemos el comité de cambios de desarrollo a calidad, el comité de cambios de calidad a producción, el comité de validación de calidad, el comité de riesgos informáticos, el comité de seguridad, el comité de calidad, el comité de arquitectura, el comité de cumplimiento y el comité de coordinación de comités? solo para reunir a todos esos comités se necesitan al menos otras 2 semanas que permitan que un montón de materia parasitrónica opine sin ningún conocimiento de lo realizado, opine solo por el mero hecho de opinar.
Este es el universo Agile parasitrón. Lo reconoceréis fácilmente porque normalmente el equipo que desarrolla es mucho más pequeño que los miembros de los distintos comités.
Ejemplo del ultimo comité de paso a producción de cualquier compañía parasitronica...
"Negocio y desarrollo deben trabajar juntos todos los días durante todo el proyecto".
En el universo parasitrón esto se entiendo cómo: "Vamos a reunirnos periódicamente. Tú (negocio) me dices lo que tengo que hacer y yo lo hago".
Nada más lejos de la visión Agile. La visión de Agile es que el equipo es uno solo y que debe trabaja forma conjunta, no con reuniones de proveedor vs cliente, sino en un trabajo continuo y constante donde las soluciones tipo Azure DevOps, Jira, etc. tienen un papel crítico, para que no nos pasemos reunidos todo el día sin poder hacer otra cosa, sino para su propósito, que es la colaboración a lo largo de un proceso. Aunque en el universo que nos ocupa esto se transformará en el reporte de horas para poder justificar porque el equipo está muy ocupado aunque no entregue nada. Además eso nos proporciona la posibilidad de crear el equipo de gestión de metodología que velará por el buen cumplimiento de la metodología. O sea que todo el mundo meta las horas en la herramienta de horas, no sea que alguien pregunte qué hacemos y no le pueda dar un informe que justifique lo que hacemos. Nadie ha pensado que si te hacen esa pregunta es porque no confían que estés haciendo algo de valor para la empresa. ¿De verdad pensáis que sí lo que entregáramos tuviese "valor", es decir, crease mas ingresos o beneficios alguien se haría esa pregunta y menos alguien del equipo? Hala, lo que ha dicho, que negocio es parte del equipo. Sí y el equipo de desarrollo (o tecnología) parte del negocio.
En esta ilustración podemos ver la típica reunión de sprint planning donde ser acuerdan los términos de .... ¿la rendición? ojalá fuese una broma pero normalmente estas "reuniones" e plantean más como una lucha de poder que como lo que son un equipo trabajando para lograr entregar un producto.
Pero no creamos que esto es culpa solo de los parasitrones tecnológicos. En muchos casos el parasitrón de negocio tiene una excusa fantástica para justificar su incapacidad plena señalando a tecnología con el dedo acusador: el producto de la competencia funciona mejor, con este CRM no se puede trabajar, no puedo hacer seguimiento de marketing... el cajón de las excusas está lleno de buenos argumentos y si tienes un CEO parasitrón cualquiera le parecerá buena.
Aun nos quedan más principios por revisar, los veremos en próximas entregas ...
"La suerte sonríe a la mente preparada".
¿En qué película dicen esta frase?
Para que luego no os digan que el cine de acción no es profundo ....
Comments