Be Wise Apps
Read in English · Lire en français · Auf Deutsch lesen
Sección 2.8 de 2.8 · Intermedio · 22 min de lectura
Elicitación, priorización y compromisos entre atributos de calidad
Videolección
5 min · narrado en inglés, con subtítulosSolo escuchar (audio)
Leer la transcripción
En esta última lección del capítulo aprenderás a encontrar las cualidades que importan, a clasificarlas y a decidir a qué renunciar.
Al planificar unas vacaciones en familia, cada uno quiere algo distinto. Uno las quiere baratas, otro quiere piscina, otro quiere trayectos cortos. No se puede tener todo. Así que toca sentarse juntos, anotar lo que cada persona necesita de verdad, votar lo que más importa y acordar a qué se renuncia. Los arquitectos hacen lo mismo con las cualidades de un sistema.
Los requisitos de calidad rara vez llegan en un backlog. La gente los da por supuestos, así que tienes que sacarlos a la luz. Empieza por las partes interesadas: a los clientes les importa la velocidad; a operaciones, la recuperación; a finanzas, el costo de operación. Los objetivos de negocio implican cualidades. Expandirse a tres países nuevos implica localización, residencia de datos y escalabilidad. La normativa crea restricciones que no se pueden negociar. Cada caída o brecha del pasado revela una cualidad que estaba poco especificada. Y si los rivales cargan en un segundo, dos segundos son un problema de calidad. Por último, mide el sistema existente. Su carga y su latencia reales dan una línea base que convierte "más rápido" en un número.
Las cualidades salen a la luz mejor cuando las partes interesadas se escuchan unas a otras. Esa es la idea que hay detrás del Quality Attribute Workshop, del Software Engineering Institute. Suele durar un día, con entre cinco y treinta personas, y se celebra antes de que la arquitectura quede fijada. Los cuatro primeros pasos establecen el contexto: las presentaciones, los objetivos de negocio, los planes de arquitectura actuales y los principales impulsores oídos hasta ese momento. Después viene el trabajo con escenarios. Todos proponen escenarios por turnos, y los casi duplicados se fusionan, pero solo cuando quienes los propusieron están de acuerdo. A continuación viene la votación. Cada persona recibe un número de votos igual a alrededor del treinta por ciento del número de escenarios. Los votos escasos revelan las prioridades reales. Por último, los cuatro o cinco escenarios principales se escriben completos, con sus seis partes.
Para organizar los resultados, los arquitectos usan un árbol de utilidad. La raíz es la utilidad: la bondad global del sistema. Se ramifica en atributos de calidad y después en inquietudes concretas, como la latencia de los pedidos o la disponibilidad del pago. Las hojas son escenarios concretos, cada uno valorado por su importancia para el negocio y su dificultad técnica: alta, media o baja. Los escenarios valorados con alta y alta son los que más importan y los más difíciles. Aquí, uno es hacer un pedido al ritmo pico. El otro es sobrevivir a una caída del proveedor de pagos. Estos dos reciben antes que ningún otro la atención del diseño. Este escenario de modificabilidad tiene importancia media y dificultad baja, así que basta con un buen diseño corriente.
Veámoslo en la práctica. Un taller de dos horas para una plataforma de reparto de comida produjo veintiséis escenarios. Con doce participantes, cada uno recibió ocho votos: el treinta por ciento de veintiséis es siete punto ocho, redondeado hacia arriba. Un escenario destacado: en el pico del viernes, con tres mil pedidos por minuto, el noventa y cinco por ciento de las confirmaciones se devuelve en menos de un segundo y medio, y el noventa y nueve por ciento en menos de tres. Una comprobación rápida de capacidad. Tres mil por minuto son cincuenta por segundo. El negocio planea duplicar el volumen, así que cien por segundo. Con la ley de Little, aunque cada pedido tardara el segundo y medio completo, como mucho habría unos ciento cincuenta en curso a la vez. El segundo escenario alta y alta: cuando el proveedor de pagos agota el tiempo de espera, los pedidos quedan en cola, no se pierde ninguno y se informa a los clientes en menos de diez segundos. Añadir un nuevo proveedor de sistemas de punto de venta para restaurantes tiene importancia media y dificultad baja. Así que el equipo hace primero un prototipo y una prueba de carga del recorrido de los pedidos y del diseño de pagos en cola.
Las cualidades entran a menudo en conflicto, porque una táctica que ayuda a una perjudica a otra. El cifrado y las comprobaciones añaden trabajo a cada solicitud. Durante un fallo de red, un sistema replicado debe elegir entre responder con datos quizá desactualizados y negarse. La posición de un repartidor puede estar algo desactualizada. Un pago no. Las capas y las interfaces facilitan el cambio, pero añaden saltos. La redundancia y las regiones adicionales cuestan dinero, así que compra nueves solo donde una caída cuesta más que evitarla. Y la autenticación robusta añade fricción. La respuesta correcta siempre depende del contexto: a qué objetivo de negocio sirve cada lado y cuánto cuesta cada opción.
Un compromiso que no se deja por escrito se volverá a discutir. Registra los significativos en registros de decisiones de arquitectura, incluido aquello a lo que has renunciado conscientemente. Haz que cada objetivo sea medible. Para la latencia de los pedidos: la escala son los segundos en el percentil noventa y cinco, y el medidor es la monitorización de usuarios reales en el pico del viernes. Fallo por encima de tres segundos, objetivo de un segundo y medio, ampliado de uno. Después, compruébalo automáticamente. Una función de aptitud es una comprobación automática, como una prueba de carga que hace fallar la compilación si la latencia se desvía. Ahí termina este capítulo: un deseo vago se convierte en un escenario, recibe una prioridad y se convierte en una comprobación.
La sección completa incluye todos los pasos del taller, el ejemplo completo del árbol de utilidad, una tabla de conflictos y una lista de comprobación para organizar tu propio taller. Con esto termina el Capítulo 2. Cuando estés listo, haz la prueba opcional del capítulo para comprobar lo que has entendido. Buen trabajo.
Lo que necesitas saber
- Los requisitos de calidad deben elicitarse a partir de las partes interesadas, los objetivos de negocio, la normativa, los incidentes pasados, la competencia y las mediciones del sistema existente, porque rara vez se formulan sin que nadie los pida.
- El Quality Attribute Workshop del SEI tiene ocho pasos; sus resultados son los impulsores arquitectónicos y unos escenarios refinados y priorizados, clasificados mediante una votación con un presupuesto fijo de votos.
- Un árbol de utilidad refina la utilidad en atributos de calidad, refinamientos y escenarios concretos, cada uno valorado (importancia para el negocio, dificultad técnica); los escenarios (H,H) reciben antes que ningún otro la atención del diseño.
- Las cualidades entran en conflicto (rendimiento y seguridad, disponibilidad y consistencia, modificabilidad y rendimiento, costo y casi todo lo demás, usabilidad y seguridad), y la resolución adecuada depende del contexto y del valor para el negocio.
- Registra los compromisos significativos en registros de decisiones y haz que cada objetivo sea medible con una escala, un medidor y unos niveles; después, haz su seguimiento a lo largo del tiempo.
- Las funciones de aptitud convierten las medidas de la respuesta de los escenarios en comprobaciones automáticas que se ejecutan a medida que el sistema evoluciona.
De dónde salen los requisitos de calidad
Los requisitos funcionales suelen llegar en un backlog. Los requisitos de calidad rara vez lo hacen: las partes interesadas los dan por supuestos ("por supuesto que tiene que ser rápido y seguro") o no saben que tienen que formularlos. Por eso los arquitectos tienen que elicitarlos activamente, a partir de varias fuentes.
Partes interesadas. Cada grupo tiene inquietudes distintas: a los clientes les importan la velocidad y la facilidad de uso; a operaciones, la monitorización y la recuperación; a finanzas, el costo de operación; a soporte, el diagnóstico de problemas; a cumplimiento normativo, las pistas de auditoría. El mapa de partes interesadas del Capítulo 1 es el punto de partida. Objetivos de negocio. "Expandirnos a tres países nuevos el año que viene" implica localización, residencia de datos y escalabilidad; "reducir un 20% los costos de atención al cliente" implica usabilidad y autoservicio. Normativa y contratos. La protección de datos, la legislación de accesibilidad, las normas sectoriales y los SLA con los clientes crean restricciones innegociables. Incidentes. Cada caída, brecha o día lento del pasado revela una cualidad que estaba poco especificada; las revisiones posteriores a los incidentes son una fuente muy rica. La competencia y el mercado. Si los rivales cargan en un segundo, dos segundos son un problema de calidad. El sistema existente. Su comportamiento medido hoy (la carga real, los percentiles de latencia reales, el tiempo de entrega de cambios real) da una línea base que convierte "más rápido" en un número.
Las entrevistas y los cuestionarios funcionan, pero los atributos de calidad salen a la luz mejor cuando las partes interesadas se escuchan unas a otras. Un product owner que oye del responsable de operaciones lo que cuesta una hora de caída a la hora de la cena de un viernes priorizará de otra manera. Esa es la idea que hay detrás de los talleres estructurados.
El Quality Attribute Workshop
El Quality Attribute Workshop (QAW), desarrollado en el Software Engineering Institute (Barbacci y sus colegas; la tercera edición del informe del método se publicó en 2003), es una sesión guiada por facilitadores, normalmente de un día, que se celebra pronto, antes de que la arquitectura quede fijada. Reúne a entre 5 y 30 partes interesadas para producir escenarios de atributos de calidad refinados y priorizados. Tiene ocho pasos.
Los ocho pasos del QAW
Qué ocurre en cada paso
- 1. Presentación e introduccionesLos facilitadores explican el propósito y el método; los participantes se presentan y exponen sus inquietudes.
- 2. Exposición del negocio o de la misiónUn representante del negocio describe el contexto, los objetivos y los requisitos de alto nivel: por qué existe el sistema y qué es lo que más importa.
- 3. Exposición del plan arquitectónicoUn responsable técnico presenta los planes actuales, los sistemas existentes, las restricciones conocidas y los compromisos tecnológicos, por incipientes que sean.
- 4. Identificación de los impulsores arquitectónicosLos facilitadores extraen los principales impulsores arquitectónicos oídos hasta ese momento (objetivos, cualidades, restricciones) y los contrastan con el grupo.
- 5. Lluvia de ideas de escenariosLos participantes proponen escenarios por turnos rotatorios; los facilitadores se aseguran de que cada impulsor tenga al menos uno y de que estén representados los escenarios de uso normal, de crecimiento y exploratorios (de estrés).
- 6. Consolidación de escenariosLos escenarios casi duplicados se fusionan, pero solo cuando quienes los propusieron están de acuerdo, para que los votos no se dividan.
- 7. Priorización de escenariosCada participante recibe un presupuesto de votos de alrededor del 30% del número de escenarios y lo gasta en dos rondas, con cualquier número de votos por escenario. El recuento clasifica los escenarios.
- 8. Refinamiento de escenariosLos cuatro o cinco escenarios principales se escriben completos: fuente, estímulo, artefacto, entorno, respuesta y medida de la respuesta, junto con los objetivos de negocio a los que sirven y las preguntas abiertas.
Los equipos que no pueden dedicar un día entero suelen celebrar un "mini-QAW" más corto, una variante más ligera descrita por profesionales como Michael Keeling, Will Chaparro y Thijmen de Gooijer, que usa una taxonomía de atributos de calidad como guía y dura unas pocas horas con un grupo más reducido. Lo esencial se mantiene: las partes interesadas juntas, escenarios en lugar de adjetivos, una votación explícita y el refinamiento de los ganadores.
El árbol de utilidad
Un árbol de utilidad es una forma de organizar y priorizar los requisitos de calidad, introducida como parte del Architecture Tradeoff Analysis Method (ATAM), que Rick Kazman, Mark Klein y Paul Clements desarrollaron en el SEI; el método de evaluación en sí se trata en el Capítulo 11. La raíz es la utilidad, la bondad global del sistema. El segundo nivel contiene los atributos de calidad (rendimiento, disponibilidad, etc.). El tercer nivel refina cada uno en inquietudes más concretas (para el rendimiento: la latencia de los pedidos, la actualidad del seguimiento). Las hojas son escenarios concretos y medibles.
Cada hoja se valora con un par: la importancia para el negocio (cuánto le importa el escenario al negocio: alta (High), media (Medium) o baja (Low)) y la dificultad técnica o el riesgo (lo difícil que es lograrlo con la arquitectura: alta, media o baja). El par se escribe (B,T), por ejemplo (H,M). Los escenarios valorados (H,H) son las máximas prioridades de la arquitectura: son los que más importan y los más difíciles, así que merecen un esfuerzo de diseño temprano, prototipos y análisis. Los escenarios (H,L) importan, pero son fáciles, así que basta con un enfoque estándar; los escenarios (L,H) son candidatos a descartarse o aplazarse, porque son difíciles pero valen poco.
El árbol es útil incluso fuera de una evaluación formal. Hace visibles los compromisos en una sola página, muestra las lagunas (una cualidad sin escenarios) e impide que la parte interesada que más alza la voz fije las prioridades por su cuenta.
Un árbol de utilidad para una plataforma de reparto de comida
Ejemplo práctico
Ejemplo práctico: construir el árbol de utilidad de una plataforma de reparto de comida
Una plataforma de reparto de comida conecta a clientes, 4000 restaurantes y 9000 repartidores en un país. El negocio planea duplicar el volumen de pedidos en 18 meses. El pico del viernes por la noche es hoy de 3000 pedidos por minuto. Un QAW de dos horas produjo 26 escenarios; con 12 participantes, cada uno tuvo 8 votos (el 30% de 26 es 7.8, redondeado hacia arriba a un 8 par). Los escenarios más votados se convirtieron en hojas del árbol.
| Rendimiento: latencia de los pedidos (H,H) | Los clientes hacen pedidos al ritmo pico de 3000 por minuto; el 95% de las confirmaciones de pedido se devuelve en menos de 1.5 s y el 99% en menos de 3 s. Importancia alta: los carritos abandonados son ingresos perdidos. Dificultad alta: la solicitud pasa por los servicios de carrito, precios, pagos y restaurantes |
|---|---|
| Comprobación de capacidad para ese escenario | 3000 pedidos/min = 50 pedidos/s. Duplicar el volumen da 100 pedidos/s. Con la ley de Little, aunque cada pedido tardara los 1.5 s completos, como mucho habría unos 100 x 1.5 = 150 pedidos en curso a la vez (Sección 2.4); la media real es menor porque la mayoría de los pedidos terminan antes |
| Disponibilidad: disponibilidad del pago (H,H) | Cuando el proveedor de pagos agota el tiempo de espera durante el pico, los pedidos se aceptan y quedan en cola para el pago, no se pierde ningún pedido confirmado y se informa a los clientes en menos de 10 s. Es difícil porque requiere pagos asíncronos, reintentos idempotentes y una experiencia de usuario para el estado "pendiente" |
| Disponibilidad: fallo de región (H,M) | Si falla la región de la nube, el servicio se reanuda en una segunda región en menos de 15 minutos (RTO) con no más de 1 minuto de datos de pedidos perdidos (RPO). Importante, pero técnicamente bien conocido |
| Seguridad: robo de cuentas (H,M) | Un ataque de relleno de credenciales se detecta y se bloquea en menos de 2 minutos; no se toma el control de ninguna cuenta protegida con autenticación multifactor |
| Rendimiento: actualidad del seguimiento (M,M) | La posición de un repartidor en el mapa del cliente nunca tiene más de 5 s de antigüedad con la carga pico |
| Modificabilidad: nuevo proveedor de POS (M,L) | Un nuevo proveedor de sistemas de punto de venta (POS) para restaurantes se integra en 5 días-persona añadiendo un adaptador (Sección 2.6) |
| Prioridades resultantes | Hacer primero un prototipo y una prueba de carga del recorrido de los pedidos y del diseño de pagos en cola; usar patrones multirregión estándar para el fallo de región; mantener sencilla la interfaz del adaptador |
Las valoraciones son juicios acordados por el grupo, no cálculos. Registra quién valoró qué y por qué, para que las valoraciones se puedan cuestionar más adelante.
El árbol guía el plan de trabajo: los dos escenarios (H,H) reciben spikes arquitectónicos (investigaciones acotadas) en los primeros sprints, mientras que el escenario (M,L) no necesita una atención especial.
El seguimiento de los repartidores solo se valoró con importancia media, lo que sorprendió a los ingenieros; el product owner explicó que los clientes consultan sobre todo la hora estimada de llegada, no el mapa.
Priorizar cuando todo es "crítico"
Cada parte interesada valorará su propia inquietud como alta. Ayudan las técnicas que obligan a elegir de verdad. Un presupuesto fijo de votos (como en el QAW) obliga a gastar votos escasos. La comparación por pares ("si solo pudieras tener una, ¿búsqueda en menos de un segundo o cero pérdida de datos en la conmutación por error?") revela el orden real. Poner dinero o tiempo junto a cada objetivo ("cuatro nueves costarán £9000 más al mes y dos meses de trabajo") cambia muchas opiniones. Y distinguir las restricciones (los requisitos legales de accesibilidad, la residencia de datos) de las preferencias evita que lo innegociable se ceda por accidente.
Las prioridades no son fijas. Una start-up que busca sus primeros clientes hace bien en anteponer el tiempo de llegada al mercado y la modificabilidad a una disponibilidad de cinco nueves; el mismo producto, tres años después, con clientes empresariales y SLA contractuales, debe volver a clasificarlas. Revisa el árbol de utilidad cuando cambie el negocio.
Conflictos entre cualidades
Las cualidades interactúan. Algunas se refuerzan entre sí: la modularidad ayuda a la capacidad de prueba, que a su vez ayuda a la desplegabilidad. Muchas entran en conflicto, porque la táctica que ayuda a una cualidad perjudica a otra. El ATAM, descrito por Bass, Clements y Kazman, llama puntos de compromiso a los puntos en los que una decisión arquitectónica afecta a varias cualidades. Reconocer los conflictos habituales te permite plantearlos antes de que sorprendan a nadie.
Conflictos habituales entre cualidades y cómo los resuelve el contexto
| Conflicto | Por qué tiran en direcciones opuestas | Formas de resolverlo en contexto |
|---|---|---|
| Rendimiento frente a seguridad | El cifrado, las comprobaciones de autenticación, la validación de la entrada y el registro de auditoría añaden trabajo a cada solicitud | Medir la sobrecarga real (a menudo pequeña con TLS y hardware modernos); almacenar en caché brevemente las decisiones de autorización; llevar las comprobaciones costosas al perímetro; no ceder nunca en la seguridad de datos que causarían un daño grave si quedaran expuestos |
| Disponibilidad frente a consistencia | Durante una partición de red, un sistema replicado debe elegir entre responder (quizá con datos desactualizados) y negarse | Decidir por operación: una carta o la posición de un repartidor pueden estar algo desactualizadas; un pago o una reserva de existencias no. Consulta CAP y PACELC en el Capítulo 6 |
| Modificabilidad frente a rendimiento | Las capas, las interfaces, los intermediarios y la vinculación tardía añaden indirección y saltos | Mantener la indirección donde es probable que haya cambios; optimizar la ruta crítica medida; aceptar algunos atajos deliberados, documentados en un registro de decisiones |
| Costo frente a casi todo | La redundancia, las regiones adicionales, más pruebas y un hardware más rápido cuestan dinero | Vincular cada objetivo de calidad a su valor para el negocio; usar presupuestos de errores y el costo unitario; comprar nueves solo donde una caída cuesta más que evitarla |
| Usabilidad frente a seguridad | La autenticación robusta, los tiempos de expiración y las confirmaciones añaden fricción | Autenticación basada en el riesgo (pedir más verificación solo para las acciones de riesgo), passkeys e inicio de sesión único, duraciones de sesión razonables; implicar a los usuarios en las pruebas |
| Tiempo de llegada al mercado frente a mantenibilidad | Los atajos aceleran el primer lanzamiento y ralentizan los siguientes | Asumir deuda técnica de forma deliberada, registrarla y planificar su pago (Capítulo 1) |
La resolución adecuada siempre depende del contexto. "La seguridad está por encima del rendimiento" es un eslogan, no una decisión: 2 ms más de negociación TLS en un sitio web público son irrelevantes, mientras que las comprobaciones de fraude síncronas en cada pago con tarjeta en un estadio abarrotado pueden ser un problema real que merece una respuesta arquitectónica (un modelo de aprobar primero y comprobar después, con límites). Pregunta: ¿a qué objetivo de negocio sirve cada lado, cuánto cuesta cada opción y quién tiene que estar de acuerdo?
Registrar las decisiones y hacer el seguimiento de las cualidades
Un compromiso que no se deja por escrito se volverá a discutir, a menudo por personas que no estaban presentes. Registra los significativos como registros de decisiones de arquitectura (Capítulo 4): el contexto, las cualidades en tensión, las opciones consideradas, la decisión y sus consecuencias, incluido aquello a lo que has renunciado conscientemente.
Después, haz que cada objetivo de calidad sea medible y visible. El Planguage de Tom Gilb ofrece un formato riguroso: una escala (scale: qué se mide y en qué unidad), un medidor (meter: cómo se mide) y niveles como fallo (fail: el umbral por debajo del cual no se cumple el requisito), objetivo (goal: la meta) y ampliado (stretch) o deseo (wish), que son niveles más ambiciosos. Aplicado al escenario de latencia de los pedidos: escala, segundos desde el envío hasta la confirmación en el percentil 95; medidor, monitorización de usuarios reales durante el pico del viernes; fallo, por encima de 3 s; objetivo, 1.5 s; ampliado, 1 s.
Por último, haz el seguimiento de las medidas a lo largo del tiempo en un panel que las partes interesadas puedan ver, junto a los SLO (Capítulo 9), y revísalas cada vez que cambien el negocio, la carga o el equipo.
De los escenarios a las funciones de aptitud
La forma más sólida de mantener vigente un requisito de calidad es comprobarlo automáticamente, cada vez que el sistema cambia. Neal Ford, Rebecca Parsons y Patrick Kua, en Building Evolutionary Architectures (2017; segunda edición con Pramod Sadalage, 2022), llaman a esa comprobación función de aptitud (fitness function) arquitectónica: una evaluación objetiva de lo bien que el sistema cumple una característica arquitectónica. Una prueba de carga en el pipeline que hace fallar la compilación si la latencia p95 de los pedidos supera 1.5 s a 100 pedidos por segundo es una función de aptitud. También lo son una prueba que falla si algún módulo fuera de payments importa la biblioteca del proveedor de pagos (lo que protege el escenario de modificabilidad), un simulacro programado de conmutación por error que mide el tiempo de recuperación o un análisis de dependencias que bloquea las bibliotecas con vulnerabilidades conocidas.
Las funciones de aptitud son el punto de llegada natural del trabajo de este capítulo: un deseo vago se convierte en un escenario (Sección 2.3), el escenario recibe una prioridad en el árbol de utilidad y la medida de la respuesta del escenario se convierte en una comprobación automática. No todas las cualidades se pueden automatizar a bajo costo (la usabilidad sigue necesitando personas), pero cada una que automatizas frena una erosión silenciosa. El Capítulo 11 trata su diseño en profundidad: funciones de aptitud y arquitectura evolutiva.
Lista de comprobación: celebrar un taller de atributos de calidad
Adaptada para una sesión de medio día o de un día; un "mini-QAW" más corto puede cubrir lo mismo con un grupo más reducido.
- Invita a la combinación adecuadaEntre 5 y 30 personas: responsables de negocio, usuarios o sus representantes, operaciones, seguridad, soporte, desarrolladores y cualquiera que dé el visto bueno al cumplimiento normativo. La ausencia de operaciones es la laguna más habitual.
- Envía una breve lectura previaLos objetivos de negocio, las restricciones conocidas y un borrador de lista de atributos de calidad (con ISO/IEC 25010 como guía), para que la gente llegue con las ideas en marcha.
- Empieza por los objetivos de negocio, no por la tecnologíaUna parte interesada de alto nivel explica por qué existe el sistema, cómo sería el éxito y cuánto costaría el fracaso.
- Acuerda los impulsores arquitectónicosUna lista breve de los objetivos, las cualidades y las restricciones que darán forma a la arquitectura, contrastada con el grupo antes de empezar con los escenarios.
- Propón escenarios por rondasTodos aportan al menos dos, por turnos, para que se oigan las voces más calladas. Incluye uso normal, crecimiento ("dentro de dos años") y estrés ("cuando el proveedor de pagos está caído").
- Fusiona duplicados solo con consentimientoLa consolidación evita que los votos se dividan, pero quien propuso el escenario debe estar de acuerdo en que dos escenarios significan realmente lo mismo.
- Vota con un presupuesto fijoCada persona recibe un número de votos igual a alrededor del 30% del número de escenarios, que gasta en dos rondas. Esto revela las prioridades reales y evita el "todo es crítico".
- Refina por completo los principalesEscribe los cuatro o cinco principales como escenarios de seis partes con medidas de la respuesta medibles, y anota el objetivo de negocio al que sirve cada uno.
- Registra las preguntas abiertas y los conflictosLos desacuerdos sobre la prioridad o la viabilidad son resultados valiosos; enuméralos con un responsable.
- Publica el resultado en pocos díasComparte los escenarios priorizados, añádelos a la documentación de arquitectura y al backlog, y planifica cuándo se comprobará cada uno.
Comprueba lo que has entendido
En un QAW con 20 escenarios consolidados, ¿aproximadamente cuántos votos recibe cada participante?
Alrededor del 30% de 20, es decir, 6 votos, gastados en dos rondas de 3.
Una hoja de un árbol de utilidad está valorada (L,H). ¿Qué sugiere eso?
Que importa poco al negocio, pero es difícil de lograr, así que es candidata a descartarse, aplazarse o renegociarse en lugar de guiar la arquitectura.
¿Por qué "la seguridad siempre está por encima del rendimiento" es una mala forma de resolver un conflicto?
Porque la respuesta correcta depende de la sobrecarga real, del daño que evita el control de seguridad y del valor del rendimiento para el negocio; el conflicto debe resolverse caso por caso, con cifras, y registrarse.
Da un ejemplo de función de aptitud para un requisito de modificabilidad.
Una prueba automática en la compilación que falla si algún módulo distinto del adaptador de pagos importa la biblioteca del proveedor de pagos, de modo que el proveedor sigue siendo sustituible.
Fuentes y lecturas recomendadas
¿Tienes una pregunta sobre esta sección? ArchitectBot, el asistente de estudio con IA del curso, responde primero a partir del curso.
Pregunta: “Nuestro product owner dice que todas las cualidades son críticas. ¿Cómo puedo organizar una sesión breve que dé una clasificación honesta?”