viernes, 12 de junio de 2020

¿Cualquiera ha de tener la autoridad para parar el tren?

Inbar Oren hablando de la PI Planning totalmente distribuida
Estoy de asistente virtual en el European SAFe® SUMMIT 2020 y asistí a la charla "Fully Distributed PI Planning - How to Collaborate and Align in a Remote Environment" de Inbar Oren, y cuando le oí decir la siguiente afirmación:

Everybody has the ability
to stop the train

comprendí la profundidad del compromiso que adquieren todos los individuos subidos a un (ART) Agile Release Train.

Al final de la PI Planning todo el ART participa del voto de confianza con una técnica muy simple llamada fist of five: El RTE pregunta "Dado lo que sabe cada uno, ¿qué tan seguros os sentís con el plan creado por el equipo para alcanzar los objetivos del PI?" y todos levantan en el mismo instante una mano con 1 a 5 dedos extendidos (desde 1 que significa sin confianza en el plan a 5 que significa un plan perfecto). Primero lo pregunta para dentro de los equipos y después lo pregunta a toda la sala.

Todos han participado durante dos o tres días en el evento, todos deberían de estar convencidos de que el plan funcionará, recordemos que en SAFe, y en Agilidad en general, los que planifican son los que van a hacer el trabajo. Si el voto promedio de la sala es de al menos 3 dedos el plan se considera bueno, si fuera menos habrá que retrabajar y hará falta un nuevo voto de confianza.

Dejar una PI Planning de dos o tres días sin un plan comprometido no es una opción, no podemos empezar en ningún caso en falso, estamos hablando que 100 personas pueden fallar y eso no debemos permitirlo. Por tanto queremos el feedback de todos del nivel de confianza en el plan obtenido; si hubiera alguien que no confiara deberemos de aclarar sus preocupaciones antes de empezar el PI. Los que hayan votado uno o dos dedos tienen la oportunidad de compartir su preocupación y razonarla, quizá sepan o hayan visto algo que los demás no. El RTE preguntará ¿Qué habría de ocurrir para que subierais vuestro voto por encima del 2?

Pero veamos qué significa ese voto de confianza, y qué compromiso implica: En primer lugar los equipos se comprometen a hacer todo lo que esté en sus manos para cumplir con los objetivos comprometidos del PI, que ellos mismos han marcado; y también se están comprometiendo a escalar de inmediato si se enteraran de cualquier impedimento que evite que se pueda cumplir con esos objetivos.

Esa es esencia de la frase de Inbar, todo el mundo tiene la habilidad (y el deber si es el caso) de parar el ART. Esto es pura esencia Lean del sistema de producción de Toyota cuando se educa a los operarios a "jalar la palanca", a para la linea de producción si identifican una mejora o un problema en la misma.

A lo largo de la ejecución del PI va a haber accidentes, incompatibilidades inesperadas, riesgos inexplorados, retrasos imprevistos y todos, absolutamente todos deben de estar comprometidos a hacerlos trasparentes a todo el ART en el momento en que surjan. En una empresa Lean/Agile se reconoce que los problemas imprevistos siempre existen y que tanto el liderazgo como TI lo entienden, lo aceptan y ponen los medios necesarios para resolverlos en el menor tiempo posible.

jueves, 11 de junio de 2020

¿Las reglas de negocio son una buena forma para dividir historias de usuario?

Esta estrategia de división propone que ciertas reglas de negocio especiales (estándares de la industria, regulaciones legales y cualquier tipo de restricciones complejas), que deban de cumplirse, sean incorporadas paulatinamente como ampliaciones incrementales de la funcionalidad inicial. 

Así el Propietario del Producto puede obtener historias de usuario iniciales que cubran un subconjunto de las reglas de negocio absolutamente necesarias, e implementar las restantes más adelante o de forma simplificada. Una regla simplificada como un mensaje en una tienda on-line que diga "No enviamos pedidos fuera de UE" puede que sea suficiente para empezar.

¿Cuándo aplicarla?

Cuando la historia de usuario involucra un conjunto de reglas de negocio implícitas o explícitas, algunas de las cuales podamos incorporar incrementalmente a posteriori.

Ejemplo de una historia de usuario de una tienda on-line:

Como comprador
Quiero pagar los artículos de mi carrito de la compra
Para poder recibirlos en mi casa

La división de esta historia genera historias igualmente complejas usando diferentes reglas de negocio:

Como propietario de la tienda
Quiero rechazar pedidos menores a 10 euros
Para poder evitar compras no rentables

Como propietario de la tienda
Quiero rechazar clientes de fuera de UE con pedidos inferiores a 100 euros
Para poder evitar gastos de envío que hacen la compra no rentable

