Agile User Experience o Experiencia de usuario Ágil
- Tema: Usabilidad
- » Se lee en 241 segs
Últimamente ha vuelto a la vida el término “Ágil o Agile (áyail en spanglish)” y he sido partícipe de varias interesantes discusiones sobre el desarrollo ágil (Agile development ) y el papel de la usabilidad en desarrollos basados en esta filosofía. Así que vamos a hacer el ejercicio de repasar qué es esto del Agile User Experince o Agile Usability Engineering o como queráis llamarla… en esta oportunidad me centraré en Agile User Experince, porque la experiencia de usuario implica muchas más metodologías que son claves en el proceso de desarrollo de cualquier aplicación y además porque soy de la “escuela de Morvile“, otro día explicaremos esto de la escuela Morvile.
Desde el el principio: ¿Qué es Agile Development? y ¿Cuándo la utilizo?
Por allá en el 2002 Scott Ambler desde los cuarteles de IBM, se le ocurrió que debía desarrollar un “algo” para hacer de los proyectos de desarrollo menos costosos en tiempo — quebradero de cabeza de todos y razón clásica de exclusión de metodologías UCD en desarrollos (Vieja escuela) — En fin, Ambler comenzó a investigar y se topó con los resultados de Kent Beck (Project Leader para Chrysler) quien desarrollo Extreme Programming (XP o dearrollo extremo) que consistía en algo así como pica código a lo bestia con la mayor simplicidad posible y corregir sobre la marcha, es un poco más complejo que eso pero para otro día esto del XP.
Ambler, le llamó la atención este método y decidió crear lo que sería más adelante el Manifiesto sobre el Desarollo Ágil (Agile Manifesto) que no era otra cosa que una filosofía rompedora de paradigmas, una filosofía que se basaría en eliminar de la metodología de desarrollo todo el tiempo invertido en planificar a la perfección y dar más peso esfuerzo a crear con sentido común y con objetivos claros.
Esto hace que los períodos de entrega se hagan mucho más cortos y dinámicos, en si esta filosofía se basa en 4 valores esenciales:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Pues, bajo estos principios se fundamenta el desarrollo ágil, es decir dejemos de planificar hasta el último detalle la perfección no éxiste, para qué perder tanto tiempo en planificación si al finar tenemos que cambiar porque nos hemos dejado cosas en el camino, al final nos gastaremos grandes cantidades de dinero en gestión y mediación con públicos internos y nos olvidamos que hacemos algo para un “Usuario” que es el que nos pagará o recompensará el servicio que le ofrecemos.
Para los gestores de la vieja escuela el planteamiento les debe sonar a “vamos a hacer una aplicación a lo artesanal, a piñón” pues resulta que no es así…. Con un desarrollo ágil nuestro enfoque es darle el acento a los usuario y al proceso de interacción en vez de pensar si monto un Sharepoint o te pongo 2 vignette con Oracle entrepirse, es darle la vuelta a la tortilla, es desarrollar en vez de invertir 4 semanas en un funcional de 260 páginas, que al final el único que se lo lee entero es el que lo escribe y se lo lee entero sólo para corregirlo (3 horas más).
En conclusión esto del Agile es: vamos a simplificar, simplifiquemos todo lo que podamos, corrijamos a medida que lo hacemos. Me gusta mucho una frase que escribió Eduardo Manchón sobre desarrollo ágil hace un par de años:
Cuanto más rápidamente ejecutes, antes descubrirás qué es bueno, qué es malo, qué es suficientemente bueno y podrás hacer mejoras. Rectificar no es fácil, conlleva ser humilde y modesto.
El mensaje es claro, ¡aterricemos! Pero seamos consientes que esta filosofía no es una ley ni un principio y que no se puede aplicar a todos nuestros proyecto, no podemos montar una terminal financiera de esta manera el riesgo es muy alto. Pero si que podemos aplicarla para proyecto menor envergadura. Para ilustrar con mayor claridad esta cuestión me salta a la memoria una frase de Peter Drucker:
Plans are only good intentions unless they immediately degenerate into hard work.
¿Cómo encaja la Experiencia de Usuario en todo este asunto del ágil?
Simple.
Recordemos el primer principio del manifisto
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Para satisface al usuario desde el desarrollo sólo puedo hacer una cosa, aplicar UCD (Diseño Centrado en el Usuario o User Centered Design) y es justamente en este punto donde hago un llamado a la Experiencia de usuario, no nos podemos quedar cortos ya que lo hacemos rápido hagámonos bien, pensemos en experiencias y no en la técnica. A veces creo que cuando hablamos de UCD no abarcamos lo suficiente ya os adelantaba que era de la escuela Morvile.
Por lo tanto, y vuelvo a pregunta, ¿Cómo lo hago? para responder Thomas Memmel, de la Universidad de Konstanz en Alemania, recopiló unas tablas comparativas entre metodologías de UCD utilizadas en modelos clásicos y con filosofía Ágil. También, como buen investigador nos introduce un nuevo término Usage Centered Design (Diseño centrado en el uso) con lo cual muestra un enfoque diferente.
En resume:
- Creemos un grupo de trabajo de pocas personas
- Reduzcamos los procesos de validación, dejemos esta responsabilidad al usuario final si no loe gusta te lo dirá pero como te lo ha dicho antes puede que no haya problemas
- Diseños aplicaciones simples, el usuario te lo agradecerá (1 o 2 funcionalidades a la vez, principio de Pareto total)
- Utilicemos prototipado rápido “Paper prototipe”, aunque la mayoría de los clientes no lo ven claro si no está pintado… pero como hemos dicho, esto es para el usuario no para el directivo
- Conceptualicemos conjuntamente con el usuario, diseño participativo como método de toma de requerimiento. Pero con usuarios reales
- Reflexión y corrección, “Errare humanum est“, no tengamos miedo
- Simplicidad, ante todo simplicidad. Ya le he dicho antes pero vale la pena repetirlo
- Has pruebas, como siempre
- Crea pensado en componentes y modelos, ensambla y prueba. Luego corrige
- Aplícalo con conciencia, no pretendas programar una central de trafico aéreo con este modelo. Mide el riesgo y el impacto
- Esta filosofía es compatible con el mundo 2.0 en el que vivimos
- Innova, reinvéntante, siempre!
Finalmente, considero que hay mucha discusión y polémica en cuanto a estos modelos, pero no hay mejor fórmula para disipar dudas que probarlo.
Por estas razones, la imagen ilustrativa del Speed Racer (AKA Meteoro o Mach GoGoGo) quien con un equipo de 3 personas lograba conquistar el corazón de sus fans (los usuarios) porque la final Speed Racer entendió que su objetivo era ganar carreras rápidamente sin mucho desarrollo y poco a poco ir creando nuevas funcionalidades para su magnífico coche, en los primieros capítulos el coche no daba esos saltos con sólo presionar el botón C. Con la ayuda de Chim-Chim, Sparky y su padre hacían el equipo perfecto… seguro que viajaban sin “funcionales de 500 páginas bajo el brazo”
Comentarios
¿Quieres Comentar?
- Usándolo.com es el blog personal de Jorge Márquez, dedicado a conversar sobre usabilidad, diseño web y tecnología.
¡ Sindica el contenido de usandolo.com usando RSS !
Temas
Últimamente
- Mobile web, la tarea pendiente
- Los filtering sliders de Facebook
- Gmail: Problema de interacción elimina mi lista de contactos
- Etiquetar o categorizar, allí la cuestión
- Agile User Experience o Experiencia de usuario Ágil
- Leyes y principios: Hick’s Law
- Tagcloud: ¿Ayudan o molestan? Depende del planteamiento…
- La diferencia entre Redes sociales y Redes sociales
- Prototipando para Facebook
- Conferencia: Comunicación y usabilidad en la empresa 2.0
Archivos
- Diciembre 2008
- Noviembre 2008
- Octubre 2008
- Septiembre 2008
- Agosto 2008
- Julio 2008
- Junio 2008
- Mayo 2008
- Abril 2008
- Marzo 2008
- Febrero 2008
- Enero 2008
- Diciembre 2007
- Noviembre 2007
- Octubre 2007
- Septiembre 2007
- Agosto 2007
- Julio 2007
- Junio 2007
- Mayo 2007
- Abril 2007
- Marzo 2007
- Febrero 2007
- Enero 2007
