Darcy

A raíz de mi actual trabajo, he tenido que documentarme, aprender e investigar sobre las diferentes metodologías de desarrollo ágil.

Hace unos meses apareció en mis feeds un artículo escrito por Anthony Colfelt llamado Bringing User Centered Design to the Agile Environment que expone aspectos negativos y positivos acerca de integrar el diseño centrado en el usuario al desarrollo ágil, particularmente en Scrum.

Escribí y traduje este post en 3 partes, el cuarto post lo dejaré para mis reflexiones personales. Acá vamos:

“En cuando tuve la oportunidad de obtener un trabajo post burbuja .com lo tomé. Gocé del lujo de hacer las cosas exactamente como pensaba que era correcto y por un tiempo fue de verdad fantástico.

Formé un equipo con un investigador de usuarios, un arquitecto de la información, diseñadores visuales y de interacción, e incluso establecimos un laboratorio de usabilidad donde tuvimos testeos con usuarios regularmente.

Desafortunadamente, el entusiasmo que tenía por mi nuevo trabajo disminuyó después de seis meses cuando un ejecutivo fue nombrado como Jefe de Desarrollo de Productos, quien nos aseguró que conocía Scrum mejor que nadie.

Como Director Creativo le cedí autoridad para desarrollar el producto como él estimara conveniente.

He trabajado con Scrum antes, entrenando con Ken Schwaber (autor y co-fundador de la Agil Alliance) y sabía un par de cosas desde la experiencia, sobre cómo lograr integrar con cierto éxito un equipo de diseño a uno Scrum.

Esto siginificó que el equipo de diseño debía trabajar en los sprint (trabajo iterativos de 1 mes) por delante del equipo de desarrollo. Pero el nuevo ejecutivo, insistía en que se debía seguir las instrucciones al pie de la letra, es decir, todas las actividades debían ser incluidas en el mismo sprint, considerando también el diseño.

Vinieron requeririmientos desde la imaginación del jefe de desarrollo de productos, y como consecuencia de la presión del tiempo el diseño fue apresurado y mal concebido, en tanto el desarrollo fue también hecho a la rápida, mal hecho o peor aún, sin terminar.

El final de las reuniones informativas del Sprint consistía en una reprimenda para todo el equipo por parte de los ejecutivos (ya que nadie había entregado lo que habían comprometido por tratar de hacer demasiado, o no habían hecho lo suficiente). Cada Sprint consistía en tratar de arreglar lo malo del Sprint anterior “o tirarlo debajo de la alfombra“, además el desarrollo era inestable sobre un código basura. La moral disminuyó, el producto era malo, el personal empezó a rotar… fue horrible.

Este es un mal ejemplo extremo de Scrum. No estoy en contra de las metododologías de desarrollo ágil aunque me da rabia a veces y siento temor cuando escucho a alguien cantando sus alabanzas, sin tener mucha experiencia.

En los últimos ocho años, he visto metodologías ágiles mal aplicadas con más frecuencia que las bien aplicadas (pero sí, se puede hacer bien también). La idea de este artículo es presentar cómo las prácticas de diseño centrado en el usuario (DCU) pueden mitigar los riesgos inherentes del desarrollo ágil y cómo éstos pueden ser integrados dentro de los enfoques de desarrollo ágil.

¿De dónde proviene el desarrollo ágil?

Fue creado por un grupo de desarrolladores, Agile es un enfoque de desarrollo iterativo que toma pequeños pasos hacia la definición de un producto o servicio. Al final de cada etapa, se construye algo que se puede mostrar al cliente (o al dueño de este producto o servicio), de esta manera, es posible incluir al cliente en oportunidades donde las metodologías en cascada suelen fallar.

El desarrollo ágil va en la línea de trabajar y construir algo a medida que se avanza en las tareas, en lugar de hacerlo  al estilo del desarrollo en cascada (donde se profundiza en la especificación) y donde a veces se descubre mucho después que no es posible construir partes de la especificación por determinadas razones (por ejemplo: un error de cálculo o nuevas necesidades).

El desarrollo ágil se puede considerar como una estrategia de gestión de riesgo. Pero en este contexto, a menudo los desarrolladores toman contacto directo con un cliente que no sabe qué es o qué hace un diseñador de experiencia de usuario, arquitecto de información o diseñador de interfaz.

Sabemos que profesionales de estas disciplinas suelen interpretar lo que los clientes quieren y traducirlo a algún tipo de especificación para los desarrolladores. Sin esta función, el desarrollador es libre para elaborar y construir lo que cree que el cliente quiere.

Debido a que el desarrollo ágil necesita mucho compromiso con el cliente, al final de cada iteración (que puede ser cada semana) se reduce el riesgo de ir demasiado lejos hacia la creación de algo que el cliente no quiere. Como tal, es un mecanismo de defensa para las necesidades cambiantes de un cliente durante el desarrollo.

¿Por qué la gente celebra esto?

Es atractivo ante la posibilidad de un retorno más rápido de la inversión, porque se podrían ver resultados u obtener una versión del software antes. En el corto plazo, esto suele lograrse. En el largo plazo puede lograrse también, aunque sólo cuando el equipo no ha sido víctima de la tentación (se abordará con más detalles después).

El desarrollo ágil también es bueno en la generación de impulso, dado que con las iteraciones se puede tener control sobre la velocidad dado que se está continuamente revisando avances y logros. Es necesario alentar a los desarrolladores a hacer sólo lo necesario para cumplir los requisitos.

Debido a que se hace hincapié en contacto cara a cara por un equipo multidisciplinario, las metodologías de desarrollo ágil, tienden a alentar que profesionales de diversas áreas contribuyan desde sus diferentes perspectivas. Esto es generalmente una influencia positiva en la innovación y la velocidad de resolución de problemas. El equipo está facultado para tomar decisiones en cuanto a cómo jerarquizar sobre los requisitos que deben cumplirse.”

Continuará…