Buscar en Gazafatonario IT

miércoles, mayo 05, 2021

Buenas y “malas” historias de usuario


Los criterios INVEST* no son los únicos que hacen a una historia de usuario una “buena” historia de usuario. Pero son un buen comienzo. Además, decir o pensar que una historia de usuario es buena o mala quizás no sea la mejor idea. En cualquier caso, lo más importante es si la historia está preparada o no para implementarse o desarrollarse. Si no lo está, entonces hace falta conversación, ojalá cara a cara, para ponerla a punto: conversación entre los usuarios o interesados clave y un dueño de producto o gerente de producto; y también, conversación entre estos y el equipo de personas que finalmente hará el trabajo de implementación de esas historias.

Nota mental: en realidad, lo más más importante de la historia de usuario es que genere Valor, en cualquiera de sus modos, por ejemplo: más ingresos, mayor felicidad a los usuarios o consumidores, menores gastos, mejora en la marca organizacional, más clientes, mayor aprendizaje, entre muchas otras formas de valor.

Y como son un buen comienzo, veamos algunos ejemplos de cómo se cumplen o no esos criterios en las historias de usuario. Usaremos la forma Connextra para escribir las historias de usuario, pero recordemos que hay muchísimas formas, cuando no infinitas, de representar las historias. Los ejemplos corresponden a una plataforma de compra y venta en línea de productos y en algunos de ellos obviaré la parte del “para” qué se quiere la historia, solo con la intención de concentrarnos en lo fundamental.

Independiente

En la medida de lo posible, las historias se pueden implementar en cualquier orden.

La historia del Comprador no se podrá implementar hasta tanto no estén establecidas todas las condiciones de venta que el Vendedor requiera. Y esta historia solo es verificable en cuanto a instituir y preservar las condiciones de venta, pero no en cuanto a hacerlas cumplir por el comprador. Las cosas así, es posible eliminar la dependencia, dividiendo las historias de usuario usando como criterio las distintas condiciones de venta del producto, desde el punto de vista del Vendedor, además de combinar el establecimiento de los términos de venta con algunas condiciones para hacerlos cumplir en cada historia.

Negociable

Se deja abierta la forma de lograr el objetivo, sin sugerencia de implementación.


La historia de usuario original no deja ningún margen al diálogo en cuanto a las posibilidades de implementación de las formas de pago, es la indicada y nada más. En cambio, la historia derivada abre las posibilidades y permitirá que se tomen las mejores decisiones para su confección mediante conversaciones sucesivas.

Valiosa para el usuario

Algo que el usuario realmente pueda usar, no solo una tarea técnica.

Hasta tanto las imágenes del producto puedan usarse, no tienen ningún valor y, por consiguiente, la historia de usuario en sí carece de trascendencia, de peso (alias de valor). No proporciona ningún beneficio. El impacto de su contraparte, sin embargo, es a todas luces evidente. El valor de la historia salta a la vista.

Estimable

No se requiere investigación, bien entendida.


¿Cuántos informes son? ¿Cuáles? ¿Con qué información o datos? ¿En qué momento se producirán? Estas y algunas otras cuestiones sin respuesta aparente no permitirán que la historia de usuario pueda estimarse en complejidad o tamaño, mucho menos en tiempo. La historia contigua, en cambio, goza de mayor precisión: es una única lista, un informe solo de productos entregados; estas condiciones reducen las posibilidades y aumentan los detalles necesarios para realizar una predicción más o menos confiable sobre cuándo podrá estar terminada.

Pequeña

Se puede pasar del concepto a estar preparada para su lanzamiento en un par de semanas y preferiblemente dentro de un par de días.


Como con el caso de la historia no estimable, no conocemos la cantidad ni la calidad de los informes a los que se refiere esta historia. El informe resumido por categoría de producto, por su parte, es algo mucho más acotado: es uno solo, su carácter de “resumido” ya deja entrever que los datos que incluirá son pocos. Tiene visos de ser una historia que se pueda implementar en dos o tres días de una iteración.

