Genome-wide association analyses

(versiones) de un producto en un User Story Map

La cualidad más importante de nuestro plan es que éste debe estar formado por objetivos priorizados y que cada uno se pueda validar independientemente del resto. De esta manera ayudaremos a que la construcción esté bien enfocada y que cada objetivo que se acabe represente un incremento de valor de nuestro producto.

Observad que esta técnica nos sirve tanto para elaborar un plan de construcción para nuestro MVP como para elaborar un plan de versiones (o plan de releases) de nuestro producto. Es una técnica muy barata y flexible, que nos permite revisitar muchas veces el plan y hacerlo encajar con nuestra visión del producto, por si ésta hubiera cambiado en función del feedback recibido.

Validar que lo construído es lo

que necesitamos Valoramos más responder al cambio que seguir un plan

9_.

Cumplir el plan no es un objetivo. De hecho, puede ser un impedimento serio. Pero tampoco podemos entrar en el terreno de la improvisación. Para ello, las metodologías ágiles nos proporcionan el concepto de iteración: un espacio de tiempo que usamos para revisar nuestro plan regular y frecuentemente, como el compás de una canción, a partir de todo el feedback recogido durante ese período. Este concepto es básico para entender cómo funciona la construcción de un producto ágil.

El tiempo pasa irremediablemente, por eso nosotros buscamos que todo el equipo tenga un ritmo constante y sostenible. Esto aporta muchas ventajas, primero que el equipo no trabaja sometido al castigo de un calendario sino que se puede enfocar en hacer bien su trabajo, sin más. Por si esto no fuera suficiente, además aporta predictibilidad y una pauta regular para revisar el plan, evitando que éstas desaparezcan de nuestro calendario porque “no tenemos tiempo que perder”. Al final de cada uno de estos ciclos, que los agilistas solemos llamar iteraciones o sprints, es cuando el equipo nos puede enseñar lo que ha acabado y nosotros validar si es lo que teníamos en mente o no. Asimismo podemos revisar nuestro plan.

De la Inception habremos salido con ese plan, una lista priorizada10 _{de cualidades que nuestro producto debe tener}

para que los usuarios lo utilicen y podamos así comenzar a medir. Cada uno de esos elementos de la lista debe, en la medida de lo posible, tener las siguientes características:

• Independientes, es decir, que uno se pueda acabar sin esperar a que lo esté otro.

• Negociables, es decir, que mientras el equipo no haya empezado a trabajar en uno, podremos cambiarlo en cualquier momento y adaptarnos así a lo que hayamos ido aprendiendo hasta entonces.

• Aportan valor, es decir, que una vez está acabado, algún usuario podrá hacer algo que antes no podía hacer.

