La agilidad, o la capacidad de responder al cambio en el mercado, a menudo se considera uno de los factores más importantes para prever el éxito de una empresa. De hecho, los proyectos ágiles disfrutan de un 60% más de posibilidades de éxito en comparación con los proyectos de tipo "waterfall" más tradicionales.

Pero, ¿qué es Agile? El concepto de un enfoque ágil es algo que se usa mucho. Pero puede haber mucha confusión sobre lo que realmente implica. ¿Tiene algo que ver con paredes llenas de post its? ¿Es un sofisticado software de gestión de proyectos? ¿O algo que solo puede aprender de consultores especializados?
En esta publicación, repasaremos los conceptos y procesos clave y más importantes del desarrollo de productos ágiles, y cómo puedes aplicarlos a tu propia organización.

Primero, antes de ver Agile, echemos un vistazo a waterfall:

Waterfall

'Waterfall' es el nombre del estilo más tradicional de desarrollo de productos, tanto para software como para productos físicos. Sigue un proceso lineal. Para empezar, normalmente hay un largo proceso de planificación, en el que se planifica absolutamente todo para el proyecto completo. Esta etapa de planificación puede durar varios meses.

Una vez completada la planificación, el proyecto pasará a la siguiente etapa, 'Diseño', donde se finaliza todo el diseño del producto. El proyecto continúa avanzando a través de las etapas, siempre completando la última etapa por completo antes de pasar a la siguiente.

Finalmente, el producto terminado completo se lanza al mercado, meses, si no años, después de la etapa de planificación inicial. Como resultado, podría introducirse en el mercado el producto equivocado, y lo que originalmente podría haber sido un producto bien planificado con una gran adecuación al mercado ahora podría estar obsoleto en el momento de su lanzamiento. La tecnología puede haber cambiado o la demanda del mercado puede haber cambiado.

Waterfall vs Agile

Hemos analizado waterfall, pero ¿qué tiene que ver con Agile?
Con Agile dividimos el proceso de waterfall en partes más pequeñas.
Primero hacemos la planificación suficiente para empezar. En lugar de planificar todo el producto, solo planificaremos un componente muy pequeño, tal vez solo una característica o dos.

Luego, nuestro objetivo es construir y diseñar lo suficiente para poder enviar este pequeño conjunto de funciones, también conocido como "lanzamiento incremental".
En Agile, todo este proceso, desde la planificación hasta el lanzamiento incremental, suele tardar unas 2 semanas y suele denominarse "sprint".
Una vez que hemos hecho un lanzamiento, comenzamos el ciclo de nuevo. Cada vez hacemos una planificación suficiente para crear la próxima versión incremental de software funcional.

Al realizar pequeños lanzamientos regulares, el proceso del producto es flexible. A medida que enviamos pequeños conjuntos de funciones o versiones incrementales, podemos comenzar rápidamente a probar y recopilar feedback de los usuarios sobre cada función enviada. Esta prueba continua significa que podemos responder rápidamente a los requisitos nuevos y cambiantes. Como resultado, podemos ajustar continuamente la hoja de ruta a corto plazo para satisfacer las necesidades de los clientes, lo que significa que es mucho más probable que entreguemos un producto final que guste mucho más y sea verdaderamente útil para nuestros usuarios.

Principios Agile

El desarrollo ágil de productos se basa en los 12 principios ágiles. Sin embargo, para que este artículo sea más útil para los principiantes, centrémonos en los 4 principios clave que creo que son útiles para tener en cuenta si eres nuevo en Agile.


1-Reflexionar y ajustar: a intervalos regulares, el equipo reflexiona sobre cómo volverse más efectivo, luego sintoniza y ajusta su comportamiento en consecuencia.

2-Satisfacer al cliente: Nuestra mayor prioridad es satisfacer al cliente mediante entregas rápidas y continuas de software valioso.

