Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.
UX, agile y cohesión del equipo
Experiencia de usuario
23/12/2010
|
Daniel Torres Burriel
Confieso que hace meses que estoy seducido por todo lo que tiene que ver con el desarrollo ágil. No en vano por esta casa en más de una ocasión he tratado de acercar a quienes os dejáis caer por aquí algunos de los conceptos del desarrollo ágil, relacionados con las hierbas que solemos tocar en este blog.
Vaya una pequeña muestra:
- Arquitectura de información y desarrollo ágil
- Diseño centrado en el usuario y desarrollo ágil
- Integración de experiencia de usuario y desarrollo ágil
Desde hace un par de meses estoy trabajando en un proyecto, del que os podré hablar a no mucho tardar, en el que estamos adoptando poco a poco muchas de las consideraciones que se hacen desde el mundo del «agilismo». Y en mi labor de gestor del proyecto estoy tratando de integrar el espíritu del desarrollo ágil a la pura gestión del proyecto y del equipo.
Miembros del equipo de proyecto, distendidos y entre risas
Una de las premisas que valoro en todo momento cuando de gestionar un equipo se trata, es la de que éste está formado por personas. Que además de ser personas tienen una serie de habilidades profesionales, unas capacidades y un nivel de excelencia extraordinario.
Considerar al equipo como simplemente la suma de partes sería un error de bulto, más si pensamos que está formado básicamente por talento. Y si a eso le añadimos elementos como:
- Escribir software/aplicaciones es un proceso técnicamente complejo y cambiante
- Desarrollar aplicaciones es un proceso que se extiende en el tiempo, y en ocasiones las necesidades o prioridades cambian durante este proceso
- Tanto el diseño centrado en el usuario como el desarrollo ágil no son metodologías, sino planteamientos filosóficos
- El desarrollo ágil no es una metodología con pasos establecidos, es simplemente una manera de pensar y de trabajar
- Hay varias metodologías que permiten desarrollar o implementar estas filosofías: Extreme Programming o Scrum para el caso del desarrollo ágil, y las seguidas por gentes como Adaptive Path, Cooper, Apple, Shedroff, Morville, Spool, Nielsen, y Norman para el caso del diseño centrado en el usuario.
No podemos llegar a otra conclusión, desde mi punto de vista, que no sea la basada en tres premisas:
- El equipo de trabajo está formado por personas, cambiantes, sensibles y ciertamente impredecibles en su ánimo
- Las relaciones personales tejidas entre los miembros del equipo son un excelente hilo conductor que permite desarrollar una capa de conocimiento común, apoyado en un alto grado de motivación autogenerada y retroalimentada de forma constante
- El papel del coordinador de un equipo de esas características se hace necesario en tanto en cuanto disminuye la presión y asume tareas no necesitadas del talento del equipo
Estas son simplemente unas reflexiones que os quería contar al hilo de una experiencia de trabajo que estoy teniendo. Si queréis hacer algún comentario al respecto, no os quepa duda de que estaré encantado.
En Torresburriel Estudio apoyamos el rediseño de tu producto digital, con un proyecto de acompañamiento donde aplicamos metodologías de diseño centrado en el usuario. Contacta con nosotros, y cuéntanos tu proyecto. Te enviaremos una propuesta adaptada a tus necesidades y presupuesto.
Siempre me ha gustado el concepto de Programación Extrema. Lo difícil es encontrar el proyecto «adecuado» donde poder (o que te dejen) aplicarlo.
«El equipo de trabajo está formado por personas» tan básico que se olvida en el 90% de los casos.
Marcos: ¿no son todos los proyectos adecuados para ello? Pregunto…
Lo bueno de XP y del «agilismo» en general es que puedes empezar siguiendo algunas prácticas(aunque haya gente que diga lo contrario…).
Más que proyectos, son contextos y clientes con los que es más difícil trabajar de forma «ágil», para mi depende principalmente de lo implicado que quiera estar el cliente y que el equipo(si lo hay XD) se atreva a cambiar de forma de trabajo. Yo creo que intentando trabajar teniendo en mente los 4 puntos del manifiesto ágil(http://www.agilemanifesto.org/iso/es/manifesto.html) es un camino por el que empezar.
Además que se pueden dar pequeños pasos con prácticas de XP seguramente empezando por hacer un desarrollo en iteraciones cortas y por tener una propiedad compartida del código. Otra cosa es querer empezar con scrum, que al final es un «framework» que marca el proceso de trabajo, y eso yo lo veo mucho más complicado de implantar «desde abajo».
PD: Menuda fotaca XD
[…] de desarrollo, la “cultura de equipo” o conceptos agile como el Code Ownership o la Arquitectura Compartida son deseables e incluso necesarios a nivel muy básico, sin esto no hay […]
[…] Agile se centra en la iteración constante. Porporcionar valor añadido cada 2-4 semanas, evolucionando un producto a lo largo del tiempo en lugar de hacerlo todo a la vez ya que es imposible saber lo que va a suceder de aqui a más de 2 semanas. Está basado en hipótesis, experimentación, lanzar en producción de forma rápida y medir en tiempo real. […]