Buscar en Gazafatonario IT

Mostrando las entradas con la etiqueta historias de usuario. Mostrar todas las entradas
Mostrando las entradas con la etiqueta historias de usuario. 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


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.


domingo, julio 25, 2021

Qué hay de "usuario" en las historias de usuario



Estamos en la era de la hiperpersonalización de productos y servicios, cada usuario, cada consumidor quiere tener su propia experiencia de consumo, de uso, de aplicación y eso ocurre a cualquier nivel, en cualquier escenario.

Entonces nos toca proporcionar productos y servicios altamente direccionados, envolventes y únicos para nuestros usuarios. Y esto comienza con cada componente del producto haciendo resonancia con los demás, para que el producto en pleno pueda ser percibido como único por sus consumidores. Esta es la manera cómo construyes relaciones más fuertes con tus clientes y usuarios.

En mi primer curso de ingeniería de software en la universidad, hace ya varias décadas aprendí algo que todavía hoy sigue vigente, pero cuya práctica se extravió en pro del seguimiento rígido a los procesos y metodologías que vinieron después: “mira al usuario en acción”. Qué hace, cómo lo hace, con quién intercambia información, qué información intercambia, a quién beneficia, qué problemas resuelve, cuáles son sus principales vicisitudes, entre otras, son algunas de las cuestiones que debes indagar para conocerlo mejor.

El apellido “de usuario” no es gratuito en las historias de usuario. Para empezar, concentrarte primero en el usuario, antes de en cualquier otra cosa de su historia, te permitirá trabajar en una estrategia de producto hacia esa hiperpersonalización exigida por los consumidores actuales para que tengan su experiencia diferenciada.

Para lograrlo tienes que practicar y fomentar una cultura de “el cliente sentado en la mesa”, pero también de ir a verlo actuando en el gemba*, el suyo, para que puedas entender a fondo sus necesidades y los escenarios en los que se desenvuelve día tras día. Es de esta forma cómo podrás:

·       Conocer su problema, incluso el problema detrás del problema, la causa raíz;

·       Identificar sus canales de comunicación preferidos;

·       Emplear un lenguaje más apropiado a sus características;

·       Generar las hipótesis de cómo el producto puede favorecerlo en la resolución de problemas;

·       De qué forma se podría arruinar su experiencia como usuario o consumidor.

Entre muchos otros aspectos de su cotidianidad.

En mi User Story Conversation Canvas ya mencionaba que el primer paso en la construcción de productos grandiosos es identificar y entender a los consumidores y usuarios. Son actividades basadas en entrevistas, observación e investigación. Hay personas que son primarias al producto o a la historia de usuario en particular, otras son secundarias e incluso otras son suplementarias.

Figura 1: Un ejemplo de User Story Conversation Canvas para la historia de usuario “acceder primero a los libros de mi interés”. Clic en la figura para ampliar.

Entre las primeras encontramos a los usuarios finales de la historia de usuario o a los consumidores del producto. Encargados como un Product Owner o un Product Manager primero, y luego el equipo de trabajo, deben conocer muy bien el perfil de estas personas, los matices personales y profesionales que los identifican, la educación, datos demográficos, sus hábitos e incluso sus motivaciones y comportamientos, lo que les gusta y lo que no. Después de todo desarrollamos productos para seres humanos. Quienes estamos comprometidos en esta tarea debemos sentir que conocemos al usuario, tener empatía con el usuario.

Las personas “secundarias” son quienes tienen algo que decir acerca de la historia de usuario (o del producto o servicio) pero que no lo usan. Pueden ser quienes lo adquieren, quienes imponen una restricción o una regulación, quienes harán la instalación o el mantenimiento, quienes venderán o distribuirán el producto a los usuarios, entre otras. Y las personas “suplementarias” son todas aquellas que de una u otra forma están o se sienten involucradas con la historia de usuario, como patrocinadores del proyecto, la dirección de la organización, representantes de los usuarios y otros interesados.

En resumen, algunos tipos de personas para tener en cuenta en y para la conversación son:

1.     Personas

2.     Usuarios o Consumidores finales

3.     Interesados

4.     Patrocinadores

5.     Equipo de desarrollo

6.     Otros (Legales, externos, etcétera)

7.     Equipo de soporte, Mercadeo, Distribución, Logística, etcétera.

Cuando observamos, entendemos y acordamos entre todos cómo las personas usan o usarán el producto, estaremos en capacidad de:

·      Planificar la accesibilidad al producto desde el principio

·      Desarrollar más rápidamente soluciones de accesibilidad

·      Tomar decisiones informadas entre diferentes opciones y evitar perder el tiempo adivinando o suponiendo o lanzando hipótesis que solo serán eso, hipótesis, hasta tanto el producto no esté en manos de quienes lo van a consumir o a usar

·      Limitar el tener que volver atrás y solucionar problemas, es decir, elaborar el producto correcto desde el principio, no generar desperdicio. Esto es más de pensamiento Lean.