Como propietario de la tienda
Quiero reservar stock de productos pedidos durante 48 horas
Para poder ofrecer a los clientes un stock real

Como propietario de la tienda
Quiero cancelar automáticamente pedidos para los que no he recibido el pago en 48 horas
Para poder vender esos productos a otros clientes
Las reglas de negocio se derivan de las políticas
Las reglas de negocio a menudo están implícitas por lo que para descubrirlas puede ser útil aplicar la estrategia de división por casos/escenarios de test primero.

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

miércoles, 10 de junio de 2020

¿Cómo dividir una historia de usuario por pasos de flujo de trabajo?

Es usual que cuando refinemos una historia de usuario que tiene un flujo de trabajo asociado descubramos que este la haga más compleja de lo que hubiéramos imaginado. Esta estrategia de división pasa por encontrar la historia MPV (Mínimo Producto Viable) y las historias incrementales necesarias para cubrir la historia original.

En algunas ocasiones el mayor valor está en el paso inicial y en el paso final del flujo de trabajo; los pasos intermedios agregan valor, pero pueden dejarse para más adelante. La historia con el paso inicial y la con el paso final formarían el MPV. La estrategia de división se basaría en los pasos o grupos de pasos que podamos agregar independientemente a posteriori.

Un flujo de trabajo ofrece una estrategia de
división excelente - cortesía de Pixabay
En otras historias de usuario todo el flujo de trabajo es necesario y el MPV ha de ser un corte fino de todo el flujo. La estrategia de división se basaría en agregar complejidad a través de historias que añadan lonchas finas al flujo de trabajo.

También nos encontraremos con historias de usuario en las que para algunos pasos del flujo de trabajo haya varias alternativas o caminos posibles. En esta situación podemos enfocar el MPV empezando por un único camino, el de máximo valor, y basar la estrategia de división en los diferentes caminos posibles.

La división por flujos de trabajo aporta el gran beneficio de mejorar el entendimiento de la funcionalidad, lo que a su vez facilita la definición del MPV.

¿Cuándo aplicarla?

Cuando la historia de usuario involucra un flujo de trabajo de algún tipo.

Ejemplo de una historia de usuario para una tienda on-line:

Como comprador
Quiero pagar los artículos de mi carrito de la compra
Para poder recibirlos en mi casa

División considerando los pasos del flujo de trabajo: MPV

Como comprador
Quiero confirmar y revisar mi carrito de la compra
Para poder confirmar antes de pagar

Como comprador
Quiero utilizar PayPal
Para poder informar de forma automática mis datos personales
y la dirección de envío y efectuar el pago

Incremento 1
Como comprador
Quiero identificarme a través de mi cuenta de Facebook
Para poder informar de forma automática mis datos personales y la dirección de envío

Como comprador
Quiero utilizar una tarjeta de crédito
Para poder efectuar el pago

Incremento 2
Como comprador
Quiero utilizar una transferencia bancaria
Para poder efectuar el pago

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

martes, 9 de junio de 2020

¿Cómo dividir una historia de usuario por roles?

Una de las primeras consideraciones al escribir una historia de usuario es sobre el rol para el cual la escribimos. Algunas historias pueden ser consumidas por varios roles, y probablemente de formas ligeramente distintas. Estos roles suelen estar representados por diferentes User-Persona que reciben valor de la historia de usuario de distintas maneras. La división por roles aplica cuando hay más de un rol receptor del valor descrito en la historia de usuario.

Imaginemos una web de reserva de restaurantes que va dirigida a dos públicos o roles: clientes comunes y clientes VIP. Probablemente el comportamiento de la reserva para uno u otro rol sea distinta, por tanto un Propietario del Producto encuentra en la división por roles una manera de dividir, priorizar y por ende entregar valor antes.

¿Cuándo aplicarla?

Cuando la historia involucra un conjunto de roles o grupos que realizan ciertas partes de la funcionalidad.

Ejemplo de una historia de usuario de un periódico on-line:

Como área responsable de noticias
Quiero publicar nuevos artículos en nuestra página web
Para poder atraer a nuestros clientes y tengan un aliciente para regresar periódicamente

División considerando los distintos roles involucrados en la funcionalidad:

Como cliente
Quiero leer nuevos artículos
Para poder estar informado de eventos importantes

Como periodista
Quiero escribir nuevos artículos
Para poder atraer a nuestros clientes

Como diseñador
Quiero aplicar los estilos corporativos a los artículos nuevos
Para poder integrarlos en el look&feel de nuestra página web

Como editor
Quiero revisar artículos nuevos antes de publicarlos en nuestra página web
Para poder prevenir errores