3-Entregar con frecuencia: la idea es entregar software que funcione con la mayor frecuencia, desde un par de semanas hasta un par de meses, pero siempre dando preferencia a la escala de tiempo más corta.

4-Equipos auto organizados: Las mejores arquitecturas, requisitos y diseños surgen de equipos auto organizados.


Como puedes ver los principios Agile no son una lista de procesos a seguir al crear un producto, sino un conjunto de valores y creencias guía que se pueden usar para ayudar a tomar decisiones útiles para desarrollar productos.

Si has estado aprendiendo sobre el "mundo ágil", es muy probable que también hayas escuchado otros términos, como "Scrum" y "Kanban". Scrum y Kanban son dos metodologías ágiles muy populares. Son marcos de desarrollo de productos que están diseñados para ayudar a los equipos a lograr los principios ágiles.

Sin embargo, si bien estas metodologías pueden ayudar a un equipo a ser ágil, no son necesariamente ágiles en sí mismas. Seguir estas metodologías solo da como resultado una práctica Ágil si ayuda al equipo a lograr los principios Ágiles. No necesariamente necesitas seguir estrictamente una metodología o procesos si descubres que esa metodología no está ayudando a su equipo a lograr los principios Agile. ¿El equipo está reflexionando y ajustándose? ¿Estás entregando funciones con frecuencia? Lograr los principios ágiles es lo que determina si un equipo es verdaderamente ágil, no la metodología que se use.

Tal vez estás aplicando Scrum, lo que sugiere tener una reunión diaria para conectarse con su equipo, pero después de aplicarlo durante algún tiempo, te das cuenta de que simplemente no está funcionando. Quizá te das cuenta que tu equipo es más productivo y se contenta con tener reuniones sobre un tema específico. ¡Eso también está bien! Puedes hacer ese cambio. Parte de Agile es responder al cambio, revisar sus procesos y adaptarse, y eso también puede significar adaptar la forma en que estructura el desarrollo de su producto.

En última instancia, debe usar lo que observes que ayuda a tu equipo a tomar mejores decisiones ágiles. No existe un método o sistema verdadero que sea la única forma de ser ágil. Para los equipos nuevos en Agile, puede ser más fácil seguir una metodología establecida para comenzar con alguna estructura establecida y luego, una vez que el equipo se sienta cómodo, puedes intentar cambiar la fórmula.

¿Quién conforma un equipo ágil?

Un equipo Agile está formado por:

Equipo de desarrollo
Este equipo a menudo incluye habilidades como diseño, desarrollo, pruebas y entrega. Los miembros del equipo a menudo juegan múltiples roles, algunos días pueden estar probando y otros días desarrollando.

Dueño del producto
El propietario de un producto es responsable de maximizar el valor del producto creado por el equipo de desarrollo. Este rol interno reúne los requisitos técnicos, prepara la acumulación de productos y detalla las historias de los usuarios.

Stakeholders
Los stakeholders pueden ser cualquier persona afectada por el desarrollo de un proyecto de software. Esto incluye una amplia categoría de personas, como usuarios finales, personas de negocio y IT.

Entendiendo a tus usuarios

• Entrevistar a los usuarios actuales sobre cómo funciona el producto en su vida.
• Permitir a los usuarios probar sus nuevas funciones después de un sprint y dar feedback.
• Preguntar a los usuarios potenciales sobre su experiencia con los productos de la competencia.

Establecer de la estrategia del producto.

Al comienzo de un nuevo proyecto de desarrollo de productos Agile, debes definir la estrategia del producto. Esto resume la necesidad comercial que tu proyecto está abordando. En términos más simples: ¿cuál es el objetivo final de este proyecto Agile y cómo lo lograrás?

