Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Dueño de Producto. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Dueño de Producto. Mostrar todas las entradas

jueves, abril 20, 2023

[Learning Lab] El poder de las historias de usuario: cómo crear productos que agreguen valor

Esta es la presentación “El poder de las historias de usuario: cómo crear productos que agreguen valor” que hice para el Learning Lab con Certiprof el 19 de abril de 2023.

Algunos aspectos de la presentación:

Las historias de usuario son una herramienta poderosa en el desarrollo ágil de productos porque ayudan a los equipos a centrarse en las necesidades y los deseos de los usuarios finales. Al crear historias de usuario, los equipos pueden identificar cómo su producto agregará valor a la vida de los clientes y asegurarse de que están construyendo algo útil y relevante.

El poder de las historias de usuario radica, entre otros, en los siguientes aspectos:

1. Centrarse en el cliente: las historias de usuario ponen al cliente en el centro del proceso de desarrollo del producto, asegurando que sus necesidades y preferencias impulsen las características y mejoras del producto.

2. Simplicidad: las historias de usuario son concisas y directas, lo que ayuda a los equipos a comunicarse de manera efectiva sobre los requisitos y objetivos del producto.

3. Colaboración: las historias de usuario fomentan la colaboración entre los miembros del equipo, fomentando una comprensión compartida del propósito y la visión del producto.

4. Adaptabilidad: las historias de los usuarios se pueden ordenar fácilmente, lo que permite a los equipos responder a las condiciones cambiantes del mercado o a los comentarios de los clientes.

Ahora bien, para crear productos que agreguen valor en todas las industrias, considera los siguientes pasos:

1. Identifica a tus usuarios objetivo: ¿Quiénes son las personas que se beneficiarán más de tu producto? Entiende sus necesidades y deseos.

2. Crea historias de usuario: haz narraciones concisas y centradas en el cliente que describan cómo tu producto abordará las necesidades y los deseos de los usuarios objetivo.

3. Ordena las historias de usuario: clasifica las historias de usuario en función de su impacto potencial, viabilidad y alineación con los objetivos estratégicos de tu empresa.

4. Itera y valida: prueba continuamente tu producto con usuarios reales para recopilar retroalimentación y refinar tus historias de usuario. Adapta su plan de desarrollo del producto según sea necesario para asegurarte de que estás entregando valor.

5. Considera los beneficios sociales y ambientales: Esfuérzate por crear productos que no solo generen ganancias financieras, sino que también contribuyan positivamente a la sociedad y el medio ambiente. Esto puede incluir la reducción de residuos, el apoyo a las comunidades locales o la promoción de la sostenibilidad.

Puedes descargar la presentación aquí:

martes, mayo 24, 2022

Monólogo de la Product Owner viendo llover en la organización*

 

El invierno de la agilidad se precipitó un martes al finalizar la reunión diaria. El día anterior había sido sofocante por las continuas solicitudes sin pies ni cabeza de la aún establecida oficina de proyectos o PMO. Pero aún en la mañana del martes no se pensaba que pudieran llover los improperios propios de grupos y seudoequipos de una empresa ámbar, más que de una que se preciaba de estar recorriendo ya el camino ágil hacia convertirse es una corporación verde y luego Teal.

Después de la reunión diaria y antes de que los miembros de los equipos tuvieran tiempo de ir por el café de la mañana, sopló un viento espeso y oscuro en forma de correo electrónico, el mismo que apenas tardó segundos en convertirse en un mensaje viral de chat que barrió en una amplia vuelta redonda los acuerdos y planes que se acababan de concertar para ese día. Alguien dijo junto a mí: “Son los vestigios de la gestión tradicional”. Y yo lo sabía desde antes. Desde antes de empezar la reunión y me sentí estremecida por la viscosa sensación en mi mente.

Los miembros de los equipos corrieron hacia los escritorios más próximos con una mano en la cabeza y los ojos arrugados, como tratando de protegerse de las noticias contradictorias y la polvareda de impedimentos que iban a encontrar en el detalle del correo. El techo de la oficina se cubrió como de una sustancia roja, que nos hizo recordar las épocas en la que los así llamados “líderes” demostraban su poder mediante el uso de la violencia y el acoso laboral, un retroceso abismal de esa utopía que suponía el pensamiento ágil y lean de poner foco en el bienestar de los empleados y la autogestión.

Durante el resto de la mañana, mi Scrum Master y yo estuvimos sentadas junto a mi escritorio, preocupadas por la revitalización de las prácticas de gestión antiguas debido al poco éxito que estaba teniendo la iniciativa de transformación ágil en la organización. Habían sido siete meses de primavera intensa, pero el polvo abrasante de la austeridad había vuelto junto al infame tren de las 2 de la tarde, lleno de los preceptos que habíamos abandonado cuando emprendimos el proceso de cambio cultural.