Comprobable

Es posible medir algo específico para verificar que la historia está terminada.


¿Qué si
gnifica “rápidas”? ¿45 segundos? ¿27? ¿Un milisegundo? No hay forma de verificarlo, no será posible probar los términos de esta historia, ni siquiera con los mejores robots de prueba existentes hoy. En general, “rápido” es una expresión ambigua, imprecisa. Si decimos “2 segundos”, la ambigüedad desaparece de inmediato. Unos pocos casos de prueba nos permitirán comprobar la completitud de la historia.

 

¿Quieres saber más sobre historias de usuario?

En octubre estaré facilitando un curso donde te contaré de mis experiencias en este y otros asuntos sobre lo esencial de las historias de usuario. Encuentras más información en:

https://luchosalazar.com/portfolio/nuevo-curso-historias-de-usuario/

¡Te espero!

 

martes, abril 27, 2021

Un instrumento para ayudarte a mejorar como Scrum Master

 


Un Scrum Master adecuado puede manejar dos o tres equipos a la vez. Si está contento con limitar su función a la organización de reuniones, el cumplimiento de los plazos y la respuesta a los impedimentos que las personas informan explícitamente puede arreglárselas con la atención de medio tiempo a esta función. Es probable que el equipo aún supere la línea de base, las expectativas previas a Scrum en su organización y probablemente no sucederá nada catastrófico.

Pero si puedes imaginarte un equipo que se lo pasa en grande logrando algo que nadie antes creía posible, dentro de una organización transformada, considera ser un Scrum Master extraordinario.

Un Scrum Master Extraordinario puede liderar un equipo a la vez.

Recomendamos un Scrum Master dedicado por equipo de aproximadamente ocho personas o menos al comenzar.

Si no has descubierto todo el trabajo que hay que hacer, sintonízate con tu Product Owner, tu equipo, las prácticas de ingeniería de tu equipo y la organización en el entorno de tu equipo. Si bien no existe una receta única para todos, esta lista describe cosas típicas que muchos Scrum Masters pasan por alto, sobre todo quienes apenas están iniciando a caminar por el sendero de la agilidad.

Esta lista de chequeo es una adaptación, más que una simple traducción, del trabajo de Michael James (mj4scrum@gmail.com). He incluido algunos aspectos que me parecieron relevantes a la luz de los últimos cambios en la guía de Scrum y de mi propia experiencia usando la lista.

Para usar el instrumento

Diligencia la lista de chequeo, puedes seguir algunas de las recomendaciones en la página de Documentación de la herramienta. Luego haz clic en el botón “Todo preparado. Muéstrame las gráficas” que encontrarás en la parte superior derecha de la hoja de “Datos de Entrada”.

Como con otros instrumentos de este tipo, para usar la lista de chequeo correctamente, diligénciala con tu equipo o con otros Scrum Masters. Otra opción es llenar la lista individualmente y luego comparar el resultado con los miembros de tu equipo. Verás las diferencias y tendrás la oportunidad de debatirlas en equipo. Empieza a hablar sobre las diferencias, ¿por qué aparecieron? Así, ¡esta lista de chequeo puede ser el comienzo de un plan de mejoramiento! Eso sí, no pienses en juzgar tu desempeño como Scrum Master basado solo en esta lista de chequeo. Recuerda que lo importante es generar Valor, entregar lo que el negocio necesita más y mejorar el proceso continuamente.

Para limpiar los datos y volver a llenar la lista, simplemente haz clic en el botón “Limpiar Datos”.

Usa la herramienta y déjame saber en el foro de tus experiencias y de cómo podemos mejorarla.

Puedes descargar el instrumento aquí. 👇

jueves, abril 22, 2021

Daily Scrum Kaizen


Advertencia: que ya no sea un lineamiento de la guía de Scrum, no quiere decir que no podamos seguir usando las “tres preguntas”.

