Un año atrás mi amiga Rox (¡que viva México!) me hizo una consulta por mail que acordamos compartir. Me demoré un poco, pero aquí va.
Primero copio su consulta:
Mañana tengo una sesión de kata de arquitectura con un equipo. El objetivo principal no es la arquitectura en sí, sino un problema que tienen en partir en historias de usuario porque la mayoría de sus requerimientos son no-funcionales y dicen que no se puede.
Así que pensé en hacer un experimento: mezclar la kata de arquitectura con una kata de User Story Splitting.
Así que estoy en el sitio, pero veo que faltan los requerimientos no-funcionales que se agregan y recuerdo que tenías unas cartas.
¿Son los "normales" (escalabilidad, performance, mantenibilidad, etc)? o ¿cuáles son?
Y ahora mi respuesta (ampliada con algún material extra que no incluí en el mensaje original, que pongo entre [corchetes]):
¡Hola, Rox!
Te paso el material:
- Las Katas de Arquitectura en español [y aquí el sitio original en inglés]
- Y mi Tarot de Arquitectura
- [agrego también la guía ágil de patrones de slicing - que a su vez tiene el link a las tarjetas con los patrones]
Pero... me suena raro que quieran hacer historias de usuario sobre requisitos no funcionales, que es algo que no recomiendo, salvo que esté originado en un problema de negocio concreto (por ejemplo, la App se pone demasiado lenta cuando hay más de N usuarios).
Las cartas de Tarot están pensadas para discutir esos temas con la gente de negocio *en el contexto* de una historia funcional.
Trataría de que para los atributos que quieren mejorar definan y anoten explícitamente:
Contexto
¿Por qué es importante este tema? Entender la operación detrás de este tema en un proceso concreto. No pensar que la aplicación tiene que escalar a tantos usuarios, sino lo como 'la transacción de pago de una orden' debe poder soportar tantas sesiones concurrentes.
Métrica
¿Cómo vamos a medir que estamos en el nivel que queremos? Siguiendo el ejemplo anterior, puede ser cuánto tiempo demora para 1, 5, 10 o 30 transacciones concurrentes, y ponerle tiempos JUNTO con la gente de negocio.
Esto luego, idealmente se escribe en pruebas automatizadas que corren al menos en el build nocturno.
Decisión
¿Cómo hacemos para lograr esa métrica?
Acá es donde nos concentramos en 'lo técnico'. ¿Hacemos un componente que escale en threads? ¿Usamos una queue? ¿Cuál? Esto se va a convertir en una o más tareas, de una o más historias.
No hay comentarios:
Publicar un comentario