9 _{Del Agile Manifesto. http://agilemanifesto.org}

10 _{En Scrum, una de las metodologías ágiles más populares, a esta lista la llamamos Product Backlog o Pila de Producto, pero voy a intentar evitar este término para}

Desarrollo Ágil de Producto para Emprendedores José Manuel Beas

España Lean Startup 2013 6

Desarrollo Ágil de Producto para Emprendedores

• Son suficientemente poco ambiguos como para que el equipo pueda hacer una estimación de lo que le costará la construcción del mismo.

• No son ni demasiado grandes ni demasiado pequeños porque cuando tratamos de abordar un trabajo demasiado grande normalmente cometemos errores y si es demasiado pequeño estaremos incurriendo en una burocracia innecesaria.

• Se pueden probar, es decir, podemos validar que hemos construido lo que queremos ofrecer a los usuarios. Esta lista es fácil de recordar con el mnemónico INVEST y es importante porque si conseguimos definir las cualidades de nuestro producto de esta manera y formar con ella una lista priorizada (por el valor que aportan, por ejemplo), entonces será bastante fácil acordar con el equipo cómo vamos a validar que cada una de ellas está acabada, es decir, lista para añadirla al producto. Si además acordamos con el equipo que trabaje respetando este orden que nosotros hemos marcado, siempre tendremos una versión más o menos acabada de nuestro producto pero siempre lista para ponerla en la calle. La técnica que solemos usar los agilistas para definir las cualidades de un producto es la Historia de Usuario.

Historias de

Usuario En realidad la historia de usuario no es más que el recordatorio en un papel de todas las conversaciones que nos _{llevan a un acuerdo sobre cuál debe ser la siguiente funcionalidad a desarrollar por parte del equipo y cómo vamos}

a validarlo. Sin embargo, en la simplicidad de la misma se encierra todo un proceso de depuración de ideas, eliminación de incertidumbre, priorización y enfoque hacia el valor para los usuarios que no es nada fácil. Es muy recomendable que si no habéis usado nunca esta técnica os forméis o busquéis a alguien que os ayude.

Las historias de usuario, como su propio nombre indican, son cosas que le pueden pasar a un usuario mientras usa nuestro producto. Por ello es importante que recuperemos el trabajo que se hace durante la Inception (o la dinámica que hayamos elegido para arrancar), durante la cual habremos identificado a muchos de nuestros usuarios, al menos a los más importantes. Nuestras historias los tendrán como protagonistas y además haremos explícito lo que pretendemos que ocurra durante esa interacción con el producto y cuál es el beneficio que el usuario va a recibir, es decir, qué va a poder hacer ahora que antes no podía. Con esta descripción y un criterio de aceptación acordado entre todos, la historia estará preparada para formar parte de nuestra lista priorizada. Una vez acabada también podrá pasar a formar parte de nuestro producto como una cualidad más del mismo.

User Personas _{Una de las técnicas que me gusta usar durante la Inception es la User Persona. Es una técnica muy conocida en}

disciplinas como el Marketing o la Experiencia de Usuario (UX) y consiste en elaborar una plantilla con la que tratamos de describir a los usuarios o grupos de usuarios de nuestro producto y sus objetivos. Podemos ver un ejemplo real en la imagen a continuación. Con las “user personas” identificamos los personajes de nuestras historias de usuario.

Ejemplo de una User Persona

Desarrollo Ágil de Producto para Emprendedores José Manuel Beas

Desarrollo Ágil de Producto para Emprendedores

El formato que empleamos para escribir una historia de usuario no es demasiado relevante, aunque se suele usar uno como el de la imagen a continuación. En el dorso de la tarjeta incluimos lo que llamamos el “criterio de aceptación”, es decir, la manera en la que comprobaremos que el equipo ha construido lo que hemos acordado. Incluso con eso no hay mucho detalle en una Historia de Usuario. Es una técnica que elude la burocracia de otras metodologías y por ello es mucho más adecuada para equipos que trabajan en un contexto de emprendimiento. Ejemplo de una Historia de Usuario ¿Cómo encontramos e incorporamos el aprendizaje?

Todo emprendedor debe tener mucho cuidado con no gastar el dinero en cosas innecesarias, pero a la vez tiene la obligación/necesidad de explorar. A esto lo llamamos “validar hipótesis”. Y el uso de jerga científica no es casual. Establecer una hipótesis a validar es fundamental para estar enfocados en el desarrollo de producto. Cada nueva versión debe aportar una certidumbre nueva sobre muestro producto. Insisto en el concepto de “aprendizaje validado”. Eso es más valioso aún que lo que podamos estar aportando a los usuarios. Pero esto queda fuera del ámbito de este artículo.

Más arriba hablábamos del MVP y de las subsiguientes versiones del producto. Cada vez que sacamos a la calle una nueva versión de nuestro producto empezamos a recibir feedback y a aprender de lo que nos dicen los usuarios. Mientras tanto, es muy posible que nuestro equipo siga trabajando en nuevas versiones, atendiendo al plan que habíamos elaborado. Ya hemos visto que un desarrollo ágil nos proporciona unos ciclos de desarrollo (o iteraciones) al principio de las cuáles es justamente cuando podemos incorporar nuestros cambios puesto que empezamos siempre con un nuevo plan, sólo para esa iteración.

Steve Blank recomienda no esperar demasiado para sacar nuestro MVP a la calle11_{, pero no tenemos por qué}

esperar a tener una versión completa para incorporar esos cambios en el plan, puesto que el mismo puede venir de otras muchas fuentes. Por ejemplo, puede haber surgido un nuevo competidor con una característica que podemos fácilmente neutralizar si respondemos rápidamente y dejamos para otro momento parte de las nuevas ideas. Si hemos aplicado nuestro criterio INVEST también a nuestras versiones, será relativamente fácil que nuestra respuesta se pueda desarrollar en la siguiente iteración. Ojo, porque eso requerirá igualmente que las historias nuevas tengan claramente identificado el valor que aportan y a qué usuarios, o corremos el riesgo de entrar en modo “bombero” y dedicarnos a “apagar fuegos”, dejando nuestro producto lleno de “parches”, que serán las futuras insatisfacciones de nuestros usuarios, a los que habremos olvidado por las prisas.

Podemos mantener el foco sobre el crecimiento del producto usando técnicas como el User Story Map, que ya hemos visto, porque con ella podremos visualizar cómo irá creciendo nuestro producto y adaptándose al feedback recibido.

Poniendo el microscopio al nivel de historia de usuario, nos tenemos que poner de acuerdo con el equipo de desarrollo sobre lo que vamos a recibir al final de cada iteración. A esto lo llamamos criterio de aceptación o definición de acabado, porque es el criterio que seguiremos todos para validar que esa historia está acabada. Es además una herramienta que nos obliga a compartir con el equipo cuáles son nuestras expectativas, a ellos a entenderlas y hacernos saber las posibles limitaciones técnicas y, juntos, a decidir si se debe cambiar alguna de

Desarrollo Ágil de Producto para Emprendedores José Manuel Beas

España Lean Startup 2013 8

Desarrollo Ágil de Producto para Emprendedores

esas expectativas. En este punto, el uso de sketching12 _{u otras técnicas de pretotipado están demostrando ser muy} valiosas.

Durante la construcción del producto, el equipo puede visualizar su trabajo con un tablero como el de la figura. En él se ve el trabajo planificado durante una iteración y cómo avanza éste. De esta manera conseguimos que el equipo esté enfocado y que cualquiera pueda ayudarle a resolver los impedimentos porque están a la vista de todos.

Ejemplo de Tablero Scrum

Además del aprendizaje sobre el feedback de los usuarios o del mercado, también podemos incorporar el aprendizaje sobre nuestra propia manera de trabajar. Este ciclo continuo de construcción puede llevar aparejado un ciclo de mejora continua incorporando en nuestro proceso de trabajo una simple reunión llamada Retrospectiva13 _{y durante la cual buscamos maneras de mejorar cómo trabajamos juntos, independientemente del}

producto. La Retrospectiva es la técnica más poderosa que aporta el agilismo al desarrollo de equipos porque les permite reflexionar de manera regular y buscar acciones de mejora concretas que, por pequeñas que sean, siempre suman. Y aunque durante las retrospectivas no se tratan aspectos relacionados directamente con el producto o productos que nuestro equipo construye, es evidente que una mejora en la manera de trabajar llevará inevitablemente a una mejora en el resultado del trabajo.

Anécdota _{Recuerdo un proyecto en el que el debíamos construir un producto, una versión en Javascript de un broker}

financiero, en menos de 3 meses porque había firmado un contrato con el cliente y éste no sabía nada de metodología ágiles. Además, el equipo no tenía experiencia con estas metodologías. Yo les tranquilicé y les dije que cuando llegara la fecha límite sería un día como otro cualquiera. La primera semana no les tranquilizó nada porque lo único que habíamos construido era una pequeña lista de datos en medio de una pantalla. Pero cuando al cabo de pocas semanas más ya estábamos integrando una versión muy reducida de toda la funcionalidad con la infraestructura del cliente, ya pensaron que el objetivo estaba más a nuestro alcance.

Semana a semana enseñábamos los avances al cliente y éste nos daba su feedback. El resultado final fue que, efectivamente, el día que llegó la fecha límite de nuestro contrato, el producto ya estaba en producción y recibimos la felicitación del cliente. Si recordamos la metáfora del misil teledirigido, habíamos dado de lleno en nuestro objetivo, a pesar de que no sabíamos muy bien si acertaríamos cuando lo lanzamos.

Conclusión _{Con todo lo que hemos visto hemos cerrado el ciclo, es decir, hemos pasado desde la concepción del producto}

hasta la validación e incorporación del aprendizaje validado a las nuevas ideas a construir. Además hemos visto que las metodologías ágiles terminan encajando de manera natural en el ciclo BUILD/MEASURE/LEARN del

12 _{En la Conferencia Agile-Spain 2013 impartí junto a Javier Alonso (@oyabun) un taller en el que poníamos en práctica estas técnicas y del que podéis encontrar la}

presentación aquí. Desgraciadamente no hay video del taller porque resultaría muy clarificador.

Desarrollo Ágil de Producto para Emprendedores José Manuel Beas

Desarrollo Ágil de Producto para Emprendedores

método Lean Startup y que, si bien no es obligatorio, sí es altamente recomendable que pidamos a los equipos que vayan a construir nuestro producto que lo hagan:

• tras participar en la elaboración del plan, quizás en una Agile Inception,

• organizando el trabajo en ciclos regulares para los que juntos elaboraremos un plan,

• plan que estará formado por una lista priorizada de historias de usuario, con su enfoque hacia aportar valor a algún usuario y con su criterio de aceptación,

• plan que revisaremos juntos al final del ciclo fijándonos en el criterio de aceptación que habríamos incorporado a cada funcionalidad,

• plan que constantemente refinaremos para que el equipo tenga ritmo sostenible,

• plan que constantemente revisaremos y reordenaremos para incorporar el aprendizaje validado, • y con una reunión retrospectiva al final de cada ciclo para mejorar la manera de trabajar juntos.

Espero que este artículo os haya resultado esclarecedor, pero si aun así tenéis dudas, no dudéis en poneros en contacto conmigo o, mejor aún, acercaros a AES para compartir vuestras dudas y experiencias, ya sean buenas o malas, porque participar de una comunidad como ésta es muy enriquecedor.

Algunas

recomendaciones • Agile Entrepreneurship Spain: Visita http://www.aespain.org/ y mantente informado de sus actividades.

• Agile Inception: Podéis encontrar una descripción más detallada en http://jmbeas.es/guias/agile-inception/ • Agile Spain: Organizan dos grandes eventos al año: una conferencia y un openspace. Os recomiendo no

perderos el openspace porque es un gran ejemplo de auto-organización. Visita su web en http://agile- spain.org/

• Historias de Usuario: Podéis encontrar una definición más detallada en http://jmbeas.es/guias/historias- de-usuario/

• Product Backlog: Podéis leer más en http://jmbeas.es/guias/product-backlog/

• User Story Map: El mejor artículo explicando el porqué de esta técnica es el original del autor, Jeff Patton, pero también puedes ampliar más en http://jmbeas.es/guias/user-story-mapping/