Los owner de productos son responsables de crear una estrategia de producto en colaboración con stakeholders para asegurar la aceptación y la alineación. Es opcional, pero se recomienda incluir también a miembros clave del equipo de desarrollo.
Establecer una estrategia clara es crucial en un entorno Agile. Los equipos de desarrollo a veces pueden sentirse atrapados en los detalles de un proyecto y perder de vista el propósito general detrás de todo su trabajo. La estrategia del producto es un objetivo de alto nivel al que el equipo puede referirse para asegurarse de que están viendo el panorama general.

Para prepararte para una reunión de estrategia de producto, ya deberías haber trabajado en estrecha colaboración con los usuarios para comprender sus puntos débiles, investigar el mercado y conocer sus objetivos comerciales generales. Hay muchas plantillas y herramientas de mapping que puedes usar para ayudarte a crear tu estrategia de producto. Uno que recomiendo porque considero que es sencillo para los principiantes es el método Elevator Pitch.

Crear la hoja de ruta de producción


Una vez que se decide la estrategia, el owner del producto con los stakeholders se reunirán para empezar a planificar el roadmap del producto.

El roadmap del producto es una aproximación de alto nivel de los requisitos, las prioridades y un marco de tiempo flexible de cómo se completará todo.

Jeff Gothelf, autor de Lean UX, explica bien el dilema del roadmapping Agile,

One of the biggest challenges in product management is planning the work in a linear, visual way…Digital product development is not linear. It is iterative. We build some things. We ship them. We see how they impact customer behavior. We iterate them and ship again.”

Los proyectos ágiles son flexibles por naturaleza, por lo que planificar la hoja de ruta para el próximo año o dos puede ser un desafío y debe abordarse de manera diferente a la planificación normal de la hoja de ruta.

Al igual que al establecer la estrategia de producto, primero necesitas hablar con los usuarios e identificar sus necesidades antes de la reunión de la hoja de ruta. ¡Las necesidades de los usuarios son combustible para la planificación!

1. Empieza a pensar en temas:

Deberías haber descubierto algunos problemas o áreas de mejora mientras hablabas con los usuarios, y con eso y las necesidades de tu negocio en mente, puedes comenzar a crear sus temas.

Los temas son elementos en su hoja de ruta. Deben hablar de resultados, no de características. Los resultados son cambios específicos medibles en la vida de su organización o de sus usuarios que desea lograr con su producto. Las características son simplemente las formas en que alcanzamos ese resultado.

Por ejemplo, un resultado que podríamos querer lograr es "Menos visitantes del sitio web que abandonen su carrito de compras". Y una función que podríamos crear para ayudarnos a conseguirlo podría ser ofrecer automáticamente códigos promocionales cuando se agrega algo a un carrito de compras.

Sin embargo, a nivel de la hoja de ruta, no queremos enumerar nuestras ideas para las funciones, ya que vendrán más adelante. Al usar temas basados ​​en resultados, mantenemos nuestra hoja de ruta en un nivel alto, lo que significa que podemos ser flexibles y cambiar funciones dentro y fuera del tema sin afectar significativamente la hoja de ruta.


2. Medir el éxito del producto:

Ya sabemos que, “No puedes mejorar lo que no mides”.
Para cada tema, necesitas decidir como equipo qué métrica o KPI usarás para medir el éxito. Esto nos ayudará a evaluar la calidad de un producto y hacer un seguimiento del rendimiento del equipo.

Las métricas comunes de éxito del producto se miden por la forma en que los usuarios interactúan con los productos y servicios, como la participación del cliente, las tasas de conversión y la rotación de clientes. Sin embargo, ten cuidado, ya que no necesitas medir algo en detrimento de otra información, y tampoco deseas medir demasiadas cosas que dispersen el enfoque del equipo.

3. Crea épicas:

Debajo de cada tema, la hoja de ruta incluirá una o más épicas (unidades de trabajo para servir al tema). Cada épica constará de las características e historias relevantes necesarias para completar esa épica.

A menudo se discute en los círculos ágiles sobre la diferencia entre epicas y temas. Un tema es típicamente una agrupación de épicas similares, pero sea cual sea su definición, es importante mantener los temas en un nivel superior.