Muchas veces, la respuesta o solución a cómo mejorar la realización o ejecución de un evento Scrum está fuera del evento: por ejemplo, para mejorar la Planning, tenemos que mejorar el refinamiento; para mejorar la Review, tenemos que mejorar la Daily Scrum; para mejorar la Retrospective, tenemos que mejorar la Planning del Sprint siguiente. Siempre he creído que lo mejor de la retrospectiva ocurre cuando esta termina y es la implementación de las acciones de mejora seleccionadas.

Y para mejorar la Daily Scrum mejoremos también la Sprint Planning.

Al definir un Objetivo del Sprint claro, específico, medible, alcanzable y significativo y, por supuesto, circunscrito al Sprint que comienza. Pero definir o establecer el Objetivo del Sprint no es suficiente. ¿Cómo lo vamos a alcanzar? ¿Qué artefacto vamos a usar para verificar que lo logramos? ¿Cuál técnica de validación? ¿Con qué personas lo vamos a hacer? Son algunas otras preguntas que tenemos que poner sobre la mesa y encontrar sus respectivas respuestas.

Recordemos que en la Daily Scrum se inspecciona el progreso hacia el Objetivo del Sprint, entonces se hace necesario dejar de girar el evento en torno a cuáles tareas o actividades hemos realizado o dejado de hacer y enfocarnos más en cómo medir ese avance hacía el objetivo formulado. Además, el Objetivo del Sprint debe tener un vínculo muy íntimo con los elementos del Product Backlog que se van a desarrollar (alias “las historias de usuario”).

Las cosas así, por ejemplo, durante la reunión diaria, responder a la cuestión:

¿Está Terminada la historia de usuario actualmente en desarrollo?

Puede mejorar el rendimiento del equipo y su progresión hacía el Objetivo de la iteración. Incluso podemos complementar esa respuesta con la de esta otra pregunta:

¿Es posible que más personas participen en el desarrollo de esa historia? Sí, ¡pues manos a la obra! Es un poco de Swarming o Enjambre. En desarrollo de software, es posible; pero también lo es en otras actividades.

Otro giro que le podemos dar a la conversación en la Daily Scrum es acercarnos más a los criterios de aceptación de las historias de usuario en desarrollo. Estos criterios también son o deben precisos y medibles, pero más que nada, deben centrarse en el resultado, en el valor a entregar, y deben ser colaborativos, es decir, que inviten a la colaboración de todo el equipo y los interesados.

De esta manera, responder a cuestiones como:

¿Cuál es el estado de los criterios de aceptación de cada historia de usuario en desarrollo?

Es una forma de saber si nos estamos acercando a la meta de Sprint definida. Si el criterio de aceptación aun no ha sido abordado, estamos algo lejos. Si está en desarrollo, ya es un pequeño paso hacia la consecución de los resultados que queremos. Si finalmente está implementado o cumplido, entonces hemos dado un gran paso con miras al logro de ese propósito de la iteración.

Otra alternativa a las tres preguntas es simplemente hablar de “cómo vamos como equipo”, como personas.

¿Cuál es nuestro estado de ánimo? ¿Nuestro nivel de energía?

¡O simplemente aprovechemos esos quince minutos para tomarnos un café! Así sea virtual. Mientras escribo este artículo, seguimos en cuarentena por el virus, catorce meses después. Si estamos haciendo un “buen Scrum”, seguramente justo antes o justo después de la reunión, actualizaremos los radiadores de información a que haya lugar y cada miembro del equipo tendrá la oportunidad de coordinarse o sincronizarse con los demás a medida que avanza la mañana.

En la práctica, no es necesario responder a nada más.

¿Y los impedimentos, riesgos o problemas? Cambiemos un poco la postura sobre este asunto y reorientémonos precisamente hacia el trabajo colaborativo. A los miembros del equipo les podemos enseñar a “levantar la mano” cuando de problemas se trata en el momento en que estos ocurren, ¿por qué esperar a la cita diaria para mencionarlos? Es posible que falten muchas horas hasta la siguiente Daily Scrum y esto puede traer como resultado una baja en la productividad de algunas personas del equipo y, a su vez, que no se pueda conquistar la Meta pretendida.

