viernes, 18 de abril de 2014

Corrupción o acomodación ágil

Después de leer un artículo muy interesante de corrupción ágil de Robert C. Martin y de reflexionar un poco acerca de experiencias del pasado, creo que este tipo de entradas en realidad son una radiografía de lo que sucede en nuestro medio. Intentamos acomodar todo de acuerdo a nuestra conveniencia, a nuestro discurso corrompiendo en esencia los principios ágiles.

No estoy diciendo que la corriente ágil sea la verdad absoluta, de hecho no lo es, pero si creo que se debe ser consecuente con los principios que se recitan a viva voz. No creo en fanatismos desbordados pero tampoco en la acomodación relativa de las cosas por simple conveniencia.

Entrando al grano, si en nuestras empresas se han venido trabajando iniciativas como CMMI o TSP/PSP o similares es muy probable que al aparecer un enfoque ágil, este se vea como una amenaza, debido a que muchas Organizaciones e incluso la academia han vendido durante años libros, cursos y costosas certificaciones con la promesa de que todo será mejor, que solo si alcanzas  cierto nivel entraras a grandes ligas. Ante la adopción de prácticas o técnicas ágiles, estas se verán con cierto recelo por los promotores o líderes de dicha burocracia e intentarán atacarlas a toda costa con argumentos como: eso acá se hace de esta manera, eso es equivalente a esto, ¿para qué entregar software en periodos cortos sin la documentación necesaria?, ¿y que pasa con el cronograma?, ¿cómo sé el porcentaje de avance?, ¿y los riesgos?, ¡ahhh esas actividades se ven bonitas y por eso me llaman la atención!, adoptemos una buena matriz de riesgos, etc.

Cuando se intenta ajustar CMMI o TSP a SCRUM, aparecen ideas como: ¿en los SPRINTs hago las inspecciones, los diseños de alto nivel y detallados, el post-mortem lo puedo reemplazar, el registro de tiempos en el dashboard, los riesgos?. En general se busca acomodar dichos modelos como sea adoptándolos para que cumplan con lo que ya está definido y desde luego sin generar problemas.

En la industria, en países y en general en diferentes contextos se han venido adoptando las prácticas ágiles porque se han comprobado con resultados. Sin embargo, cuando se intentan adoptar sin convicción se busca a toda costa la trampa, los argumentos rancios y sobre todo las posiciones con poca argumentación pero si con una actitud bélica (no puedo perder esta batalla) como: ¡no es necesario entregar software funcionando o una iteración no tiene porque tener entregas de valor! ¿qué es valor, acaso no es el tiempo, el alcance y el costo? ¡no es necesario que los miembros de un equipo de trabajo estén trabajando juntos!

Aún es más difícil cuando empiezan las discusiones acerca de los principios ágiles. De igual forma hay Organizaciones que promueven certificaciones de SCRUM olvidando dichas bases acomodando sus intereses en actividades relacionadas con cursos, coaching, entre otros, olvidando la coherencia.

En otros escenarios existen ciertos personajes que acomodan su discurso ágil, buscando fines publicitarios, de marketing o por cumplir con las exigencias de un Cliente; en términos generales se disfrazan pero en si son farsantes y no pueden sostener una mentira por mucho tiempo pues no tienen convicción. Estos a todo lo llaman ágil o SCRUM e incluso incrustan practicas o técnicas con aleaciones raras o hacen propias teorías o modelos ajenos; quizás en la vida han desarrollado una buena línea de código.

Cuando llega la discusión de las prácticas ágiles todo empeora, pues aparece TDD, integración continua, refactorización, programación por pares, entre otros, y alguien preguntará ¿y eso para qué si lo que yo necesito es SCRUM?. Ahí nace un problema serio pues se prioriza el management sobre las técnicas orientadas a la generación de buen código, saludable y duradero que en esencia son el fundamento de la corriente ágil.

Es obvio que en una empresa es complicado iniciar modelos ágiles arrancando todo a la vez, de la noche a la mañana; hay que decidir por dónde comenzar, pero no hay que olvidar la visión, el fin, los objetivos propuestos creyendo y aplicando lo que se profesa. En si, creo que debemos ser buenos artesanos de software adoptando las prácticas y técnicas que nos den más productividad (como XP) a la vez que implantamos a SCRUM, LEAN u otro modelo.

Es probable que muchos hablen del ser práctico con frases de cajón como "lo perfecto es enemigo de lo oportuno", así funciona, da igual, pero definitivamente creo que debemos trabajar en lo que creemos y ser coherentes y no colocar sellos ágiles "made in" a cualquier cosa. Ejemplo: CMMI for Development 1.3 - Agile approach.




2 comentarios:

  1. Gabriel, comercialmente siempre va a ocurrir esto con cualquier tendencia, habrá quienes lo ejecuten bien y quienes quieran montarse en el tren de la victoria diciendo que si cumplen cayendo en falsas adopciones o pobres adopciones.

    Lo interesante es que notar la diferencia entre los buenos y los malos ejecutores de Agile es fácil, y los primeros con seguridad se quedarán con la mejor porción del mercado.

    ResponderEliminar
    Respuestas
    1. Montarse en el bus de la victoria está bien con convicción ...si no es así no se podrá hacer las cosas bien.

      Eliminar