Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta Conversación. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Conversación. Mostrar todas las entradas

lunes, agosto 22, 2022

Ámbito o contexto de las historias de usuario

Haz clic en la imagen para ampliar y descargar en alta definición

Sigo viendo muchas historias de usuario que más bien parecen historias de ficción y hasta de ciencia ficción: el “usuario” de “historia de usuario” no aparece por ninguna parte.

Ahora vengo con esta imagen, a ver si ayuda. ¿Cómo la ven? ¿Qué les dice? Por favor, déjenmelo saber en el foro.

Para saber más sobre el Contexto de las historias de usuario, o de la cuarta C de las historias de usuario, visita:

http://www.gazafatonarioit.com/2019/06/las-historias-de-usuario-se-cuentan-con.html

También, el User Story Conversation Canvas:

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


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, haz clic en el siguiente enlace o ve a la parte superior de la imagen que sigue y toca en "start from template" o en el icono de Mural.

https://app.mural.co/template/a233e5bd-6759-4c89-98bc-de1add6230b6/48d04f21-51a0-4175-bcd7-4ced17c633b8


lunes, enero 17, 2022

Cómo ayudar a tu equipo a mejorar su Daily Scrum

Imagen tomada de Pixabay
La guía de Scrum es cada vez menos prescriptiva para ser más inclusiva, es decir, para que la usen más tipos de personas, de equipos y de organizaciones. Hoy por hoy, Scrum se usa en casi cualquier rincón de la empresa y de la sociedad, entonces es aconsejable que se aleje de lo que la hacía más allegada al mundo del desarrollo de software. Con esto en mente, es importante dejar claro que si un lineamiento o una sugerencia ya no está en la guía no significa que era una mala práctica o algo equivocado. De ninguna manera.

Uno de los ejemplos más visibles de esta situación es el de las famosas y muchas veces poco entendidas “tres preguntas” de la Daily Scrum o reunión diaria. Las tres preguntas pasaron de ser una regla del juego Scrum en versiones previas de la guía, a ser “un ejemplo de lo que podría usarse” (durante la reunión) en la edición de 2017, a desaparecer por completo en la última edición de 2020.

Sin embargo, ello no quiere decir que no puedan seguirse usando para “inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario”, de acuerdo con la guía 2020. En cualquier caso, la conversación o la discusión durante la sesión diaria puede ocurrir de muchas maneras siempre que esta “se centre en el progreso hacia el Objetivo del Sprint y produzca un plan viable para el siguiente día de trabajo”.

¿Qué tipo de conversaciones podemos tener para realizar una Daily Scrum efectiva? ¿Qué otras cuestiones podemos abordar durante la sesión para asegurar que conocemos con exactitud en dónde estamos respecto al objetivo del sprint? Empecemos por mejorar el matiz de las preguntas clásicas.

“¿Que hice ayer?” es la pregunta que se harían los miembros de un equipo con una perspectiva estática de lo que hacen o de lo que quieren hacer a continuación. De alguna manera, este tipo de preguntas son estacionarias, aunque las estaciones solo sean de 24 horas.

En cambio, una persona, un equipo o una organización con una perspectiva dinámica bien puede responder a la pregunta: ¿qué hice para garantizar que aprendimos algo nuevo ayer? Esto imprime una energía distinta y más vigorosa a la sesión, a las personas, al ambiente de trabajo, y permite que el equipo practique y promueva una cultura de mejoramiento continuo.

Más allá de esta pregunta, otras cuyas respuestas nos dan una idea más precisa de qué tanto hemos avanzado hacía el logro de la meta propuesta son:

  • ¿Qué hicimos ayer que mejoró nuestra eficiencia?
  • ¿Qué valor o principio de la empresa, del equipo o de alguna otra índole determinó en gran medida nuestro comportamiento de ayer para avanzar hacia el logro del objetivo del sprint?
  • ¿Qué decisiones tomamos ayer que nos permitieron avanzar hacia el logro del objetivo del sprint?
  • ¿Qué decisiones tomamos ayer que no nos permitieron avanzar hacia el logro del objetivo del sprint?
  • ¿Qué podemos aprender de esto para garantizar que mañana estaremos más cerca de lograr el objetivo del sprint? Las respuestas a esta última consulta derivan en un plan de actividades para el siguiente día hábil de trabajo.

