Kelly Waters nos da algunas claves para no perder de vista la visión de conjunto (the big picture) durante el desarrollo de un proyecto ágil. Aquí os dejo una traducción libre:

“Cuando utilizamos un enfoque basado en el desarrollo ágil, no hay grandes especificaciones ni diseños inamovibles. El alcance del proyecto varía. Algunos requisitos evolucionan, y otros nuevos van emergiendo. Las funcionalidades crecen, cambian y desaparecen a lo largo de todo el ciclo de vida del proyecto. En este entorno variable, la cuestión es: ¿qué podemos hacer para no perder de vista la visión de conjunto?

Aunque el desarrollo ágil consiste, en gran parte, en trocear los objetos hasta conseguir pedazos pequeños y manejables -para obtener, por ejemplo, el product backlog y el sprint backlog- es muy importante no perder de vista el contexto global, para que nos sirva como guía y referencia a lo largo de todo el proceso.

Este contexto se nos presenta en 3 formas principales:

• Contexto de negocio
• Contexto de proyecto
• Contexto de la solución

Contexto de negocio

ALGUNAS PREGUNTAS ÚTILES: ¿Cuál es la visión de negocio? ¿Cuáles son los retos y las oportunidades desde el punto de vista del negocio? ¿Cuáles son los objetivos de negocio a corto, medio y largo plazo? ¿Quiénes son los clientes? ¿Por qué compran y para que utlizan las solución que vamos a desarrollar? ¿Qué les gusta y qué no les gusta del proyecto? ¿Quién es la competencia y cómo son sus soluciones?

Sin esta información global de contexto, cualquier equipo de desarrollo está trabajando con una gran desventaja. La gente de desarrollo puede ser muy innovadora y si los equipos de desarrollo cuentan con una visión interna real del contexto de negocio, pueden ser mucho más proactivos. Con esta información, es mucho mas probable que las soluciones innovadoras emerjan a la superficie.

Contexto del proyecto

Muchos de los elementos definidos en la fase de inicio de un proyecto tradicional siguen siendo importantes en un entorno de desarrollo ágil.

ALGUNAS PREGUNTAS ÚTILES: ¿Cuáles son los problemas específicos o las oportunidades que el proyecto intenta abordar? ¿Cuál es la visión para el proyecto? ¿Cuáles son los objetivos del proyecto? ¿Cuál es el enfoque? ¿Cuál es el coste previsto y el plazo de entrega? ¿Cuáles son los beneficios y cómo se van a conseguir? ¿Quién trabajará en el proyecto y cuál será su estructura?

Las respuestas a éstas y otras preguntas constituyen una guía de referencia importante para el equipo. Esta guía se hace más necesaria si cabe en un desarrollo ágil, en el que hay libertad para cambiar las cosas durante todo el proceso. Con esta información, el equipo dispone de algunos parámetros con los que trabajar, y tiene claro cuáles son los resultados esperados.

Contexto de la solución

He escrito varios posts sobre cómo escribir buenas historias de usuario. Me gusta que sean tan pequeñas, autoexplicativas y manejables. Hacen que las cosas resulten sencillas. Pero, ¿qué deberíamos hacer antes de llegar al detalle de las historias de usuario? Es importante enmarcarlas dentro del contexto global de la solución. Las siguientes herramientas pueden ayudarnos:

• Mapa (roadmap) de producto de “alto nivel” (no entra en detalles). Utilizando una línea de tiempo amplia -por ejemplo, meses o trimestres- este mapa nos permite destacar las funcionalidades clave del producto y los diferentes hitos principales que se producen a lo largo del proyecto. A diferencia de un plano, un mapa de producto es indicativo y evoluciona a medida que las cosas cambian. Proporciona al equipo una estructura del plan de sprints, y ayuda a identificar las prioridades y a establecer los objetivos de cada sprint.
• Visuales de alto nivel. Pueden ser wireframes o maquetas con las pantallas clave, un storyboard conceptual para el interfaz de usuario, etc. Sea cual sea su forma, este boceto de alto nivel debe mostrar cómo funcionará la solución desde la perspectiva del usuario. No hace falta que estos visuales especifiquen todas las pantallas, ni todas las funcionalidades. La solución final ni siquiera tiene que mostrar el mismo aspecto de los visuales (de hecho, casi nunca lo hace). Pero constituye una buena guía para arrancar el proyecto porque cubre los escenarios principales a los que se va a enfrentar el usuario-tipo.
• Arquitectura (de alto nivel) de la solución. No hace falta que sea un diseño detallado. Lo que necesitamos es una arquitectura que nos sirva para entender las tecnologías clave, la estructura del producto, y cómo se comporta la solución desde una perspectiva técnica. Puede ser una imagen que vaya evolucionando. Algo así como el boceto que dibujamos en una pizarra al iniciar el proyecto, pero complementado con los detalles que vamos añadiendo a medida que el proyecto avanza y tomamos decisiones técnicas.

Resumen: Un equipo de desarrollo ágil necesita trocear las cosas en pequeños fragmentos y hacer las entregas de manera incremental. Para hacerlo, resulta especialmente importante tener en mente el contexto general. Mi consejo es que utilices herramientas-guía de alto nivel, ligeras y muy visuales (objetivos del proyecto, mapa de producto, arquitectura de la solución), y las mantengas pegadas en la pared junto con las historias de usuarios y las tareas diarias.

Podéis leer el post original aquí.