Entonces rebobiné mis recuerdos. ¿Por qué estábamos fracasando? ¿Por qué nos habíamos estancado ante la vegetación ámbar donde se llegaba a la cúspide empresarial por antigüedad y no habíamos logrado llegar a ese punto donde el empoderamiento estuviera en todos y cada uno de los miembros de la organización? Reviví una conferencia donde mi Scrum Master le preguntó al Agile Coach de turno que “cómo lidiaba con un PO con ínfulas de PM” y de otro Scrum Master que se sumó a la conversación para indagar sobre “qué hacer con un PO que habían nombrado a dedo y de manera inesperada”.

Vivifiqué mis pensamientos de entonces. Quise pensar que mi Scrum Master dijo “lidiar” solo como una forma de decir que quería mejorar su relación con el PO, conmigo, o con cualquier otro. Estaba segura de que lo primero en lo que debería pensar es en que no somos “sujetos de lidia”, como los toros, ni más faltaba. Tampoco se lidia con ninguna otra persona del equipo ni de la organización. Lidiar es un término despectivo que no ayuda a la relación. Al PO, aún con delirios de PM, lo acompañas, le facilitas su vida como PO, lo ayudas en la transición. Paso a paso. Despacio. Con paciencia. Sin importar como haya llegado al equipo. A propósito, casi siempre un PO llega al equipo como dijo el otro Scrum Master: nos ponen allí. El viernes a las 7 de la noche me dijeron que, a partir del siguiente lunes, además de lo que ya hacía, ahora iba a ser PO. Nada raro en una empresa de ambiente rojo, que tuvo su origen en las comunidades más primitivas y que se basaba en la existencia de un líder todo poderoso que ejercía su autoridad a través del miedo.

Tampoco se trataba simplemente de explicarme una sola vez cuales eran mis responsabilidades como Product Owner, o cuales eran las distinciones del enfoque ágil respecto al enfoque tradicional que veníamos abrazando desde siempre, ni de decirme que tome un curso de esto o de lo otro. Es un proceso. Es un camino realmente. En estas situaciones es donde el coaching y la mentoría entran a jugar un papel muy importante, es donde las conversaciones conscientes se vuelven el instrumento principal de mejora. Para mejorar la comunicación conmigo como PO, haciéndome pedidos efectivos, asegurándote de brindarme todo lo que necesito para que cumpla con mis compromisos, pero un paso a la vez.

Tienen que saber, estimados Scrum Masters, que el cambio es algo difícil, es el síndrome del “siempre lo hemos hecho así”. El temor a la falla. Es algo natural. Por ejemplo, enséñame que es distinto “fracasar” que “cometer errores” y que de ambas situaciones puedo aprender. Enséñame a experimentar como PO, a hacer planes es un contexto empírico. En los entornos tradicionales eso es algo que desconocíamos. Enséñame distintas maneras de expresar historias de usuario, entre otras, usando Hypothesis-Driven Development, por aquello de los experimentos. Las posibilidades son muchas, por no decir que infinitas.

Como siempre, el equipo en pleno debe estar comprometido en la gesta. Si el equipo no entrega valor, no produce al menos parte de los resultados que quiero como Product Owner, muy poco o nada de lo anterior nos va a servir. Y una vez más, con paciencia, el cambio de mentalidad no va a suceder pronto. Aún los PO con mentalidad de emprendedores tenemos miedo alguna vez o muchas veces.

No sé cuánto tiempo estuve hundida en aquel sonambulismo en que los sentidos perdieron su valor. Solo sé que después de muchas horas incontables oí una voz en el cubículo vecino. Era una voz fatigada, propia de las personas que han vivido bajo una cultura de sacrificio laboral y andando “millas extras” por doquier, como si el permanecer en la oficina produjera resultados de valor. Era una voz casi de persona convaleciente. Una voz que decía: “Ahora tendremos una retrospectiva”. Esa voz tenía razón, las últimas retrospectivas no habían servido de mucho, ¿por qué esta habría de ser distinta?

Solo entonces me di cuenta de que había llegado la cita a la reunión y de que en torno a nosotros se extendía un silencio, una tranquilidad, una beatitud misteriosa y profunda, un estado imperfecto que debía ser muy parecido a la muerte laboral.


* El título y algunos apartes del artículo están basados en el cuento “Monólogo de Isabel viendo llover en Macondo”, de Gabriel García Márquez.


Crédito de la foto de la portada: Foto de Zinkevych en iStockPhoto https://www.istockphoto.com/es/portfolio/Zinkevych?mediatype=photography

viernes, enero 21, 2022

Plantilla en Mural para el User Story Conversation Canvas


Las buenas historias de usuario estimulan, en el buen sentido, la conversación entre los involucrados (por ejemplo, Dueño de Producto y miembros del equipo). Además, las historias de usuario ven, o dejan ver, la funcionalidad desde la perspectiva del negocio, específicamente desde el Valor que la historia proporciona al negocio.