Como ven, podemos seguir usando las tres preguntas, pero también podemos usar muchas otras tácticas y estrategias para mejorar no solo la Daily Scrum, sino cualquiera de los demás eventos. ¿Y tú, qué técnicas estás usando para mejorar tus reuniones diarias? Por favor, déjamelo saber en el foro.


miércoles, abril 14, 2021

Nuevo curso: Historias de Usuario - 10 de octubre

Las historias de usuario son un poderoso medio para fomentar la cooperación y la enseñanza de muchas cosas. Estas permiten crear un vínculo entre usuarios o consumidores y desarrolladores de productos o servicios. Y esta relación es el primer gran paso hacia la creación y pináculo de productos admirables, que influencien positivamente a las personas que los usen o consuman e incluso cambien para mejorar su estilo de vida.

Esta Certificación proporciona los fundamentos sobre las principales características de las historias de usuario como instrumentos de comunicación entre los miembros de equipo y los demás interesados en los proyectos de desarrollo de productos o servicios, sean de tecnología o de cualquier otra área del negocio.

Objetivos de Aprendizaje:

Al final del curso los participantes estarán en capacidad de:

  • Entender los beneficios de usar historias de usuario en entornos inciertos y ambiguos.
  • Desarrollar las habilidades necesarias para usar las historias de usuario como instrumentos de conversación entre las partes interesadas.
  • Aplicar varias formas de escribir historias de usuario.
  • Reconocer si una historia de usuario cumple con los atributos de toda buena historia de usuario.
  • Emplear distintas técnicas de división de historias de usuario para que estas se puedan elaborar en períodos muy breves de tiempo, desde unas pocas horas, hasta muy pocos días.
  • Usar las historias de usuario para comprender la proposición de valor del producto y de sus características desde el inicio del proyecto.
  • Guiar a otras personas de sus equipos en el uso apropiado de historias de usuario en contextos complejos y adaptativos.
  • Certificarse en User Stories Foundations Certificate (respaldando el conocimiento y la aplicación fundamental de las Historias de Usuario).

Público Objetivo:

Este curso y certificación es apropiado para cualquier persona interesada en usar las técnicas relacionadas con historias de usuario, que estén o vayan a participar en proyectos ágiles con marcos de trabajo como Scrum; también, para interesados en los proyectos que están en la cadena de valor de proporcionar características o requisitos a los equipos de desarrollo de productos o servicios.

● Gerentes de producto
● Dueños de Producto
● Mercadeo de productos
● Analistas del negocio
● Analistas funcionales
● Patrocinadores de los proyectos de desarrollo

También a las áreas de TI de la organización:
● Líderes técnicos
● Gerentes de Proyectos
● Desarrolladores
● Arquitectos de software
● Analistas de Prueba
● Diseñadores
● Scrum Masters
● Desarrolladores Scrum
● Consultores Comerciales,
● Consultores de Preventa de Proyectos
● Líderes Funcionales de Áreas Usuarias de Software o similares

Entre otras personas interesadas en mejorar las interacciones de manera efectiva con los demás miembros del equipo y de su empresa mediante el uso de historias de usuario.

Requisitos Previos:

Haber recibido entrenamiento o tener conocimientos o experiencia en al menos uno de estos temas:
● Scrum Master
● Product Owner
● Team Member

Opcional:
Leer el Manifiesto Ágil
Leer la guía de Scrum

Entrenamiento:

Tipo de Curso: Foundations

Código de la Certificación: USFC.

Examen de Certificación:

Formato: Opción Múltiple.
Preguntas: 40.
Lenguaje: Inglés/Español/.
Puntaje de aprobación: 32/40 o 80 %
Duración: 60 minutos máximo.
Libro Abierto: No.
Entrega: Este examen está disponible en formato en línea.
Supervisado: Será a discreción del Partner.