Como responsable audiovisuales
Quiero incluir fotografías y vídeos en los artículos nuevos
Para poder registrar las escenas de la noticia
Tres roles del ejemplo que con sumen la historia original: diseñador, responsable audiovisuales y editor - cortesía de Pixabay

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

lunes, 8 de junio de 2020

¿Cómo dividir una historia de usuario por operaciones?

La división por operaciones es indicada para aquellas historias de usuario que involucren operaciones, ofreciéndonos así una forma natural de dividirlas en implementaciones independientes de cada operación asociada.

Pensemos en historias de usuario sobre entidades como artículos, pedidos, tarifas, usuarios, etc., todas ellas asociadas a operaciones tipo CRUD (CRUD - Create, Read, Update & Delete). En este caso el Propietario del Producto puede llevar al equipo sólo las funcionalidades más prioritarias o complejas, como el alta de un artículo por ejemplo, mientras que otras, que son poco frecuentes, las puede dejar para más adelante, como por ejemplo eliminar o actualizar un artículo, que mientras no se desarrolle, se puede efectuar directamente sobre la base de datos (BBDD). 

¿Cuándo aplicarla?

Cuando una historia de usuario involucre operaciones, por ejemplo si menciona la palabra "gestionar" nos está indicando que cubre múltiples operaciones; como por ejemplo las típicas de alta, lectura, modificación y baja (CRUD - Create, Read, Update & Delete), u otras como "configurar" y "gestionar".

Ejemplo de una historia de usuario para un carrito de la compra:

Como comprador on-line de libros
Quiero gestionar los libros que voy eligiendo en un carrito de la compra
Para poder realizar la compra con mi decisión final

División considerando las operaciones individuales (CRUD):

Como comprador on-line de libros
Quiero añadir libros nuevos a mi carrito de la compra
Para poder tener visibilidad sobre los libros elegidos
y una vez agotado mi presupuesto efectuar la compra de esos libros

Como comprador on-line de libros
Quiero poder consultar mi carrito de la compra
Para poder saber lo que he elegido hasta el momento

Como comprador on-line de libros
Quiero poder actualizar las unidades de cada libro
Para poder comprar varios ejemplares de un mismo libro

Como comprador on-line de libros
Quiero poder eliminar libros de mi carrito de la compra
Para poder efectuar una compra de los libros más importantes para mi
y que la compra se ajuste a mi presupuesto
Añadir es "la" funcionalidad - cortesía de Pixbay

Démonos cuenta que desde la perspectiva del valor de negocio el añadir libros al carrito de la compra es la funcionalidad más prioritaria.

Si abriéramos nuestra tienda con esa única funcionalidad quizá habría compradores que puedan estar sorprendidos o molestos por la precariedad de la tienda, pero seríamos los primeros en apuntarnos a una oportunidad de negocio emergente de venta de libros on-line.

Por otro lado, lo quieren nuestros compradores es encontrar los libros que buscan y comprarlos, y aunque nuestra funcionalidad fuera precaria, si han logrado lo que buscaban, van a volver.

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

domingo, 7 de junio de 2020

¿Cómo dividir una historia de usuario por compatibilidad de navegador?

Esta estrategia propone dividir las historias de usuario por la diversidad de navegadores de internet por los cuales un usuario puede interactuar con la página web.

Las aplicaciones web a menudo tienen que trabajar con diferentes navegadores (Chrome, Firefox, Edge, ...), los más modernos tienden a ser más compatibles con los estándares y los más antiguos suelen necesitar de personalizaciones para que todo funcione correctamente.

Esta estrategia es una oportunidad de división que le permite al Propietario del Producto priorizar y así ayudar al equipo a dedicar tiempo y esfuerzo a la funcionalidad de más valor en cada momento. Probablemente un alto porcentaje de usuarios de un tienda on-line accedan con Chrome, y probablemente los usuarios de una intranet de una gran multinacional cargada de legacy accedan mediante Internet Explorer. Focalizándonos en el navegador más utilizado podemos entregar valor antes.

¿Cuándo aplicarla?

Cuando tengamos historias para aplicaciones web que deban funcionar en distintos navegadores.

Ejemplo de una web de venta on-line de artículos de belleza:

Como comprador
Quiero ver los detalles del producto
Para poder decidir si es lo que quiero comprar

División considerando los diferentes navegadores donde se debe poder ver la funcionalidad:

Como comprador
Quiero ver los detalles del producto en el navegador moderno Edge
Para poder decidir si es lo que quiero comprar

Como comprador con un ordenador vintage
Quiero ver los detalles del producto en Internet Explorer 7
Para poder decidir si es lo que quiero comprar