4. Priorizar:

Una vez que hayas identificado varios temas que el equipo ha considerado importantes, debes priorizarlos. Después de todo, tienes recursos limitados y no puedes abordar todo a la vez. Entonces, teniendo en cuenta los KPI, la estrategia del producto y los recursos disponibles, puedes comenzar a clasificar los temas.


5. Iterar:

Al igual que los productos producidos por equipos ágiles, las hojas de ruta ágiles son iterativas. Los procesos ágiles de planificación y planificación son actividades continuas que deben ajustarse periódicamente para adaptarse a los cambios.

Por ejemplo, pueden aparecer en el horizonte oportunidades inesperadas en el mercado que su empresa sería una tontería dejar pasar. Para que las empresas sobrevivan en un mercado volátil, no solo pueden cambiar las hojas de ruta, sino que deben hacerlo.

La hoja de ruta del producto no es solo para los stakeholders del negocio, sino también para todo el equipo del producto. La hoja de ruta brinda al equipo una visión general del producto y cómo el trabajo que están haciendo hoy se ajusta a esa imagen. Como resultado, pueden tomar decisiones mejor fundamentadas en su trabajo.

También sirve como una buena manera de mantener a las personas de negocio y a los stakeholders en la misma página y enfocados en el panorama general. Es este uso de la hoja de ruta del producto para comunicar mejor la estrategia a largo plazo del equipo y los stakeholders uno de los beneficios más útiles de una hoja de ruta del producto, convertirse en una herramienta de comunicación. ¿Y para planes tácticos más detallados? Usaremos el product backlog. 

Product backlog

Una buena hoja de ruta de productos Agile proporciona contexto para la acumulación de productos. Aquí es donde empezamos a entrar en detalles.

Es la única fuente autorizada para las cosas en las que trabaja un equipo. Un product backlog es una lista de las nuevas funciones, los cambios en las funciones existentes, las correcciones de errores, los cambios de infraestructura u otras actividades que un equipo puede realizar para lograr un resultado específico. Puedes pensar en algo similar a una lista de "cosas por hacer" para el equipo de desarrollo.

A medida que lleguen las solicitudes, los comentarios de los usuarios y las nuevas ideas, terminarás con un montón de funciones y proyectos potenciales para realizar. Estos viven en tu product backlog hasta que estés listo para agregarlos a un sprint.

No se hace nada que no esté en el product backlog, pero también a la inversa: la presencia de un elemento en el product backlog no garantiza que será entregado. Los elementos del product backlog son simplemente opciones que tiene el equipo para lograr un resultado específico en lugar de un compromiso.

El product backlog es flexible. El administrador de trabajos pendientes, generalmente el product owner, debería poder agregar o eliminar elementos rápidamente en el trabajo pendiente. El product backlog debe adaptarse constantemente a la forma en que se considere que el equipo puede lograr mejor el resultado deseado.

Los elementos del product backlog toman una variedad de formatos, siendo las historias de usuario las más comunes.

Historias de usuario

Las historias de usuario son historias simples que describen algo que le daría valor al usuario. Nos ayudan a organizar nuestro trabajo en pequeñas partes.Un formato común que se utiliza para las historias de usuarios es el siguiente formato 'Quién, qué + por qué':

Como tal  <rol>
Quiero <objetivo>
Para conseguir <beneficio>

Por ejemplo, "Como trabajador por cuenta propia, quiero realizar un seguimiento fácil y sin estrés de las finanzas relacionadas con el trabajo, para poder estar seguro de que he pagado mis impuestos correctamente".

Las historias de usuario pueden ayudarnos a seguir uno de los principios clave de Agile: "nuestra máxima prioridad es satisfacer al cliente a través de la entrega temprana y continua de valiosas funciones de software".