Al hacer este tipo de preguntas todos los días, el equipo empieza gradualmente a desarrollar principios referentes a la forma cómo toma las decisiones, pero también comienza a ver un estándar en la forma cómo se acerca al objetivo del sprint, cada sprint. Las respuestas a estas preguntas guían en términos de cómo y qué elementos deberían ordenar para alcanzar el objetivo propuesto y entregar el valor planificado al negocio.

En medio de este análisis de si el equipo alcanzará el objetivo propuesto, es vital preguntarse por el impacto de las interrupciones causadas por eventos que provienen del entorno:

¿Hay algo en el entorno que está ocasionando distracciones al equipo o a algunos de sus miembros? ¿Es posible evitar esas distracciones?

Ahora bien, los objetivos no se pueden alcanzar a cualquier precio. En particular, no tiene sentido lograr una meta si en el camino dejamos una estela de desperdicio, de trabajo mal elaborado o de desgaste moral y físico de las personas. Aquí surge una pregunta clásica, pero cuyas respuestas pueden dar luz al equipo sobre el estado del avance hacia el logro del objetivo del sprint:

¿Estamos haciendo correctamente el producto correcto?

Finalmente, el objetivo del sprint se define durante la planificación de este, al principio del sprint. Sin embargo, a medida que pasan las horas y los días, el equipo Scrum aprende más sobre el alcance, sobre los elementos del product backlog que están implementando, por ejemplo, sobre las historias de usuario, sobre lo que viene a continuación en los dos siguientes sprints en sesiones de refinamiento y sobre la capacidad real de las personas, entre otras cosas.

Toda esta información puede conducir a hacer un cuestionamiento sobre si el objetivo del sprint es alcanzable o no, sobre si debiera replantearse, delimitarse o sobre si el sprint debiera cancelarse debido a que su objetivo empieza a sufrir de obsolescencia. Así que las respuestas a preguntas como “¿el objetivo del sprint sigue vigente?” dilucidan este aspecto. Otras como “¿lo que hemos aprendido hasta ahora mantienen la vigencia del objetivo del sprint?” también ayudan en este sentido.

Así que, en la práctica, tenemos una gran lista de temas para conversar en la Daily Scrum que nos ayudan a concentrarnos en el cómo vamos hacia el logro del objetivo del sprint. Cuáles preguntas abordar es algo que depende del escenario actual, de lo que esté sucediendo en el equipo y en el entorno. Un Scrum Master debe estar atento a las señales en el ambiente, pero lo mejor es que le proporcione pautas a las personas de equipo para que sean ellas quienes seleccionen la táctica o la estrategia adecuada en un día específico.

Una sola pregunta puede ser suficiente, pero a veces son necesarias dos o más. Sin embargo, si el avance hacia el logro del objetivo del sprint no está claro hacia el final de la Daily Scrum, una práctica que no deja dudas es la del voto de confianza. Esta consiste en que cada persona emite un voto, a manera de porcentaje, de 0 a 100, expresando que tanto confía en que el equipo Scrum alcance el objetivo este sprint. Si el promedio general es de menos del 90 % o de un porcentaje previamente acordado por el equipo, seguramente habrá que replantear o negociar qué se hará y que no se hará en lo que resta de la iteración.

¿Qué otras cuestiones o prácticas se te ocurren que pueden servir al equipo en una Daily Scrum? Por favor, déjamelo saber en el foro.

Más sobre la Daily Scrum

Daily Scrum Kaizen:

http://www.gazafatonarioit.com/2021/04/daily-scrum-kaizen.html

El Scrum Master y el Scrum Diario:

http://www.gazafatonarioit.com/2020/09/el-scrum-master-y-el-scrum-diario.html

Compendio sobre el Scrum Diario:

http://www.gazafatonarioit.com/2014/01/compendio-sobre-el-scrum-diario.html


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.


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!

 

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.

 

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

lunes, junio 08, 2020

El lenguaje y la transformación organizacional


Escucha el audio de este artículo aquí:

