¿Es diferente crear una historia de usuario en un proyecto de infraestructura en comparación con una aplicación orientada al usuario? La mayoría de las definiciones de una historia de usuario no se preocuparán por el usuario o el sistema específico. Sin embargo, los ejemplos comunes de historias de usuarios suelen estar centrados en los usuarios finales de un producto. Al trabajar en un proyecto reciente en el que estábamos migrando una infraestructura tecnológica local a la nube pública, me resultó difícil identificar al usuario final, y el producto era algo que ya existía. Aquí hay algunas lecciones que aprendí y que considero aplicables a la mayoría de los proyectos de migración, si no a los proyectos de infraestructura en general.
Comprender "terminado" mediante mapas de historias y hitos
¿Cómo se ve "terminado"? Para un objetivo final, tiene sentido migrar todo, pero eso deja un solo hito, que es difícil de reasignar, cambiar o estimar. Esto se convirtió en una meta fantástica y fácil de comunicar que ayudó a evitar la expansión del alcance (¿ayuda la Tarea X a migrar?). Pero necesitábamos algunos objetivos más pequeños para mantenernos encaminados y ver el valor antes.
Para dividir nuestra meta en hitos más pequeños y medibles, utilizamos los mapas de historias de manera muy efectiva. Tradicionalmente, un mapa de historias sigue una estructura de Objetivos > Actividades > Historias. Rápidamente descubrí que usar "Actividades" no se ajustaba a la forma en que trabajaban nuestro equipo de infraestructura y los expertos en plataformas. Estaban acostumbrados a implementar componentes de manera secuencial de una manera que no coincidía con la forma en que un usuario interactuaría con el sistema.
Por lo tanto, dimos un paso adicional para asegurarnos de capturar todo. El primer paso fue crear un mapa de historias de Objetivo > Componente > Historias / Puntos de enfoque. Nuestro resultado final se parecía mucho a esto:
Esto coincidió con la implementación actual del sistema. El paso 2 es cuando incorporamos los recorridos de usuario, identificando las partes mínimas viables (MVP) que se convirtieron en nuestros hitos, al tiempo que nos aseguramos de capturar cada componente en nuestra migración. Estos hitos se eligieron en función de los usuarios de nuestra plataforma: los equipos de desarrollo de la organizació
Al incorporar los recorridos después de capturar todo, pudimos utilizarlos como un método para priorizar la puesta en marcha rápida de las cosas. Esto también nos ayudó a identificar en qué áreas podríamos haber estado sobreingenierizando. ¿Lo que queremos hacer cumple con el objetivo? ¡Si no es así, podemos posponerlo para más adelante!
Exploraciones para comprender la complejidad técnica
Uno de los grandes desafíos que enfrentamos fue decidir cómo abordar la migración. Azure ofrece varias formas de lograr los resultados deseados, según sus requisitos. Dado nuestro acceso limitado a expertos, una infraestructura heredada complicada y poca experiencia con componentes específicos de Azure, no estábamos listos para comenzar directamente a completar historias.
Las exploraciones (spikes) se utilizan típicamente para crear el "programa más simple posible para explorar posibles soluciones". Modificamos esto un poco, utilizándolos para explorar y luego acordar una forma de migrar un componente. Esta fase de recopilación de información y prototipado centrada nos permitió reducir los riesgos en aspectos clave de la entrega.
Lo que fue realmente importante para nuestras exploraciones fue que contenían las siguientes tres cosas:
- Una pregunta que responder
Una vez que estuvieras seguro de tu respuesta, habrías terminado con la exploración.
- Un límite de tiempo
Si no hay solución para entonces, necesitamos recurrir a un foro más grande o a experiencia específica.
- Consideraciones funcionales o multifuncionales
Estos son los requisitos que la solución deberá cumplir. A veces habrá muy pocos, otras veces habrá muchos. Si hay muchos, considera dividir la exploración, ya que es posible que estés tratando de encontrar una solución mágica.
Las exploraciones también se vincularon de manera efectiva a través de Registros de Decisiones de Arquitectura Ligera (ADR, por sus siglas en inglés). La salida de cada exploración se capturó en un ADR, asegurándonos de que no solo se documentara nuestro aprendizaje, sino que también todo el equipo de desarrollo y las plataformas futuras pudieran utilizar esa información.
Criterios de aceptación: resultaron ser más similares de lo que esperaba
Fue difícil lograr que los criterios de aceptación funcionaran bien. Aquí hay algunas cosas que intentamos y que no funcionaron para nosotros:
- Bullet con especificaciones detalladas
Esta especificación cambiaba y confundía por completo a los evaluadores de calidad (QA)
- Bullet points sin especificaciones detalladas
Los evaluadores de calidad (QA) no sabían qué o dónde buscar para comenzar las pruebas
- Desarrollo enfocado en el usuario y estilo de desarrollo basado en comportamiento (BDD) (Dado, Cuando, Entonces)
Necesitaríamos migrar una gran parte del sistema antes de que esto fuera probable, lo que resultaría en historias que tardarían meses en entregarse.
- Un espacio más libre para que los desarrolladores agreguen criterios de aceptación al inicio o durante el desarrollo
Esto se convertiría en una lista de los pasos que los evaluadores de calidad (QA) deberían seguir para probar algo, lo que no cumplía con el propósito de nuestros evaluadores de calidad (QA)
- ¡Ninguno!
...Seguro que puedes imaginar cómo terminó esto.
Lo que funcionó fueron los criterios de aceptación liderados por los desarrolladores utilizando el enfoque BDD.
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.
