2

Carta de un Desarrollador ágil a un UX fanboy


Lo que he llamado “carta” es una respuesta muy meditada de David a un post que redacté hace mucho tiempo, (en Twitter @davidcontrerasm ) él es Ingeniero de Software y Diseñador UX especializado en movilidad. Tuve la oportunidad gratísima de trabajar con él en 4iKIM.com y es un experto en aplicación de metodologías ágiles y gestión de equipos de desarrollo. Y a decir verdad, vale la pena publicar su comentario pues es acertadísimo.

Creo que hay algunas cosas que habría que dejar claras con respecto a qué son las metodologías ágiles, cuál es su propósito y su utilidad.

Déjame contarte una historia (seré muy breve, lo prometo):

Cuando en los años 40 se empezó a desarrollar Software (con válvulas y relés, alucina), la escritura de programas era algo casi “artesanal”.

El “mago del software” que se ponía delante de aquellas máquinas, sin formación específica de ningún tipo y apenas habiéndose leído su manual, escribía programas a su criterio y como buenamente podía.

Apenas sí se generaba documentación sobre los proyectos, no había metodologías de ningún tipo, y si el “mago” se iba de la empresa, muchas veces el Software acababa muriendo, ya que ninguna otra persona sabía cómo manipularlo o mantenerlo.

Este sistema de trabajo se mantuvo más de 20 años, hasta que a finales de los 60 a un grupo de iluminados, cansados de las desviaciones en plazo y calidad de los proyectos de Software se les ocurrió la idea de crear marcos de trabajo y metodologías para controlar estos procesos, tomando muchas ideas de la producción industrial.

Como en un movimiento pendular, se paso del caos y el “sindios”, a (en muchos casos) una marea de documentación y papeles que se generaban más para justificar el trabajo de los desarrolladores y las abultadas facturas de las consultoras que para crear Software de valor: El sistema seguía sin funcionar. Sobre todo porque ponía el foco en los procesos, y no en las personas, que son al final las que desarrollan el Software.

Sin embargo, ese sistema se mantuvo por más de 30 años, de hecho en muchas empresas todavía se usa, se llaman “metodologías predictivas”, y ¡hasta funcionan para algunos proyectos predecibles! Y mejor aún en aquellos que son monstruosamente grandes e involucran a mucha, mucha gente.

Como desgraciadamente esos no son la mayoría, en el año 2000 un grupo de desarrolladores, tomando como tesis el “sindios” y como antítesis las metodologías predictivas, y en un nuevo movimiento pendular, crearon las metodologías ágiles como síntesis de los dos marcos anteriores.

Las metodologías ágiles ponen el foco en las personas, y te dicen CÓMO debes hacer las cosas, no QUÉ cosas debes hacer, ya que esto último ni es su responsabilidad ni pretende serlo. Te indican cómo organizar tu trabajo, cómo relacionarte con el resto de personas del equipo, cómo involucrar a tu cliente en el proyecto, como visualizar el flujo de trabajo, cómo planificar los entregables…

¡¡¡aunque estos entregables sean totalmente incorrectos desde el punto de vista del usuario final!!!

Esta idea se ve claramente en el hecho de que a las metodologías ágiles muchas veces se les ataca, por ejemplo, diciendo que no generan suficiente documentación sobre los proyectos, pero ¡espera! es que no dicen QUÉ documentación generar, cada uno que genere la que quiera

Por eso no tiene sentido que te quejes de que la usabilidad en las aplicaciones no mejora con la aplicación de SCRUM. Es como quejarse de que se sigue sin generar documentación o de que no se separa en capas el código. ¡NO ES RESPONSABILIDAD DE SCRUM!

Si quieres gestionar proyectos usa SCRUM, si además quieres mejorar la calidad de tu código usa TDD, si además quieres mejorar la calidad de tus despliegues usa Integración Contínua, si además quieres expresar el funcionamiento de algunas partes complejas de tu Software usa UML, si además quieres mejorar la colaboración entre tus programadores usa Pair Programming…

Lo mejor de todo, es que la aplicación de metodologías ágiles es totalmente flexible. Yo mismo uso una adaptación particular de Kanban que se ajusta a mis necesidades que además puede combinarse con otras técnicas ¿Por qué dices que es cuadriculado?

También dices que las metodologías ágiles están sobrevaloradas y que se olvidan “del cliente y el producto” ¿Conoces el rol de “Product owner” de SCRUM? ¿Y cómo se prioriza el “Product Backlog”? ¿Dónde dice SCRUM que las historias de usuario son sólo “código”? ¿Dónde has leído que no puedan usarse test de usabilidad en SCRUM? ¿O Mock-ups y Wireframes? ¿O técnicas de Eyetracking con el Software generado?

Hablas a continuación de UX (que por cierto me encanta) como la solución a todos estos problemas, sin embargo ¿Cómo te permite UX expresar el funcionamiento de una parte de tu Software que no tiene representación en la Interfaz de Usuario? (me vienen a la cabeza los diagramas de secuencia o de estado de UML) ¿Cómo te permite UX planificar un proyecto? ¡No puede!

Como ves, se están juntando, como se dice en España “churras con merinas” (dos tipos diferentes de ovejas). UX no te permite hacer nada de lo que te pregunto porque NO ES SU RESPONSABILIDAD, de la misma manera que no es la de SCRUM garantizar la usabilidad del producto sino garantizar que el producto es lo que el cliente ha pedido y satisface sus necesidades, incluso en entornos cambiantes.

Hablas de UX como “la herramienta definitiva”, cómo si con un destornillador, por muy bueno que sea, pudieses hacer todo lo que necesitas…pero no: UX encaja muy bien dentro de la aplicación de metodologías ágiles, como una herramienta más dentro de tu caja de herramientas, pero no es aplicable por sí sola.

Si te has encontrado problemas en equipos de trabajo que aplicaban SCRUM, se me ocurren dos cosas: La primera es que SCRUM no puede aplicarse de un día para otro. Lleva meses conformar un equipo de trabajo compenetrado y que respete y aplique las reglas de SCRUM, y segundo, puede ser que ninguno de los integrantes de ese equipo sean expertos o les guste particularmente el tema de UX, por lo que no se aplicará.

Por último y para terminar, hablas de “post-agilismo” como si fuese la antítesis del agilismo, como si echase por tierra todo el trabajo del “Manifiesto ágil” y demostrase que no funciona. Curiosamente los principales impulsores del post-agilismo son personas que llevan varios años usando metodologías ágiles que se preguntan “¿y ahora qué?¿Cómo podemos seguir mejorando?”.

Pues ahora estamos en otro movimiento pendular, que toma como tesis las metodologías predictivas, como antítesis las ágiles, y que está creando soluciones como CMMI Ágil o PMI Ágil por un lado, y soluciones radicalmente distintas por otro. ¿Serán la solución definitiva? Seguramente no, pero nos aproximarán un poco más a crear Software de calidad, sin llegar a ser un incordio el aplicarlas.


Foto por: lucamascaro via Compfight cc

Tags:
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