Al final de nuestro sprint de 2 semanas, nuestro objetivo es haber entregado nuestro lanzamiento incremental de valiosas funciones de software. Para completar las historias de los usuarios y entregar software valioso, solo nos enfocamos en construir lo que es necesario para entregar el valor.

Por ejemplo, en waterfall es posible que deseemos construir primero la base de datos completa para todo el producto antes de pasar a otras partes de la estructura. En Agile, solo construiremos lo suficiente de la base de datos para ofrecer la función.

Puede parecer poco intuitivo al principio, y es posible que tengas que volver atrás y volver a trabajar en cosas que hiciste en el pasado a medida que las futuras historias de usuarios se vuelven más claras. Pero es importante recordar que la metodología Agile es una forma más eficiente de crear productos. En lugar de esperar años para lanzar un proyecto, en cuestión de semanas puedes enviar características funcionales que agregan valor al usuario y al negocio. A partir de las funciones que envíes, puedes recopilar feedback para futuras iteraciones y adaptarte rápidamente a los cambios del mercado.

Sprint backlog y planificación de sprints

Una vez que la acumulación de productos haya recopilado suficientes historias de usuarios para comenzar a enviar algunas características, estarás listo para la reunión de planificación del sprint.

Un sprint suele durar 2 semanas y se repite varias veces. En cada sprint, solo estás planificando y construyendo lo suficiente para lanzar la próxima versión incremental. El ciclo de sprint se repite hasta que se completa el producto.

Antes de un nuevo sprint, el equipo tendrá una reunión de planificación de sprint para crear la acumulación de sprint. Aunque no es necesario pasar demasiado tiempo en esta etapa, en realidad podría llevarle de 2 a 4 horas.

La acumulación de sprints es como un subconjunto de la acumulación de productos. El equipo se pone de acuerdo acerca de qué historias del product backlog quieren incluir en el próximo sprint.

La planificación de Sprint en Agile la realiza el equipo del producto, pero debe incluir información y orientación del propietario del producto. Sin embargo, en última instancia, depende del equipo decidir qué debe (y puede) hacerse en un sprint.

Mientras planifica el sprint, naturalmente encontrará que algunas de las historias de usuarios del product backlog tienen menor prioridad para el usuario. Al decidir en qué historias de usuario trabajar en este sprint, idealmente queremos construir historias de alta prioridad primero.
Pero, ¿cuántos deberíamos tirar en un sprint? Tenemos un tiempo fijo y, obviamente, no podemos construirlos y lanzarlos todos.

Un método popular para priorizar las historias de usuarios en la planificación de sprints es usar story points. Aquí es donde el equipo analiza los votos de las historias para asignar historias con puntos, para estimar cuánto esfuerzo requerirá una historia. De esta manera, puede tener una idea de cuáles son historias más grandes y cuáles son logros fáciles y más sencillos. Luego, el equipo decide qué historias se pueden completar dentro del marco de tiempo del sprint.

A medida que el proyecto continúa, la velocidad pronosticada se volverá clara: aproximadamente la cantidad de puntos que su equipo puede manejar en un sprint sin sobrecargarse de trabajo o perder calidad. Esto ayudará con la planificación futura.

La estimación es difícil, y con un nuevo equipo puede ser difícil predecir el esfuerzo estimado, así que no te preocupes si te da cuenta después de algunos sprints de que necesitas recalibrar tus estimaciones. Como siempre con Agile, la reflexión y la adaptación son claves.

En la reunión de planificación del sprint, también debes revisar su definición de "done": así es como se verás el software al final del sprint. Es importante que las personas que realizan el trabajo (los desarrolladores) y los que lo inspeccionan (el propietario del producto y otras partes interesadas) estén todos en sintonía con esta definición. 

Daily meeting

• ¿Qué completaste ayer?
• ¿En qué estás trabajando hoy?
• ¿Hay algún obstáculo que se interponga en el camino?

Revisiones