Como comprador con un móvil iPhone
Quiero ver los detalles del producto en mi navegador Safari
Para poder decidir si es lo que quiero comprar
Las estadísticas del blog marcan que la combinación de Chrome y Windows son la preferida de los lectores, por tanto nuevas historias de usuario pueden estar priorizadas según esta combinación

My thanks to Christiaan Verwijs on who I have based and who inspired me for this post :-)

sábado, 6 de junio de 2020

¿Qué podría ser una guía para el trabajo remoto?

#YoMeQuedoEnCasa y #YoTrabajoEnCasa, gracias Belén @bgcampa
Uno de los grandes aprendizajes del confinamiento por el COVID-19 es el haber impulsado verdaderamente el teletrabajo, un teletrabajo distribuido en el día a día en todas sus dimensiones. Los trabajadores del conocimiento llevamos meses trabajando en casa y nos coordinamos y comunicamos a través videoconferencias y herramientas colaborativas digitales.

Recordemos que no es lo mismo informar que comunicar, comunicar implica que la parte que da el mensaje tiene la responsabilidad de asegurarse que el mensaje llegué y se entienda correctamente. Actualmente la comunicación a través de los medios digitales conlleva un paradigma diferente y más que nunca la comunicación efectiva se ha vuelto crítica, tanto entre iguales como entre líderes y equipos.

Asistí a un meetup de Scaling Agile New York que trató sobre "Leading your organization in a remote environment (Agile & non-Agile)" en el que Bridgette Wilson de ezTagile expuso entre otras una guía para una comunicación efectiva en la situación actual.

La comunicación efectiva en el trabajo remoto viene marcada por 7 puntos clave:
  • Invertir en tecnologías de mensajería que fomenten la colaboración: Si estamos teletrabajando y queremos ser productivos a través de una comunicación efectiva, necesitamos dotar a las personas de las mejores infraestructuras de comunicación posibles; necesitamos todo el hardware y software necesario para que las videoconferencias y los tableros virtuales funcionen eficientemente y sean fáciles de manejar. El coste de retraso por no dotar a todo el ecosistema de teletrabajo de las herramientas adecuadas puede ser muy alto en comparación con la dotación de esas infraestructuras.
  • Establecer pautas para la comunicación: Colaborar de forma remota requiere acuerdos sociales adicionales o complementarios a las reuniones y eventos presenciales. Por ejemplo para fortalecer la comunicación en las videoconferencias es adecuado:
    • Tener el vídeo encendido en la medida de lo posible, vernos permite leer gestos y expresiones faciales que nos acercan y nos conectan, potenciado así la comunicación sincrona.
    • Tener el audio apagado mientras no hablemos para evitar posibles interferencias y ruidos ambientales que rodean a los asistentes.
    • Levantar la mano para pedir turno para hablar o preguntar.
    • Pausas frecuentes explícitas, como la técnica del pomodoro de 25 minutos por ejemplo, para que todos mantengamos la atención y estemos presentes.
  • Asegurar clarificar las expectativas a los equipos: Para que nuestros equipos y sus miembros entiendan de qué están formando parte y fomentar su participación activa, es necesario hacerles entender la misión que les estamos encomendando y las expectativas que tenemos.
  • Puntos de seguimiento individuales posteriores con los miembros de equipo: En presencial las conversaciones conllevan muchas comunicaciones en paralelo que alinean a las diferentes personas que participan, en remoto, y con la consecuente desconexión, es necesario cuidar de que las personas no diverjan en sus acciones con respecto a la misión del mensaje.
  • Pedir feedback sobre la situación remota: Trata de aplicar la mejora continua y refinar continuamente la comunicación; hemos de encontrar nuestra receta para la comunicación más efectiva posible, y para ello hemos de tomar feedback de todos los implicados y buscar oportunidades de mejora de forma frecuente.
  • Sobrecomunicar y ser claramente explícito: En eventos remotos ocurren momentos de personas en sombra, por ejemplo una distracción en su ubicación o una caída de conexión de la que no nos damos cuenta. En una sala presencial sabemos quienes están presentes y sabemos si ocurre algo. En remoto no tenemos esa visión completa de la sala y por tanto hemos de lanzar el mensaje con la mayor claridad posible, y repetirlo hasta que sintamos que ha llegado a todos.
  • Transparencia, alineamiento y visualizar el trabajo: Haciendo visible toda información significativa de forma transparente en tableros virtuales o herramientas que permitan tanto una visión agregada como detallada, reforzaremos la comunicación y el alineamiento en todo el equipo.
"Leading your organization in a remote environment (Agile & non-Agile)" en el que Bridgette Wilson