Como su nombre lo indica, este User Story Conversation Canvas es un medio de comunicación, un instrumento para promover y facilitar las conversaciones que se dan o deben darse alrededor de las historias de usuario. En el fondo, es una herramienta visual para documentar diferentes aspectos o dimensiones de historias de usuario nuevas o existentes en el backlog de producto.

Con este lienzo cualquier persona involucrada, el Dueño de Producto, el equipo en pleno o solo un miembro de este, el Scrum Master, incluso un usuario, puede encontrar la ayuda que necesita para describir adecuadamente los aspectos más relevantes de una historia de usuario, desde las personas que están o se verán involucradas durante la definición, evolución, desarrollo y puesta en marcha de la historia, hasta el resultado esperado y las métricas asociadas a la historia, pasando por el contexto de la misma. Pero, sobre todo, podrá encontrar el soporte que necesita para preparar conversaciones fantásticas sobre los elementos que componen el producto.

Las sesiones de refinamiento, la planificación y la revisión son tres de los escenarios principales donde podemos usar este Lienzo para Conversar Sobre Historias de Usuario. Pero se puede usar en muchas otras circunstancias: el dueño de producto hablando con los usuarios y otros interesados, los miembros del equipo de desarrollo, para acordar y sincronizar el trabajo a realizar, el Scrum Master y el Dueño de Producto, en conversaciones alrededor del producto, del backlog, al aplicar patrones para dividir las historias, entre otros escenarios.

¡Cuando se trata de historias de usuario, el énfasis es en la Conversación!

Para saber más sobre Historias de Usuario, los criterios INVEST de las historias y otros aspectos no menos relevantes sobre el tema, puedes visitar mi serie de artículos “Historias de usuario altamente efectivas” en mi Gazafatonariohttp://bit.ly/lashistoriasdelucho.

Descarga el lienzo y la guía completa en alta definición aquí:

http://www.gazafatonarioit.com/2017/05/the-user-story-conversation-canvas.html

Y para estos tiempos de trabajo virtual he desarrollado esta plantilla en Mural para que puedas trabajar de manera colaborativa con historias de usuario y con el lienzo para conversar sobre historias de usuario. Para ir a la plantilla, ve a la parte superior de la siguiente imagen y toca en "start from template" o en el icono de Mural.

martes, enero 11, 2022

Cinco formas de mejorar tu desempeño con historias de usuario

 

Imagen tomada de Pixabay

Las historias de usuario no son para escribirlas

La pregunta que debes hacer no es “¿cómo escribir mejores historias de usuario? El objetivo no debe ser escribir historias de usuario. Cámbiala más bien por ¿cómo mejorar mis conversaciones con historias de usuario? Las historias de usuario son un instrumento de comunicación social y sabemos que la forma más efectiva de comunicar información es la conversación, ojalá cara a cara. La forma más efectiva de evolucionar las historias de usuario es vía conversaciones, primero entre los usuarios e interesados y el Product Owner y luego, entre este y los miembros del equipo.

Puedes leer mi artículo Las historias de usuario como instrumentos de negociación para saber más sobre este tema. Clic aquí para leerlo.

Las historias de usuario te ayudan a encontrar tu por qué

Las historias de usuario son una herramienta para iniciar el descubrimiento del producto con el usuario, consumidor o cliente, no es para finalizarlo. De esta manera, tanto el Product Owner, como los desarrolladores (quienes hacen el trabajo finalmente) deberían ver las historias de usuario como algo que describe el por qué están haciendo lo que hacen, no precisamente qué están haciendo. Como siempre, si un usuario no estuvo involucrado en el descubrimiento y desarrollo de las historias de usuario, estas quizás no sean historias de usuario del todo; quizás sean más bien “quimeras imaginadas”.

Conoce a los usuarios

Por eso, mi primerísima recomendación, concisa, si eres responsable de las historias de usuario, es: habla con las personas que tienen la necesidad, el problema, indaga por el problema detrás del problema, la causa raíz. Esto aumentará tu comprensión de lo que se necesita y por qué. Acompaña esta práctica con un conocimiento profundo y empático del usuario o consumidor: quién es, qué hace, con quién lo hace, qué información intercambia y cómo lo hace, son algunas de las cuestiones a escudriñar si quieres tener éxito con historias de usuario.

En mi artículo Qué hay de "usuario" en las historias de usuario profundizo sobre este asunto. Clic aquí para leerlo.

Las historias de usuario y el product backlog

Una historia de usuario no está sola, aislada del resto del producto. Así que es importante pensar sobre ella como un componente de primer orden del product backlog. Y en este punto, es de mucha importancia considerar la transparencia del backlog. Recordemos que transparencia significa que todos los interesados, usuarios y equipo comparten el mismo significado de las cosas, por ejemplo, qué significa que algo está terminado.

Las cosas así, las historias de usuario deben ser transparentes y estar disponibles para todos los interesados, para que estos tengan visibilidad de lo que está haciendo el equipo, en qué orden y por qué. En particular, resuelve preguntas como:

- ¿Los interesados saben cómo acceder a las historias de usuario?

- Cuando acceden a las historias de usuario, ¿el contenido los ilustrará o los confundirá?

En mi artículo El extraño caso de las historias de usuario técnicas pongo de manifiesto que una “historia de usuario técnica” es una práctica disfuncional. Clic aquí para leer el artículo. Este otro artículo también te puede dar ideas al respecto: Buenas y “malas” historias de usuario. Clic aquí para leerlo.

Desarrollo de producto dirigido por hipótesis y experimentos

Las historias de usuario son hipótesis. Trátalas como tal. Haz experimentos y comprueba esas hipótesis. La última línea de defensa es el consumidor final, el usuario. Mientras tanto, no dejarán de ser eso precisamente: supuestos o conjeturas. En este apartado entran en escena las entregas tempranas y frecuentes y, sobre todo, la retroalimentación directa que logres de los clientes o usuarios. Es de esta manera que podrás adaptarte al entorno y tomar mejores decisiones en el futuro inmediato que beneficien a los usuarios. Para lograrlo, tus historias de usuario deben ser realmente pequeñas. Piensa que solo tienes algunas horas para implementarlas o construirlas, hasta unos muy pocos días, dos o tres a lo sumo.

En este apartado, una anotación especial para desarrolladores de software: si todavía te encuentras con el escenario de “mini cascadas”, es decir, primero un “subequipo” desarrolla la historia y luego otro “subequipo” prueba la historia, entonces tus historias de usuario deben ser aún más pequeñas. No te imaginas cómo sufren los analistas de prueba mientras esperan a que desarrollo les entregue las historias para empezar a probar cuando el final del sprint ya está encima. Como siempre, el mejor antídoto contra todo esto, es empezar a cambiar radicalmente las técnicas de desarrollo, incursionando en TDD, BDD y automatización, entre otras. Pero tengo que confesarlo, esto es más fácil decirlo que hacerlo. Por eso hago toda esta recomendación especial.

Quieres saber más

Estos y otros temas de interés hacen parte de mi curso de historias de usuario. En febrero estaré facilitando una nueva edición del curso. Toda la información en https://bit.ly/cursohu.


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í. 👇

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.

 

miércoles, diciembre 16, 2020

Scrum: cambió la guía ¿y ahora qué hago?


Se ha hablado mucho de los cambios en la guía de Scrum 2020. Pero ¿los hemos entendido? ¿Y qué sucede con lo que no cambió? ¡Scrum sigue siendo Scrum! ¿Por qué causaron tanto revuelo los tales cambios si es a todas luces evidente que la mala práctica de Scrum abunda en la región? ¿Ya leíste la guía completa y no solo el log de cambios que aparece al final de la versión en español?

¿Estás preparado para una conversación seria y profunda sobre Scrum? ¿Sobre los muy comentados, pero poco entendidos cambios propuestos este 2020? Lee la guía (toma menos de una hora hacerlo), anota tus inquietudes sobre la misma y acompáñanos en la última sesión de este año 2020 atípico. Hablaremos de Scrum, de lo que no cambió y no has terminado de entender, de lo que cambió y que te llevará mucho tiempo comprender. Te daremos pistas sobre cómo abordar tus próximas iniciativas ágiles con Scrum y prácticas relacionadas.

Es tu oportunidad de empezar el 2021 con una nueva y mejor visión sobre el marco de trabajo más ampliamente usado por los practicantes ágiles en todo el mundo. Invita a tus amigos y colegas, trae tu natilla y buñuelo navideño o lo que acostumbres compartir en navidad, y prepárate para un gran coloquio.

El 16 de diciembre nos reunimos en la Comunidad Ágiles Colombia a hablar un poco del tema, acompañado como siempre de mi gran amigo Jorge Abad. Grandes conversaciones.

Puedes ver y descargar la presentación con los aspectos más relevantes de esas conversaciones aquí:



Puedes ver el video de la sesión en Ágiles Colombia el 16 de diciembre de 2020, aquí:

martes, noviembre 10, 2020

De qué hablamos cuando hablamos de Historias de Usuario

Las historias de usuario son instrumentos de comunicación social que guían la creación y el desarrollo de producto.

En la práctica, podemos representar muchas cosas de un producto o servicio específico como historias de usuario, o todas. Pero hay algunas cosas que definitivamente no son historias de usuario y estamos cayendo en el infame síndrome de que "cuando somos martillo, todo lo vemos como un clavo". Es decir, queremos maltratar cualquier cosa que necesitamos hasta hacerlas parecer como una historia de usuario.

En esta presentación breve y conversatorio, hablaremos precisamente de esto y más alrededor de las historias de usuario. Y, de manera colaborativa con la audiencia, trataremos de encontrar una respuesta a la pregunta "¿de qué hablamos cuando hablamos de Historias de Usuario?"

Puedes ver y descargar la presentación que hicimos en #Agiles2020 aquí:

Actualización 20210405: Puedes ver y descargar la presentación, 2da edición, revisada, no corregida y aumentada, aquí:



domingo, agosto 23, 2020

El extraño caso de las historias de usuario técnicas

 

Photo by fauxels from Pexels

Nota: la versión en inglés de este artículo en:

https://luchosalazar.com/2020/08/25/the-strange-case-of-technical-user-stories/

Advertencia

La atención continua a la excelencia técnica y al buen diseño mejora la agilidad”.

[Manifiesto por el desarrollo ágil de software]

Cuando Kent Beck llegó con la idea de las historias de usuario como parte del juego de planificación de eXtreme Programming (XP Planning Game), no imaginó el impacto que esa idea tendría en el desarrollo de software y, por extrapolación, en el desarrollo de productos, varios años después; fue como un “efecto mariposa”. De hecho, al principio solo las describió como algo con lo que los clientes definen el alcance del proyecto "con historias de usuarios, que son como casos de uso". Pueden encontrar más sobre esto en “La historia de las historias de usuario”.

Pero una de las prácticas que ha perdurado hasta nuestros días es esta de querer expresar todo como una historia de usuario. En la práctica, esto es posible. Ya que las historias de usuario se pueden representar de infinitas formas. En el libro Historias de usuario: una visión pragmática, que escribimos con Jorge Abad, quien también  me compartió algunas de sus ideas para este artículo, hablamos precisamente de algunos de los modos de representación de las historias de usuario, incluyendo el User Stories Conversation Canvas, un lienzo para mantener y registrar conversaciones sobre estos elementos del backlog de producto.

Sin embargo, hay algunas cosas que definitivamente no son historias de usuario. El “apellido”, ese “de usuario” está allí por una razón muy importante que ni siquiera el mismo Kent Beck imaginó al comienzo. Él hablaba de “stories”, simplemente historias: estas se ven, se perciben, se entienden, se describen desde el punto de vista de quien las va a usar una vez estén implementadas o de quienes las van a consumir una vez hagan parte de los productos o servicios que se desarrollen usando esta técnica.

Las cosas así, cuando se trata de software, las llamadas historias técnicas no son una buena idea. ¿Quién es el usuario de “quiero integrar la IA de Google para hacer la traducción del texto”? ¿O de “quiero optimizar la base de datos para acelerar las consultas”? Pero sí es posible saber quién es el usuario de “quiero traducir un texto para entenderlo mejor” y de “quiero consultar la información del cliente” con la condición de que el resultado de la consulta se presente en menos de dos segundos.

Es un hecho, representar algo en forma de historia de usuario cuando no se trata de usuarios-personas del sistema es un error. Hay mejores formas de documentar o registrar este otro tipo de actividades “internas” de un sistema. Una de ellas es precisamente poniéndolas en su lugar como tareas que el equipo debe realizar para lograr finalmente algo de valor para el usuario-persona a través de una o varias historias de usuario. Pensemos en historias de usuario como “historias de persona”. Quizás esto nos ayude a entender la diferencia.

Una de las formas de saber si algo es una “historia de usuario-persona” o no, es cuando al mantener conversaciones con los representantes del negocio, por ejemplo un Dueño de Producto, estas conversaciones fluyen naturalmente y la fuente de información casi siempre es ese representante del negocio. Pero si este empieza a preguntar por términos o expresiones técnicas que emergen en el diálogo y el equipo de desarrollo tiene que dar explicaciones intrincadas que no son del dominio de aquel, entonces quizás hemos traspasado el plano del valor o beneficio de la historia para los usuarios a uno del dominio del equipo técnico.

Photo by fauxels from Pexels

Tenemos que hacer un left outer join seguido de una eliminación de duplicados” es algo con lo que perdemos a los usuarios. “Diariamente hacemos refactoring del código y luego lo integramos con el del resto del equipo usando Bamboo o Jenkins”, mientras “automatizamos los escenarios de prueba usando behaviour-driven development” y “consumimos el web service de [INSERTA AQUÍ TU PROVEEDOR DE WS FAVORITO] para conocer el valor del dólar minuto a minuto”, son conversaciones clásicas que dejarán en ascuas a un Dueño de Producto o a cualquier otra persona de las áreas del negocio.

Y no, no es porque usamos los términos en inglés. Aun en español van a sonar muy extraños a los usuarios. Más, cuando muchas de esas expresiones no tienen un equivalente apropiado en nuestro idioma o, en la vida cotidiana, significan algo totalmente distinto para el común de las personas:

¿Una “combinación externa por la izquierda”? – ¿A qué estará jugando?

¿“Desarrollo conducido por comportamiento”? – ¿Estará hablando de que su comportamiento en la empresa lo tiene a prueba?

¿Y mi consulta de los datos del cliente?”, preguntan con los ojos bien abiertos y con esa expresión de desánimo que solo significa que no están recibiendo lo que quieren y que incluso los lleva a pensar que los miembros del equipo no han entendido del todo lo que los usuarios necesitan. Por lo general, es una combinación de ambos. El asunto se pone más grave si alguien del equipo intenta explicar con mayor detalle lo que significa todo ese galimatías* técnico o trata de justificar con ello los tiempos estimados de desarrollo. A estas alturas es a todas luces evidente que se requiere la presencia de un facilitador, coach, Scrum Master o similar, para abortar la conversación y llevarla por otro camino.

Finalmente, no entendamos las historias de usuario-persona o las historias de persona como aquellas que solo abordan el “front-end” o la experiencia del usuario, de la persona. No. Toda historia de usuario tiene componentes “verticales” que van desde la forma cómo se comunica una persona con el sistema, hasta cómo se almacena y se procesan los datos que intercambia esa persona con el sistema o el entorno: base de datos, servicios, lógica del negocio, presentación, etcétera.

Más sobre cómo conducir conversaciones con historias de usuario en nuestra serie de historias de usuario altamente efectivas:

http://www.gazafatonarioit.com/p/la-serie-historias-de-usuario-efectivas.html

Y todavía mucho más en el libro Historias de usuario: una visión pragmática.

Llamado a la acción

Separemos explícitamente las historias de usuario, las de valor para el negocio, usuarios o clientes, de las tareas del equipo y de los componentes “internos” del sistema (producto) con los que se logra obtener ese valor o beneficio. Como agentes de cambio, asegurémonos de que los miembros del equipo desarrollen habilidades y destrezas en el dominio del negocio, ayudándolos a ellos y a los Dueños de Producto e interesados a mejorar las interacciones entre unos y otros mediante la conversación continua, ojalá cara a cara (¡en 2020 encendamos la cámara!) y a que no todo tiene que ser una historia de usuario, al menos no representadas de la misma manera.

Conclusión

Si en la conversación sobre una historia de usuario es el Dueño de Producto quien termina interrogando al equipo para aclaraciones y no al contrario, quizás el diálogo no sea realmente sobre la historia de usuario.

Epílogo

*Usé intencionalmente la expresión “galimatías”, quizás poco conocida, pero que tiene un lugar en mi Gazafatonario, para dejar la sensación en el ambiente de lo que percibe o siente un usuario final cuando lo confundimos con tecnicismos propios del desarrollo de software.

galimatías

Del fr. galimatias 'discurso o escrito embrollado', y este del gr. κατὰ Ματθαῖον katà Matthaîon 'según Mateo', por la manera en que este evangelista describe la genealogía que figura al comienzo de su evangelio.

1. m. coloq. Lenguaje oscuro por la impropiedad de la frase o por la confusión de las ideas.

2. m. coloq. Confusión, desorden, lío.

Real Academia Española © Todos los derechos reservados

viernes, marzo 13, 2020

Sobre el Incremento de Producto y el Refinamiento

Imagen de mohamed Hassan en Pixabay
Llegan algunas preguntas de colegas a mi buzón:

En el review:

¿A quién se le hace la entrega el incremento?

¿Este incremento debe ponerse en producción antes o después del review? (Si es antes, ¿qué pasa si el PO no lo avala o si es después, sería una tarea del siguiente Sprint?)

En el refinamiento:

¿En qué momento se contextualiza al equipo de trabajo sobre una funcionalidad o cambio sobre las funcionalidades pactadas? Es que entiendo que el refinamiento puede ser en cualquier momento entre todo el equipo.

¿Debería existir un día en el Sprint para refinar? ¿Eso no distrae al equipo de desarrollo?

Veamos algunas ideas al respecto:

Sobre la entrega del incremento

En la Revisión del Sprint se presenta el incremento del producto funcionando. El responsable de entregar este  incremento de Valor es el Equipo Scrum en pleno. ¿A quiénes se hace la entrega? A un grupo de interesados en el producto: patrocinadores, usuarios finales o consumidores, jefes, alta gerencia, personas de mercadeo y ventas, publicidad, operaciones u otras áreas que tengan que ver con el producto, entre otros. Tampoco se trata de una reunión “amplia” con mucha gente, se trata de algunos “interesados clave” invitados por el Dueño de Producto.

Esta es una reunión informal, no de seguimiento. El Dueño de Producto ya debe tener conocimiento previo de lo que se va a entregar, de su estado (solo se entrega producto terminado), de la calidad, etcétera. Después de todo, se supone que el Dueño de Producto está trabajando con el equipo de Producto de manera cotidiana. 

Dos aspectos clave de la reunión son que:

  • El Dueño de Producto explica qué elementos del backlog de Producto se han “Terminado” y cuales no se han “Terminado”; y
  • El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca del Incremento;

Pero la reunión va más allá. Es en este momento cuando siempre sugiero volver a leer la guía de Scrum.

Además de lo que dice la guía de Scrum, Jorge ha publicado, entre otros, los siguientes artículos sobre el tema de la revisión del sprint:

[Agenda Scrum] Pasos para Realizar el Review o Revisión

Sobre el incremento

Imagen de Gerd Altmann en Pixabay
El incremento debe estar probado y funcionando, es decir, debe ser potencialmente distribuible, que se pueda poner en producción. Este incremento cumple la Definición de “Terminado” del Equipo Scrum. Debe representar en buena medida la meta del sprint. En la práctica, no concibo un Incremento de Valor que no aporte en un altísimo porcentaje hacia el cumplimiento del objetivo del Sprint.

Normalmente el incremento se pone en producción después de la Revisión. Es posible que sea antes pero es algo difícil en los entornos actuales. Este asunto de la puesta en producción tiene su propia complejidad porque, si no estamos en un entorno con cultura DevOps, donde haya automatización y herramientas, el incremento quizás se tenga que entregar a un equipo externo y este, a su vez, deberá pasar por uno o más comités de "Paso a Producción", entre otras restricciones y, las cosas así, el paso final puede tardar desde algunas horas, hasta algunos días o semanas. En cualquier caso, es el Dueño de Producto quien autoriza el paso, al menos por el lado del producto. Ya los demás comités y áreas harán lo suyo.

Importante: el objetivo del Equipo Scrum es entregar un incremento de producto en cada Sprint. Que tenga valor para el negocio, los usuarios o consumidores. Es decir, que genere retorno de la inversión, que haga ganar más dinero, que minimice costos, que mejore procesos, que evite más costo de la demora innecesario, entre otros aspectos. Si tu equipo no lo está logrando, es tiempo de una retrospectiva cuyo foco sea precisamente este de la no entrega de valor.

Sobre el refinamiento

Imagen de Gerd Altmann en Pixabay 
La contextualización sobre una funcionalidad o cambio en las funcionalidades pactadas se hace, precisamente, durante el refinamiento. Es el mejor momento.

El refinamiento es una tarea diaria del Dueño de Producto, con su equipo de producto, con los usuarios, con los interesados, con los consumidores finales, etcétera. Y, de tanto en tanto, durante el Sprint, se reúne con el equipo para contarles sobre las funcionalidades que vienen en los dos siguientes Sprints. 

Scrum nos sugiere que podemos usar hasta un 10% del tiempo del sprint para el refinamiento. Pero el equipo debe o debería estar completo con el Dueño de Producto a bordo. Para que todos vayan con el mismo conocimiento a las siguientes planificaciones y refinamientos. 

Sobre cuándo hacer el refinamiento

Se puede seleccionar un día del sprint o dos, dependiendo de la duración del mismo. Por ejemplo, sesiones de 2 horas o de 4 horas máximo vienen bien. Se recomienda que sean a mediados del sprint, nunca al principio y mucho menos al final. De hecho, el equipo puede tomar este tiempo como un "respiro" de sus tareas más complejas de desarrollo, así que puede ser beneficioso. Lo que no puede suceder es que se hagan tres o más reuniones de refinamiento en el sprint, que sean breves, eso no. Aunque es cuestión de experimentar, no creo que este último sea el camino, eso sí puede distraer al equipo, puede hacer que pierdan el foco continuamente, en fin, veo algunas desventajas en hacerlo así. Una o dos sesiones máximo.

Más sobre refinamiento en:

Purga ágil de producto
http://www.gazafatonarioit.com/2016/06/purga-agil-de-producto.html

Sobre el Backlog de Producto, el Refinamiento del Producto y el Rol del Dueño de Producto
http://www.gazafatonarioit.com/2017/06/sobre-el-backlog-de-producto-el.html

En este mismo Gazafatonario.

martes, octubre 29, 2019

La deuda de producto: cómo se manifiesta y qué hacer al respecto

The Uncomfortable Entrance - Illustration by Katerina Kamprani

Este tipo de deuda se presenta cuando el producto no constituye algo significativo para tu identidad como consumidor o usuario, para tu desarrollo personal o tu bienestar. Aquí estamos hablando de la experiencia de usuario. Es decir, si el producto no genera en sus consumidores emociones y actitudes positivas que sean capaces de impactar su estatus actual. O si esos usuarios no perciben aspectos del producto como su utilidad, la facilidad de uso y la eficiencia, entonces estamos ante una deuda en rojo.