·      Evitar tener que hacer concesiones más tarde porque esperamos demasiado para para conocer mejor al usuario y para abordar las características relevantes del producto.

·      Tener una mejor perspectiva sobre los estándares de uso, las pautas y otros requisitos, que es posible que deba cumplir ahora o más adelante, por ejemplo, si el producto será de uso gubernamental o debe cumplir con ciertas regulaciones.

Todo esto beneficia al equipo de trabajo, incluyendo Product Owner si lo hay, a la media y alta dirección de las organizaciones y a cualquier otro interesado en el desarrollo y puesta en marcha del producto.

User Personas

No en vano, Personas es el primer componente del lienzo para conversar sobre la historia de usuario. Ya desde antes existía este otro instrumento en el que podemos registrar lo que observemos y aprendamos del usuario en acción: se trata del User Persona o simplemente Persona.

Figura 2: un ejemplo de User Persona para registrar el conocimiento que tenemos de un usuario de nuestras historias de usuario. Clic en la figura para ampliar.

En este, podemos registrar aspectos como los de la figura 2:

·      Objetivos del usuario, esto es, las metas que quiere alcanzar o que queremos que alcance en el mediano y largo plazo con el producto

·      Barreras o problemas actuales y posibles problemas futuros

·      Puntos de dolor o necesidades

·      Comportamientos o hábitos del usuario

Y no está demás conocer algunos detalles demográficos y hasta personales del usuario en cuestión, además de ciertos aspectos biográficos que ayuden a conocerlo y, sobre todo, a entenderlo mejor, a ser más empático con esa persona. Incluso, si es alguien conocido, un colaborador de la empresa, bien podemos traer su fotografía y usar sus datos reales, y hasta un lema o declaración de vida, su distintivo o consigna.

Figura 3: otro ejemplo de User Persona para registrar el conocimiento que tenemos de un usuario de nuestras historias de usuario. Clic en la figura para ampliar.

Otros aspectos que bien podrían servir son:

·      Su experiencia ideal

·      La tecnología que usa o las fuentes de información a las que accede habitualmente

·      Por qué quiere usar nuestro producto, de hecho, este aspecto es crucial, deberíamos empezar por allí.

·      Respuestas a la pregunta: ¿qué arruinaría su experiencia usando el producto?

Recomendación final

No me andaré por las ramas: nunca intentes, ni lo sueñes siquiera, empezar a implementar o a desarrollar una historia de usuario de un producto si no conoces quien la usará y por qué. Perentorio.

Conclusión

Involucrar y conocer a los usuarios en las primerísimas etapas del descubrimiento del producto y más tarde, durante el propio desarrollo de este, da como resultado mejores productos para los consumidores, un desarrollo más eficiente y otros beneficios para los interesados y, por supuesto, para los mismos usuarios o clientes.

Y tú, qué haces para conocer a tu usuario. Por favor, déjamelo saber en el foro.

 

Quieres saber más

* Gemba |現場|' es un término japonés que significa "en el sitio de acción" o en la “escena del crimen". En negocios, Gemba se refiere al lugar donde se crea "valor"; en fabricación Gemba es el piso de la fábrica y en ventas es el área de ventas o el lugar donde el proveedor de servicios interactúa directamente con el cliente.1

Más sobre el User Story Canvas en:

El libro Historias de usuario: una visión pragmática:

https://luchosalazar.com/portfolio/historias-de-usuario-una-vision-pragmatica/

O en:

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

Más sobre historias de usuario en:

bit.ly/lashistoriasdelucho

Y en octubre, una nueva edición del curso User Stories FoundationCertificatedonde 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!


Créditos

Imagen de la portada por Gerd Altmann en Pixabay.



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!

 

miércoles, abril 14, 2021

Nuevo curso: Historias de Usuario - 10 de octubre

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

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

Objetivos de Aprendizaje:

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

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

Público Objetivo:

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

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

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

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

Requisitos Previos:

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

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

Entrenamiento:

Tipo de Curso: Foundations

Código de la Certificación: USFC.

Examen de Certificación:

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

Información del próximo curso:

Duración: 9 horas

Modalidad: en línea (virtual)

Fechas y horarios:

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

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

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

Inversión:

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

U$245 precio regular.

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

QUIERO UN LUGAR EN EL CURSO

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

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

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

 

jueves, abril 01, 2021

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

Image by Alexandr Ivanov from Pixabay 

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

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

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

De dónde venimos

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

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

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

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

Para dónde vamos

Image by Merhan Saeed from Pixabay 

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

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

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

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

·       Historias de usuario más pequeñas.

·       Menos historias de usuario.

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

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

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

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

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

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

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

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

·       Trabajo en pares.

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

·       Pasantías.

·       Acompañamiento y mentoría.

·       Autoestudio.

·       Potenciación de habilidades.

·       Práctica. Kata. Kata. Kata.

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

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


---

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