Muchas personas no creen que la terminología o el vocabulario usado importe. Pero el lenguaje se refleja directamente en los modelos mentales que hacemos de las cosas. Y los modelos son una representación de la realidad que nos rodea. Así que los modelos ayudan o soportan la construcción o elaboración de esas realidades a nuestro alrededor y de los escenarios en los que vivimos.

En los procesos de cambio o de transformación, es importante modificar no solo nuestros comportamientos sino también el vocabulario que usemos. Así la alta dirección y todos en la organización no se sentirán ansiosos pensando que nada está cambiando. Veamos un ejemplo:

De pensar en proyectos a pensar en productos

Imagen de Nattanan Kanchanaprat en Pixabay

No se trata solo de un cambio en la terminología, sino también en la forma cómo vemos e interpretamos el mundo. Se trata de la forma en que percibimos y pensamos sobre las cosas: los proyectos inician con buenas ideas, de esas que dan ganas de volver una realidad. Pero las formas de gestión tradicional de proyectos los han catapultado como “exitosos” si el plan inicial de alcance, tiempo y costo del proyecto estuvo cerca o muy cerca de los números al final del mismo: se trata del así llamado Triángulo de Hierro del management vetusto.

En principio, esto no tiene nada de malo. Son las prácticas de gestión que han predominado durante décadas en las organizaciones, aunque a muchas de estas les ha costado más de un dolor de cabeza. Pensemos en que el 88% de las compañías que el siglo pasado estaban en la lista de las 500 más grandes de Estados Unidos (Fortune 500), en 2017 habían desaparecido de la lista o de la faz de la tierra para siempre o simplemente se habían convertido en un pequeño departamento dentro de una corporación mucho más grande que las absorbió. Más sobre esto en:

http://www.aei.org/publication/fortune-500-firms-1955-v-2017-only-12-remain-thanks-to-the-creative-destruction-that-fuels-economic-prosperity/

O si no pregúntale a Nokia. Cien mil empleados, una infraestructura considerable y millones en activos y por la que Microsoft pagó incluso menos que por Skype, otra compañía muchísimo más pequeña, con apenas algunos cientos de empleados. ¿Cómo es posible que la empresa cuyas ventas de celulares se encuentran en la cima de todos los listados de ventas y que se cuentan por cientos de millones de unidades, se haya convertido en unos pocos escritorios dentro del gigante del software y luego desaparecido para siempre?

Bueno, si tú o tu empresa siguen pensando en términos de proyectos y menos en términos de productos y valor, tu destino puede cambiar rápidamente. Y más en los actuales escenarios de altísima incertidumbre y volatilidad e igualmente o más complejos y ambiguos que los de hace apenas algunos años. Es por ello que queremos reemplazar conceptos (vocabulario) como el “triángulo de hierro” de los proyectos por el triángulo ágil o por mi versión extendida que puedes encontrar en:

http://www.gazafatonarioit.com/2016/04/del-triangulo-de-hierro-al-triangulo.html

O por los conceptos mencionados de producto y de valor. El objetivo de toda organización, y el paradigma al cual se enfrentan hoy por hoy, es entregar productos o servicios de valor para sus consumidores. Productos que generen retorno de la inversión, disminuyan los costos, ganar más clientes, eliminen desperdicios en los procesos y, en fin, todo lo que signifique generar valor para la empresa.

Hoy es preferible pensar en términos del mínimo producto viable (MVP), incluso es mejor pensar en términos de experimentos y de sus conceptos subyacentes. Es lo que te permitirá cambiar la forma de hacer las cosas porque tus modelos mentales serán diferentes y, por ende, la realidad que te rodea, la realidad que construyes basado en esos modelos. Esta forma de pensar, ágil por demás, conduce a generar menos desperdicio, a mayor creatividad y a más entregas y de mejor calidad.

Sobre técnicas para encontrar el MVP y, en general, sobre la creación de productos, puedes consultar en:

http://www.gazafatonarioit.com/2016/08/inceptions-con-jorge-abad.html

Y sobre productos y su contexto, puedes leer en:

http://www.gazafatonarioit.com/2019/12/el-contexto-de-tu-producto-importa-aqui.html

De pensar en trabajo en equipo a trabajo colaborativo

Imagen de Gerd Altmann en Pixabay