Le faltan esos atributos tangibles e intangibles que brindan al consumidor los beneficios esperados por este y que le resuelven una necesidad específica. Con tangibles me refiero a lo que hace el producto, a la tecnología, al diseño, a la forma. Con intangibles, a los elementos emocionales que generan apego en el usuario, a su identidad de marca, a su ecosistema, a si impacta positivamente la vida de quienes lo consumen y si ese impacto es sostenible. Otra vez, estas dos clases de características es lo que hace posible una extraordinaria experiencia de consumidor, de cliente.

La deuda de producto también es interna, algo que muchas veces ni siquiera el usuario es capaz de percibir. Me refiero a la cultura de Agilidad en medio de la cual fue creado o elaborado el producto, al empoderamiento del equipo, a la felicidad de sus miembros, al foco en el cliente que pusieron todas las personas encargadas de su ideación, descubrimiento, prototipado, desarrollo y puesta en producción de ese producto.

La deuda de producto crece cuando el equipo no aprendió ni mejoró un ápice durante su desarrollo. Además, si el equipo y otros interesados no conocen al cliente, cuáles son sus necesidades o porqué deberían adquirir o usar el producto, la deuda de ese producto también se incrementa.

Si no hubo confianza en el equipo, no se le delegaron las principales responsabilidades para elaborar el producto ni se les habilitó un entorno seguro, donde el empoderamiento y la experimentación estuvieran a la orden del día, hay más deuda de producto.

Si todas las buenas ideas del producto terminan con su despliegue al mercado, todavía habrá un gran camino que recorrer, una deuda aumentada que pagar. El despliegue del producto no es el objetivo. La meta es el cliente, su satisfacción, su felicidad, mejorar su modus vivendi. Si nos quedamos en la puesta en marcha del producto, apenas si nos habremos concentrado en la salida del producto, un número de características de las cuales no sabemos cuáles serán usadas y cuáles no. Consecuencia: más deuda de producto. En cambio, si nuestro foco es el cliente y sus necesidades y la experiencia que tenga usando el producto, entonces estaremos concentrándonos en el valor, en el resultado positivo que puede entregar ese producto a la humanidad.

Otras causas de la deuda de producto:
  • Siempre aplicamos las mismas prácticas en todas partes
  • Siempre exigimos adherencia a actividades y procesos, ágiles o no
  • Definimos la cadena de herramientas permitida
  • Forzamos la estandarización en todas partes
  • Creemos que el proceso habla por sí mismo
  • Confiamos en el proceso más que en las personas y el equipo
Las cosas así, podríamos definir la deuda de producto como:

Deuda de Producto = Falta de Experiencia de Usuario + Falta de Tangibles (Tecnología, Diseño, Forma) + Falta de Intangibles (Emociones, Identidad de Marca) + Falta de Agilidad + Falta de Foco en el Cliente + Falta de Confianza en el Equipo + Falta de Delegación + Otros*

* Incluye aquí los que aplican para tu entorno específico

Para no incurrir en más deuda de producto

El Dueño de Producto debe:
  • Definir y liderar la visión del producto.
  • Investigar y probar las necesidades del cliente / mercado
  • Identificar opciones de productos de alto valor.
  • Hacer que los elementos del backlog estén "preparados" para su planificación y desarrollo
  • Aceptar solo trabajo "terminado"
  • Realizar demostraciones de producto
  • Fomentar la consistencia donde esta sea importante, en todos los niveles de la organización
  • Explicar siempre el valor detrás de un proceso
  • Observar, aprender de y analizar el mercado.
  • Compartir ideas en la organización con respecto al producto y aceptar retroalimentación oportuna
  • Decidir las fechas de lanzamiento y el contenido.
  • Salir al mercado (a producción) tan rápido como sea posible e ir afinando el producto a medida que recibe información de su uso
  • No lanzar en la fecha, lanzar en calidad (a lo Spotify).
  • Asegurarse de que el producto vaya de excelente en su salida inicial a extraordinario después del lanzamiento, afinándolo continuamente.
  • Saber cuándo descontinuar o sacar el producto del mercado
El equipo de desarrollo de producto debe:
  • Ser pragmático en la elección de las herramientas
  • No obsesionarse con las ceremonias o eventos de un proceso o marco de trabajo, por muy ágil que este parezca. Atención a eso Scrum Másters, coaches ágiles, habilitadores ágiles, consultores Lean y estrategas Kanban, entre otros.
  • Demostrar voluntad de evolucionar en función de la retroalimentación que proporcione el entorno
Toda la organización debe:
  • Concentrarse en el Valor.
¡Esperen! Sobre Valor del producto hablaré en una próxima oportunidad. Hasta entonces, déjame saber en el foro tus experiencias e impresiones sobre este asunto crítico de la deuda de producto.

Créditos de la imagen de portada:
The Uncomfortable Entrance
Illustrations by Katerina Kamprani
https://www.theuncomfortable.com/portfolio/the-uncomfortable-entrance/