[Orador 1]: Muy buenos días a todos.
Vamos con nuestra sesión prevista para hoy.
Es la cuarta, como sabéis, de una serie dedicada a métodos ágiles y en particular
Scrum.
Y hoy finalizamos con algo que no es exactamente algo de proceso o un elemento
organizativo, sino que ya es uno de los primeros elementos técnicos en el
desarrollo del software, que es la ingeniería de requisitos con una
metodología de descripción de requisitos que particularmente casa y se suele usar
en combinación con Scrum como proceso de desarrollo, que es el de las user stories
o historias de usuarios.
Bueno, por si alguien se suma hoy y no lo ha hecho a sesiones anteriores,
presentarme un poquito a mí mismo.
Soy Juan Carlos Yelmo, profesor de la Universidad Politécnica de Madrid y
coordinador de formación de este centro, del Center for Open Middleware.
Hoy me toca a mí jugar los dos roles de autopresentarme y de dar la charla.
Bien, pues vamos a empezar ya sin más.
Lo que vamos a ver...
Hoy es una breve introducción para unificar nuestra terminología, nuestro
conocimiento sobre el campo de aplicación de lo que es la ingeniería de requisitos,
para luego ir al grano de lo que nos llevará hoy, yo supongo que unos 50
minutitos no más, más luego un debate hasta donde a vosotros os parezca
conveniente.
Vamos a hablar de historias de usuario, vamos a introducir el concepto, vamos a
ver qué formato de representación tiene, vamos a discutir los distintos niveles de
granularidad de representación de historias de usuario, vamos a ver qué
podemos hacer entre las historias de usuario y Scrum para representar y validar
los requisitos no funcionales, vamos a dar unos criterios de elaboración y con eso
terminamos.
Un par de recomendaciones bibliográficas lo damos por terminado.
Bueno, vamos a empezar con ingeniería de requisitos.
Supongo que todos tenemos una noción, aunque sea intuitiva, de qué es ingeniería
de requisitos.
Pero yo aquí tengo una definición.
Y para no hacerlo yo todo, me gustaría que en 30 segundos la leyereis vosotros
mismos.
Supongo que se lee incluso desde el fondo.
Bueno, dice, uso sistemático de principios contrastados, técnicas, lenguajes y
herramientas para hacer algo efectivo en coste.
Eso es ingeniería.
Siempre que se hace algo de forma sistemática para hacerlo bien, pero no a
cualquier coste, eso es ingeniería.
Me encanta.
Somos muy útiles.
Hay políticos como Josep Borrell que dicen que los ingenieros mueven el mundo.
Yo lo digo en casa, mi mujer me mira como diciendo, si tú lo dices.
Pero hay gente sabia que sostiene que los ingenieros movemos el mundo.
A mí me gusta.
y que hacemos las cosas bien sistemáticamente, es decir, que no nos
sale bien una vez, sino que repetida a veces, lo hacemos bien y que lo hacemos
siempre con un coste proporcional y equilibrado a lo que pretendemos
conseguir.
En este caso, para el análisis, documentación, evolución de necesidades de
usuario y la especificación del comportamiento externo de un sistema
software.
En este contexto vamos a interpretar software para satisfacer dichas
necesidades.
Es decir, que eso en sí es una disciplina de ingeniería en sí misma.
La ingeniería de requisitos tiene su complejidad, es una disciplina en sí
mismo, tiene libros, congresos, expertos, es decir, que hay gente que se dedica solo
a eso y que ha alcanzado una madurez considerable.
Abarca muchas cosas.
La ingeniería de requisitos suele tener como dos grandes ramas.
por una parte el desarrollo de requisitos y por otra la gestión de requisitos.
En cuanto a desarrollo de requisitos leo una cosa que está en la transparencia
siguiente para que luego cualquiera que lo pueda leer pero que yo leo aquí en
relación con este dibujo es, consiste en identificar, acordar y documentar el
conjunto de requisitos y características de producto que permitan alcanzar los
objetivos de negocio planteados por el sistema e involucra actividades de captura
de requisitos
que es la comprensión de los usuarios y sus necesidades, en inglés lo llaman
elicitation, que podremos traducir como sonsacar, lo que pasa es que como aquí
tiene una connotación negativa, decir sonsacar, que parece un interrogatorio
policial, pues casi siempre lo dejamos en captura de requisitos, pero en inglés se
suele decir elicitation.
Luego esos requisitos hay que analizarlos desde una perspectiva ya técnica por parte
de los ingenieros, de forma que los desarrollan, los refinan, los valoran,
hacen con ellos determinados modelos, establecen criterios para posteriormente
validarlos, etc.
Luego está la especificación.
que es el registro de la información sobre requisitos para facilitar la comunicación
entre stakeholders de forma que queda por escrito y no a lugar a confusión sobre qué
es lo que interpretamos que debía hacer el sistema y finalmente está la validación
que es asegurarnos de que los requisitos son correctos y el sistema finalmente
desarrollado los cumple.
Y luego hay una faceta que algunas veces uno no recuerda bien cuando habla de
ingeniería de requisitos que es la gestión de requisitos.
que tiene que ver con la gestión de la evolución de los requisitos, atendiendo a
su evolución temporal, peticiones de cambio sobre los requisitos, es la típica
tarea de gestión de configuración, gestión de versiones, gestión de cambios, que
normalmente interpretamos que aplica sobre código fuente de un sistema en desarrollo,
pero que también aplica a los requisitos.
Todos los requisitos evolucionan con el tiempo y aunque en un momento se registran
de una manera, algún stakeholder puede solicitar un cambio posterior sobre él y
ese cambio hay que valorarlo y hay que priorizarlo y hay que decidir qué coste
tiene, hay que decidir si se lleva o no se lleva a cabo y cómo se lleva a cabo y
quién lo lleva a cabo.
Además los ingenieros lo refinan y lo desarrollan y lo extienden según va
pasando el tiempo, sobre todo en un modelo de proceso que sea iterativo.
Y eso requiere control de cambios y control de versiones y hay herramientas
para hacer eso y es en sí mismo también un mundo.
Nosotros en cualquier caso en la charla de hoy nos vamos a ocupar más de la
izquierda, del desarrollo de los requisitos y sobre todo en lo que se
refiere a captura.
Ese es un poquito nuestro ámbito.
¿Pero qué es un requisito del software?
Pues también todos nos imaginamos qué es un requisito del software.
Bueno, supongo, porque ni siquiera nos ponemos de acuerdo en cómo llamarlo.
Muchos de nosotros decimos requisitos, otros tantos de nosotros decimos
requerimientos, que parece que queda bien por la traducción del inglés requirement,
¿vale?
Yo prefiero requisitos, no le voy a decir a nadie cómo debe llamar a las cosas, yo
prefiero requisito que requerimiento, que a mí me suena más a la orden que te da un
juez de ven pa' acá, pa' acá, ¿vale?,
¿Qué es un requisito?
Un requisito es una capacidad característica o factor de calidad que un
sistema software necesita para tener valor y utilidad para un usuario.
No sé si estáis de acuerdo en esa definición de requisito.
Es algo que un sistema tiene que cumplir obligatoriamente para demostrar
conformidad con unas necesidades planteadas de una manera también formal.
De forma que para que tenga valor para mí un sistema es imprescindible que cumpla
esto, esto, esto, esto y esto y de no ser así pues degradará el valor que para mí
tiene.
Eso es un requisito.
Desde ese punto de vista, la ingeniería del software y la ingeniería de requisitos
en particular tiene como objetivo básico encontrar enfoques sistemáticos para que
de una manera eficiente y repetida poder ser capaz de encontrar, documentar,
organizar, monitorizar los requisitos de un sistema que sucede que son cambiantes y
no porque sea una maldición bíblica,
como lo de que te ganaras el pan con el sudor de tu frente y parirás con dolor.
No es una maldición, es una realidad.
Debemos hacer mecanismos organizativos que encajen bien esa evolución en los
requisitos.
Desde luego que el modelo de proceso determina también el modelo de gestión de
los requisitos.
Puede haber modelos secuenciales como el cascada donde los requisitos se establecen
al principio y se congelan a lo largo de la duración de todo el ciclo de desarrollo
o hay modelos iterativos que los crean y los hacen evolucionar enriqueciéndoles a
lo largo de todo el proceso y además
SELES de alguna manera cuantifica el valor de negocio para priorizarlo, pudiendo
reconsiderar esa prioridad o ese valor de negocio a lo largo del tiempo.
Son dos modelos que encajan en distintas tipologías de proyectos, no hay ninguno de
ellos que sea mejor que el otro, sino que simplemente son diferentes y que tenemos
que ser capaces de adecuarlo a lo que el proyecto nos pide.
El ser humano, cuando se plantea cosas muy complejas, que no es capaz de manejar
conceptualmente de una sola tacada, tiende a clasificar.
Esto no sé lo que es, pero te voy a decir los tipos que hay.
Por ejemplo, la vida.
Muy difícil saber qué es la vida, pero te voy a clasificar las distintas especies,
en mamíferos, primates...
Entonces, no sé definirlo, pero clasifico.
Pues lo mismo pasa con los requisitos, que es muy complicado definirlo, pero los
clasificamos, que es siempre la estrategia de huida.
Entonces, los requisitos del software tradicionalmente se descomponen en
funcionales y no funcionales.
Y últimamente aparece otra categoría, que son las reglas de dominio.
Los requisitos funcionales son las funciones o características que describen
qué debe hacer el sistema en mi beneficio.
Pongamos el caso de un cajero automático, un cajero automático de banco, que ofrece
a los clientes del banco la posibilidad, las 24 horas del día, en casi cualquier
lugar cercano a donde te encuentras, obtener información sobre saldo y
movimientos de tu cuenta.
De forma que eso ofrece un valor a las personas que tienen una manera sencilla de
mantener un control sobre sus finanzas personales.
Una persona observa eso de valor, resuelve una de sus necesidades y tanto es así que
está dispuesto a pagar por ello, sea vía una comisión o sea vía comisiones cuando
lo utilice como medio de pago.
O sea, eso ya depende del modelo de negocio.
Un requisito no funcional es un atributo de calidad del sistema.
de tipo prestaciones, el sistema tendrá un tiempo de respuesta inferior a 0,2
segundos, el sistema procesará 7500 paquetes por minuto, ese tipo de cosas, de
tipo de velocidad,
precisión, el sistema calculará la gravedad terrestre hasta la milmillonésima
de ese tipo de cosas, son prestaciones.
O pueden ser cosas como requisitos de interfaz, que a pesar del nombre no se
refiere a interfaz de usuario, sino requisitos en cuanto a interfaces con
sistemas externos que el sistema ha de respetar.
O son requisitos en términos de operación, que sí se suele referir a la interfaz de
usuario,
tanto de uso como de administración.
O son requisitos en cuanto a uso de recursos, memoria, disco, periféricos
especiales.
O son requisitos en cuanto a seguridad, seguridad de la información,
autenticación, autorización, no repudio, confidencialidad, ese tipo de cosas.
O pueden ser requisitos de fiabilidad, tiempo medio entre fallos, tiempo medio de
reparación, porcentaje de disponibilidad.
O son cosas de tipo safety, que podríamos traducir por salvaguarda, es decir, los
mecanismos que tiene el software para que en caso de mal funcionamiento no se
ocasionen daños personales o económicos.
Y al final es fácil distinguir un requisito funcional de no funcional, no,
no es fácil.
Un poquito la regla del 9 es que un requisito funcional,
no funcional, siendo imprescindible, en sí mismo no tiene valor de usuario.
Imaginad que a alguien se le presenta un nuevo cajero automático y dice esto tiene
una interfaz telepática.
Es un requisito de operación.
De forma que tú miras fijamente al cajero y cuando comprende tu pensamiento cambia a
rojo.
Y ya está.
Pero no da dinero.
No, dinero no.
Se pone en rojo.
¿Pagarías por ello?
Este cajero tarda en responderte 0,7 nanosegundos.
Y dinero no vale.
Solo que es rápido.
En fin.
Y este fiable no se ha caído nunca.
Lleva aquí 10 años, pero da dinero.
No, no, en estos 10 años no ha dado ni un billete.
Es decir, un poquito la regla del 9, por recordarlo, es que un requisito no
funcional, siendo imprescindible a nivel de sistema, en sí mismo no aporta valor de
usuario y nadie pagaría por él.
Como regla.
Las reglas de dominio son requisitos...
que representan restricciones generales del dominio de aplicación, de la empresa
en que se sitúa o del sistema legal.
Son, por ejemplo, la ley de protección de datos de carácter personal.
Todo ese sistema informático que atiende al público debe tener en cuenta que no
puede difundirse información de clientes a terceros porque hay una ley que lo impide.
Y las reglas de dominio, si hay algo que las distingue, es que no aplican a un
sistema solo, sino a todos los sistemas de la organización.
Por ejemplo, es posible, digo yo, no lo sé, que en un banco solo determinados
empleados pueden hacer arqueo de caja.
Solo algunos de ellos.
Eso es una regla de dominio.
Todos los sistemas, sea para hacer arqueo de caja de un cajero automático, como para
hacerlo de la caja de una oficina comercial,
debe cumplir con eso y por tanto sólo pueden estar autorizados aquellos
empleados que lo puedan.
Es una regla de dominio, no es un requisito de sistema y un poco la
diferencia está en que aplica a todos los sistemas de la organización y no sólo a
uno en concreto.
También puede ser aplicaciones de estándares.
Así que en general podemos decir que hay requisitos funcionales, no funcionales y
reglas de dominio.
Hay muchas clasificaciones mucho más pormenorizadas de las que yo he hecho.
Grandes clientes de software como el Departamento de Defensa norteamericano o
la Agencia Europea del Espacio proporcionan clasificaciones.
Asociado al modelo de proceso unificado, ese modelo iterativo, un poco inspirado en
el modelo espiral, también proporciona una clasificación que se llama Forbes Plus.
y también hay estándares como el ISO 25000 que si bien inicialmente está pensado para
valorar la calidad de los productos de software a través de una serie de
atributos bien puede ser usado al revés para clasificar los requisitos en función
de ese estándar de forma que garantiza que al final cumple con los criterios de
calidad así que bueno estas son las distintas categorías en la representación
de los requisitos y ya si nos centramos un poquito en el
En esa figura jerárquica que representaba la ingeniería de requisitos en la parte de
desarrollo y sobre todo en la parte de captura de requisitos, fundamentalmente en
la literatura nos encontramos dos grandes enfoques.
El enfoque centrado en producto y el enfoque centrado en usuario.
En el enfoque de centrar un producto nos centramos en describir de manera
pormenorizada las características que el sistema ha de implementar para cumplir su
objetivo, en forma de funciones, objetivos, atributos de calidad.
Es la típica especificación de sistema software que se escribe en forma de
clausulado contractual donde dice requisito funcional 1, requisito funcional
2, requisito funcional 3, requisito no funcional 1, requisito no.
El sistema muchas veces ahí en inglés se pone will o can o may en el sentido de si
es opcional o obligatoria la característica con una medida de
prioridad, así muy robotizado.
Por ejemplo, sería una característica de un sistema, el cajero automático dispondrá
de una tecla de cancelación para abortar la transacción en curso.
Ese es un ejemplo de característica del sistema.
Este tipo de enfoque es apropiado para sistemas, software de infraestructura o
software de sistemas operativos, de protocolos de comunicaciones, middleware,
aplicaciones de tiempo real o empotradas o aplicaciones en las que el usuario final
no aparece, las aplicaciones intensivas en computación, en cómputo o tratamiento de
datos.
Entonces son sistemas adecuados para representarlo de esa manera, pero
últimamente
están ganando una cierta importancia los llamados enfoques centrados en uso usuario
donde lo que hacemos es ponernos en la piel del usuario, del humano que va a
utilizar el sistema para tratar de averiguar cuáles son sus objetivos y
necesidades y estructurar la descripción de requisitos del sistema de forma que
enfatizamos en primer plano
Unidades de especificación que ponen de manifiesto que el sistema está ahí para
cubrir sus necesidades, para resolver sus problemas.
Que todo gira en torno a que sabemos que él tiene problemas que quiere resolver con
un sistema software y que el sistema lo hará.
Y que sabemos identificar esas necesidades y valorar esa importancia o valor de
negocio.
Esto lógicamente es más apropiado para sistemas intensivos en interacción con los
usuarios, para sistemas finalistas.
Desde ese punto de vista, por ejemplo, que exista una tecla de cancelación para
abortar una transacción en cualquier momento carece de valor para un cliente
medio de un cajero automático.
En el sentido de que nadie...
Por eso solo considerado de manera aislada y autocontenida pagaría un duro.
Oye, este sistema permite que abortes en cualquier momento.
Bien.
¿Pagarías?
Pues no, gracias.
Ahora bien, tienes un sistema que te permite tener conocimiento y control sobre
saltos y últimos movimientos de tu cuenta.
¿Mola?
Sí.
¿Pagarías?
Sí.
puedes disponer de un sistema que te permite disponer de efectivo en muchas
localizaciones geográficas próximas a tu situación actual y en las 24 horas del
día.
¿Te gusta?
¿Te apetece?
¿Te resuelve un problema?
Sí.
¿Pagarías?
Sí.
Esas son las formas de representar los requisitos del sistema desde el enfoque
centrado en uso usuario.
¿Se termina con este enfoque diciendo que habrá una tecla de cancelación?
Sí.
Se termina diciendo, pero en segundo plano.
en otro sitio, no con esa relevancia, es decir, porque no se considera que sea un
elemento de información adecuado para intercambiar información con stakeholders
de la importancia de los usuarios finales que no son usuarios técnicos y que no
consideran eso una prioridad.
Después de esto, que es la introducción, vamos a las historias de usuario.
¿Qué son las historias de usuario?
Es una técnica de captura de requisitos de estas últimas que he mencionado, de las
centradas en uso o usuario y por tanto adecuadas para sistemas intensivos en
interacción con los usuarios y no tanto para software de infraestructura, software
de sistemas, sistemas empotrados, middleware, ese tipo de cosas.
Es un mecanismo que genera descripciones de requisitos basadas en objetivos de
usuario y la interacción de los usuarios con el sistema para el logro de dichos
objetivos.
Es decir, que lo que nos planteamos los ingenieros encargados de desarrollar el
proyecto
Intentan averiguar por todos los medios, con fuentes directas e indirectas, cuáles
son las necesidades a cubrir por el sistema, a ponerse en la piel de los
usuarios y a describir todos esos elementos con la granularidad adecuada
para encontrar cosas de valor que puedo priorizar desde lo más importante a lo
menos importante.
Al final son descripciones concisas por escrito, en lenguaje natural, porque
tienen que ser un elemento adecuado para el intercambio de información con usuarios
no técnicos.
que sea ágil y eficaz.
Y se trata de encontrar qué proporciona valor para el usuario.
El usuario stakeholder en general, porque la existencia de un cajero automático y la
posibilidad de poder pedir saldo y movimientos en cualquier lugar aporta
valor al usuario final por el control de sus finanzas personales, pero también para
el banco fideliza clientes
y por disminución de los clientes que tienen que acudir a la oficina para ese
tipo de operaciones a lo mejor lo puede hacer con menos plantilla.
Es decir que los distintos requisitos caracterizados de esta manera aportan
valor a los stakeholders en general y no solo a los usuarios directos del sistema.
Aquí por tanto de lo que se trata es de enfatizar el cumplimiento de objetivos y
el valor que proporciona a sus stakeholders.
Es una técnica muy vinculada a procesos ágiles.
y a modelos de procesos de desarrollo de software de tipo iterativo y ya veréis que
encaja muy bien con la idea de los ítems del Product Backlog del Scrum como ya
hemos visto en otras sesiones anteriores.
El término User Story fue acuñado por Kent Beck
que es el autor de otro de los modelos de procesos ágiles muy conocidos, que aquí no
hemos mencionado mucho, es Extreme Programming.
Lo menciona en su libro de 1999 este término como historias de usuarios o user
story.
¿Qué formato tienen las historias de usuario?
Pues son frasecitas muy sencillas que puede entender cualquiera.
Tienen esta pinta.
Esta plantilla es una de los formatos de plantilla de historia de usuario.
Yo como
rol, quiero un objetivo, de forma que una razón.
Hay algunas otras estructuras para representar historias de usuario, pero se
parecen mucho.
Por ejemplo, aquí tengo otra.
Yo como tipo de usuario, por ejemplo, cliente de cuenta corriente, por
distinguirlo de un cliente de depósito, por distinguirlo de un cliente de
Cartilla de ahorro, por distinguirlo, a lo mejor puedo dar una categoría, un tipo.
Quiero, y este es más procedimental, realizar determinada tarea con objeto de
alcanzar determinado objetivo.
Son semánticamente equivalentes, aunque varían un poquitín.
Os voy a dar una tercera opción con una estructura distinta, pero ya la pinto en
forma de tarjeta.
Porque es muy común representar las historias de usuario o en una tarjeta de
papel o en un post-it que se puede pegar en una pizarra.
Bueno, esto es una cosa que a los americanos les encanta.
O sea, esto de las tarjetitas, rellenar tarjetitas, bueno, desde los años 70 o así
es una cosa que se hace con un montón de técnicas de trabajo estructurado de
trabajo en grupo.
Aquí hemos tardado muchas décadas en pensar que eso es algo más que hacer el
indio y que es un poco procrastinar el trabajo real, pero que no llegue un jefe,
asome por la puerta y diga, pero vosotros cuándo os vais a poner a escribir el
código, macho, mientras tú pegas post-it por aquí y por allá.
Pero bien pensado es una buena idea, ya veréis cómo lo es.
Bueno, aquí pone que yo como persona, persona en inglés, persona en inglés
significa rol social o personaje reinterpretado por un actor.
Es lo que significa persona en inglés.
Yo como persona me gustaría que el sistema tuviera determinada característica de
forma que yo obtenga determinado beneficio o valor.
Bueno, una tercera estructura posible de historia de usuario que viene a ser
semánticamente equivalente, pero bueno, para que dispongáis de un abanico de
opciones.
Vamos a poner algunos ejemplos de historia de usuario.
Yo como usuario registrado en el sistema me gustaría hacer login para acceder a
contenido reservado a abonados.
Podría ser un requisito de alguien que quiera ver la tele en directo a través de
la aplicación Go de Movistar Televisión, por ejemplo.
Pues yo como usuario abonado y registrado de Telefónica me gustaría poder acceder a
esta aplicación web para acceder al contenido reservado solo para abonados.
Bueno, pues es una opción.
Otro ejemplo.
Yo como usuario típico quiero leer críticas objetivas de los restaurantes
próximos a una localización con objeto de decidir a dónde puedo ir a cenar.
Bueno, pues es una forma sencilla en lenguaje natural de representar los
requisitos sobre un sistema, pero que eso sí, pone en valor exactamente lo que el
cliente espera de la aplicación.
¿Qué es lo que quiere un cliente de TripAdvisor cuando busca un restaurante?
Esto.
Y la aplicación tendrá éxito en la medida en que lo cubra.
Y por otra parte, está escrito en un lenguaje tan sencillo que cualquiera lo
puede comprender y discutir sobre ello.
Más ejemplos.
Como usuario de la wiki quiero poder subir un fichero a la wiki para compartirlo con
mis colegas.
Bueno, pues otro.
Y otro que está aquí es de estudiantes, porque yo he usado esta transparencia en
clase.
Y digo, les voy a poner uno de los que a ellos les hacen mastilín.
Y no debo haberme acordado de poner uno de banca aquí para quedar mejor con vosotros.
Yo como estudiante quiero poder consultar mis notas online para no tener que esperar
hasta una comunicación formal para saber si he aprobado.
A los estudiantes de la universidad últimamente se les pone en una aplicación
que se llama Politécnica Virtual todas sus notas y además lo reciben por SMS.
Porque no queremos que los chicos dejen sus intensas actividades de ocio para
venir a averiguar sus notas a la universidad.
Es una molestia importante que no queremos que sufran.
Entonces, bueno, pues como estudiante a día de hoy cualquiera tiene este
requisito.
Si no le llega por SMS...
Pues, ¿qué mierda universidad es esta?
Bien, pues esta es la pinta que tienen las historias de usuario.
Es sencillo, ¿verdad?
La verdad es que no tienen mucha miga.
Una cosa que es importante destacar aquí es que realmente estas historias de
usuario no especifican un requisito.
Se dice que son placeholders o contenedores para especificar un
requisito.
De forma que son una especie de título identificativo que permite que todos los
stakeholders, usuarios y desarrolladores sepan que están encargados de hacer un
sistema que permita que el estudiante consulte sus notas online
sin necesidad de esperar a una comunicación formal para saber si ha
aprobado o suspendido.
Y que detrás de esa etiqueta puede haber documentos de cientos de páginas
detallando acuerdos, consensos, modelos, especificaciones, mecanismos de
comprobación de conformidad o validación, reglas de satisfacción, ese tipo de cosas.
De forma que
Eso solo es una etiqueta o placeholder o contenedor para el consenso en relación
con un requisito de usuario.
En primer lugar, ahí no está todo.
Eso es solo la etiqueta identificativa de un requisito escrito en términos de valor
para un usuario.
Y por otra parte, que justo ese concepto de placeholder para la especificación de
requisitos es la definición de un item de un product backlog en un modelo de proceso
tipo Scrum.
Por esa razón casa estupendamente esta metodología de las historias de usuario
con la idea de Scrum y básicamente lo que se propone y es lo más frecuente de
utilizar es que los ítems en un Product Backlog sean historias de usuario,
historias de usuario como esta, que por sí solas no contienen toda la información,
repito, sino que son placeholders para toda la información que contienen.
En ese sentido de que estos títulos no lo son todo,
Normalmente en la literatura se considera tres grandes componentes en la descripción
de una historia de usuario.
Lo que llaman tarjeta o card, que viene a ser esto que hemos visto en la
transparencia anterior, un titulito.
Yo como usuario me gustaría, como objeto de alcanzar tal objetivo.
Es una descripción escrita de la historia de usuario, efectos de descripción de
requisitos, planificación y como referencia para discusión posterior.
Se escribe en una tarjeta o más frecuentemente en un post-it y se suele
pegar en un tablón.
Pero eso es solo un título.
Lo importante es lo que viene a continuación.
La conversación.
Se entiende por conversación toda la discusión entre todos los stakeholders
posterior a la puesta en común del título en relación con la especificación del
contenido.
Todas las aclaraciones que los clientes hicieron, todas las propuestas que los
desarrolladores hicieron, los refinamientos posteriores, lo podemos
considerar como un blog donde se va registrando todas las conversaciones que
los stakeholders mantienen en relación con la historia de usuario y que representan
de verdad la especificación del requisito funcional asociado.
Creo que lo menciono más adelante, pero desde un punto de vista filosófico,
también la conversación tiene la consideración de puntos de consenso entre
stakeholders, porque aquí Scrum, os recuerdo, es un equipo de desarrollo
multidisciplinar con personas de alta cualificación y alta motivación que
trabajan de forma autónoma y con capacidad de decisión y criterio para conseguir que
la aplicación cumpla sus objetivos de negocio.
Entonces, en ese contexto no cuadran bien las coerciones contractuales.
Escribí el 15 de marzo en la especificación del sistema que tiene
carácter contractual que el sistema proporcionaría tal funcionalidad.
No es ese carácter el que tiene aquí.
No son especificaciones de carácter contractual entre un cliente que paga
y un equipo o empresa que desarrolla lo que le han encargado, sino que juega el
rol de registro de conversaciones como instrumento de consenso,
De forma que se alcanza un acuerdo común sobre lo que el sistema tiene que
proporcionar y todos somos un equipo y todos estamos involucrados y nadie impone
al otro como si de una cláusula contractual se tratara ese requisito del
sistema.
Y finalmente hay una tercera parte en las historias de usuario que son la
confirmación.
Es la sección donde se describen las normas de satisfacción.
Como después de implementada esa historia de usuario, yo voy a
comprobar que está correctamente implementada y que efectivamente satisface
las necesidades de usuario.
Puesto todo en un ejemplo junto que va en una tarjeta, aunque no se suele poner todo
en una tarjeta, aquí tenemos una especie de User Story avanzada.
Avanzada e inútil, no me gusta este procedimiento.
Aquí se ve mucha información.
La historia de usuario tiene una tarjeta aquí donde tiene la típica expresión
textual de As a registered user I want to login so I can access subscriber content.
Es uno de los ejemplos que he puesto antes.
Pero además se la numera, arriba a la izquierda hay un número, esa es la
historia de usuario número 1.
Tiene un nombre abreviado, user login.
Tiene a la derecha una asignación de valor en puntos de función según la serie de
Fibonacci.
Luego tiene medio como una especie de borrador o diseño preliminar de
pantallazo, de cómo es el login.
Y se determina que debe tener un tick para decir cuándo quieres que te recuerde para
la próxima vez, de forma que se generará una cookie que el navegador guardará para
no volverte a pedir autenticación en futuras conexiones.
Tiene una especificación de que el username será tu dirección de email.
Tiene una nota a la derecha diciendo...
qué servidor de autenticación se va a comprobar la password, que tiene ahí un
montón de información.
Se trata de una historia de usuario que ya refleja el resultado de muchas
conversaciones y acuerdos.
Y en el reverso, los criterios de confirmación, los criterios de
satisfacción.
En cuanto a éxito, la idea de que todo usuario válido se registrará y será
dirigido a la página adecuada una vez registrado,
Y que en caso de que esté el TIC en el cuadro de Remember Me, pues se almacenará
una cookie para que la próxima vez no se tenga que repetir el proceso y que en caso
contrario no.
En cuanto a fallos, se hace una descripción de los posibles mensajes de
fallos.
O bien porque la dirección de correo electrónico utilizado no tiene el formato
adecuado, o porque no se reconoce el nombre, o porque la password es
incorrecta, o porque el servicio está temporalmente no disponible, o bien porque
la cuenta ha expirado.
Entonces estos son los criterios de satisfacción.
Yo no creo que sea útil poner todo en una tarjeta física de esta manera.
Lo habitual es que el título
de la historia de usuario se escribe en un post-it y esté en el tablón de trabajo del
equipo de desarrollo y que haya herramientas de soporte que guarden el
registro de las conversaciones y de los criterios de satisfacción para no
concentrar la información en una pieza de papel tan pequeña que realmente haría
ilegible o poco sencillo concentrar tanta información.
Así que yo entiendo que, aunque a modo de ejemplo está bien, no creo que sea lo más
práctico.
A lo mejor es un post-it con el título y conversación y confirmación estén en
alguna herramienta de soporte al proceso.
Las historias de usuario pueden tener distinta granularidad.
Es decir, que la necesidad de los stakeholders puede plantearse con niveles
de granularidad muy grandes y muy pequeños.
Desde, por ejemplo, cajero automático.
¿Qué propósito cumple?
Obtener beneficios por intermediación financiera.
Qué grueso, ¿no?
Eso parece realmente la misión de negocio del banco en su conjunto.
O alguien puede decir, yo quiero que los movimientos me los presenten línea a línea
con la fecha a la derecha.
Vaya, pues eso parece como de granularidad muy fina, ¿no?
Probablemente, entre blanco y negro, pues habrá algún gris que sea adecuado.
De todos modos, en esta metodología de historias de usuario, suele darse nombres,
digamos, a historias de usuario con mayor o menor nivel de granularidad.
A las historias de usuario que tienen un nivel de granularidad grueso, se les suele
llamar épics, ¿vale?,
como las historias épicas.
Epics aquí es un nombre, en castellano épico solo es un adjetivo, tiene que
acompañar a otra historia, pero bueno, en inglés se usa como nombre.
Entonces una epic es una gran historia de usuario que en general, y en eso se la
distingue, abarcará meses de desarrollo cubriendo no solo muchos sprints, sino
probablemente más de una release de producto.
Está bien empezar con EPICS, pueden ser adecuadas, pero al final el equipo de
trabajo tiene que refinarlas o descomponerlas en características de menor
nivel de granularidad.
Muchas veces se encuentra un nivel intermedio de granularidad que se llaman
features, que son historias de usuario de tamaño intermedio.
Algo que en un momento dado entran enteras en una release de producto, pero
difícilmente en un único sprint.
Y finalmente están las stories, las stories básicas, que son historias de un
tamaño adecuado para implementar en un sprint, teniendo en cuenta que un sprint
muchas veces implementa más de una historia de usuario.
Así que esas son las historias de usuario propiamente dichas, las stories.
Lo que pasa es que muchas veces el proceso de elaboración comienza con epics, se
descomponen en fichas y las fichas se descomponen en historias de usuario.
Luego una cosa que también aparece muchas veces es la idea de theme, que solo es un
contenedor, un nombre, similar a los paquetes de Java, si alguien está
acostumbrado a... Lo vamos a ver en un ejemplo más adelante lo que es un theme.
Vamos a poner un ejemplo de una historia de usuario de granularidad demasiado
gruesa para implementar en un único sprint.
Bueno, alguien está desarrollando una aplicación que hace backup automático de
un PC.
Bueno, pues eso puede ser una cosa tremendamente sencilla como una copia
directa y literal de todo el disco duro a un disco externo, puede ser una cosa
sofisticada como la Time Machine de Apple o puede ser una herramienta de
administrador de sistema que hace backup incremental y que solo guarda deltas, en
fin.
y que admite muchos elementos de configuración.
Entonces, pues la historia de usuario como usuario del sistema, me gustaría poder
hacer backup del disco duro completo, pues tiene una granularidad de epic, es decir,
difícilmente cabe eso en un único sprint.
Y hay muchas historias de usuario en las que puede refinarse, ahí tengo un par de
ejemplos.
La primera, por ejemplo, como administrador de sistema o power user, me
gustaría tener un...
Modo extendido de backup en el que determino que se haga backup solo de
ficheros de determinado tamaño o con determinada fecha de creación o
modificación.
Es una característica que el usuario ordinario no tendrá, no requerirá.
no le hace falta, pero que un administrador de sistema sí, puede tener
la necesidad de decidir, voy a hacer backup de los ficheros más grandes o solo
de los ficheros creados en el último día o de los ficheros modificados en las dos
últimas horas.
Pues eso ya sí es de granularidad adecuada para un sprint.
O otra puede ser, como usuario me gustaría poder indicar en la configuración de
backup algunas carpetas que por contener información que yo considero de poca
importancia, no es necesario que se haga backup.
Normalmente porque ahí tendré cosas que no quiero que vean nadie, probablemente.
Bueno, pues ese es un ejemplo como a partir de una epic de granularidad gruesa
puede derivarse un conjunto de user stories que tienen la granularidad
adecuada.
Granularidad adecuada es que caben en un sprint.
Es el criterio básico y fundamental.
Bueno, y esos son los elementos, los de abajo, las historias de usuario, que se
introducen como item en un product backlog.
En el product.log se introducen estos ítems que son historias de usuario, se
meten las etiquetas, pero ojo que cada etiqueta luego da lugar a mucha
información de conversaciones y reglas de confirmación o satisfacción y comienza el
proceso de grooming,
Epic demasiado gruesa se descompone en stories donde dos stories se refunden en
una de mayor nivel porque se observa que tienen un nivel de granularidad muy fino
donde se evalúa y se reevalúa una estimación de esfuerzo o complejidad donde
se considera y reconsidera el valor del negocio y por tanto el nivel de prioridad
en el stack que tiene cada característica y esto es donde engancha con Scrum porque
se presta muy bien a esta metodología.
Si bien es común que en los ítems del Product Backlog haya historias de usuario,
también puede haber otras cosas.
Peticiones de cambio, defectos encontrados por los usuarios en el sistema o
actividades de adquisición de conocimiento o de resolución de riesgos técnicos.
Es decir, que aparte de historias de usuario con requisitos funcionales de
usuario final, en un product backlog puede haber, aquí Iván nos contaba el otro día
un mecanismo combinado con Kanban donde esas otras cosas iban por otra vía, pero
puede haber también peticiones de cambio,
defectos del sistema en producción o actividades de adquisición de conocimiento
y resolución de riesgos técnicos.
Es decir, no tienes ni idea si con tal tecnología podrás lograr implementar tal
cosa o no sabes si es mejor usar una base de datos SQL o no SQL y te inventas un
item de product backlog que prototipa ambas cosas para hacer un proceso de
evaluación y selección de la más adecuada en función de algún criterio.
Y a lo que iba entonces, y los requisitos no funcionales.
¿Qué hacemos con los requisitos no funcionales?
Porque las historias de usuarios son requisitos funcionales.
Bueno, en principio también podrían ponerse como user stories.
Por ejemplo...
Como usuario quiero que el sistema soporte los navegadores Firefox y Chrome de forma
que funcione para la mayoría de los ordenadores europeos.
Es un requisito no funcional de portabilidad.
En sí mismo no presenta valor de usuario final.
Si ese sistema es de ver imagenio a través de una aplicación web, el valor es ver
imagenio a través de la aplicación web.
Si es Firefox o Chrome,
O si el sistema debe funcionar tanto para Firefox o Chrome, realmente a mí me da
igual.
Es un requisito de portabilidad que no tiene un valor nítido para el usuario
final.
¿Lo puedo poner como historia de usuario?
Sí.
Sin embargo, la mayoría de los autores recomiendan otra alternativa y es
incluirlo en la definición de hecho.
Recordad que el criterio de finalización de un sprint o de una historia de usuario
implementada en un sprint
era que cumpliera con lo que el equipo había consensuado que era la definición de
hecho, con características de tipo compila, ha pasado pruebas unitarias, ha
pasado pruebas de integración, se ha puesto en beta en determinada plataforma
del cliente final, añadir ahí el cumplimiento de requisitos no funcionales.
Por ejemplo, forma parte de la definición de hecho de esta aplicación web que se ha
comprobado que funciona tanto para Chrome
¿Cómo para Firefox?
Bueno, es una alternativa.
Tenemos las dos, poner los requisitos no funcionales como historia de usuario o
bien incluirlo en la definición de hecho del equipo.
Bueno, eso está comentado ahí.
Bueno, criterios de elaboración de un buen conjunto de historias de usuario.
¿Cuándo las historias de usuarios que me he sacado de la manga son buenas,
regulares o malas?
Bueno, pues algunos autores, usando también una cosa que a los americanos les
gusta mucho, es poner una especie de metáfora como acrónimo para que nos sirva
de regla mnemotécnica, es los criterios INVEST, que son seis criterios que dicen
que tienen que cumplir un buen conjunto de historias de usuarios.
Entonces, INVEST es un acrónimo de independent o independientes, que es que
las historias de usuarios deben ser independientes, totalmente independientes
es imposible, pero que la conexión entre dos historias de usuarios sea débil, que
no estén fuertemente acopladas.
Es un criterio de bajo acoplamiento muy viejo en ingeniería del software, que
tiene 40 años.
El criterio de bajo acoplamiento entre historias de usuarios, es decir, que más o
menos sean unidades independientes.
Por otra parte,
La idea de que las historias de usuarios son negociables, son conversaciones entre
stakeholders, no una especificación contractual que alguien impone porque es
el que paga y los demás han de cumplir.
Que no debe tener ese criterio, sino que tiene que ser una oportunidad de discusión
y consenso en un equipo uniforme que persigue un fin común.
Por otra parte, que tengan valor.
es decir, deben tener valor para el usuario final o stakeholder en general,
describiendo características del sistema que resuelven problemas que uno tiene y
que merecen que uno pague por ello.
Tienen que ser cuantificables, es decir, deben contener suficientes detalles para
establecer alguna métrica de esfuerzo o coste en su desarrollo.
deben ser relativamente pequeñas, es decir, con un nivel de granularidad
pequeño, de forma que quepan en un sprint.
Se les llama muchas veces sprintables.
Y debe ser comprobable, es decir, que tiene que haber pruebas o criterios de
satisfacción que permitan determinar si finalmente conseguimos el objetivo cuando
las hemos implementado.
Así que cuando hacemos un juego de historias de usuarios nos tenemos que
plantear
como una posibilidad, no será la única, sí cumple con los criterios de Invest, ¿de
acuerdo?
Y en cuanto a cómo proceder para elaborarla, bueno, venga, vale, ya tengo
el kit de metodología de historias de usuario y Scrum, me han encargado un nuevo
sistema que tiene que hacer algo, ¿cómo empezamos?
Bueno, pues yo en la literatura he recogido un par de prácticas comunes, y
es...
Lo primero, trabajar en forma de workshop estructurados, esto también es muy viejo,
sale de metodologías de captura de requisitos de los años 70 que se llamaban
Join Application Development,
donde se trataba de crear grupos heterogéneos, multidisciplinares, que se
juntaban en plan cónclave, cerrando con llave y de allí no salía nadie hasta que
no se especificaban un conjunto de cosas y tal, y que se estructuraba la reunión con
un secretario, un facilitador, que era alguien no involucrado directamente, pero
que facilitaba la discusión entre los demás, bueno, en fin, son cosas muy
conocidas.
Entonces se trata de hacer un workshop de story mapping, de story writing, perdón,
donde en conjunto, esto funciona en grupos pequeños, yo lo he intentado hacer en
clase, que son 40, es un gallinero, no funciona, entonces esto tiene que ser en
grupos, yo diría, 10 o menos, de lo contrario no funciona.
Entonces, las personas, de forma espontánea, en grupos estructurados y
multidisciplinares, y que no vienen a la reunión con la mente en blanco, sino que
previamente han hecho unos deberes y traen propuestas concretas, tienen que proponer
una serie de roles de usuario y un conjunto de user stories candidatas.
o bien para todo el proyecto o al menos para la siguiente entrega.
De una manera estructurada se discute sobre ellas y se las clasifica en cuanto a
nivel de granularidad en epics, features o stories y así se va procediendo.
Y la segunda actividad, una vez que tengo un juego de historias de usuario
candidatas, es hacer lo que se llama story mapping, que es la descomposición en la
granularidad adecuada para las historias de usuario
y su organización y secuenciación temporal.
Tengo un par de dibujitos que vienen a aclararlo.
El story mapping viene a situar en un eje de tiempos que va de la izquierda a la
derecha todas las historias de usuario, de forma que, y como no voy a saber usar el
láser me voy a levantar a apuntar,
Yo aquí pongo epics y por debajo de cada epic pongo las historias de usuario en que
se descompone.
El criterio de valor de negocio o prioridad es de arriba a abajo y el orden
de implementación es de izquierda a derecha.
De forma que esta historia de usuario tiene mayor valor que esta historia de
usuario, aunque se van a implementar a la vez.
Y estas dos historias de usuario tienen el mismo valor de negocio, aunque yo voy a
implementar esta antes que esta.
Así que aquí las dos dimensiones son significativas.
En vertical el valor de negocio, en horizontal de izquierda a derecha el orden
de implementación.
de forma que con las historias de usuario que identifiqué en el workshop anterior y
una vez descompuestas hasta su nivel de granularidad adecuado, yo voy a conseguir
ordenarlas de forma que sé lo que tengo que implementar, con qué prioridad y en
qué orden temporal.
Aquí está muy bonito, muy cuadrado, en la realidad suele tener más bien este
aspecto, en algún tipo de tablón o papel en la pared y con post-its
pues yo pongo aquí por lo que se ve hay epics aquí esto de aquí en amarillo suelen
ser themes se agrupa este conjunto de historias de usuario bajo un nombre común
porque giran en torno a la misma funcionalidad y aquí historias de usuario
que no están puestas en un orden arbitrario sino por importancia de arriba
a abajo y por orden de implementación de izquierda a derecha si
Quisiéramos poner un ejemplo como bien hecho y con esto casi vamos a terminar.
Yo tendría algo así.
Aquí veis esto es un sistema inventado que debo haber sacado no sé de dónde para el
desarrollo de un cliente avanzado de correo electrónico que tiene la
funcionalidad de enviar y recibir correos electrónicos y también dispone de un
calendario para organizar tu agenda.
Entonces por arriba hemos encontrado cuatro EPICS.
Organizar email, gestionar email, gestionar calendario y gestionar
contactos.
Son los grandes EPICS o funcionalidades de altísimo nivel que tiene que tener la
aplicación.
En cuanto a organizar email yo he puesto aquí dos themes.
Búsqueda de correos y registro de correos.
En búsqueda de correos tenemos buscar por palabra clave,
buscar por campo, limitar la búsqueda a solo un campo, buscar por attachment o
buscar en subcarpetas.
En cuanto al registro de emails, tengo dos historias de usuario, poder mover emails
entre carpetas y poder crear subcarpetas.
En cuanto a la epic de gestionar email, tengo dos grandes themes, componer
mensajes, es decir, crear mensajes de correo y leer mensajes de correo.
En componer mensajes de correo tengo crear y enviar email básico, crear y enviar en
formato RTF, crear y enviar en formato HTML.
crear email con nivel de prioridad y así sucesivamente.
En leer tengo leer básico, leer RTF, leer HTML, en borrar tengo borrar mensaje o
borrar la carpeta de trash o de basura y así sucesivamente.
Como normalmente un proyecto tengo que ponerlo en explotación, no solo cuando
acabo, sino que hay entregas intermedias de producto que pueden ponerse en
explotación, puedo trazar líneas horizontales que representan releases.
De forma que esta es la funcionalidad que voy a entregar en la release 1 del
producto.
esta es la funcionalidad que le voy a añadir a la segunda release de producto y
esta es la funcionalidad que le voy a añadir a la tercera release de producto.
Así que si yo he tenido éxito en la aplicación de esta metodología de
descripción de requisitos funcionales de un sistema, lo tendré todo organizado de
forma que tengo claro qué valor tiene cada historia de usuario, qué prioridad o valor
de negocio tiene,
en qué orden las voy a implementar y cuáles van a ir en la release 1, en la
release 2 y en la release 3.
Esto que en un ejemplo, digamos, académico se muestra muy bien en una transparencia,
no es fácil de conseguir en la realidad.
Es decir, llegar a esa pizarra o ese tablón donde de una vez por todas esto
está tan organizado, además de que es dinámico.
que yo puedo llevarme este post-it de aquí y lo pongo aquí, y este de aquí a aquí, y
voy marcando hecho o pospuesto, es decir que esto se va moviendo, sin lugar a
dudas, es decir que esto es una cosa viva.
Y luego por otra parte, esto está muy bien para que se manejen los equipos de
trabajo, pero con frecuencia también se utilizan herramientas, herramientas donde
está la información detallada de todo esto.
pues yo tengo alguna experiencia, nosotros hemos usado con propósitos académicos una
herramienta que se llama Ice Scrum, donde permite registrar todo esto para que en
extenso las conversaciones en relación con cada historia de usuario queden
registradas y donde hay criterios de validación.
Hay herramientas como Fitness,
que a partir de un criterio de validación escrito en el lenguaje natural es capaz de
crear casos de pruebas de aceptación escritas en Java, por ejemplo.
Hay muchas herramientas que se pueden añadir a este mecanismo básico de
interacción en grupos de trabajo.
Yo creo que no tengo nada más para este somero repaso a lo que es la metodología,
solo nombraros
algo de bibliografía que tiene la gracia de que si se accede desde una dirección de
la UPM se puede acceder a un servicio gratuito que es Safari Books Online, es
decir, que no hace falta comprarse los libros, solo si se accede desde una
dirección de la UPM que es quien paga la suscripción al servicio.
Y por mi parte,
Pues creo que nada más, con esto termino y bueno, lo que os parezca oportuno debatir
o preguntar.
[Orador 2]: Mi pregunta es cómo encajan algunos mecanismos que hay de más amplio nivel
como descripción de escenarios o descripción de personas donde cuentas...
toda una historieta donde entrarían varias de estas user stories interrelacionadas
sin saber muy bien dónde acaba una, dónde empieza otra.
¿Cómo encajaría esto que se hace muchas veces para empezar a arrancar una
definición, una especificación de requisitos en Scrum?
Si se usa o si es algo completamente aparte.
[Orador 1]: No estoy seguro de entender la pregunta, Samuel.
[Orador 2]: Sí, hay metodologías como por ejemplo definición de personas donde dices, Claire
es una estudiante deportista que no sé qué, vas contando todas sus motivaciones y
cuentas como usaría el sistema Sí, una caracterización de ese rol en concreto de
ese usuario O descripciones de escenarios donde no se centra tanto en el usuario
sino que empieza a decir, pues el usuario llega por la mañana, abre la aplicación
del email, tiene muchos emails de trabajo, emails personales
empieza a responder emails, luego cambia, no entras tanto en la definición de los
requisitos concretos que serían las User Stories que aquí ya están muy
concretizadas responder email, escribir email, borrar email ¿Cómo encajarían este
tipo de artefactos que se usan a veces muy de principio de no sé cómo voy a abordar
el sistema dentro de Scrum?
¿Sería razonable empezar por ahí?
No, yo creo que no.
[Orador 1]: Yo creo que te refieres a descripciones que son más elevator pitch que otra cosa.
Normalmente es cuando se quiere vender una moto, ¿no?
Se pone el escenario de alguien que en un uso cotidiano de la vida, pues algo de
tipo futurista, ¿no?
Y fulano llega al hotel y le gustaría tener los mismos canales de su proveedor
de televisión de pago que tiene en casa.
Y entonces, con solo identificarse por voz ante la tele, dirá.
Y entonces se presenta un escenario atractivo y para vender una moto, no.
No, eso es un vendemotos, no tiene que ver con una metodología de captura de
requisitos funcionales para un sistema.
Bueno, un vendemotos, no quiero ser despectivo, pero es un elevator pitch para
llamar la atención a alguien sobre las bondades de lo que quieres venderle.
No, no tienen relación, casi relación.
¿Alguna otra cuestión?
[Orador 3]: Sí, yo quería preguntar, si vamos dos transparencias atrás, que va a ser más
fácil preguntarlo, justo la representación de las historias de usuario con respecto
al tiempo y al valor de negocio.
Aquí pintamos las release, pero claro, en teoría el eje horizontal es tiempo,
entonces no sé encajar, porque al final las tres release las tienes...
en el mismo tiempo, al finalizar.
[Orador 1]: Bueno, no, claro, no está bien representado.
Iríamos en zigzag.
Cogen la banda de la raíz 1, la implementas, entregas, vuelves a la
izquierda.
Sí, en dos dimensiones no es... He visto hace poco la película Interestelar.
No sé si la habéis visto alguno.
Yéndome a la quinta dimensión hubiera podido quizás representarlo, pero no...
Bueno, veo que no muchos de vosotros lo habéis visto, es que va de dimensiones y
viajes en el espacio que sales diciendo no sé en qué dimensión estoy.
¿Alguna pregunta más?
¿Os ha quedado todo claro?
Bueno, pues si no tenéis más preguntas, lo dejamos aquí.
Muchas gracias a todos.