Clase 6 Metodologías Ágiles aplicadas al proyecto (Guión de Clase)

Vista previa del material en texto

Clase 06. Metodologías Ágiles aplicadas al proyecto
Desarrollo Agile
‘Agile’ es un conjunto de metodologías para el desarrollo de proyectos que precisan de rapidez y flexibilidad para adaptarse a condiciones cambiantes del sector o mercado. Estas metodologías unidas a las técnicas que proporciona la investigación en UX, permiten introducir cambios rápidos muy enfocados a mejorar aspectos importantes de las interfaces o de los propios procesos.
Nuestra disciplina acompaña a las empresas en el camino de probar, testear y aprender lo más rápido posible y llevar adelante ese conocimiento a la acción. Las guía, se preocupa por fomentar y buscar un equilibrio entre los usuarios/clientes, la tecnología y los objetivos de negocio. Y todo, por supuesto, trabajando dentro de un equipo multidisciplinar. Y es que, crear una buena experiencia de usuario siempre será el resultado de un montón de personas poniendo atención a que el producto/servicio final sea de calidad.
Hay muchas formas, diferentes conceptos, enfoques y alternativas (Lean, Agile, Scrum o Kanban) pero al final, lo importante es adaptarnos a la empresa, al equipo y buscar en nuestra gran caja de métodos y herramientas la que mejor se adapte en cada etapa de nuestro proceso de trabajo. Nuestro rol en agile tiene que ser más de «facilitador» e invitar al resto del equipo en nuestro proceso de investigación y diseño para potenciar el intercambio de ideas.
Pasos a seguir en la implementación:
· Aterrizaje: definir estrategias de trabajo e integrar con alguna metodología ágil.
· Sprint de UX: trabajar para que el equipo de desarrollo tenga un prototipo de diseño ya testeado con usuarios y negocio.
Para ello, durante 2 o 3 semanas escuchamos la visión de negocio y del resto de Stakeholder del proyecto, participando en la toma de requisitos. Realizamos , según el proyecto, encuestas, entrevistas o test con los usuarios objetivos para detectar necesidades o validar hipótesis. Una vez finalizado ese proceso, lo convertimos en conceptos que generarán experiencias. A través del diseño de interacción planteamos los diferentes escenarios de uso y lo plasmamos en prototipos interactivos. Validamos las propuestas con los diferentes responsables del proyecto y usuarios para hacer ajustes, cambios, etc.
Al final de este trabajo se hacen las historias de usuario que nutrirán el Backlog. Para mapear historias solemos tirar técnicas como la de Jeff Patton. Esta técnica combina el concepto de diseño centrado en el usuario y la descomposición en historias de usuario y nos permite trabajar con una de las mayores problemáticas que aparece en la construcción de software: la elaboración de documentación compartida no genera entendimiento compartido.
El mapa de historias de usuario trata de mitigar el riesgo de este escenario a través de la gestión visual y la conversación. Este ejercicio, eso sí, tiene sentido si se hace junto a otros miembros del equipo (otros stakeholders, diseño y desarrollo). Esta forma de comunicación contribuye a generar una retroalimentación a través de la conversación continua entre todos.
De este ejercicio saldrán las tareas que luego se planificará para los próximos sprints en el que los diseñadores de UX y otros miembros del equipo de desarrollo podrán implementarlas.
“UX no termina su trabajo cuando entrega el prototipo”. A partir de ahora trabajaremos en iteraciones para probar y validar constantemente las funciones.
· Sprint de Equipo: el equipo de ux trabajara con desarrollo en paralelo validando el front de esa funcionalidad.
Un día de la semana (normalmente un lunes) los equipos de desarrollo comienzan su sprint. El día empieza planificando las tareas que entrarán durante ese tiempo (normalmente 2 semanas). UX debe de participar en esta reunión de planificación para mostrar los prototipos de las historias que van a entrar relacionadas con la interfaz, dar explicaciones, solventar dudas que puedan tener los desarrolladores, etc. Durante este tiempo, el equipo de desarrollo trabajará en ellas.
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos. Cada iteración tiene que proporcionar un resultado completo, un incremento de producto que sea potencialmente entregable. Esto es fantástico porque nos permitirá como UX poder iterar, medir y aprender rápidamente al final de cada sprint.
En estas fases finales, se realiza una demo donde todo el equipo del proyecto (negocio, marketing, clientes, ux y desarrollo) vemos las tareas completadas. Se proponen los cambios oportunos (que si todo se ha planificado y se ha validado correctamente antes no tienen que ser muchos) y a producción.
· Aprendizaje: medir y analizar los cambios para empezar un proceso de optimización.
· Retrospectiva: aprender y mejorar para el siguiente sprint.
Kanban
Originalmente el principio Kanban fue desarrollado por Taiichi Ohno en Toyota Motor Corporation en 1947. El objetivo era aumentar la productividad y la eficiencia con el propósito de tener más ventajas frente a los competidores. Mediante el uso de “Kanban” Toyota fue capaz de controlar la producción de forma mucho más flexible y eficiente.
Es un sistema visual que permite visualizar el flujo de trabajo y el trabajo en sí, pasando por el proceso. El objetivo principal del Kanban es identificar potenciales «cuellos de botella» en el flujo y arreglarlos para poder trabajar de una manera más efectiva a una velocidad óptima.
Se rige por 4 principios fundamentales:
1. Empieza por lo que estás haciendo ahora. Los cambios deben producirse de manera gradual, en un periodo de tiempo que sea cómodo para el equipo. Por lo tanto, hay que empezar trabajando sobre el proceso actual.
2. Compromiso a realizar cambios graduales que supongan una evolución continua del proceso.
3. No imponer cambios a nivel organizativo de los roles y responsabilidades actuales. En lugar de eso, si hay que realizar cambios se hacen de manera gradual cuando el equipo identifica la necesidad.
4. Alentar actos de liderazgo a todos los niveles. No tienen por qué venir de los jefes, todos deben promover ideas de mejora y tirar del equipo hacia delante, mostrando dotes de liderazgo para implementar pequeños cambios.
El método Kanban se puede utilizar en otro tipo de organizaciones para la mejora de procesos, no tiene por qué estar atado al desarrollo software. Ofrece una forma sencilla de visualizar el proceso de trabajo y foco en el trabajo a realizar.
¿Cómo funciona?
1. Permite visualizar el flujo de trabajo: Cada columna en el tablero representa un paso en tu flujo de trabajo y cada tarjeta Kanban representa una tarea o elemento de trabajo
2. Limita el trabajo en progreso: Establece los elementos máximos por etapa (columna) para garantizar que las múltiples tareas no están mellando la productividad de tu equipo. Limitar el trabajo en progreso iluminará rápidamente las áreas problemáticas en tu flujo para que puedas identificarlas y resolverlas.
3. Administrar flujo: Por flujo, nos referimos al movimiento de los elementos de trabajo a través del proceso de producción. Nos enfocamos en administrar y comprender los procesos de trabajo. Nuestro objetivo es hacer que ese trabajo pase por el sistema lo más rápido posible ajustando el flujo de trabajo.
4. Haz explícitas las políticas de proceso: Escribe las reglas para mover las tarjetas de una columna a otra, por lo tanto, las tareas de una etapa a otra. Asegúrate de que todos en el equipo estén en la misma página y entiendan las reglas. DoD: Definición de Hecho (Definition of Done) | Antes de empezar es necesario definir qué significa que la tarea está hecha.
5. Implementa intervalos de retroalimentación: Para mejorar el rendimiento, se deben realizar reuniones periódicas para el intercambio de conocimientos y comentarios. Un buen comienzo es hacer reuniones diarias de pie para la sincronización del equipo.
6. Mejorar de una manera colaborativa, experimentar y adaptarse: El Método Kanban es un proceso de mejora evolutiva. Te ayuda a adoptar pequeños cambios y mejorar gradualmentea un ritmo y tamaño que tu equipo pueda manejar. Ve qué funciona y qué no para lograr la máxima productividad.
Requerimientos
Resumen Creativo UX
El brief es una herramienta estratégica que te ayudará a enfrentar un nuevo proyecto, determinar las problemáticas y crear una buena estrategia. El brief es un resumen escrito que debe contener y explicar con claridad los siguientes aspectos: Estrategia que sustenta y condiciona el proyecto, Objetivos, Metas, Plazos de implementación, Equipo de trabajo y Presupuesto asignado.
Partes del Brief
1. Introducción: Lo primero que hay que definir es el objetivo de lo que diseñemos. ¿Se trata del rediseño de una página? ¿Por qué se rediseña? ¿Vamos a añadir una nueva funcionalidad? ¿Por qué? Recuerda que debe ser medible para que posteriormente sepamos si lo hemos alcanzado o no.
2. Roles, Funciones, Responsabilidades y Cargos: Es fundamental designar un jefe de proyecto que represente al cliente, que pueda convocar a sus pares, organizar la agenda, clarificar dudas y comunicarle las decisiones a lo largo del desarrollo. La lista de los stakeholders (interesados e interesadas) debería contener: nombre, cargo, función, email, teléfonos y un pequeño perfil (formación, etcétera).
3. Problema a Resolver y Propuesta de Valor: El documento deberá permitir, desde un comienzo, que los ejecutivos comprendan tu tarea, que es la de diseñar bajo metodologías centradas en los usuarios. ¿Qué conocen de sus clientes y prospectos? Qué sabe el cliente, qué ha investigado, cuáles son los supuestos, las tendencias y cómo están respaldadas.
4. Necesidad del Cliente: Puede ser de ayuda consultar por los deseos y motivaciones de la empresa. Verás que algunas novedades interesantes saldrán de estas respuestas. 
5. Activos y Herramientas existentes: Todo proyecto de Diseño UX gira en torno al contenido. Diseñamos estructuras racionales de interacción combinadas con la emoción de las interfaces, principalmente para que el contenido fluya. En este aspecto vale la pena preguntar: ¿Existe contenido? (textos, imágenes, videos, audio). ¿Dónde? ¿En qué estado está? ¿Está editado para medios digitales? ¿Quiénes lo mantienen? ¿Con qué herramienta o metodología? No importa si estás trabajando una simple web, un espacio transaccional o una aplicación; al diseñar software deberás coincidir con esta área para que tu proyecto vea la luz tal y como lo diseñaste. Entonces considerar los activos de TI (humanos y plataformas) y convocarlos desde un comienzo, es crítico para el éxito del futuro trabajo. Acá también se consideran el tipo de app o web a generar, sistema operativo, entre otros.
6. Objetivos y Metas: ¿Cuáles son los objetivos del proyecto? ¿Cuáles son sus metas? Los objetivos del proyecto deben estar relacionados con los estudios, condiciones y realidad presupuestaria de la compañía. Las metas son más simples, pero son fundamentales para demostrar avances y dar paso al debrief. Dichas metas deben ser, nuevamente, realistas y acordes a lo que la empresa es, quiere y puede llegar ser. Las metas son, al final, la manifestación concreta del trabajo ejecutado.
7. Presupuesto: Diseñar la experiencia de los usuarios no es barato ni rápido. Es una visión estratégica de negocios, de manera que evitar el tema presupuesto puede ser un gran error.
8. Tiempos: Es fundamental conocer los tiempos de entrega que espera el cliente. Lo normal es que, al hablar de tiempos, se consideren sólo los de desarrollo y no se especulen los tiempos de respuestas y aprobaciones.
9. Notas e Ideas: Por último, es importante dejar que los clientes se explayen en sus ideas sobre el proyecto, qué piensan, qué están viendo, etc. Es un buen antecedente para saber cuáles son los niveles de involucramiento en esta disciplina y qué tanto aprecian la experiencia de sus clientes y/o usuarios.
Indicadores del Proyecto
Un indicador es una característica específica, observable y medible que puede ser usada para mostrar los cambios y progresos que está haciendo un programa hacia el logro de un resultado específico. Debe haber por lo menos un indicador por cada resultado. El indicador debe estar enfocado, y ser claro y específico. El cambio medido por el indicador debe representar el progreso que el programa espera hacer. 
Cuando diseñamos un proyecto debemos contemplar necesariamente cuál va a ser nuestro diseño de evaluación del mismo. La evaluación con frecuencia es la gran olvidada de los proyectos y, así, nos lanzamos a desarrollar ideas que pocas veces evaluamos de forma sistemática. Incluir en nuestro diseño de proyecto cómo vamos a evaluar nos va a facilitar orientar el seguimiento del mismo en su fase de ejecución, determinando qué datos debemos recoger para la evaluación final.
La evaluación debería:
· Determinar las actividades realizadas, especificar su grado de ajuste a lo previsto en la programación y estimar su contribución al logro de los objetivos, identificando posibles mejoras.
· Determinar cuáles han sido los recursos efectivamente utilizados y con qué intensidad, valorando su uso (eficiencia).
· Valorar los procesos de gestión, e identificar mejoras a partir de la experiencia
· Conocer la valoración de las y los destinatarios últimos y de las partes interesadas.
Indicadores de Resultados
1. Logros: permiten evaluar los cambios que se esperan lograr al final del proyecto, e incluso más allá de su finalización.
2. Actividad: permiten evaluar la ejecución de las actividades (realización, número de participantes…).
3. Impacto: permiten evaluar los cambios esperados y deseados, que pueden producirse como consecuencia del proyecto
Indicadores de Gestión
4. Procesos: permiten evaluar el ajuste y adecuación de los procesos de gestión (ajuste a plazos, realización de tareas según lo previsto,…).
5. Recursos: permiten evaluar el ajuste de los recursos a lo previsto y su uso adecuado (cantidad de recursos utilizados, eficiencia, desempeño profesional…).
Hoja de Ruta o RoadMap
El roadmap (hoja de ruta) es el término que se utiliza para definir el documento en el que se detalla la planificación en el desarrollo de un proyecto. Aunque se utiliza con mayor frecuencia en proyectos relacionados con el desarrollo de un software, el término puede usarse en cualquier área de desarrollo.
El documento básico de un roadmap debe contener los objetivos, grandes o pequeños, y sus fechas de consecución. El conjunto de un objetivo y una fecha se conoce como hito o en inglés milestone (son las piedras pintadas al lado de las carreteras que nos indican el punto kilométrico en el que nos encontramos).
El roadmap debe estar secuenciado de forma que se describa el conjunto de hitos que se deben lograr entre el estado actual del producto y el futuro pasando por todos los milestones secundarios que es necesario lograr.
Hoja de Ruta o Roadmap de proyecto centrado en el usuario
Gráfico 1: Hoja de Ruta de producto centrado en el usuario
Se centra en resolver problemas específicos y no construir funcionalidades o tareas aisladas (Gráfico 1). Este enfoque de la hoja de ruta nos permite comunicar rápidamente a los stakeholders o actores claves y a todo el equipo que se está construyendo y por qué. Da un marco para la priorización y toma de decisiones, que se hace en función de los objetivos de negocio y el usuario. Favorece la creatividad y la innovación porque se piensa en el problema, no en una solución concreta.
¿Cómo construir la hoja de ruta?
1. Objetivos y Tareas: Elegir un problema del usuario o un objetivo de negocio para el primer ciclo. Este problema/objetivo tiene diferentes tareas asociadas.
2. Detalle del ciclo: En cada ciclo se debe definir la fecha de entrega y el nombre del mayor objetivo que se quiere lograr. Cuando hablamos de Objetivos debemos relacionar con los objetivos de negocio o beneficios para el usuario. Las funcionalidades o tareas se desprenden de los objetivos planteados, no son un fin en sí mismos. Por último y lo más importante, es la definición de las métricas e indicadores.
3. Criterios para priorizar: Deberástener presente los siguientes criterios, y los que creas necesarios, para definir cómo se organizan los objetivos y entregables. Nuestro proyecto ideal sería el cual nos permita tener un alto porcentaje de todos ellos, pero sabemos que la realidad siempre no está a nuestro favor.
4. Hoja de Ruta: Finalmente obtendremos nuestra hoja de ruta agile que nos permitirá enfocarnos en los usuarios e ir presentando avances, y que todos los actores involucrados en el proyecto sepan qué estamos haciendo, por qué lo estamos haciendo y qué resultados esperamos conseguir.
Características principales:
1. Funcionalidades agrupadas en función de problemas, objetivos o necesidades de los usuarios.
2. Se evalúan objetivos estratégicos
3. POR QUÉ - define la solución, no el problema
4. Los problemas suelen ser permanentes
5. Específica problemas a resolver
Desafíos ágiles dentro de las organizaciones
Obtener el apoyo de toda la empresa ha sido una batalla cuesta arriba. Los equipos deben trabajar duro para mostrar a los no creyentes el valor de Agile y animarlos a salir de sus zonas de confort.
1. Falta de apoyo ejecutivo: Uno de los mayores desafíos con Agile es obtener soporte desde arriba. Algunas de las personas con las que hablé expresaron su frustración por la falta de compromiso con la administración. Sin el respaldo de los ejecutivos, los equipos se ven obligados a tomar atajos y trabajar con menos eficacia. Los malentendidos sobre el proceso ágil dan como resultado una interrupción de la comunicación y una planificación incoherente.
2. Recursos inadecuados: La falta de apoyo ejecutivo generalmente resulta en una disminución de recursos. Los profesionales con los que hablé coinciden en el mérito de las metodologías Agile y Lean como Scrum. Cada componente de Scrum está estructurado para abordar una necesidad de proceso. Algunos de los proyectos más exitosos ocurren cuando los equipos pueden comprometerse con la metodología. Sin embargo, casi todos los que entrevisté no siguieron la receta o se vieron obligados a tomar atajos. La principal razón: falta de recursos.
Consejos para ejecutar equipos ágiles de UX sin problemas
1. Mantenga la coherencia de los equipos: Se necesita tiempo para construir un equipo bueno y cohesionado con el conocimiento del dominio para tomar las decisiones correctas rápidamente. Cada equipo Agile puede trabajar de manera diferente y tener una dinámica de equipo única. La perturbación del sistema interrumpe enormemente la velocidad porque es necesario restablecer el conocimiento y las expectativas.
2. Sea proactivo, no reactivo: Si está acostumbrado a trabajar con la cabeza hacia abajo durante largos períodos de tiempo, entonces debe cambiar su estilo de trabajo o corre el riesgo de quedar desactualizado. La colaboración es clave para el desarrollo exitoso de productos. La participación de los miembros del equipo multifuncional facilita la transparencia y permite que los problemas se identifiquen temprano. Participe en todos los aspectos del proceso de diseño, incluida la planificación. Esté preparado para compartir sus ideas, mostrar en qué está trabajando y contribuir a las discusiones.
3. La UX debe funcionar al menos un paso antes del Sprint: Agile es amigable con el desarrollo, pero eso no es excusa para reducir la influencia de UX. Los profesionales de UX efectivos se incorporan al proceso Agile contribuyendo activamente con ideas, desde la preparación de trabajos pendientes y la planificación de impresión hasta el wireframing y la investigación de usuarios. Los diseñadores de UX deben planificar actividades antes de que ocurra el sprint , lo que significa ser proactivo y probar supuestos y abordar los diseños antes que el resto del equipo. Realizan actividades de mostrar y contar antes de los sprints para presentar conceptos a los usuarios y miembros del equipo para que, cuando el desarrollo esté listo para comenzar, el equipo tenga los diseños que necesitan.