Información del próximo curso:

Duración: 9 horas

Modalidad: en línea (virtual)

Fechas y horarios:

Sesión 1:
martes 10 de octubre de 2023 4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 2:
miércoles 11 de octubre de 2023. 4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Sesión 3:
jueves 12 de octubre de 2023. 4 p.m. a 7 p.m. (GMT – 5. Bogotá, Lima, Quito)

Inversión:

U$195 precio temprano. *Hasta septiembre 12 de 2023.

U$245 precio regular.

Descuento de 10 % a grupos de tres o más personas. Escríbeme a contacto@luchosalazar.com si quieres acceder a este descuento.

QUIERO UN LUGAR EN EL CURSO

Atención: Incluye certificación User Stories Foundation Certificate

Escríbeme a contacto@luchosalazar.com para reservar tu cupo en un nuevo curso o para despejar cualquier duda que tengas.

¿Quieres este curso para tu empresa? Contáctame para más detalles.

 

jueves, abril 01, 2021

Sobre multifuncionalidad y la creación de un incremento de producto

Image by Alexandr Ivanov from Pixabay 

Sobre multifuncionalidad y la creación de un incremento de producto

O de las minicascadas en el Sprint y de cómo deshacernos de ellas

“Todos los patrones de conjuntos fijos son incapaces de adaptabilidad o flexibilidad. La verdad está fuera de todos los patrones fijos”. -Bruce Lee

De dónde venimos

Todos hablamos de que un equipo Scrum es un equipo multifuncional y autogestionado. En nuestro contexto, multifuncional significa que el equipo en pleno suma todas las habilidades y capacidades necesarias para producir un incremento de producto al final de cada iteración. En la práctica eso es más fácil decirlo que hacerlo posible. ¿Qué sucede cuando conformamos un equipo cuyos miembros, en el mejor de los casos, dominan solo una pequeña parte de ese espectro de multifuncionalidad necesaria para hacer el trabajo?

Estos escenarios son mucho más comunes de lo que creemos. Solo para mencionar uno de estos: pensemos en una empresa que viene trabajando con prácticas tradicionales de gestión en las últimas décadas y cuya área de Tecnología cuenta con proveedores externos: unos para desarrollar el software y otros para realizar las pruebas de este. Y tanto las personas de un proveedor como del otro no se hablan sino a través de procesos y herramientas, como un bug tracker o actas formales de entrega y recepción de partes del producto.

Es muy probable que en esos equipos prime la alta especialización: el así llamado desarrollador de front-end, el analista de requisitos, el desarrollador de back-end, el arquitecto del software, de un lado. El analista de pruebas funcionales, el de pruebas no funcionales, el automatizador de pruebas, lo que sería un gran avance, del otro lado. Seguramente cada uno de estos equipos incluya uno o más gestores de esto y de lo otro. Incluso la empresa para la cual trabajan, el cliente, cuente con sus propios roles y responsabilidades dentro de todo este intrincado ecosistema de trabajo.

Imaginemos ese escenario: aquí los unos y los otros son de organizaciones diferentes. Pensemos en que ahora esa empresa quiere hacer las cosas usando enfoques ágiles y lean y prácticas como Scrum e historias de usuario. Además, quiere aprovechar el conocimiento que tienen sus proveedores actuales y decide invitarlos a embarcarse en un viaje que los llevará por los caminos ignotos de la agilidad: una nueva forma de pensar y de hacer las cosas, nuevos comportamientos, conceptos y preceptos muy distintos a los que venían usando, “metodologías” con poca información sobre el cómo hacer las cosas. Nuevos roles. ¡Y un solo equipo!

Para dónde vamos

Image by Merhan Saeed from Pixabay 

