5

Post-Agilismo, ese tabú de los tekis

Leí interesado un post sobre los métodos ágiles, si éstos están siendo tan sobrevalorados que al final su propia aplicación en el desarrollo de software llega a ser un incordio en vez de una herramienta por la cual se mejora el proceso de construcción de los productos. Vamos a ver qué acercamiento vemos sobre el Post-Agilismo.

He sido testigo de la implantación del método scrum en una organización que pensaba que desarrollaba software y lo único que he podido verificar es que los desarrolladores (a los que llamaré “tekis“) iban contra el tiempo abocados únicamente a la consecución de sus propias tareas, tan independientes uno del otro que podrían llamarse “islas de producción”, a nadie le importaba lo que el otro estuviese haciendo hasta el despliegue.

Ceñirse al famoso “scrum burndown chart” era razón de vida y obviamente el resultado final era un despliegue de algo realmente feo y lo que llamaría “felicidad desplegando caca” de los tekis.

Eran curiosas las reuniones del “daily scrum” porque eran momentos en que los tekis explicaban sus semejantes los avances y dificultades en la construcción del producto… y dirán ¿porqué me causaba gracia?, pues porque al momento de llevar el producto a la mínima validación por usuarios  todo su pomposo sistema de scrum se venía abajo por los garrafales errores de usabilidad y bugs propios del desarrollo, entonces, ¿qué cosa es lo que había fallado?, todo el ritual había sido seguido al pie de la letra, la documentación impecable, horas extras voluntarias por doquier, dolores de cabeza en los despliegues, autocríticas terribles al final y así en adelante peores lamentos que, cosa curiosa, yo sí lograba entender del porqué de estas cosas y lo comentaré al final.

He podido observar de cerca otro sistema de estos como el kanban, que también sigue otro ritual muy bonito con tarjetitas de colores que los tekis hacen con todo entusiasmo para construir los productos, debo decir que no he podido notar nada diferente en cuanto a lo cuadriculado de su aplicación y con resultados similares al scrum, usabilidad bochornosa y los consabidos bugs aquí y allá con su propia dosis de dolores de cabeza.

Estoy más que seguro que en todos estos métodos sucede lo mismo, es que hasta en los cómics de Dilbert hacen notar esto de forma poco sutil. Y ¿porqué es que pasa? Yo tengo una teoría que más bien va a ser algo más que certero:

En todos éstos métodos ágiles ha fallado lo que nos ha llevado de las cavernas a la luna: No aplicar el sentido común

Jason Gorman en su blog lo dice clarísimo:

Post-Agilism is simply doing what works for you (Post-agilismo es simplemente hacer lo que mejor se adapta a tus necesidades -traducción libre del autor-)

Ya no se trata de la rigidez y severidad con la que apliques tu método ágil, sino con la flexibilidad que sólo el uso del sentido común puede ofrecer, y esto lectores tiene muchísimo que ver con un factor que hasta ahora no se ha mencionado: Todos los esfuerzos, métodos, ideas, desarrollos, propuestas, reuniones, etc., deben estar enfocados a una sola cosa y nada más que a ello que es el buscar como crear soluciones y no únicamente construir producto.

Creo que es ésta la idea que resuelve todos estos dilemas del porqué no salen las cosas como las habíamos planeado. Construir soluciones entonces ya no es sólo hacer por hacer producto, sino tener un fin, un porqué, un qué, un cómo y un para quién, que son preguntas tan simples y tan poco utilizadas en el desarrollo de software únicamente porque no se quiere entender que, tal como dice Jason Gorman, lo que mejor funciona para nosotros es construir soluciones para usuarios y es ahí donde yo entiendo que el post-agilismo se integra con la UX, en muchos casos lo que mejor se ajusta es aplicar una forma de trabajo más ligera como el LeanUX (ideal para start-ups) o lo que mejor se ajusta para organizaciones mucho más grandes es contar con todo un equipo de UX, que oriente y no haga perder el foco a los desarrolladores que el fin de toda producción es crear soluciones, pero soluciones que resuelvan problemas que existan, no soluciones ineficaces para problemas inexistentes como lo decía en un post anterior. De hecho en este post se lee:

Se ha asociado a “Agile” la pasión por el código, olvidando al cliente y el producto. Agile se entiende hoy como todo lo que no es Agile.

Como yo lo veo es que el ciclo debe comprender más que sólo código y que el post-agilismo pudiera estar incluído dentro del proceso del diseño del producto (y no se entienda diseño por colorines), igual esta gráfica es mejor que mil palabras, ¿pueden ubicar dónde estaría inmerso el agilismo?

Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /web/htdocs/www.uxinperu.com/home/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1273