Scrumízate
Las historias de usuario son una técniva transversal en los entornos que se basan en los principio ágiles y/o lean. Se trata de una técnica que nos permite definir aquellas necesidades de un usuario y que debemos incorporar a nuestro producto. Se centran en la aportación de valor hacia el usuario y no en qué debemos hacer con largas listas de tareas.
Utilizar correctamete las historias de usuario nos aleja y sustituye aquellos pesados documentos de casos de uso y otros diagramas UML que definen una larga lista de requisitos. El model tradicional de requisitos no situa en un marco de definir todo antes de empezar el proyecto y desear que una vez terminado de desarrollar el usuario quede satisfecho a nivel de funcionalidad y experiencia. La experiencia nos respite una y otra vez que no debemos seguir bajo los patrones tradicionales cuando desarrollamos software.
En este post relacionaremos las ventajas que nos ofrecen utilizar historias de usuario y cuanto nos acercan a los principios destacados del Manifiesto Ágil. Una primera valoración es recordar que puntos los firmantes del manifiesto aseguran haber aprendido a valorar (entre paréntesis cuanto nos acerca a esta idea las historias de usuario):
- Individuos e interacciones sobre procesos y herramientas (Sustituyen el modelo cascada y potencia las conversaciones entre el equipo).
- Software funcionando sobre documentación extensiva (Sustituyen los grandes requisitos con su pesada documentación y propone iteraciones constantes en el producto).
- Colaboración con el cliente sobre negociación contractual (Son abiertas al cambio en pro de la experiencia del usuario o la satisfacción del cliente).
- Respuesta ante el cambio sobre seguir un plan (En cada iteración del producto debemos priorizar las historias de usuario que aportan mayor valor en aquel momento dado).
Un truco que acudo recurrentemente con el paso del tiempo es la lectura del Manifiesto Ágil. Lo utilizo para abrir un espacio de reflexión a través de sus palabras, que sirven de guía espiritual entre la agilidad y las fuerzas de la oscuridad.
Si hace tiempo que no lees el Manifiesto Ágil (y especialmente si eres de aquellos que promueven la agilidad dentro de un entorno, utilizas muchos post-its y nunca has leído, y reflexionado sobre, el Manfiesto por el Desarrollo Ágil de Software) te recomiendo que accedas a él antes de seguir con este post. Son 3 minutos de lectura!
Entrega rápido, entrega a menudo
El conocido cofundador de Linkedin y anteriormente miembro del equipo de Paypal, Reid Hoffman, tiene las ideas muy claras acerca cuando es preciso lanzar un nuevo producto al mercado. En concreto tiene muy claro cuando sería demasiado tarde y en este sentido un grave error.
Si no te averguenzas de tu primer producto, es que lo lanzaste muy tarde.
Estamos ante una visión completamente lean y, al ser muy fácil de recordar, tenerla gravada en la mente, especialmente si eres product owner o vives muy de cerca el producto. Dos apreciaciones (una sobre la propuesta de valor y otra sobre el equipo) le sirven para dar forma a la idea y tener una línea clara de camino a seguir en las decisiones importantes.
Sobre la propuesta de valor Reid Hoffman argumenta que no se debe tener una fe ciega, o demasiado ciega, en las hipótesis propias. Es normal tener una tendencia hacia la consideración de que tenemos entre manos un buen producto. Aún así, aún teniendo un buen producto 10 veces mejor que las soluciones de mercado, es indispensable contar con una buena red de distribución. Para ganar la partida el producto debe ser accesible a todos su posibles usuarios.
Acerca del equipo Reid Hoffman nos dice que el mayor propósito de un equipo es entregar rápido y entregar a menudo. Para conseguir este objetivo está convencido que se necesita un equipo rápido y dinámico y sobretodo que aprenda deprisa. Rodearnos de personas con una alta capacidad de aprendizaje va mucho más allá de las capacidades de base técnica nos acercará al objetivo máximo del equipo: entregar rápido y entregar a menudo.
Si te interesa profundizar en las ideas de Reid Hoffman os recomiendo el libro The Start-up of You. Es un libro donde, gracias a su experiencia y trayectora, da un conjunto de consejos y advertencias para emprendedores.
Desarrollo iterativo e incremental
Para considerarnos un entorno ágil debemos alejarnos completamente del decadente modelo de ciclo de vida en cascada. En acción y pensamiento. Una ejecución ordenada, unitaria y dividida en fases con un enfoque a proyecto no tiene lugar en un entorno ágil. La transformación ágil se hace de raíz o no es real ni satisfactoria, solo puro maquillaje.
El ciclo de vida en cascada en un modelo guiado por las fases de requisitos, análisis, diseño, desarrollo pruebas... Cada una de estas fases se realizan, teóricamente porqué no hay errores ni cambios, sólo una vez. Solo se empieza una fase cuando se ha terminado justo la anterior. La realidad nos asegura que los requisitos cambian con el transcurso del tiempo y que el uso del producto genera el mejor feedback para cambios y nuevas funcionalidades.
El enfoque de desarrollo iterativo e incremental de software nos permite cambiar de modelo de ciclo de vida. Este enfoque funciona a la perfección con la técnica de historias de usuario y nos permite alinear la visión de todo el equipo, sean cuales sean sus capacidades o responsabilidades.
El desarrollo iterativo e incremental se centra en que el software debe estar lo antes posible funcionando. Una vez que lo usan los usuarios realizar pequeñas iteraciones que permitan mejorar de forma constante la experiencia de usuario con la aportación de mejoras en el producto o nuevas funcionalidades necesarias con el uso del producto. Con el paso del tiempo el software debe estar siempre funcionando.
Agregar una funcionalidad nueva la entendemos como un desarrollo incremental. Estos tipos de desarrollos normalmente van asociados a un nuevo módulo del producto. Mejorar las funcionalidades existentes forman parte de los desarrollos iterativos. Bajo la idea anterior, entregar pronto y frecuentemente, el equipo dedica mayoritariamente su tiempo a desarrollos iterativos.
En noviembre de 2017 ya escribí un post acerca del ciclo de vida de desarrollo iterativo y como se relaciona con el concepto lean de Mínimo Producto Viable y como nos pueden ayudar frameworks ágiles como scrum.
Dudas y problemas habituales
Las historias de usuario forman parte del grupo de responsabilidades del product owner del equipo. Las historias de usuario se acumulan y priorizan en el product backlog y nos asegura que el equipo tendrá una conversación sobre la misma. Necesitamos considerar una historia de usuario como una promesa de que vamos a tener como equipo una conversación.
A continuación veremos tres casos típicos en los que los equipos caen y no aprovechan así el impulso que proporciona un uso satisfactoria las historias de usuarios.
Backlog lleno de tareas
Las historias de usuario no definen el cómo se debe realizar sino qué necesita el usuario con el uso del producto. Aquí nace el primer problema más habitual: un product backlog lleno de tareas. Las tareas en el backlog nos genera una larga lista de cosas a hacer sin poder identificar el valor que aportan al usuario. Complica la priorización y limita la libertad de pensamiento para realizar soluciones efectivas de forma más rápida.
Un backlog lleno de tareas nos maquilla de ágil un ciclo de vida en cascada.
La ventaja de las historias de usuario frente a las tareas es que las historias de usuario son end to end. Una vez se a terminado una historia de usuario es claro el valor que se ha aportado al cliente.
Historias épicas
Entornos que están empezando la transformación ágil suelen caer en el recurso de definir historias épicas. Un product owner que trabaje con historias de usuario demasiado largas o épicas actúa contra el principio ágil de entregar frecuentemente nuevo software funcionando.
El uso de épicas hacen que los equipo vayan más lentos, entreguen más tarde y menos a menduo.
Curiosamente también en noviembre, pero del 2018, confeccioné este perqueño manual con las mejores estrategias para dividir las historias de usuario. Seguir estas recomendaciones nos permite aprovechar los beneficios de escribir buenas historias de usuario, ser más rápidos y aportar más valor al usuario.
Deuda técnica
Los males típicos de los modelos en cascada y de los problemas anteriormente mencionados nos deja en todos los casos con una deuda técnica con la que (sobre)vivir. La deuda técnica normalmente se va acumulando debido a decisiones que se toman ante retrasos o errores en el software.
La deuda técnica es 100% responsabilidad de los desarrolladores implicados.
De quién será sino? Aceptar esta responsabilidad es el primer paso para actuar sobre la deuda técnica. Cuanto antes empieces, antes mejorará tu vida. La deuda técnica se genera con decisiones que comrpometen la viabilidad del producto a largo plazo. Escuchar sobre una supuesta y deseada V2 (versión 2) o oir voces que defienden rehacerlo todo de cero, es realmente escuchar excusas y falsos razonamientos que permiten que uno se sienta mejora y siga perpetuando los mismos problemas de siempre.
En agosto de 2018 profundicé en la reación entre scrum y la lucha contra la deuda técnica en un post que te recomiendo su lectura. Es precisamente un análisis de las causas de la deuda técnica, una reflexión soble la responsabilidad sobre la deuda técnica y un enfoque de como ayudarse de los frameworks ágiles nos ayudarán a empezaar solucionar.
Conclusiones
El propósito de cualquier desarrollador o cualquier equipo creador de productos digitales, sea cual sea la disciplina de cada miembro, es la entrega rápida de nuevas versiones que permitan avanzar en prestaciones con el software siempre funcionando.
Cada entrega debe aportar valor. Debemos entregar pronto y frecuente.
El ciclo de vida iterativo e incremental junto a la técnica de las historias de usuario por parte del product owner promueve el principio del manifiesto ágil de la entrega rápida de nuevas versiones. Trabajar en espacios cortos de tiempo y entregando valor end to end al usuario en cada uno de estos espacios nos permite combatir hasta eliminar las debilidades del modelo cascada.
Debemos aceptar que los requisitos cambian y cambiarán con el paso del tiempo. Esta limitación no nos debe generar frustación como equipo sino que debemos transformarlo en una ventaja competitiva que nos permita ofrecer una mejor experiencia de usuario.
Unir el desarrollo iterativo e incremental, la creación de Mínimos Productos Viables y la creación de valor con historias de usuario nos acerca a poder entregar más pronto y más a menudo. Destacamos estos principios del Manifiesto Ágil para relacionar las ideas comentadas:
- La mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
- Aceptar que los requisitos cambian, incluso en las etapas más tardías del desarrollo y convertirlo en una ventaja competitiva.
- Entregar software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
- El software funcionando es la medida principal de progreso
Te ha gustado el post? No olvides suscribirte en nuestra newsletter! Ayúdanos a dar a conocer Scrumízate y comparte este post en la redes sociales para que llegue a más personas o envíalo a alguien a quien también le pueda interesar. Gracias!