Entonces esto de la autogestión y la multifuncionalidad no ocurre mágicamente por la intervención de un Scrum Master o de un agente de cambio con alguna etiqueta específica. Es fácil decir o proponer que el tamaño de los elementos del product backlog se encuentren en un rango, por ejemplo, entre 1/10 a 1/6 de la velocidad “conocida” del equipo. Pero una cosa es contar con un equipo cuyos jugadores dominen más de una especialidad, sino todas, a hacerlo en un equipo donde eso no ocurre ni ocurrirá durante algún tiempo. Adquirir habilidades T toma tiempo, aunque los beneficios son evidentes una vez que se consigue. Pues bien, una primera recomendación es reducir aún más el tamaño de las historias de usuario.

Es algo para tener en cuenta cuando se hace refinamiento o, simplemente, cuando se dividen elementos del product backlog en piezas más pequeñas. Eso es necesario porque el trabajo en el sprint será una minicascada: si se trata de desarrollo de software, por ejemplo, primero se realizará el trabajo de diseño y programación y luego se hará el trabajo de pruebas o de aseguramiento de la calidad. Incluso es posible que, en cada una de esas breves fases, haya etapas más pequeñas que se lleven a cabo de manera secuencial.

Las cosas así, no será posible cumplir la promesa de tener elementos del product backlog (alias las historias de usuario) terminados durante los primeros días del sprint. Esto, como sabemos, sube la presión y el estrés sobre el equipo y sobre los interesados y usuarios, representados por el Product Owner. Es un hecho: llegar a la mitad del sprint o más allá, independientemente de su duración, sin que ninguna historia de usuario alcance la Definición de Terminado, aumenta la ansiedad e inicia un ciclo nocivo de sucesos que derivan en resultados pobres, pero, sobre todo, en desmotivación y en una baja de energía en el equipo.

Estas son algunas recomendaciones de experimentos que he encontrado útiles para despejar esas nubes cenizas que arremeten contra el trabajo colaborativo:

·       Historias de usuario más pequeñas.

·       Menos historias de usuario.

·       Sprints de dos o de tres semanas. Siempre podemos disminuir la duración más adelante.

·       Un refinamiento que “mire” dos o, mejor, tres Sprints hacia adelante.

·       Manejo de expectativas con los usuarios e interesados, vía la Product Owner o el Scrum Master o alguna otra persona del equipo o muy cercana a este.

·       Ordenamiento por valor del product backlog, más que hacer priorización. Es decir, ordenar uno a uno, por valor e impacto para el negocio, para los usuarios o clientes, cada historia de usuario. Muchas veces la priorización se hace por grupos de elementos. El ordenamiento se hace de manera individual. Esto asegura que en cada sprint se entregue Valor, aunque este sea en pocas cantidades.

·       Foco en una historia a la vez y concentrarse en su finalización.

·       Promover la colaboración, el trabajo en equipo, la inteligencia colectiva.

Pero lo más importante y crítico es poner en marcha un plan de desarrollo de competencias que faculte a las personas para adquirir habilidades T en principio y, más adelante, habilidades Pi. Esto toma tiempo, requiere de una inversión considerable, pero es lo que va a permitir hacer las cosas de una manera diferente de una vez por todas y para siempre. Un plan que incluya:

·       Adquisición de nuevas prácticas y, si es necesario, de nuevas herramientas.

·       Trabajo en pares.

·       Usar el patrón Swarming o Enjambre. Esto es, todo el equipo, o casi todo, trabajando en una única historia de usuario a la vez. Más sobre este patrón en: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/.

·       Pasantías.

·       Acompañamiento y mentoría.

·       Autoestudio.

·       Potenciación de habilidades.

·       Práctica. Kata. Kata. Kata.

Los beneficios de desarrollar este plan no girarán solo en torno al aumento de la productividad del equipo, sino también a la entrega de mayor valor en cada iteración, al incremento de la calidad, a la mayor satisfacción y felicidad de usuarios o consumidores finales, y también contribuirán a energizar al equipo, a su bienestar, a menos estrés y a más motivación.

¿Qué te parecen estas ideas? Por favor, cuéntamelo en el foro.


---

*Crédito de la imagen de la sección "De dónde venimos": silhouettes by Gerd Altmann from Pixabay