Ya desde los mismos conceptos, el primero de ellos no da señales de que ese trabajo se haga efectivamente de manera colaborativa. Es posible tener un “equipo” de especialistas, como ha ocurrido históricamente, donde cada miembro elige o se le asignan tareas por hacer de acuerdo con sus habilidades específicas. Pero eso no tiene nada de colaborativo, no exige mucha comunicación entre uno y otro integrante del equipo y quizás requiera de poca o ninguna interacción entre unos y otros.

El verdadero trabajo colaborativo va más allá. Implica interacción constante, poner de manifiesto la inteligencia y las habilidades de cada persona para un bien mayor, el del equipo y el de la organización. Requiere de confianza entre las personas, de mucha comunicación, ojalá cara a cara, del establecimiento y práctica de valores como la apertura y el respeto, incluso el coraje. Requiere de mucha proactividad y de sentido de pertenencia y de familia. Bajo este paradigma no hay espacio para individualidades, el responsable de una tarea y de todas las tareas es el equipo en pleno, ningún miembro del mismo es dueño del resultado, solo el equipo.

Esta forma colaborativa de hacer las cosas hace posible la experimentación y la falla, requiere del liderazgo de todos los participantes en el equipo, rompe barreras, elimina silos, promueve recompensas a todo el grupo, no solo a unos pocos individuos, maximiza las habilidades de escucha y, en general, de comunicación, comportamientos que, a la postre, traerán como consecuencia un cambio en la cultura de la empresa, una transformación organizacional.

Estos cambios se van generando de manera natural, orgánicamente. Primero como un reflejo en nuestras mentes y en las mentes de los comprometidos con el cambio, más adelante, si lo sabemos promover, el cambio empieza a ocurrir en los demás interesados y, a partir de allí, en el resto de la organización. Finalmente esos cambios son el reflejo de nuestra forma de pensar, la que conseguimos encontrando nuevos conceptos y formas de ver e interpretar el mundo, un nuevo lenguaje que impacte positivamente nuestro modo de pensar.

Otros cambios necesarios en tu vocabulario

Estos apenas fueron un par de ejemplos sobre cómo el lenguaje impacta nuestro pensamiento y nuestra forma de actuar. Pero, en la práctica, quizás nos topemos con aspectos de la cultura organizacional, de la forma de trabajar de las personas y los equipos y de los paradigmas de gestión y de ejecución de tareas para los que no tengamos un vocabulario común o simplemente no hallemos una forma de verbalizarlo. Es allí donde es importante lo acentuado que tengamos una u otra forma de interpretación de los escenarios que enfrentemos y del contexto que tengamos de las cosas.

Con todo esto en mente, te invito a cambiar tu léxico:

·       De trabajo por habilidades o especialidades, aislado, a trabajo colaborativo, en red.

·       De una entrega final de producto a entregas tempranas y frecuentes de valor.

·       De analizar los resultados al final de un gran ciclo de trabajo (proyecto), a reflexionar sobre el estado de las cosas repetidamente: inspección y adaptación.

·       De tratar de mejorar todo y de una sola vez, a realizar mejoras graduales y pequeñas pero continuas.

·       De planificar una sola vez y ejecutar el plan, a realizar planes periódicos, quizás tanto como todos los días.

·       De pensar solo en tener éxito, a pensar en experimentar y fallar para aprender

·       De fomentar el trabajo de expertos en distintas áreas a promover el aprendizaje continuo de las personas para que adquieran habilidades T o Pi (especialistas generalistas)

·       De gastar tiempo estimando las actividades del equipo a ordenar los elementos del producto y empezar a crearlo de inmediato

·       De hacer multitarea a tener foco en una sola tarea a la vez, tanto individualmente como en equipo

Y de pensar que hay una palabra, una expresión verbal o escrita para todo, a tener presente que hay aspectos del universo que no somos capaces de modelar porque no hay forma de representarlos y allí es donde nuestras emociones y nuestro sentido común juegan un papel importante: es el fundamento o la esencia por el cual estamos aquí y la razón por la cual queremos cambiar para mejorar.

Al hacerlo, seguramente notarás un cambio en la realidad circundante. Por ahora, cuéntame en el foro qué otros cambios estás promoviendo en tu equipo y en tu organización.

Puedes ver y descargar la presentación aquí: