User Stories Applied Mike Cohn 3.en - Es

138 W SOMBRERO S TORIES UNA RE norte Antiguo Testamento
Título del caso de uso: Pagar por un puesto de trabajo
Actor principal: Reclutador

Nivel: Objetivo del actor
Condición previa: La información del trabajo ha sido ingresada pero no se puede ver.
Garantías mínimas: Ninguna

Garantías de éxito: El trabajo se publica; Se cobra la tarjeta de crédito del reclutador.
Escenario principal de éxito:
1. El reclutador envía el número de tarjeta de crédito, la fecha y la información de autenticación.
2) El sistema valida la tarjeta de crédito.
3) El sistema cobra el monto total de la tarjeta de crédito.
4) La publicación de empleos se hace visible para los solicitantes de empleo.
5. El reclutador recibe un número de confirmación único.

Extensiones:
2a: La tarjeta no es de un tipo aceptado por el sistema:

2a1: el sistema notifica al usuario que use una tarjeta diferente. 2b: la tarjeta ha
caducado:
2b1: el sistema notifica al usuario que use una tarjeta diferente. 2c: la tarjeta ha
caducado:
2c1: el sistema notifica al usuario que use una tarjeta diferente. 3a: La tarjeta no
tiene suficiente crédito disponible para publicar el anuncio.
3a1: El sistema carga lo más que puede a la tarjeta de crédito actual.
3a2: se informa al usuario sobre el problema y se le solicita que ingrese una segunda
tarjeta de crédito para el cargo restante. El caso de uso continúa en el Paso 2.
Figura 12.1 Un ejemplo de caso de uso para el pago de un puesto de trabajo.
responde al escenario de éxito principal del caso de uso, y que las pruebas de la historia corresponden a las
extensiones del caso de uso.
Por ejemplo, en el Capítulo 6, "Historias de usuarios de pruebas de aceptación", vimos que los casos de prueba de
aceptación apropiados para la historia "Un reclutador puede pagar por un puesto de trabajo con una tarjeta de crédito" podría
ser:
• Prueba con Visa, MasterCard y American Express (pase).
• Prueba con Diner's Club (falla).
• Pruebe con números de identificación de tarjeta buenos, malos y faltantes.
De la biblioteca de www.wowebook.com
U SER S TORIES UNA RE norte Antiguo Testamento U SE C ASES 139
• Prueba con tarjetas caducadas.
• Pruebe con diferentes cantidades de compra (incluida una por encima del límite de la tarjeta). Al observar
estas pruebas de aceptación, podemos ver la correlación entre ellas y las extensiones de la Figura 12.1.
Otra diferencia importante entre casos de uso e historias es su longevidad. Los casos de uso a menudo
son artefactos permanentes que continúan existiendo mientras el producto se encuentre en desarrollo o
mantenimiento activo. Las historias, por otro lado, no tienen la intención de sobrevivir a la iteración en la
que se agregan al software. Si bien es posible archivar tarjetas de historia, muchos equipos simplemente
las destruyen.
Una diferencia adicional es que los casos de uso son más propensos a incluir detalles de la interfaz de usuario, a
pesar de las advertencias para evitar esto (Cockburn 2001; Adolph, Bramble, et al. 2002). Hay varias razones por las que
esto sucede. Primero, los casos de uso a menudo conducen a un gran volumen de papel y sin otro lugar adecuado para
poner los requisitos de la interfaz de usuario terminan en los casos de uso. En segundo lugar, los redactores de casos de
uso se centran demasiado pronto en la implementación del software más que en los objetivos comerciales.
La inclusión de detalles de la interfaz de usuario causa problemas definidos, especialmente al principio de un nuevo
proyecto, cuando el diseño de la interfaz de usuario no debería ser más difícil por preconceptos. Recientemente me
encontré con el caso de uso que se muestra en la Figura 12.2, que describe los pasos para componer y enviar un mensaje
de correo electrónico.
Título del caso de uso: Redactar y enviar un mensaje de correo electrónico.
Escenario principal de éxito:
1. El usuario selecciona el elemento del menú "Nuevo mensaje".
2) El sistema presenta al usuario el cuadro de diálogo "Redactar mensaje nuevo".

3. El usuario edita el cuerpo del correo electrónico, el campo del asunto y las líneas del destinatario.
4. El usuario hace clic en el botón Enviar.
5) El sistema envía el mensaje.
Figura 12.2 Un caso de uso para componer y enviar un mensaje de correo electrónico.
Este caso de uso tiene supuestos de interfaz de usuario en todo momento. Se supone que hay un elemento de
menú "Mensaje nuevo", que hay un cuadro de diálogo para redactar mensajes nuevos, que hay campos de entrada de
asunto y destinatario en ese cuadro de diálogo y que hay un botón Enviar. Muchos de estos supuestos pueden parecer
buenos y seguros, pero pueden descartar una interfaz de usuario donde hago clic en el nombre del destinatario para
iniciar
tiate el mensaje en lugar de escribirlo. Además, el caso de uso de la Figura 12.2 impide el uso del
reconocimiento de voz como la interfaz del sistema.
Es cierto que hay muchos más clientes de correo electrónico que trabajan con mensajes escritos que con
reconocimiento de voz, pero el caso es que un caso de uso no es el lugar adecuado para especificar la interfaz de
usuario como esta. Piense en la historia del usuario que reemplazaría a la Figura 12.2: "Un usuario puede redactar y
enviar mensajes de correo electrónico". No hay suposiciones de interfaz de usuario ocultas allí. Con las historias, la
interfaz de usuario aparecerá durante la conversación con el cliente.
Para solucionar el problema de los supuestos de la interfaz de usuario en los casos de uso, Constantine y
Lockwood (1999) han sugerido el uso de casos de uso esenciales. Un caso de uso esencial es un caso de uso que
ha sido despojado de supuestos ocultos sobre tecnología y detalles de implementación. Por ejemplo, la Tabla 12.1
muestra un caso de uso esencial para componer y enviar un mensaje de correo electrónico. Lo interesante de los
casos de uso esenciales es que las intenciones de los usuarios podrían interpretarse directamente como historias
de usuarios.
Otra diferencia es que los casos de uso y las historias se escriben para diferentes propósitos (Davies 2001).
Los casos de uso están escritos en un formato aceptable tanto para clientes como para desarrolladores para que
cada uno pueda leerlos y aceptarlos. Su propósito es documentar un acuerdo entre el cliente y el equipo de
desarrollo. Las historias, por otro lado, están escritas para facilitar la planificación de lanzamiento e iteración, y
para servir como marcadores de posición para conversaciones sobre las necesidades detalladas de los usuarios.
Tabla 12.1 Un caso de uso esencial.
Intención del usuario Responsabilidad del sistema
Redactar mensaje de correo
electrónico Indicar destinatario (s)
Recopilar contenido de correo electrónico y destinatario (s)
Enviar mensaje de correo electrónico
Enviar el mensaje
No todos los casos de uso se escriben rellenando un formulario, como se muestra en la Figura 12.1. Algunos casos de uso se
escriben como texto no bloqueado. Cockburn se refiere a estos como calzoncillos de casos de uso. Los informes de casos de uso
difieren de las historias de los usuarios de dos maneras. Primero, dado que un resumen de caso de uso debe cubrir el mismo alcance
que un caso de uso, el alcance de un resumen de caso de uso suele ser mayor que el alcance de una historia de usuario. Es decir, un
resumen de caso de uso generalmente contará más de una historia. En segundo lugar, los informes de casos de uso están destinados
a vivir durante la vida útil de un producto. Las historias de usuarios, por otro lado, se eliminan.
U SER S TORIES UNA REN ' T S CENARIOS 141
Finalmente, los casos de uso generalmente se escriben como resultado de una actividad de análisis, mientras que las historias de
los usuarios se escriben como notas que se pueden usar para iniciar conversaciones de análisis.
Las historias de usuarios no son escenarios
Además de referirse a una única ruta a través de un caso de uso, la palabra guión También es utilizado por los
diseñadores de interacción humano-computadora. En este contexto, un escenario es una descripción detallada de la
interacción de un usuario con una computadora. Los escenarios de diseño de interacción no son los mismos que los
de un caso de uso. De hecho, un escenario de diseño de interacción suele ser más grande o más abarcador que
incluso un caso de uso. Por ejemplo, considere este escenario:
Maria está pensando en hacer un cambio de carrera. Desde los días de gloria del boom de las
puntocom, ha trabajado como probador en BigTechCo. María, una ex maestra de matemáticas
de secundaria, decide que será más feliz si regresa a la enseñanza. Maria va al sitio web
BigMoneyJobs.com. Ella crea una nueva cuenta con un nombre de usuario y contraseña.
Luego crea su currículum. Ella quiere encontrar un trabajo como maestra de matemáticas en
cualquier lugar de Idaho, pero preferiblemente cerca de su trabajo actual en Coeur d'Alene.
María encuentra un puñado de trabajos que coinciden con sus criterios de búsqueda. El
trabajo que más la intriga es con North Shore School, una escuela secundaria privada en
Boise. María tiene una amiga, Jessica, en Boise, a quien espera que conozca a alguien en
North Shore. Maria ingresa la dirección de correo electrónico de Jessica y le reenvía el enlace
del trabajo con una nota preguntando si conoce a alguien en la escuela. A la mañana
siguiente, María recibe un correo electrónico de Jessica diciendo que no conoce a nadie en la
escuela, pero que sabe de la Escuela North Shore y que tiene una reputación maravillosa.
Maria hace clic en un botón que envía su currículum a North Shore.
Carroll (2000) dice que los escenarios incluyen los siguientes elementos característicos:
• un ajuste
• actores
• metas u objetivos
• acciones y eventos
El escenario es el lugar donde tiene lugar la historia. En la historia sobre María, la historia
probablemente tiene lugar en la computadora de su casa; pero como eso no se dice, la ubicación de la
historia podría ser su oficina durante la jornada laboral.
Cada escenario incluye al menos un actor. Es posible que un escenario tenga múltiples actores. Por ejemplo,
en nuestro escenario, tanto María como Jessica son actores. María puede ser referida como la actor principal porque
el escenario describe principalmente sus interacciones con el sistema. Sin embargo, debido a que Jessica recibe
un correo electrónico del sistema y luego usa el sitio web para ver el anuncio de trabajo, se la considera una actor
secundario A diferencia de los casos de uso, los actores en escenarios de diseño de interacción son siempre
personas y nunca otros sistemas.
Cada actor en un escenario persigue uno o más objetivos. Al igual que con los actores, puede haber
objetivos primarios y secundarios. Por ejemplo, el objetivo principal de María es encontrar un trabajo
apropiado en su ubicación deseada. Mientras trabaja para lograr ese objetivo, persigue objetivos secundarios
como ver información detallada sobre un hotel o compartir información con un amigo.
Carroll se refiere a las acciones y eventos como el trama de un escenario. Son los pasos que toma un actor
para lograr su objetivo o la respuesta de un sistema. Buscar un trabajo en Idaho es una acción que realiza
María. La respuesta a esa acción es el evento del sistema que muestra una lista de trabajos coincidentes.
Las principales diferencias entre las historias de usuarios y los escenarios son el alcance y los detalles. Los
escenarios contienen muchos más detalles y su alcance generalmente cubre múltiples historias. El escenario de
ejemplo contiene muchas historias posibles, como:
• un usuario puede enviar información sobre un trabajo a un amigo por correo electrónico
• un usuario puede crear un currículum
• un usuario puede enviar su currículum para un trabajo coincidente
• un usuario puede buscar trabajo por región geográfica
Incluso con sus detalles adicionales, los escenarios (como las historias) dejan detalles para trabajar en
una discusión. Por ejemplo:
• Maria inició sesión en el sitio con un nombre de usuario y contraseña. ¿Todos los usuarios deben iniciar sesión
en el sitio? ¿O el inicio de sesión habilita algunas de las funciones que usó María (tal vez la función para enviar
un correo electrónico)?
• Cuando Jessica recibe el correo electrónico, ¿el correo electrónico contiene información sobre el trabajo o
simplemente se vincula a una página en el sitio con esa información?
Q UESCIONES 143
Resumen
• Las historias de usuario son diferentes de las especificaciones de requisitos de software IEEE 830, casos de uso y
escenarios de diseño de interacción.
• No importa cuánto pensemos, pensemos y pensemos, no podemos especificar completa y

perfectamente un sistema no trivial por adelantado.
• Hay un valioso bucle de retroalimentación que ocurre entre la definición de los requisitos y los usuarios
que tienen acceso temprano y frecuente al software.
• Es más importante pensar en los objetivos de los usuarios que enumerar los atributos de una solución.
• Las historias de usuario son similares a un escenario de caso de uso. Pero los casos de uso aún tienden a ser más
grandes que una sola historia y pueden ser más propensos a contener suposiciones incrustadas sobre la interfaz de
usuario.
• Además, las historias de los usuarios difieren de los casos de uso en su integridad y longevidad. Los casos
de uso son mucho más completos que las historias de usuarios. Los casos de uso están diseñados para ser
artefactos permanentes del proceso de desarrollo; las historias de usuarios son más transitorias y no
pretenden sobrevivir a la iteración en la que se desarrollan.
• Las historias de usuarios y los casos de uso están escritos para diferentes propósitos. Los casos de uso están escritos para
que los desarrolladores y los clientes puedan discutirlos y aceptarlos. Las historias de los usuarios se escriben para facilitar la
planificación del lanzamiento y para servir como recordatorios para completar los detalles de los requisitos con las
conversaciones.
• A diferencia de las especificaciones IEEE 830 y los casos de uso, las historias de usuarios no son artefactos de las actividades de
análisis. Más bien, las historias de usuarios son una herramienta de apoyo para el análisis.
• Los escenarios de diseño de interacción son mucho más detallados que las historias de los usuarios y difieren en el tipo de
detalle proporcionado.
• Un escenario típico de diseño de interacción es mucho más grande que una historia de usuario. Un escenario puede
comprender múltiples casos de uso, que, a su vez, pueden comprender muchas historias de usuarios.
Preguntas
12.1 ¿Cuáles son las diferencias clave entre historias de usuarios y casos de uso?
12.2 ¿Cuáles son las diferencias clave entre las historias de usuarios y las declaraciones de requisitos de
IEEE 830?
12.3 ¿Cuáles son las diferencias clave entre historias de usuarios y escenarios de diseño de interacción?
12.4 Para un proyecto no trivial, ¿por qué es imposible escribir todos los requisitos al
comienzo del proyecto?
12.5 ¿Cuál es la ventaja de pensar en los objetivos de los usuarios en lugar de enumerar los atributos del
software que se va a construir?
Capítulo 13
¿Por qué historias de usuarios?
Con todos los métodos disponibles para considerar los requisitos, ¿por qué deberíamos elegir historias de
usuarios? Este capítulo analiza las siguientes ventajas de las historias de usuarios sobre enfoques alternativos:
• Las historias de usuarios enfatizan la comunicación verbal.
• Las historias de usuario son comprensibles para todos.
• Las historias de usuarios son del tamaño adecuado para la planificación.
• Las historias de usuario funcionan para el desarrollo iterativo.
• Las historias de usuarios fomentan el aplazamiento de los detalles.
• Las historias de usuario respaldan el diseño oportunista.
• Las historias de usuarios fomentan el diseño participativo.
• Las historias de usuarios acumulan conocimiento tácito.
Después de haber considerado las ventajas de las historias de usuarios sobre los enfoques alternativos, el
capítulo concluye señalando algunos inconvenientes potenciales para las historias de usuarios.
Comunicación verbal
Los humanos solían tener una tradición oral tan maravillosa; Los mitos y la historia se transmitieron oralmente de
una generación a la siguiente. Hasta que un gobernante ateniense comenzó a escribir Homero La Ilíada para que no
se olvide, se contaron historias como las de Homero, no se leyeron. Nuestros recuerdos deben haber sido mucho
mejores en ese entonces y deben haber comenzado a desvanecerse en algún momento de la década de 1970
porque para entonces ya no podíamos recordar ni siquiera declaraciones breves como "El sistema le pedirá al
usuario un nombre de usuario y contraseña". Entonces, comenzamos a escribirlos.
145
146 W HY U SER S TORIES?
Y ahí es donde empezamos a salir mal. Cambiamos el enfoque a un documento compartido y lejos de
un entendimiento compartido.
Parece tan fácil pensar que si todo está escrito y acordado, entonces no puede haber desacuerdos, los
desarrolladores sabrán exactamente qué construir, los evaluadores sabrán exactamente cómo probarlo y,
lo más importante, los clientes obtendrán exactamente lo que desean. querido. Bueno, no, eso está mal:
los clientes obtendrán la interpretación de los desarrolladores de lo que fue escrito, que puede no ser
exactamente lo que ellos querido.
Hasta que lo intente, parecería bastante simple escribir un montón de requisitos de software y hacer que un
equipo de desarrolladores construya exactamente lo que desea. Sin embargo, si tenemos problemas para
escribir un menú de almuerzo con suficiente precisión, piense lo difícil que debe ser escribir los requisitos del
software. En el almuerzo del otro día, mi menú decía:
El plato principal viene con una opción de sopa o ensalada y pan.
Esa no debería haber sido una oración difícil de entender, pero lo fue. ¿Cuál de estos significaba que
podía elegir?
Sopa o (Ensalada y Pan) (Sopa o

Ensalada) y Pan
A menudo actuamos como si las palabras escritas fueran precisas, pero no lo son. Contrasta las
palabras escritas en ese menú con las palabras habladas de la camarera: "¿Quieres sopa o ensalada?" Aún
mejor, eliminó toda ambigüedad colocando una cesta de pan sobre la mesa antes de tomar mi pedido.
Igual de malo es que las palabras pueden tener múltiples significados. Como un ejemplo extremo,
considere estas dos oraciones:
Buffalo Buffalo Buffalo. Buffalo Buffalo

Buffalo Buffalo.
Guau. ¿Qué pueden significar esas oraciones? Búfalo puede significar ya sea el gran animal peludo (también
conocido como un bisonte) o una ciudad en Nueva York, o puede significar "intimidar", como en "Los desarrolladores
se comprometieron a prometer una fecha de entrega más temprana". Entonces, las primeras oraciones significan
que el bisonte intimida a otro bisonte. La segunda oración significa que los bisontes intimidan a los bisontes de la
ciudad de Buffalo.
A menos que estemos escribiendo software para bison, este es un ejemplo poco probable; pero es
realmente mucho peor que esta típica declaración de requisitos:
• El sistema debe mostrar de manera prominente un mensaje de advertencia cada vez que el usuario ingresa datos no
válidos.
V ERBAL C OMUNICACIÓN 147
Hace debería significa que el requisito puede ser ignorado si queremos? yo debería comer tres porciones
de vegetales al día; Yo no. Que hace exhibir prominentemente
¿media? Lo que es prominente para quien escribió esto puede no serlo para quien lo codifica y prueba.
Como otro ejemplo, recientemente me encontré con este requisito que se refería a la capacidad de un usuario
para nombrar una carpeta en un sistema de gestión de datos:
• El usuario puede ingresar un nombre. Puede tener 127 caracteres.
De esta declaración no está claro si el usuario debe ingresar un nombre para la carpeta. Quizás se
proporcione un nombre predeterminado para la carpeta. La segunda oración es casi completamente sin sentido.
¿Puede el nombre de la carpeta tener otra longitud o debe tener siempre 127 caracteres?
Escribir cosas tiene ventajas: las palabras escritas ayudan a superar las limitaciones de la memoria a
corto plazo, las distracciones y las interrupciones. Pero, muchas fuentes de confusión, ya sea por la
imprecisión de las palabras escritas o de las palabras con múltiples significados, desaparecen si
cambiamos el enfoque de los requisitos de escritura a hablar de ellos.
Naturalmente, algunos de los problemas de nuestro lenguaje existen tanto con la comunicación verbal
como escrita; pero cuando los clientes, desarrolladores y usuarios hablan, existe la oportunidad de un
breve ciclo de retroalimentación que conduce al aprendizaje y comprensión mutuos. Con las
conversaciones no existe la falsa apariencia de precisión y exactitud que existe con las palabras escritas.
Nadie cierra una conversación y nadie la señala y dice: "Ahí mismo, hace tres meses, un martes, dijiste que
las contraseñas no podían contener números".
Nuestro objetivo con las historias de usuarios no es documentar hasta el último detalle sobre una
característica deseada; más bien, es escribir unas pocas oraciones cortas que recuerden a los desarrolladores
y a los clientes que mantengan conversaciones futuras. Muchas de mis conversaciones ocurren por correo
electrónico y no podría hacer mi trabajo sin él. Envío y recibo cientos de correos electrónicos todos los días.
Pero, cuando necesito hablar con alguien sobre algo complicado, siempre cojo el teléfono o camino a la
oficina o al espacio de trabajo de la persona.
Una conferencia reciente sobre ingeniería de requisitos tradicionales incluyó un tutorial de medio día
sobre cómo escribir "requisitos perfectos" y prometió enseñar técnicas para escribir mejores oraciones para
lograr requisitos perfectos. Escritura Perfecto los requisitos parecen un objetivo tan elevado e inalcanzable.
E incluso si cada oración en un documento de requisitos es perfecta, todavía hay dos problemas. Primero, los
usuarios refinarán sus opiniones a medida que aprendan más sobre el software que se está desarrollando. En
segundo lugar, no hay garantía de que la suma de estas partes perfectas sea un todo perfecto. Tom Poppendieck
me ha recordado que 100 zapatos perfectos a la izquierda no producen un solo par de zapatos perfectos. Un
lejano
objetivo más valioso que los requisitos perfectos es aumentar historias adecuadas
con Conversaciones frecuentes.
Las historias de los usuarios son comprensibles
Una de las ventajas que los casos de uso y los escenarios nos brindan sobre las especificaciones de requisitos de software
de estilo IEEE 830 es que son comprensibles tanto para los usuarios como para los desarrolladores. Los documentos de
estilo IEEE 830 a menudo contienen demasiada jerga técnica para que los usuarios puedan leerla y demasiada jerga
específica de dominio para que los desarrolladores puedan leerla.
Las historias van más allá y son aún más comprensibles que los casos o escenarios de uso. Constantine y
Lockwood (1999) han observado que los escenarios de énfasis en el realismo y los detalles pueden hacer que los
escenarios oscurezcan problemas más amplios. Esto hace que sea más difícil, cuando se trabaja con escenarios,
comprender la naturaleza básica de las interacciones. Debido a que las historias son breves y siempre se escriben
para mostrar el valor del cliente o del usuario, las personas de negocios y los desarrolladores siempre pueden
comprenderlos fácilmente.
Además, un estudio a fines de la década de 1970 descubrió que las personas son más capaces de
recordar eventos si se organizan en historias (Bower, Black y Turner
1979). Aún mejor, los participantes del estudio recordaron mejor tanto las acciones declaradas como las acciones inferidas.
Es decir, las historias no solo facilitan el recuerdo de las acciones declaradas, sino que también facilitan el recuerdo de las
acciones no declaradas. Las historias que escribimos pueden ser más concisas que las especificaciones de requisitos
tradicionales o incluso casos de uso, y debido a que están escritas y discutidas como historias, el recuerdo será mayor.
Las historias de los usuarios son del tamaño adecuado para la planificación
Además, las historias de los usuarios son del tamaño adecuado para la planificación: no demasiado grandes, ni
demasiado pequeñas, sino perfectas. En algún momento de la carrera de la mayoría de los desarrolladores, ha
sido necesario pedirle a un cliente o usuario que priorice los requisitos de estilo IEEE 830. El resultado habitual
es que el 90% de los requisitos son obligatorios, el 5% son muy deseables pero pueden diferirse brevemente y
otro 5% puede diferirse un poco más. Esto se debe a que es difícil priorizar y trabajar con miles de oraciones,
todas comenzando con "El sistema debe ..." Por ejemplo, considere los siguientes requisitos de muestra:
U SER S TORIES W ORK PARA yo TERATIVA re EVELOPMENTO 149
4.6) El sistema permitirá reservar una habitación con tarjeta de crédito.
4.6.1) El sistema aceptará tarjetas Visa, MasterCard y American Express.
4.6.1.1) El sistema deberá verificar que la tarjeta no haya expirado.
4.6.2) El sistema cargará a la tarjeta de crédito la tasa indicada para todas las
noches de la estadía antes de que se confirme la reserva.
4.7) El sistema le dará al usuario un número de confirmación único.
Cada nivel de anidamiento dentro de una especificación de requisitos IEEE 830 indica una relación
entre las declaraciones de requisitos. En el ejemplo anterior, no es realista pensar que un cliente podría
priorizar 4.6.1.1 por separado de
4.6.1. Si los elementos no pueden priorizarse o desarrollarse por separado, tal vez no deberían escribirse como
elementos separados. Si solo se escriben por separado para que cada uno pueda probarse discretamente, sería
mejor simplemente escribir los exámenes directamente.
Cuando considera las miles o decenas de miles de declaraciones en una especificación de requisitos
de software (y las relaciones entre ellas) para un producto típico, es fácil ver la dificultad inherente en
priorizarlas.
Los casos de uso y los escenarios de diseño de interacción sufren el problema opuesto: son demasiado grandes.
Priorizar algunas docenas de casos de uso o escenarios a veces es fácil, pero los resultados a menudo no son útiles
porque rara vez se da el caso de que todos los elementos de alta prioridad sean más importantes que todos los
elementos de segunda prioridad. Muchos proyectos han intentado corregir esto escribiendo muchos casos de uso
más pequeños con el resultado de que se balancean demasiado en esa dirección.
Las historias, por otro lado, son de un tamaño manejable, de modo que pueden ser utilizadas
convenientemente para planificar lanzamientos, y por desarrolladores para programación y pruebas.
Las historias de usuarios funcionan para el desarrollo iterativo
Las historias de usuarios también tienen la gran ventaja de que son compatibles con el desarrollo iterativo.
No necesito escribir todas mis historias antes de comenzar a codificar la primera. Puedo escribir algunas
historias, codificar y probar esas historias, y luego repetirlas tantas veces como sea necesario. Al escribir
historias, puedo escribirlas con el nivel de detalle apropiado. Las historias funcionan bien para el desarrollo
iterativo debido a lo fácil que es iterar sobre las historias mismas.
Por ejemplo, si estoy empezando a pensar en un proyecto, puedo escribir historias épicas como "el usuario puede
componer y enviar correos electrónicos". Eso puede ser justo para una planificación muy temprana. Más tarde dividiré
esa historia en quizás una docena de otras historias:
• Un usuario puede redactar un mensaje de correo electrónico.
• Un usuario puede incluir gráficos en mensajes de correo electrónico.
• Un usuario puede enviar mensajes de correo electrónico.
• Un usuario puede programar que se envíe un correo electrónico a una hora específica. Los
escenarios y los documentos IEEE 830 no se prestan a este tipo de niveles progresivos de detalle. Por la
forma en que están escritos, los documentos IEEE 830 implican que si no hay una declaración que diga
"El sistema ...", se supone que el sistema no lo hará. Esto hace imposible saber si falta un requisito o si
simplemente no se ha escrito todavía.
El poder de los escenarios está en sus detalles. Por lo tanto, la idea de comenzar un escenario sin detalles y
luego agregar progresivamente detalles según lo necesiten los desarrolladores no tiene sentido y despojaría
completamente a los escenarios de su utilidad.
Los casos de uso se pueden escribir en diferentes niveles progresivos de detalle, y Cockburn (2001) ha
sugerido excelentes formas de hacerlo. Sin embargo, en lugar de escribir casos de uso con texto de forma libre, la
mayoría de las organizaciones definen una plantilla estándar. Luego, la organización exige que todos los casos de
uso se ajusten a la plantilla. Esto se convierte en un problema cuando muchas personas se sienten obligadas a
completar cada espacio en un formulario. Fowler (1997) se refiere a esto como Completismo En la práctica, pocas
organizaciones pueden escribir algunos casos de uso a nivel de resumen y otros a nivel detallado. Las historias de
usuario funcionan bien para los completistas porque, hasta ahora, nadie ha propuesto una plantilla de campos para
cada historia.
Las historias fomentan los detalles diferidos
Las historias también tienen la ventaja de que alientan al equipo a diferir la recopilación de detalles. Se
puede escribir una historia inicial a nivel de meta ("Un reclutador puede publicar una nueva oferta de
trabajo") y luego reemplazarla con más detalles una vez que sea importante tener los detalles.
Esto hace que las historias de los usuarios sean perfectas para proyectos con limitaciones de tiempo. Un equipo
puede escribir rápidamente algunas docenas de historias para darles una idea general del sistema. Luego pueden
sumergirse en los detalles de algunas de las historias y pueden codificar mucho antes que un equipo que se siente
obligado a completar una especificación de requisitos de software de estilo IEEE 830.
S TORIES S UPPORT O PPORTUNISTA re EVELOPMENTO 151
Las historias apoyan el desarrollo oportunista
Es tentador creer que podemos escribir todos los requisitos para un sistema y luego pensar en una
solución de arriba hacia abajo. Hace casi dos décadas, Parnas y Clements (1986) nos dijeron que nunca
veremos un proyecto que funcione de esta manera, porque:
• Los usuarios y clientes generalmente no saben exactamente lo que quieren.
• Incluso si los desarrolladores de software conocen todos los requisitos, muchos de los detalles que necesitan
para desarrollar el software se vuelven claros solo a medida que desarrollan el sistema.
• Incluso si todos los detalles pudieran conocerse por adelantado, los humanos son incapaces de
comprender tantos detalles.
• Incluso si pudiéramos entender todos los detalles, se producen cambios en los productos y proyectos.
• La gente comete errores.
Si no podemos construir software de una manera estrictamente vertical, ¿cómo lo hacemos? Guindon
(1990) estudió cómo los desarrolladores de software piensan sobre los problemas. Presentó a un pequeño
conjunto de desarrolladores de software un problema al diseñar un sistema de control de ascensor para un
edificio. Luego grabó en video y observó a los desarrolladores mientras trabajaban en el problema. Lo que
descubrió fue que los desarrolladores no siguieron un enfoque de arriba hacia abajo en absoluto. Por el
contrario, los desarrolladores siguieron un oportunista enfoque en el que se movían libremente entre considerar
los requisitos para inventar y discutir escenarios de uso, hasta diseñar en varios niveles de abstracción. A
medida que los desarrolladores percibieron las oportunidades de beneficiarse al cambiar su forma de pensar,
lo hicieron rápidamente.
Las historias reconocen y superan los problemas planteados por Parnas y Clements. A través de su gran
dependencia de la conversación y su capacidad de ser fácilmente escritos y reescritos en diferentes niveles de
detalle, las historias proporcionan una solución:
• que no depende de que los usuarios conozcan y comuniquen sus necesidades exactas por adelantado
• eso no depende de que los desarrolladores puedan comprender completamente una amplia gama de detalles
• que abraza el cambio
En este sentido, las historias reconocen que el software debe desarrollarse de manera oportunista. Dado que no
puede haber un proceso que se desarrolle en una ruta estrictamente lineal desde los requisitos de alto nivel hasta el
código, las historias de los usuarios permiten fácilmente que un equipo cambie entre los niveles de pensamiento y de nivel
alto y bajo de los requisitos.
Las historias de los usuarios fomentan el diseño participativo
Las historias, como los escenarios, son interesantes. Cambiar el enfoque de hablar sobre los atributos de un sistema a
historias sobre los objetivos de los usuarios para usar el sistema conduce a discusiones más interesantes sobre el
sistema. Muchos proyectos han fallado debido a la falta de participación de los usuarios; Las historias son una manera
fácil de involucrar a los usuarios como participantes en el diseño de su software.
En diseño participativo ( Kuhn y Muller 1993; Schuler y Namioka 1993) los usuarios de un sistema se
convierten en parte del equipo que diseña el comportamiento de su software. No se convierten en parte del
equipo a través del edicto de gestión ("Formarás un equipo multifuncional e incluirán a los usuarios"); más
bien, los usuarios se convierten en parte del equipo porque están muy comprometidos con los requisitos y las
técnicas de diseño en uso. En el diseño participativo, por ejemplo, los usuarios ayudan en la creación de
prototipos de la interfaz de usuario desde el principio. No están involucrados solo después de que un prototipo
inicial esté disponible para su visualización.
En contraste con el diseño participativo es diseño empírico, en el que los diseñadores de nuevo software
toman decisiones al estudiar a los posibles usuarios y las situaciones en las que se utilizará el software. El
diseño empírico depende en gran medida de la entrevista y la observación, pero los usuarios no se convierten
en verdaderos participantes en el diseño del software.
Debido a que las historias y escenarios de los usuarios carecen por completo de jerga técnica, son
totalmente comprensibles para los usuarios y clientes. Si bien los casos de uso bien escritos pueden evitar la
jerga técnica, los lectores de casos de uso generalmente deben aprender a interpretar el formato de los casos de
uso. Muy pocos lectores nuevos de un caso de uso tienen una comprensión implícita de los campos comunes en
los formularios de casos de uso, como extensiones, precondiciones y garantías. Los documentos IEEE 830
típicos adolecen tanto de la inclusión de jerga técnica como de la dificultad inherente de comprender un
documento extenso y jerárquicamente organizado.
La mayor accesibilidad de historias y escenarios alienta a los usuarios a participar en el diseño del software.
Además, a medida que los usuarios aprenden a caracterizar sus necesidades en historias que son directamente
útiles para los desarrolladores, los desarrolladores involucran más activamente a los usuarios. Este ciclo virtuoso
beneficia a todos los involucrados en el desarrollo o uso del software.
W HY norte Antiguo Testamento S TORIES? 153
Historias acumulan conocimiento tácito
Debido al énfasis puesto en la comunicación cara a cara, las historias promueven la acumulación de
conocimiento tácito en todo el equipo. Cuanto más a menudo los desarrolladores y los clientes hablan entre
ellos y entre ellos, más conocimiento se acumula dentro del equipo.
¿Por qué no historias?
Habiendo examinado una serie de razones por las cuales las historias son un enfoque preferido para los requisitos ágiles,
consideremos también sus inconvenientes.
Un problema con las historias de usuarios es que, en un proyecto grande con muchas historias, puede ser difícil
entender las relaciones entre las historias. Este problema puede reducirse mediante el uso de roles y manteniendo las
historias en un nivel moderado a alto hasta que el equipo esté listo para comenzar a desarrollar las historias. Los
casos de uso tienen una jerarquía inherente que ayuda cuando se trabaja con una gran cantidad de requisitos. Un
caso de uso único, a través de su escenario de éxito principal y sus extensiones, puede recopilar el equivalente de
muchas historias de usuarios en una sola entidad.
Un segundo problema con las historias de usuarios es que es posible que deba aumentarlas con
documentación adicional si su proceso de desarrollo exige la trazabilidad de los requisitos. Afortunadamente,
esto generalmente se puede hacer de una manera muy ligera. Por ejemplo, en un proyecto en el que
realizamos un desarrollo subcontratado a una empresa mucho más grande con certificación ISO 9001, se nos
exigió que demostráramos la trazabilidad desde los requisitos hasta las pruebas. Logramos esto de una manera
muy ligera: al comienzo de cada iteración produjimos un documento que contenía cada historia que planeamos
hacer en la iteración. A medida que se desarrollaron las pruebas, los nombres de las pruebas se agregaron al
documento. Durante la iteración, mantuvimos el documento actualizado agregando o eliminando historias que
entraban o salían de la iteración. Esta adición a nuestro proceso probablemente nos cueste una hora al mes.
Finalmente, aunque las historias son fantásticas para mejorar el conocimiento tácito dentro de un equipo,
pueden no escalar bien a equipos extremadamente grandes. Algunas comunicaciones en equipos grandes
simplemente deben escribirse o la información no se dispersará entre tantos en el equipo. Sin embargo, tenga
en cuenta la verdadera compensación entre un gran número de personas que saben un poco (a través de
documentos escritos de bajo ancho de banda) y un número menor de personas que saben mucho (a través de
conversaciones cara a cara de gran ancho de banda).
Resumen
• Las historias de usuarios fuerzan un cambio a la comunicación verbal. A diferencia de otras técnicas de requisitos que
se basan completamente en documentos escritos, las historias de los usuarios otorgan un valor significativo a las
conversaciones entre desarrolladores y usuarios.
• El cambio hacia la comunicación verbal proporciona ciclos de retroalimentación rápidos, lo que conduce a
una mayor comprensión.
• Las historias de usuario son comprensibles tanto para desarrolladores como para usuarios. Las especificaciones
de los requisitos del software IEEE 830 tienden a llenarse con demasiada jerga técnica o comercial.
• Las historias de usuarios, que generalmente tienen un alcance más pequeño que los casos de uso y escenarios, pero
más grandes que las declaraciones IEEE 830, son del tamaño adecuado para la planificación. La planificación, así
como la programación y las pruebas, se pueden completar con historias sin mayor agregación o desagregación.
• Las historias de usuario funcionan bien con el desarrollo iterativo porque es fácil comenzar con una historia épica
y luego dividirla en varias historias de usuario más pequeñas.
• Las historias de usuarios fomentan los detalles diferidos Las historias de usuarios individuales pueden escribirse muy
rápidamente, y también es extremadamente fácil escribir historias de diferentes tamaños. Las áreas de menor
importancia, o que no se desarrollarán inicialmente, pueden dejarse fácilmente como épicas, mientras que otras
historias se escriben con más detalle.
• Las historias fomentan el desarrollo oportunista, en el que el equipo cambia rápidamente el enfoque entre
niveles de detalle altos y bajos a medida que se descubren oportunidades.
• Las historias mejoran el nivel de conocimiento tácito en el equipo.
• Las historias de usuarios fomentan el diseño participativo, más que empírico, en el que los usuarios se
convierten en participantes activos y valorados en el diseño del comportamiento del software.
• Si bien hay muchas razones para usar historias, tienen algunos inconvenientes: en proyectos grandes
puede ser difícil mantener cientos o miles de historias organizadas; pueden necesitar ser aumentados
con documentos adicionales para la trazabilidad; y, si bien es excelente para mejorar el conocimiento
tácito a través de la comunicación cara a cara, las conversaciones no se escalan adecuadamente para
reemplazar por completo los documentos escritos en grandes proyectos.
Q UESCIONES 155
Responsabilidades del desarrollador
• Usted es responsable de comprender por qué ha elegido cualquier técnica que elija. Si el equipo del
proyecto decide escribir historias de usuarios, usted es responsable de saber por qué.
• Usted es responsable de conocer las ventajas de otras técnicas de requisitos o de saber cuándo
puede ser apropiado aplicar una. Por ejemplo, si está trabajando con un cliente y no puede llegar a
un acuerdo acerca de una característica, quizás sea útil discutir un escenario de diseño de
interacción o desarrollar un caso de uso.
Responsabilidades del cliente
• Una de las mayores ventajas de las historias de usuarios sobre otros enfoques de requisitos es que
fomentan el diseño participativo. Usted es responsable de convertirse en un participante activo en el
diseño de lo que hará su software.
Preguntas
13.1 ¿Cuáles son cuatro buenas razones para usar historias de usuarios para expresar requisitos?
13.2 ¿Cuáles pueden ser dos inconvenientes para usar historias de usuarios?
13.3 ¿Cuál es la diferencia clave entre diseño participativo y empírico?
13.4 ¿Qué tiene de malo la declaración de requisitos, "Todos los informes de varias páginas deben estar
numerados"?
Esta página se dejó en blanco intencionalmente
Capítulo 14
Un catálogo de olores de historias
Este capítulo presentará un catálogo de "malos olores", es decir, indicadores de que algo anda mal en la
aplicación de un proyecto de historias de usuarios. Se describirá cada olor y se proporcionarán una o más
soluciones.
Las historias son demasiado pequeñas
Síntoma: Una necesidad frecuente de revisar las estimaciones.
Discusión: Las historias pequeñas a menudo causan problemas con la estimación y programación de las
historias. Esto sucede porque la estimación asignada a una pequeña historia puede cambiar dramáticamente
dependiendo del orden en que se implemente la historia. Por ejemplo, considere estas dos pequeñas
historias:
• Los resultados de la búsqueda pueden guardarse en un archivo XML.
• Los resultados de la búsqueda pueden guardarse en un archivo HTML.
Claramente, existe una gran cantidad de trabajo superpuesto entre estas dos historias. El tiempo dedicado a
una de las historias reducirá el tiempo dedicado a la otra. Historias como estas deberían combinarse con fines de
planificación. Cuando la historia se divide en una iteración, la historia se puede dividir; pero, hasta que sea
necesario, las historias deben permanecer combinadas.
Historias interdependientes
Síntoma: Dificultad para planificar iteraciones debido a dependencias entre historias.
Discusión: Cuando dos o más historias dependen unas de otras, se hace difícil planificar las historias
individuales en iteraciones. El equipo se encuentra en una situación en la que una historia en particular solo
se puede agregar a una iteración si
157
158 C.A. ATÁLOGO DE S CONSERVADOR S MELLS
otra historia también se agrega a la iteración. Pero esa historia solo se puede agregar si también se agrega una tercera historia,
y así sucesivamente. Esto se produce cuando las historias son demasiado pequeñas o se han dividido de manera inapropiada.
Si sospecha que las historias son demasiado pequeñas, la solución fácil es simplemente combinar las historias
interdependientes en una sola. Si, en cambio, las historias aparecen para todos los demás propósitos con el tamaño
adecuado, entonces observe cómo se han separado las historias interdependientes. El Capítulo 7, “Pautas para
buenas historias”, ofreció la sugerencia de que las historias se dividieran para ser una “porción de pastel” completa,
incluida la funcionalidad de todas las capas de la aplicación.
Oro platino
Síntoma: Los desarrolladores están agregando características que no fueron planificadas para la iteración, o están
interpretando historias generosamente y van más allá de lo necesario para implementar una historia.
Discusión: Oro platino se refiere a la adición de características innecesarias por parte de los desarrolladores.
Algunos desarrolladores tienden a agregar mejoras o ir más allá de lo que se necesita para satisfacer las
necesidades declaradas de un cliente. Esto puede suceder por un par de razones. Primero, a algunos
desarrolladores les gusta "sorprender" al cliente y eso es más difícil de hacer con la mayor participación del cliente
en los procesos ágiles. Si el cliente está involucrado día a día, es difícil darle una sorpresa agradable y obtener la
"sorpresa" que disfrutan algunos desarrolladores.
En segundo lugar, cuando se trabaja en proyectos ágiles, guiados por historias con iteraciones cortas, los
desarrolladores suelen sentir una gran presión para estar siempre produciendo. Goldplating les permite una breve
oportunidad de escapar de esta presión. Después de todo, si la función no se puede terminar a tiempo, nadie
sabrá que se ha iniciado.
Finalmente, los desarrolladores disfrutan de poner su propia marca en un proyecto, y agregar algunas características de
mascotas es una forma de hacerlo.
Un ejemplo de chapado en oro

En un proyecto en el que estaba, teníamos una historia para tomar una pantalla muy llena y reescribirla como un
diálogo con pestañas para mejorar la usabilidad. Después de que el desarrollador finalizó este cambio, mejoró el código de
diálogo de la pestaña de bajo nivel en esta aplicación para que una pestaña pudiera arrancarse de su ubicación actual y
moverse por la pantalla. Esto no fue algo que el cliente solicitó. Los desarrolladores deben concentrarse en las historias
priorizadas por el cliente. Si un desarrollador tiene una buena idea para una nueva historia, debe sugerirla al cliente para
su posible inclusión en la próxima iteración.
yo NCLUDING U SER yo Interfaz re ETAIL T OO S OON 159
Si un proyecto está experimentando un enchapado de oro significativo por parte de los desarrolladores, puede
evitarse aumentando la visibilidad de las tareas en las que todos están trabajando. Por ejemplo, mantenga breves
reuniones diarias donde todos digan en qué están trabajando. Con una mayor visibilidad de lo que cada
desarrollador está trabajando en el equipo, se auto-vigilará contra el chapado en oro.
Del mismo modo, las reuniones de revisión de finalización de la iteración, donde todas las nuevas funcionalidades
se demuestran en detalle para el cliente y otras partes interesadas, ayudarán a identificar el enchapado de oro que
ocurrió durante la iteración. Será demasiado tarde para corregirlo durante esa iteración, pero el equipo será más
consciente de ello para futuras iteraciones.
Finalmente, si el proyecto tiene una organización de control de calidad, también pueden ayudar a identificar el
enchapado, especialmente si estuvieron involucrados en las conversaciones entre el programador y el cliente.
Demasiados detalles
Síntoma: Se dedica demasiado tiempo a recopilar detalles con bastante anticipación a la implementación
de una historia. O se dedica más tiempo a escribir sobre historias que a hablar sobre ellas.
Discusión: Uno de los beneficios de escribir historias en tarjetas de notas es que el espacio disponible
para escribir la historia es bastante limitado. Es difícil meter muchos detalles en una tarjeta pequeña. Incluir
demasiados detalles en una historia es indicativo de dar demasiado valor a la documentación y favorecerla en
lugar de la conversación.
Tom Poppendieck (2003) ha hecho la observación de que "si te quedas sin espacio, usa un menor tarjeta."
Esta es una gran idea porque obliga a los escritores de historias a incluir muy conscientemente menos detalles
en las historias.
Incluyendo detalles de la interfaz de usuario demasiado pronto
Síntoma: Historias escritas temprano en un proyecto (especialmente un proyecto para desarrollar un nuevo producto)
que incluyen detalles sobre la interfaz de usuario.
Discusión: En algún momento de un proyecto, el equipo definitivamente escribirá historias de usuarios con
suposiciones muy directas (o incluso conocimiento directo) sobre la interfaz de usuario. Por ejemplo, "Un buscador
de trabajo puede ver información sobre la empresa contratante en la página Descripción del trabajo". Sin embargo,
durante el mayor tiempo posible, debe evitar escribir historias con este nivel de detalle.
Al principio del proyecto, no sabe que habrá una "página de descripción de trabajo", por lo tanto, evite
restringir el proyecto asociando historias con él. En lugar de la historia anterior, escriba uno como "Al ver
detalles sobre un trabajo, un Solicitante de empleo puede ver información sobre la empresa contratante".
Pensando demasiado lejos
Síntoma: Los indicadores de este olor pueden ser que las historias son difíciles de encajar en las tarjetas de notas,
hay interés en usar un sistema de software en lugar de tarjetas de notas que no estén controladas por el tamaño o la
ubicación del equipo, alguien propone una plantilla de historia para capturar todos los detalles necesario para una historia,
o tal vez que se haga una sugerencia para dar estimaciones con mayor precisión (por ejemplo, horas en lugar de días).
Discusión: Este olor es particularmente común entre los equipos acostumbrados a grandes esfuerzos iniciales
de "ingeniería de requisitos". Para que un equipo supere este olor, pueden necesitar un curso de actualización sobre
los puntos fuertes de las historias. Fundamental para el uso de historias es el reconocimiento de que para la mayoría
de los problemas es imposible identificar todos los requisitos de antemano. El buen software surge a través de
iteraciones repetidas en las que se agregan cantidades cada vez mayores de detalles al software. Las historias
encajan bien con este enfoque debido a la facilidad con que se pueden expresar los detalles en versiones
posteriores de una historia. Es posible que el equipo deba recordarse de qué se trataba su proceso de desarrollo
anterior que los llevó a adoptar historias.
Dividiendo demasiadas historias
Síntoma: División frecuente de historias durante la planificación de la iteración para que la cantidad correcta de
trabajo encaje en la iteración.
Discusión: Cuando los desarrolladores y el cliente seleccionan las historias que pasarán a una
iteración, a veces necesitarán dividir una historia en dos o más historias constitutivas. Normalmente, una
historia debe dividirse durante la planificación por una de dos razones:
1. La historia es demasiado grande para caber en la iteración.
2. La historia contiene historias secundarias altas y bajas, y el cliente solo quiere que se realicen las
historias secundarias de alta prioridad durante la próxima iteración. Ninguno de estos casos es
representativo de un problema. Muchos proyectos y equipos tendrán ocasiones en las que será útil
dividir una historia para acomodar
C USTOMER H COMO T RUBLO PAGS RIORIZACIÓN 161
La duración de un sprint y el ajuste con la velocidad observada por el equipo. Sin embargo, la situación comienza a
oler cuando el equipo se encuentra dividiendo historias con frecuencia.
Si las historias se dividen con más frecuencia de lo que parece razonable, entonces considere pasar
por las historias restantes y busque historias que deberían dividirse.
El cliente tiene problemas para priorizar
Síntoma: Elegir y priorizar historias a menudo es difícil; pero a veces priorizar las historias es tan difícil
que puede considerarse un olor.
Discusión: Si un cliente tiene problemas para priorizar las historias, lo primero que debe tener en cuenta es el
tamaño de las historias. Si las historias son demasiado grandes, pueden ser difíciles de priorizar. Supongamos que, en
el extremo, el sitio web de BigMoneyJobs incluye solo las siguientes tres historias:
• Un buscador de trabajo puede buscar trabajo.
• Una empresa puede publicar una oferta de trabajo.
• Un reclutador puede buscar candidatos.
¡Lástima el pobre cliente que tiene que priorizar solo entre estas historias! Su reacción es probablemente
decir: "¿Pero no puedo tener un poco de esto y algo de eso?" En este caso, deshazte de las historias actuales
y reemplázalas por otras más pequeñas para que pueda seleccionar las piezas de cada una que quiera.
Además, puede ser difícil priorizar las historias si no se han escrito para expresar el valor comercial.
Por ejemplo, suponga que al cliente se le presentan estas historias:
• Un usuario se conecta a la base de datos a través de un grupo de conexiones.
• Un usuario puede ver información detallada del error en un archivo de registro. Historias como estas
pueden ser muy difíciles de priorizar para el cliente porque el valor comercial de cada una no está claro.
Las historias deben reescribirse para que el valor de cada una sea claro para el cliente. La forma en que
se reescribe variará según el conocimiento técnico del cliente, por lo que la mejor recomendación es que el
cliente escriba las historias ella misma. Por ejemplo, considere estas versiones reescritas de las historias
anteriores:
• Un usuario puede iniciar la aplicación sin un retraso notable mientras se conecta a la base de datos.
• Cada vez que ocurre un error, los usuarios reciben suficiente información para saber cómo corregir el
error.
El cliente no escribirá ni priorizará las historias
Síntoma: El cliente en un proyecto no aceptará la responsabilidad de escribir o priorizar las historias.
Discusión: En una organización llena de culpa siempre hay algunas personas que han aprendido que
su mejor decisión es evitar toda responsabilidad. Si no eres responsable de algo, no se te puede culpar
cuando falla, sin embargo, generalmente hay una manera de reclamar al menos parte del éxito. Las
personas en este tipo de cultura no querrán tener nada que ver con decisiones difíciles, como priorizar las
funciones dentro y fuera de los lanzamientos. Recurrirán a declaraciones como "No es mi problema que no
se pueda completar todo antes de la fecha límite, encontrar una forma de hacerlo".
La mejor solución que he encontrado en estas situaciones es encontrar una manera de liberar al
cliente. Encuentro una manera no amenazante para que ella exprese sus opiniones. Dependiendo del
individuo, esto puede ser una conversación privada. Si estoy trabajando con varios clientes, les digo a cada
uno que estoy recabando información de los demás, pero que soy el responsable de las decisiones finales,
especialmente si resultan equivocadas.
Resumen
En este capítulo aprendimos sobre los siguientes olores:
• historias que son demasiado pequeñas
• historias interdependientes
• oro platino
• agregando demasiados detalles a las historias
• incluidos los detalles de la interfaz de usuario demasiado pronto
• pensando demasiado lejos
Q UESCIONES 163
• dividiendo demasiadas historias
• problemas al priorizar historias
• el cliente no escribirá ni priorizará historias
• Usted comparte la responsabilidad con el cliente de estar al tanto de estos olores, así como de
cualquier otro que pueda detectar, y luego trabajar para corregir los que afecten su proyecto.
• Usted comparte la responsabilidad con los desarrolladores de estar al tanto de estos olores, así como de
cualquier otro que pueda detectar, y luego trabajar para corregir los que afecten su proyecto.
Preguntas
14.1 ¿Qué debe hacer si el equipo constantemente encuentra dificultades para planificar la próxima
iteración?
14.2 ¿Qué debe hacer el equipo si constantemente se está quedando sin espacio para escribir en las
tarjetas de la historia?
14.3 ¿Qué podría hacer que el cliente tenga dificultades para priorizar historias?
14.4 ¿Cómo sabe si está dividiendo demasiadas historias?
Capítulo 15
Usando historias con Scrum
Las historias de usuarios se originaron como parte de Extreme Programming. Naturalmente, las historias encajan
perfectamente con las otras prácticas de programación extrema. Sin embargo, las historias también funcionan bien como el
enfoque de requisitos para otros procesos.
En este capítulo veremos Scrum, otro proceso ágil, y veremos cómo las historias pueden integrarse como una
parte importante de Scrum. 1 Los términos que forman parte del léxico Scrum aparecerán en cursiva cuando se usen
por primera vez.
Scrum es iterativo e incremental
Al igual que XP, Scrum es tanto un proceso iterativo como incremental. Dado que estas palabras se usan
con tanta frecuencia sin definición, las definiremos.
Un proceso iterativo es aquel que progresa a través del refinamiento sucesivo. Un equipo de desarrollo
realiza un primer corte en un sistema, sabiendo que está incompleto o débil en algunas (quizás muchas) áreas.
Luego refinan iterativamente esas áreas hasta que el producto sea satisfactorio. Con cada iteración, el software
se mejora mediante la adición de mayores detalles. Por ejemplo, en una primera iteración, una pantalla de
búsqueda podría codificarse para admitir solo el tipo de búsqueda más simple. La segunda iteración podría
agregar criterios de búsqueda adicionales. Finalmente, una tercera iteración puede agregar manejo de errores.
Una buena analogía es esculpir. Primero, el escultor selecciona una piedra del tamaño apropiado. A
continuación, el escultor talla la forma general de la piedra. En este punto, quizás se pueda distinguir la
cabeza y el torso, y discernir que el trabajo terminado será de un cuerpo humano en lugar de un pájaro.
Luego, el escultor refina su trabajo agregando detalles. Sin embargo, es poco probable que el escultor vea
una sola área como completa hasta que se complete todo el trabajo.
1. Para una cobertura completa de Scrum, vea Desarrollo ágil con Scrum ( Schwaber y Beedle 2002).
165
166 U CANTA S TORIES CON S CRUM
Un proceso incremental es aquel en el que el software se construye y entrega por partes. Cada pieza, o
incremento, representa un subconjunto completo de funcionalidad. El incremento puede ser pequeño o grande,
tal vez desde la pantalla de inicio de sesión de un sistema en el extremo pequeño hasta un conjunto altamente
flexible de pantallas de gestión de datos. Cada incremento está totalmente codificado y probado, y la
expectativa común es que el trabajo de una iteración no necesitará ser revisado.
Un escultor incremental elegiría una parte de su trabajo y se centraría por completo en él hasta que esté
terminado. Puede seleccionar pequeños incrementos (primero la nariz, luego los ojos, luego la boca, etc.) o
grandes incrementos (cabeza, torso, piernas y luego brazos). Sin embargo, independientemente del tamaño del
incremento, el escultor incremental intentaría terminar el trabajo de ese incremento lo más completamente
posible.
Scrum y XP son incrementales e iterativos. Son iterativos en el sentido de que planean mejorar el
trabajo de una iteración en las iteraciones posteriores. Son incrementales porque el trabajo completado se
entrega a lo largo del proyecto.
Los fundamentos de Scrum
Scrum proyecta el progreso a través de una serie de iteraciones de treinta días llamadas
sprints Al comienzo de cada sprint, el equipo determina la cantidad de trabajo que puede realizar durante
ese sprint. El trabajo se selecciona de una lista priorizada llamada Pila de Producto. El trabajo que el equipo
cree que puede completar durante el sprint se traslada a una lista llamada reserva de sprint. Una breve
reunión diaria, el
scrum diario, se lleva a cabo para permitir que el equipo inspeccione su progreso y se adapte según sea necesario.
Gráficamente, Scrum es como se muestra en la Figura 15.1, que está adaptada del sitio web de Ken Schwaber en
www.controlchaos.com.
El equipo de Scrum
Un equipo Scrum generalmente consta de cuatro a siete desarrolladores. Mientras que un equipo Scrum puede
involucrar a desarrolladores especializados (probadores y administradores de bases de datos, por ejemplo), un
equipo Scrum comparte una actitud de "todos estamos juntos en esto". Si hay que hacer pruebas y no hay un
probador dedicado disponible, entonces alguien más hace las pruebas. Todo el trabajo es propiedad colectiva. Los
equipos de Scrum se autoorganizan. Es decir, no hay una directiva de gestión que indique que Mary codifica y Bill
realiza pruebas. Debido a esto, nombres de roles como programador, arquitecto y
T ÉL PAGS RODUCTO si ACKLOG 167
El probador generalmente no se usa en equipos Scrum. Todo sobre cómo un equipo realiza su trabajo
queda en manos del equipo.
Este equipo central se complementa con dos personas clave: el dueño del producto y el ScrumMaster. El
propietario de un producto Scrum es esencialmente el cliente de Extreme Programming. El propietario del
producto es en gran parte responsable de colocar los elementos y priorizar la lista de tareas pendientes del
producto de la funcionalidad necesaria. ScrumMaster es similar a un gerente de proyecto, excepto que el
papel es mucho más de liderazgo que de gestión. Debido a que los equipos Scrum se autoorganizan y tienen
un gran margen de maniobra para completar el trabajo de un sprint, ScrumMaster del proyecto sirve al equipo
en lugar de dirigirlo. Un ScrumMaster generalmente sirve a su equipo eliminando obstáculos para el progreso
y ayudando al equipo a seguir las pocas reglas simples de Scrum.
horas
Scrum diario
Reunión
Tareas acumuladas 30 días 24

por equipo
Backlog de Sprint
Incremento de producto
Producto acumulado según la prioridad del propietario potencialmente transportable
del producto
Figura 15.1 Representación gráfica del proceso Scrum.
La cartera de productos
La cartera de productos es la lista maestra de todas las funciones deseadas en el producto. Cuando se
inicia un proyecto, no hay un esfuerzo integral para anotar todas las características previsibles. Por lo
general, el propietario del producto y el equipo escriben todo lo obvio, que casi siempre es más que
suficiente para un primer sprint. Luego, se permite que la cartera de productos crezca y cambie a medida
que se aprende más sobre el producto y sus clientes.
Un ejemplo de producto atrasado de un proyecto real aparece como se muestra en la Tabla 15.1. Como puede ver en
esta tabla, los elementos acumulados pueden ser tareas técnicas ("Refactorizar la clase de inicio de sesión para generar
una excepción") o más centradas en el usuario ("Permitir deshacer en la pantalla de configuración").
El propietario del producto clasifica la acumulación de productos en orden de prioridad. Aún mejor, el propietario del
producto puede (en realidad alentar) mezclar los elementos de la cartera de productos a medida que las prioridades
cambian de mes a mes.
Tabla 15.1 Una lista de muestra de productos atrasados.
Número Descripción
1 Finalizar el versionado de la base de datos
2 Deshágase de Java innecesario en la base de datos
3 Refactorice la clase de inicio de sesión para lanzar una excepción
44 Agregar soporte para licencias de usuario concurrentes
55 Agregar soporte para licencias de evaluación
66 Admite comodines al buscar
77 Guardar configuración de usuario
8 Permitir deshacer en la pantalla de configuración
La reunión de planificación de Sprint
UNA reunión de planificación de sprint se lleva a cabo al comienzo de cada sprint. La reunión suele durar
hasta un día completo y asisten el propietario del producto, el ScrumMaster y todo el equipo de
desarrolladores. También pueden asistir representantes de la gerencia o clientes interesados y apropiados.
Durante la primera mitad de la reunión de planificación de sprint, el propietario del producto describe las
características restantes de mayor prioridad para el equipo. El equipo hace suficientes preguntas para que
durante la segunda mitad de la reunión puedan determinar qué elementos pasarán de la cartera de pedidos del
producto a la cartera de sprint.
El propietario del producto no tiene que describir cada artículo que se rastrea en la cartera de pedidos del
producto. Dependiendo del tamaño del trabajo atrasado y la velocidad del equipo, puede ser suficiente describir solo
los elementos de alta prioridad, ahorrando la discusión de los elementos de menor prioridad para la próxima reunión
de planificación de sprint. Por lo general, el equipo Scrum brindará orientación cuando comiencen a avanzar en la
lista de pedidos pendientes de lo que saben que se puede hacer en el próximo sprint.
Colectivamente, el equipo y el propietario del producto definen un meta de sprint, que es una breve
descripción de lo que el equipo planea lograr durante ese sprint. en un
T ÉL S IMPRESIÓN PAGS LANNING METRO COMER 169
reunión de revisión de sprint celebrado al final del sprint, el equipo evaluará su éxito en función del objetivo
del sprint, en lugar de cada elemento específico seleccionado de la cartera de productos.
Durante la segunda mitad de la reunión de planificación del sprint, el equipo se reúne por separado para
discutir lo que escucharon y decidir cuánto pueden comprometerse durante el próximo sprint. Conceptualmente, el
equipo comienza en la parte superior de la lista de pedidos de productos priorizados y dibuja una línea después de
la más baja de las tareas de alta prioridad que consideran que pueden completar. En la práctica, no es inusual ver
a un equipo seleccionar, por ejemplo, los cinco elementos principales y luego dos elementos de la parte inferior de
la lista que están asociados con los cinco primeros. En algunos casos, se negociará con el propietario del
producto, pero siempre dependerá del equipo determinar cuánto pueden comprometerse a completar.
Las principales reglas de Scrum
Se lleva a cabo una reunión de planificación de sprint al comienzo de cada sprint.
Cada sprint debe entregar un código funcional y probado que demuestre algo de valor para los usuarios
finales o el cliente.
El propietario del producto prioriza la acumulación de productos.
El equipo selecciona colectivamente la cantidad de trabajo aportado al sprint. Una vez que comienza un sprint, solo el
equipo puede agregar al backlog de sprint. La acumulación de productos puede agregarse o volver a priorizarse en
cualquier momento. Se celebra una breve reunión de scrum todos los días. Cada participante del proyecto responde:
¿Qué hiciste ayer? ¿Qué vas a hacer hoy? ¿Qué obstáculos hay en tu camino?
Solo los participantes activos en el sprint (observadores no interesados o partes interesadas removidas) pueden
hablar durante la reunión diaria de scrum.
El resultado de un sprint se demuestra en una reunión de revisión de sprint al final del sprint.
El software de trabajo se demuestra durante la revisión de sprint. No se permiten presentaciones de diapositivas.
No se pueden pasar más de dos horas preparándose para la revisión del sprint.
Una vez que comienza el sprint, solo el equipo puede agregar trabajo al sprint. El CEO no puede acercarse al
equipo y pedir algo que el propietario del producto omitió. Un vendedor no puede solicitar una función más para un
cliente especial. Y el propietario del producto no puede cambiar de opinión y solicitar funciones adicionales. El
único momento en que se puede agregar trabajo a un sprint es si el equipo se encuentra antes de lo previsto. En
ese momento, el equipo puede pedirle al propietario del producto que lo ayude a identificar uno o dos elementos
adicionales.
A cambio de su compromiso de completar el trabajo seleccionado para el sprint, el equipo recibe el

compromiso de la organización de que no cambiará el contenido del sprint mientras dure el sprint. Si
sucede algo tan significativo que la organización siente que necesita cambiar el sprint, entonces se cancela
el sprint actual y se inicia un nuevo sprint comenzando con otra reunión de planificación del sprint.
A medida que el equipo selecciona elementos de la cartera de pedidos del producto, los expande en la cartera de sprint
más basada en tareas. Cada elemento de la cartera de pedidos del producto puede expandirse en uno o más elementos en la
cartera de pedidos de sprint, lo que permite al equipo compartir el trabajo de manera más efectiva.
La reunión de revisión de Sprint
Cada sprint es requerido para entregar un Incremento de producto potencialmente transportable.
Esto significa que al final de cada sprint de un mes, el equipo ha producido un software codificado, probado
y utilizable. El software debe ser potencialmente enviable, lo que significa que la organización podría elegir
enviar el software a los clientes (o usarlo internamente) si se incluye suficiente funcionalidad nueva para
justificar los gastos generales de envío o implementación de la nueva versión. Un distribuidor de software
comercial, por ejemplo, probablemente no elegiría enviar una nueva versión todos los meses debido a los
problemas de actualización que podrían causar a sus clientes. Sin embargo, con Scrum los desarrolladores
deben producir una versión potencialmente enviable cada mes.
Al final de cada sprint, se lleva a cabo una reunión de revisión de sprint. Durante esta reunión, el equipo
muestra lo que lograron durante el sprint. Por lo general, esto toma la forma de una demostración de las nuevas
características.
La reunión de revisión de Sprint se mantiene intencionalmente de manera informal, generalmente con reglas que
prohíben el uso de diapositivas de PowerPoint y no permiten más de dos horas de tiempo de preparación para la
reunión. Una reunión de revisión de sprint no debe convertirse en una distracción o un desvío significativo para el
equipo; más bien, debería ser un resultado natural del sprint.
Todo el equipo, así como el propietario del producto y ScrumMaster participan en la reunión de revisión
de sprint. Otros que estén interesados en el proyecto (como la gerencia, clientes o ingenieros de otros
proyectos) pueden asistir a la revisión de sprint si lo desean.
Durante la reunión de revisión de sprint, el proyecto se evalúa con respecto a la meta de sprint que se determinó
previamente durante la reunión de planificación de sprint. Idealmente,
T ÉL re AILY S CRUM METRO COMER 171
el equipo ha completado cada elemento planeado para el sprint, pero es más importante que logren el
objetivo general del sprint.
La reunión diaria de Scrum
Scrum es probablemente el primer proceso documentado que incluye una reunión diaria corta (Beedle
1999), que en Scrum se llama "el scrum diario". La idea, sin embargo, se ha extendido rápidamente a
muchos de los otros procesos ágiles como XP y FeatureDriven Development. Siempre que sea posible,
queremos elegir el método que menos tiempo y menos intrusivo para recopilar y compartir información del
proyecto. Para muchos propósitos, el scrum diario logra exactamente ese objetivo.
El scrum diario generalmente se lleva a cabo lo más temprano posible cada día, pero después de que todo el
equipo ha llegado para trabajar. Esto suele ser a las 9:00 o 9:30. Todos los miembros del equipo deben asistir,
incluidos los programadores, los evaluadores, el propietario del producto y el ScrumMaster. La reunión se mantiene
corta: generalmente 15 minutos o menos y nunca más de 30. Para mantener la reunión corta, algunos equipos
requieren que los participantes se paren.
Durante el scrum diario, cada miembro del equipo responde las siguientes tres preguntas:
1. ¿Qué hiciste ayer?
2. ¿Qué vas a hacer hoy?
3. ¿Qué obstáculos hay en tu camino?
Es importante que el scrum diario no parezca una parrilla del ScrumMaster. Uno de los objetivos de la
reunión es que cada desarrollador se comprometa frente a sus pares. No se hacen compromisos con el
gerente o la empresa, sino entre ellos.
El scrum diario debe ajustarse lo más posible a las tres preguntas anteriores, y no debe pasar a diseñar
partes del sistema o resolver problemas que surgieron. Dichos elementos se anotan durante la reunión
pero se resuelven después. Está bien identificar un subconjunto del equipo que se reunirá para resolver un
problema, pero no resolver problemas durante el scrum diario. Por ejemplo, supongamos que alguien
pregunta si deberíamos comenzar a usar la versión 5.0 recientemente lanzada del servidor de aplicaciones
de nuestro proveedor. En ese caso, acordamos que justo después del scrum diario se realizará otra
reunión entre:
• El arquitecto técnico, que puede evaluar el impacto técnico en el uso del nuevo servidor de
aplicaciones
• el propietario del producto, que proviene del departamento de Marketing y estará en la mejor posición
para decidir si nuestros clientes implementarán el servidor de aplicaciones antiguo o nuevo
• un representante del equipo de prueba que puede evaluar el impacto en su grupo. El ScrumMaster
está disponible como facilitador y para asegurarse de que la reunión se mantenga enfocada en las tres
preguntas y avance a un ritmo rápido. La propietaria del producto está presente porque idealmente tendrá
trabajo para informar como cualquier otra persona (“Terminé de escribir pruebas para la historia 'Agregar
libro al carrito de compras' y hoy voy a hacer un estudio de mercado sobre qué tarjetas deberíamos
aceptar. Debería poder terminar eso al final del día ").
Un beneficio de celebrar reuniones diarias es que pueden servir como puntos de control aleatorios para los
gerentes senior o cualquier otra persona interesada en el estado del proyecto. Al reunirse constantemente a la
misma hora del día y extender una invitación general de "únete a nosotros cada vez que estés interesado", el equipo
puede salir de reuniones más onerosas, como las revisiones mensuales de proyectos. Sin embargo, si los miembros
que no son del equipo están invitados a los scrums diarios, asegúrese de establecer una regla que solo las
personas directamente en el proyecto puedan hacer preguntas durante la reunión. Entonces, el Gran Jefe puede
asistir y escuchar el contenido de su corazón. Sin embargo, no puede redirigir la reunión haciendo preguntas.
El scrum diario proporciona a todos los miembros del equipo una instantánea rápida de la situación actual
del proyecto. Esto lo convierte en el momento perfecto para que el equipo reconsidere las tareas actuales.
Por ejemplo, supongamos que Randy informa que la historia en la que está trabajando está tardando mucho
más de lo que esperaba y Andrew informa que está significativamente adelantado a lo previsto. En este caso,
puede ser apropiado que Andrew pase el día emparejado con Randy y trabajando en las tareas de Randy o
que Andrew asuma la responsabilidad de algunas de las tareas de Randy.
El ScrumMaster debe caminar una línea fina durante los scrums diarios. Ella necesita mantener el ritmo
rápido pero no puede dejar que las reuniones se sientan como si fueran solo para su beneficio. Una
pregunta que nunca debería formularse es "¿Cuánto tiempo le queda en la historia de 'Pedir un libro'?" Esta
información es extremadamente importante, pero si se solicita durante el scrum diario, entonces el scrum
diario tendrá que ver con estimaciones y números. Aparte de la reunión diaria de scrum, hago que el equipo
actualice sus estimaciones en una pizarra comunitaria o en el software que estamos utilizando si no
estamos colocados.
S TORIES EN EL S IMPRESIÓN PAGS LANNING METRO COMER 173
Agregar historias a Scrum
Después de describir el enfoque general de Scrum, ahora enfocamos nuestra atención en cómo se puede
mejorar Scrum combinándolo con el uso de historias.
Historias y la cartera de productos
He tenido un gran éxito al expresar los elementos de la cartera de Scrum en forma de historias de usuarios (Cohn 2003). En lugar
de permitir que los elementos de la cartera de pedidos del producto describan nuevas características, problemas que investigar,
defectos que se deben corregir, etc., la cartera de pedidos del producto se limita solo a las historias de los usuarios. Cada historia en
la cartera de productos debe describir algún elemento de valor para un usuario o para el propietario del producto.
Al restringir el trabajo atrasado del producto solo a historias de usuarios, resulta mucho más fácil para el propietario del
producto priorizar el trabajo atrasado. Con todos los elementos de la cartera de pedidos en términos que puede entender, se
vuelve fácil para el propietario del producto tomar decisiones para cambiar una característica por otra.
Al igual que con XP, en Scrum no es importante que el propietario del producto identifique todos los
requisitos por adelantado. Sin embargo, a menudo es beneficioso anotar tantos como sea posible desde el
principio. Scrum no tiene un enfoque prescrito, o incluso recomendado, para almacenar inicialmente la cartera
de pedidos del producto. Tradicionalmente, esto ha sucedido a través de una discusión no estructurada entre el
propietario del producto, ScrumMaster y uno o más desarrolladores. Sin embargo, descubrí que al identificar
primero los roles de los usuarios y luego centrarme en las historias para cada rol de usuario, Scrum se combina
con una poderosa técnica de identificación de requisitos.
Historias en la reunión de planificación de Sprint
Durante la reunión de planificación del sprint, el propietario del producto y el equipo discuten los elementos de mayor
prioridad en la cartera de productos. Luego, el equipo identifica los elementos que se comprometerán a completar durante el
sprint. Luego dividen esas tareas en tareas más pequeñas según sea necesario para que los desarrolladores puedan
registrarse para las tareas a medida que avanza el sprint.
Las historias obligan a cada elemento de la cartera de productos a cada valor de entrega que el cliente puede evaluar. Debido
a esto, he descubierto que las reuniones de planificación de sprints son más fáciles de realizar y van más rápido que cuando el
equipo se ve obligado a explicar el beneficio de los elementos de la cartera de pedidos impulsados por la tecnología como
"refactorizar la clase de inicio de sesión para lanzar una excepción".
Las historias también encajan bien en la planificación de sprints porque, como vimos en el Capítulo 10, "Planificación
de una iteración", las historias pueden desglosarse fácilmente en sus tareas constitutivas.
Historias en la reunión de revisión de Sprint
El uso de historias beneficia a Scrum durante la reunión de revisión de sprint porque las historias hacen que sea
más sencillo evaluar qué partes de un sprint se han completado. En un proyecto Scrum que utiliza una colección
aleatoria de tareas técnicas, requisitos, problemas y correcciones de errores como su cartera de productos, puede
ser difícil para el equipo demostrar que cada elemento se abrió paso en el producto construido durante ese sprint.
Cuando toda la cartera de productos está compuesta de historias que describen elementos de valor para el cliente
o el usuario, generalmente es más fácil demostrar esos elementos.
Historias y la reunión diaria de Scrum
He encontrado historias beneficiosas para las reuniones diarias de scrum porque ayudan a garantizar que el
enfoque permanezca en los deseos de los clientes y usuarios finales. Debido a que no hay requisitos iniciales o
fase de análisis que precede a un sprint, los sprints se inician con una comprensión parcial de lo que se construirá
exactamente. El equipo puede saber que está planeando agregar una pantalla de búsqueda, pero puede que no
sepa qué campos se podrán buscar, cómo se pueden combinar los criterios de búsqueda, etc. Las historias son
útiles porque le recuerdan al equipo la intención detrás de lo que se está desarrollando. En medio de un sprint, el
equipo puede usar la historia (así como las discusiones en curso con el propietario del producto sobre la historia)
para determinar si han ido lo suficientemente lejos, o tal vez demasiado, en la programación de una historia en
particular.
Un caso de estudio
Como ejemplo de agregar historias a Scrum, consideremos un proyecto en el que estuve involucrado. La
compañía, llamémosles Cosmodemonic Biotech por conveniencia, fue un desarrollador de software pequeño pero
que cotiza en bolsa para la industria de las ciencias de la vida. Cosmodemonic Biotech acababa de completar un
esfuerzo de desarrollo de nueve meses para presentar un nuevo producto para genetistas humanos. Poco después
de que el nuevo producto fuera entregado a su sitio beta inicial, la compañía anunció que estaba siendo adquirido.
La empresa compradora estaba interesada en la lista de clientes que acompañaba al producto. Sin
embargo, decidieron que el software necesitaría ser reescrito por una variedad de razones, que incluyen:
S UMARIO 175
• Las tecnologías del cliente del producto original (HTML) no encajaban bien con la visión estratégica
del nuevo propietario
• El mercado objetivo para el producto cambió de grandes compañías farmacéuticas con bases de datos de varios
terabytes a laboratorios de investigación académica y pequeñas empresas de biotecnología con bases de datos
mucho más pequeñas.
• una implementación relativamente pobre en gran parte del código original. El producto original se
había desarrollado de manera estricta en cascada durante un período de nueve meses con un equipo de
hasta 100 desarrolladores. El nuevo producto necesitaría ofrecer esencialmente la misma funcionalidad,
pero tendría un tamaño de equipo de no más de siete.
Para lograr esto, utilizamos Scrum aumentado con historias de usuarios como se describe en este capítulo.
Por todas las medidas, el proyecto fue un éxito. Al equipo Scrum le llevó doce meses completar lo que el
equipo de la cascada había hecho en nueve. Sin embargo, debido a que el equipo Scrum nunca excedió a
siete personas, incluidos el propietario del producto y ScrumMaster, el proyecto tardó 54 meses en
completarse. La versión en cascada había tardado 540 personas-meses en completarse.
El equipo de cascada produjo 58,000 declaraciones fuente Java sin comentarios. El equipo de Scrum
con historias hizo más con menos y produjo 51,000. Esto significa que el equipo en cascada produjo 120
declaraciones fuente Java por persona-mes, mientras que el equipo Scrum produjo 840 por persona-mes.
Estas comparaciones se muestran en la Tabla 15.2.
Tabla 15.2 Comparación de los dos enfoques para el mismo proyecto.
Cascada Scrum con historias
Páginas de casos de uso 3.000 00
Cuentos 00 1,400
Meses calendario 99 12
Meses Personales 540 54
Líneas de código Java 58,000 51,000
Líneas de código Java / persona-mes 120 840
Resumen
• Scrum es un proceso iterativo e incremental.
• Scrum proyecta el progreso en una serie de iteraciones de treinta días llamadas sprints.
• Un ScrumMaster cumple el rol de gerente de proyecto pero es más líder y facilitador que gerente.
• Un equipo típico de Scrum incluye de cuatro a siete desarrolladores.
• La cartera de pedidos del producto es una lista de todas las características deseadas que aún no se han
agregado al producto o planificadas para el sprint actual.
• El retraso del sprint es una lista de tareas a las que el equipo se ha comprometido para el sprint actual.
• El rol del cliente de XP lo desempeña el propietario del producto Scrum.
• El propietario del producto prioriza la acumulación de productos.
• Al comienzo del sprint, el equipo selecciona qué y cuánto trabajo se comprometen a completar
durante el sprint.
• Se llevan a cabo breves reuniones diarias de scrum. Durante estas reuniones, cada miembro del
equipo dice lo que completó ayer, lo que completará hoy e identifica cualquier obstáculo en su
camino.
• Cada sprint es responsable de producir un incremento de producto potencialmente enviable.
• Al final del sprint, el equipo demuestra el software que creó en una reunión de revisión de sprint.
Preguntas
15.1 Describa las diferencias entre un proceso incremental y uno iterativo.
15.2 ¿Cuál es la relación entre la cartera de pedidos del producto y la cartera de Sprint?
15.3 ¿Qué se entiende por incremento de producto potencialmente transportable?
15.4 ¿Quién es responsable de priorizar el trabajo y de seleccionar el trabajo que realizará el equipo
durante un sprint?
15.5 ¿Qué preguntas son respondidas por cada miembro del equipo en el scrum diario?
Capítulo 16
Temas adicionales
A lo largo de esta parte del libro, hemos analizado algunos temas que se plantean con frecuencia cada vez
que se discuten historias de usuarios. Hemos visto cómo las historias de usuario difieren de otros métodos de
requisitos y por qué las historias de usuario son preferibles en algunos casos. Hemos analizado algunos olores
o problemas comunes, con historias de usuarios y cómo corregirlos. En este capítulo dirigimos nuestra
atención a varios temas adicionales:
• manejo de requisitos no funcionales
• si los equipos deben usar tarjetas de notas en papel o software
• El impacto de las historias de usuario en la interfaz de usuario
• si las historias de los usuarios deben conservarse después de que se hayan desarrollado
• la relación entre informes de errores e historias
Manejo de requisitos no funcionales
Un obstáculo común para los equipos que comienzan con historias de usuarios es su sensación de que todo
debe transmitirse como una historia de usuario. La mayoría de los proyectos encontrarán al menos algunos
requisitos que no pueden reflejarse adecuadamente como historias. Con frecuencia, estos serán requisitos no
funcionales del sistema.
Los requisitos no funcionales pueden abordar una variedad de necesidades del sistema. Algunos de los tipos
más comunes de requisitos no funcionales se encuentran en las siguientes áreas:
• actuación
• exactitud
• portabilidad
177
178 UNA DDICIONAL T OPICS
• reutilización
• mantenibilidad
• interoperabilidad
• disponibilidad
• usabilidad
• seguridad
• capacidad
Muchos requisitos no funcionales pueden considerarse como restricciones en el comportamiento del

sistema. Por ejemplo, no es raro que un proyecto incluya un requisito como "El sistema se escribirá en Java".
Esto es claramente una restricción en el diseño del resto del sistema. Como se discutió en el Capítulo 7,
“Pautas para buenas historias”, las restricciones se manejan mejor escribiendo la restricción en una tarjeta y
anotando la tarjeta con “Restricción”. En la mayoría de los casos, se puede escribir una prueba automatizada
(y ejecutarla al menos diariamente) para garantizar el cumplimiento de una restricción. Algunas restricciones
no pueden ser probadas de manera realista o no vale la pena probarlas. Me viene a la mente la restricción "El
sistema se escribirá en Java". Ciertamente, hay formas fáciles de garantizar que se cumpla esta restricción.
En la Tabla 16.1 se muestran ejemplos de algunas restricciones comunes. Más allá de escribir
restricciones en una tarjeta, si hay requisitos adicionales no funcionales que un sistema debe cumplir,
comuníquelos en cualquier forma que sea apropiada o tradicional. Si, por ejemplo, el proyecto puede
beneficiarse de un diccionario de datos que muestra el tamaño y el tipo de todas las variables en el
sistema, cree un diccionario de datos.
Tabla 16.1 Restricciones de muestra escritas para una variedad de requisitos no funcionales comunes.
Zona Restricción de muestra
Actuación El 80% de las búsquedas en la base de datos devolverán los resultados a la pantalla en menos de dos
segundos.
Exactitud El software predecirá correctamente el ganador de un juego de fútbol al menos el 55% del
tiempo.
Portabilidad El sistema no utilizará ninguna tecnología que dificulte el puerto a Linux.
Reusabilidad La base de datos y el código de acceso a la base de datos serán reutilizables en futuras aplicaciones.
PAGS APER O S OFTWARE? 179
Tabla 16.1 Restricciones de muestra escritas para una variedad de requisitos no funcionales comunes.
(Continuado)
Zona Restricción de muestra
Las pruebas unitarias automatizadas deben existir para todos los componentes. Las pruebas unitarias
automatizadas deben ejecutarse en su totalidad al menos una vez cada 24 horas.
Interoperabilidad El sistema se escribirá en Java. Todos los datos de configuración se

almacenarán en archivos XML. Los datos se almacenarán en MySQL.
Capacidad La base de datos será capaz de almacenar 20 millones de miembros en el hardware

especificado sin dejar de cumplir los objetivos de rendimiento.
lado, una práctica común entre aquellos que se pueden mantener

¿Papel o software?
¿Aún más común que ser preguntado "papel o plástico"? en la tienda de comestibles se trata de si las
historias deben escribirse en tarjetas de papel o almacenarse en un sistema de software. Muchos en la
comunidad de Extreme Programming abogan por el uso de tarjetas de notas de papel debido a su
simplicidad. La Programación Extrema otorga una prima a las soluciones simples, y las tarjetas de notas en
papel son definitivamente simples. Además, las tarjetas fomentan la interacción y la discusión. Se pueden
colocar sobre una mesa en varias formaciones durante la planificación, se pueden apilar y clasificar, se
pueden llevar a cualquier reunión, etc.
natural en la cantidad de texto. Esta limitación no existe en la mayoría de las alternativas de software. Por otro
Por otro lado, hay productos de software diseñados específicamente para el seguimiento de historias
(VersionOne, 1 XPlanner, 2 Seleccione Scope Manager 3) así como software de uso general que puede usarse
con historias (hojas de cálculo, rastreadores de defectos y wikis).
Una de las principales ventajas que tienen las tarjetas sobre el software es que su naturaleza de baja tecnología es
un recordatorio constante de que las historias son imprecisas. Cuando se muestran en el software, las historias pueden
asumir la apariencia de los requisitos de estilo IEEE 830 y aquellos que escriben historias pueden agregar detalles
adicionales e innecesarios debido a eso.
La tarjeta de nota típica puede contener una cantidad limitada de escritura. Esto le da un límite superior
1) Ver www.versionone.net.
2) Ver www.xplanner.org
3) Consulte www.selectbs.com/products/products/select_scope_manager.htm.
usar tarjetas de notas es escribir algunas pruebas de aceptación de muestra para una historia en el reverso de la tarjeta. En
muchos casos, el tamaño de la tarjeta puede funcionar en contra de ella al escribir los casos de prueba.
Elección de software en ClickTactics

ClickTactics es un proveedor de soluciones de marketing que escribe componentes de software accesibles desde la web.
Comenzaron con tarjetas de notas pero cambiaron al software, V1: XP de VersionOne.
Mark Mosholder, Gerente Senior de Producto en ClickTactics, dice que una razón para el cambio es que su fuerza de
ventas y alta gerencia se distribuyen en múltiples sitios. Con las partes interesadas remotas no podían decir "ve a mirar el
tablero", por lo que pasaron mucho tiempo actualizando a la alta gerencia y otras partes interesadas remotas. Además,
cuando usaban tarjetas de notas, tenían problemas con las tarjetas que se perdían ocasionalmente y luego se
encontraban semanas después en una pila debajo de un escritorio.
Mantener historias en el software VersionOne permitió a ClickTactics promover su uso de XP como herramienta
de ventas. Al usar el software, les dan a algunos clientes una visibilidad limitada de sus iteraciones. Luego
promueven la velocidad con la que pueden cambiar las nuevas versiones para los clientes diciéndoles: "Podemos
ofrecerle una nueva funcionalidad en tres semanas".
Mark dice que no ha habido inconvenientes en su decisión y dice que volvería a tomar la misma decisión.
Un proyecto que busque la certificación ISO (Organización Internacional de Normalización), o similar, que
requiera trazabilidad desde una declaración de requisitos hasta el código y las pruebas probablemente
favorecerá al software. Debería ser posible lograr la certificación ISO con tarjetas de notas escritas a mano, pero
la implementación y la demostración de procedimientos adecuados de control de cambios sobre una baraja de
cartas probablemente supere las otras ventajas que pueden tener las tarjetas.
Del mismo modo, un equipo que no está ubicado probablemente preferirá el software a las tarjetas de notas.
Cuando uno o más desarrolladores, o especialmente el cliente, es remoto, es muy difícil trabajar con papel.
Una ventaja adicional de las tarjetas de notas es que son muy fáciles de clasificar y pueden clasificarse de
varias maneras. Una colección de historias se puede clasificar en pilas de alta, media y baja prioridad. O
podría clasificarse en un orden más preciso con la primera historia con mayor prioridad que la segunda y la
segunda con mayor prioridad que la tercera y así sucesivamente.
A diferencia de muchos de los partidarios más devotos de cualquier técnica, mi opinión es que ambos
enfoques pueden ser apropiados. Recomiendo comenzar con tarjetas
U SER S TORIES Y EL U SER yo Interfaz 181
y ver cómo funcionan en su entorno. Luego, si hay una razón convincente para usar el software, cambie.
Usando un Wiki en Diaspar Software Services

JB Rainsberger es el fundador de Diaspar Software Services, un desarrollador de software.
empresa de consultoría y consultoría. Como consultor, JB no siempre puede estar en el sitio con sus clientes. En
esas situaciones, JB usa un wiki para mejorar la comunicación entre él y su cliente remoto. Un wiki es un
conjunto de páginas web especiales que cualquier persona que vea la página puede editar. JB y Diaspar
Software usan FitNesse como wiki. En lugar de escribir una tarjeta de historia para cada historia, crean una
nueva página para cada historia.
JB informa que esto funcionó extremadamente bien en un pequeño proyecto reciente. Como el tenia
preguntas sobre una historia, él anotaría la pregunta en la página y agregaría el texto "todo". Varias veces a la
semana, su cliente revisaba el wiki, buscaba "todo" y respondía las preguntas. Los problemas urgentes se
manejaron por teléfono; pero debido a la eficacia del uso de un wiki, sorprendentemente hubo pocos problemas
urgentes. JB ha trabajado con tarjetas de notas en papel en otros proyectos, pero informa que en este proyecto,
con su cliente remoto, nunca hubo un momento en que deseara tener las historias en las tarjetas, así como en la
wiki.
Aunque JB usa el wiki de FitNesse para escribir pruebas ejecutables para cada proyecto, señala que "tener
a todos en la sala hace innecesario poner historias en un wiki".
Historias de usuarios y la interfaz de usuario
Se ha señalado que los métodos ágiles ignoran en gran medida los problemas de diseño de la interfaz de usuario.
Hasta cierto punto, esto es comprensible: los procesos ágiles son altamente iterativos, mientras que los enfoques
tradicionales para el diseño de la interfaz de usuario han sido importantes con una gran dependencia del diseño inicial.
Es importante comprender los riesgos potenciales en la búsqueda de un enfoque ágil basado en la historia para una
aplicación con una interfaz de usuario significativa o importante.
Es uno de los principios del desarrollo ágil que podemos refinar iterativamente un sistema. Las historias de
usuario nos permiten diferir las conversaciones hasta poco antes de que los desarrolladores estén listos para
agregar soporte para la historia al programa. A veces, diferir estas conversaciones hace que los desarrolladores
modifiquen ligeramente las partes existentes de una aplicación; pero la creencia es que el costo de estas pequeñas
modificaciones está más que justificado por los ahorros en no mantener discusiones sobre los requisitos
acerca de las características que luego se eliminarán, y por los beneficios de permitir que el cliente dirija el
producto con muchas correcciones de curso más pequeñas.
Si estos cambios ocurren debajo de la interfaz de usuario de una aplicación, entonces esta creencia puede ser
cierta. Sin embargo, ¿qué sucede cuando estos cambios afectan la interfaz de usuario? Larry Constantine (2002)
escribe que:
Para las interfaces de usuario, la arquitectura (la organización general, la navegación y el aspecto y la
sensación) deben diseñarse para ajustarse a la panoplia completa de tareas a cubrir. Cuando se trata de
la interfaz de usuario, el refinamiento posterior de la arquitectura no es tan aceptable porque significa
cambiar el sistema para los usuarios que ya han aprendido o dominado una interfaz anterior. Incluso
pequeños ajustes en la ubicación o forma de las características pueden ser problemáticos para los
usuarios. Esto significa que si la interfaz de usuario será importante para el éxito de nuestro producto, es
posible que tengamos que pensar en la interfaz de usuario desde el principio. Si cambiar la interfaz de
usuario causará problemas a los usuarios, entonces probablemente haya una restricción no escrita en el
proyecto: "Cambie la interfaz de usuario lo menos posible una vez que se haya iniciado".
Constantine y Lockwood (2002) proponen un diseño ágil centrado en el uso como una solución. El diseño ágil
centrado en el uso se basa en casos de uso esenciales o casos de tareas en lugar de historias de usuarios. Sin
embargo, podemos reemplazar los casos de uso esenciales con historias, lo que conduce a la siguiente variación
basada en historias en el diseño centrado en el uso ágil:
1. Realizar el modelado de roles de usuario.
2. Arrastre por historias de usuarios de alto nivel.
3. Priorizar historias.
4. Refinar historias de alta y media prioridad.
5. Organizar historias en grupos.
6. Crear un prototipo en papel.
7. Refina el prototipo.
8. Comience a programar.
El primer paso es mantener una sesión de modelado de roles de usuario, exactamente como se describe en el
Capítulo 3, "Modelado de roles de usuario". Para completar los siguientes pasos, inicie un taller de redacción de historias
como se describe en el Capítulo 4, "Recopilación de historias". En el taller, enfóquese inicialmente en capturar las historias
de más alto nivel, probablemente no más de dos docenas.
U SER S TORIES Y EL U SER yo Interfaz 183
Luego, priorice las historias de alto nivel en tres grupos: las historias de alta prioridad deben estar en el próximo
lanzamiento, las historias de prioridad media se desean para el próximo lanzamiento, y las historias de baja
prioridad se pueden diferir hasta un lanzamiento posterior. Ponga a un lado las historias de baja prioridad mientras
refina las historias de alta y mediana prioridad en historias más pequeñas. Estas historias deben ser del tamaño con
el que trabajará para planificar el lanzamiento.
A continuación, organice las historias de alta y media prioridad en grupos que tengan una alta
probabilidad de realizarse juntas. Luego, dibuje prototipos en papel para cada grupo de historias. Después de
crear los prototipos en papel, muéstrelos a los usuarios (o representantes del usuario si es necesario) y refine
los prototipos en función de sus comentarios.
Si agrega estos pasos a su proyecto, recuerde mantener el proceso lo más liviano posible. Algunas de
las historias que se identificaron y que se están prototipando en una interfaz de usuario podrían terminar
siendo eliminadas del proyecto antes de que se desarrollen. Evite pasar más tiempo del necesario. Para la
mayoría de las aplicaciones, esto puede implicar desde unos pocos días hasta no más de unas pocas
semanas (para software comercial con usuarios remotos).
Escribir dos
Hace unos años estaba trabajando en un proyecto y trajimos a Ward Cunningham para consultar y evaluar el
proyecto. En ese momento, el equipo estaba luchando con preguntas sobre la interfaz de usuario. Hubo muchos
debates candentes sobre si los usuarios preferirían una interfaz basada en navegador o si preferirían una aplicación
nativa. Nuestro grupo de marketing les había preguntado a los usuarios, pero no estábamos seguros de haber
encuestado a suficientes usuarios o de haber realizado la investigación de la manera correcta.
Ward resolvió la pregunta diciéndonos "Escribe dos interfaces de usuario". Su lógica era que ninguno de los
dos sería difícil de escribir y, entre los dos, mantendrían honesto el nivel medio de la aplicación. Con dos interfaces
de usuario, ninguna funcionalidad se movería de manera inapropiada al nivel de cliente si hacerlo significa que la
funcionalidad tendría que escribirse dos veces.
La sugerencia de Ward era correcta. Nosotros, por supuesto, no escuchamos, pensando que sería demasiado costoso
desarrollar dos interfaces de usuario completas. Cuando el producto terminó, nuestros clientes nos hicieron saber que
habíamos elegido la tecnología de interfaz de usuario incorrecta. Y se comenzó rápidamente un proyecto para agregar una
segunda interfaz de usuario.
Reteniendo las historias
Las discusiones sobre si las historias deben ser retenidas son comunes. Por un lado están aquellos que
dicen que el placer de romper una tarjeta completa supera cualquier valor de conservar la tarjeta. En el
lado opuesto está la multitud más conservadora que preferiría salvar la historia que arriesgarse a tirarla y
luego necesitarla más tarde.
Si está utilizando un software para guardar sus historias, hay muy pocas razones para deshacerse de las historias
completas. Es posible que obtenga un poco de placer y sentimientos de cierre al eliminar una historia electrónica, pero
probablemente no sea tan grande como el placer visceral de rasgar una tarjeta física por la mitad.
Si está usando tarjetas de notas de papel, puede haber un placer tangible asociado con terminar una
tarjeta y romperla por la mitad. He usado tarjetas para guiar la escritura de este libro y cada vez que
completo una nueva sección o revisión, rompo la tarjeta. Sin embargo, cuando estoy trabajando en un
proyecto de software, en lugar de un libro, prefiero conservar las tarjetas y archivarlas en un estante con una
banda elástica.
A lo largo de los años, he estado involucrado en un puñado de situaciones en las que he estado agradecido de
haber conservado los requisitos. Estos son algunos de los casos:
• La compañía para la que trabajaba estaba siendo comprada. La empresa adquirente estaba
intrigada por nuestro proceso de desarrollo de software liviano, pero tenían su propio enfoque
fuertemente orientado a la cascada con numerosas puertas y puntos de cierre por los que tenía que
pasar cada proyecto. Debido a que pude mostrarles nuestro proceso (desde historias hasta códigos
y pruebas), nos permitieron continuar con nuestro proceso y no adoptar el estándar de toda la
empresa. Aún mejor, eventualmente pudimos hacer algunos avances en la difusión de nuestro
proceso en otras divisiones de la empresa.
• En varias ocasiones he estado involucrado en reescribir completamente productos comerciales. En

un caso, la primera versión de un producto fue un fracaso comercial debido a algunas malas
elecciones tecnológicas. El producto fue reescrito completamente y se convirtió en un éxito
moderado. Otro producto fue un éxito fenomenal como aplicación cliente-servidor, y cinco años
después, la compañía quería que fuera reescrito y disponible en la web. Siempre que había historias
o requisitos obsoletos, era útil tenerlos cerca.
• En otra situación más, estuve involucrado con una pequeña startup que estaba tratando de cerrar un
trato con una empresa mucho más grande. Si el acuerdo se cerrara, empujaría a la compañía a un
territorio rentable, y el jefe también prometía grandes bonos de cinco dígitos a todos los
desarrolladores. Nos pidieron "pro-
S TORIES PARA si UGS 185
vide una copia de los requisitos ". Comencé a seguir el camino de describir cómo realmente no nos
enfocamos en los requisitos escritos y que en su lugar nos enfocamos en la conversación y la
colaboración. Pude sentir que la conversación no iba a terminar bien y que la rentabilidad de la
compañía y las grandes bonificaciones para desarrolladores se estaban evaporando. Cambié de
marcha y les dije cómo escribimos los requisitos en forma de historias de usuarios. Les gustó la idea.
Afortunadamente nuestras historias fueron almacenadas electrónicamente en ese proyecto. Los
cortamos del sistema en el que se encontraban, los pegamos en un documento de Word, agregamos
una página de portada y una página de firma y todos estaban felices. Teniendo en cuenta la variedad
de ocasiones en las que he encontrado útil tener historias retenidas, mi recomendación es que también
lo haga. Si estás usando software, mantenga el software instalado o imprima un informe y archívelo en
algún lugar. Si está usando tarjetas, guarde las tarjetas o cópielas de tres en tres en papel.
Historias para errores
Una pregunta muy común es la relación entre historias e informes de errores. Lo que he encontrado que funciona
mejor es considerar cada informe de error como su propia historia. Si la reparación de un error puede llevar tanto
tiempo como una historia típica, ese error puede tratarse como cualquier otra historia. Sin embargo, para los errores
que el equipo espera poder corregir rápidamente, debe combinar los errores en una o más historias. Con las tarjetas,
puede hacerlo fácilmente engrapando las tarjetas de la historia junto con una tarjeta de la historia de portada. Luego,
para fines de planificación, la colección de errores puede tratarse como una sola historia.
¿Qué pasa con los colores?
Algunos equipos prefieren usar tarjetas de diferentes colores para indicar el tipo de historia en la tarjeta. Por ejemplo, las
tarjetas blancas tradicionales podrían usarse para historias normales. Las tarjetas rojas podrían usarse para errores, las
tarjetas azules podrían usarse para tareas de ingeniería, etc.
Para mí, usar tarjetas de colores siempre parece una buena idea en teoría; pero en la práctica no vale la molestia extra.
En lugar de mantener un suministro de tarjetas blancas en mi bolsillo, tengo que asegurarme de llevar siempre algunas de
cada color. Si me quedo sin escribir y escribo la historia sobre lo que esté disponible, entonces necesito volver a escribir la
historia más tarde. Pero si crees que los colores te ayudarán a organizar tus historias, pruébalo. Me atendré a lo que es
simple: una enorme pila de cartas blancas.
Resumen
• Los requisitos no funcionales (como rendimiento, precisión, portabilidad, reutilización,

mantenibilidad, interoperabilidad, capacidad, etc.) a menudo se pueden manejar creando tarjetas de
restricción. Si el sistema tiene requisitos que son más complejos que esto, complemente su enfoque
de historia de usuario con cualquier formato o técnica adicional que exprese mejor esos requisitos.
• Ni las tarjetas de notas ni un sistema de software son la mejor manera de escribir historias en todos los casos. Haga coincidir
la herramienta con el proyecto y el equipo.
• Un proceso iterativo puede conducir a cambios iterativos en la interfaz de usuario. A los usuarios, que
se acostumbran a aspectos muy específicos de la interfaz, no les gustan los cambios en la interfaz de
usuario que afectan cómo han aprendido a operar el software. Considere agregar algunas prácticas del
diseño centrado en el uso ágil para evitar iterar la interfaz de usuario.
• Hay una cierta alegría en romper una tarjeta de historia tan pronto como esté completa. Pero también hay
razones para retener las tarjetas. Errar en el lado seguro y retener las historias.
• Grape pequeños informes de errores junto con una tarjeta de historia de portada y trátelos como una sola historia.
• Usted es responsable de sugerir y utilizar técnicas y métodos alternativos para expresar los
requisitos cuando corresponda.
• Usted comparte la responsabilidad de decidir qué es lo correcto para su proyecto: tarjetas de notas o un sistema
de software.
• Usted comparte la responsabilidad de comprender las ventajas y desventajas de considerar la

interfaz de usuario general al comienzo del proyecto.
Q UESCIONES 187
• Usted es responsable de solicitar o utilizar técnicas y métodos alternativos para expresar requisitos
si no cree que las historias de los usuarios reflejen con precisión alguna parte de los requisitos.
• Usted comparte la responsabilidad de decidir qué es lo correcto para su proyecto: tarjetas de notas o un sistema
de software.
• Usted comparte la responsabilidad de comprender las ventajas y desventajas de considerar la

interfaz de usuario general al comienzo del proyecto.
Preguntas
16.1 ¿Cómo debe manejar un requisito para que un sistema se amplíe para ser utilizado por 1,000 usuarios
concurrentes?
16.2 ¿Prefiere escribir historias en tarjetas de notas o en un sistema de software? Defiende tu

respuesta.
16.3 ¿Qué impacto tiene un proceso iterativo en la interfaz de usuario de una aplicación?
16.4 Dé algunos ejemplos de sistemas que podrían beneficiarse de una consideración más directa de la
interfaz de usuario que la que normalmente se da en un proyecto ágil.
16.5 ¿Recomienda conservar o deshacerse de las historias una vez que la historia ha sido
desarrollada? Defiende tu respuesta.
PARTE IV
Un ejemplo
La Parte IV reúne todo en un ejemplo completo. En los capítulos siguientes, conocerá los suministros
náuticos de la costa sur y algunos de sus empleados a medida que crean un sitio web para aumentar su
catálogo impreso. Tendrá la oportunidad de identificar roles de usuario, escribir historias con Lori
(vicepresidenta de ventas y marketing de la costa sur y el cliente para este proyecto), estimar las historias,
crear un plan de lanzamiento y luego escribir algunas pruebas de aceptación para las historias en El plan
inicial.
Capítulo 17
Los roles del usuario
En el transcurso de los próximos cinco capítulos, emprenderemos un pequeño proyecto hipotético. En este
capítulo comenzaremos identificando los roles de usuario clave. En los capítulos siguientes, pasaremos a escribir
historias, estimar las historias, planificar un lanzamiento y escribir pruebas de aceptación para las historias en el
lanzamiento.
El proyecto
Nuestra empresa, South Coast Nautical Supplies, ha estado vendiendo suministros de navegación a través de un catálogo
impreso durante treinta años. Nuestros catálogos cuentan con artículos como sistemas de posicionamiento global, relojes,
equipos meteorológicos, equipos de navegación y trazado, balsas salvavidas, chalecos inflables, cartas, mapas y libros.
Hasta ahora, nuestra presencia en Internet ha sido un simple sitio de una página que dirige a las personas a llamar a un
número gratuito para solicitar un catálogo.
Nuestro jefe ha decidido que finalmente deberíamos llegar con los tiempos y comenzar a vender cosas por
Internet. Sin embargo, en lugar de comenzar vendiendo algunos de nuestros artículos más grandes, él quiere que
comencemos vendiendo solo libros. Algunos artículos en nuestro catálogo cuestan más de $ 10,000 y hasta que
sepamos que nuestro sitio funciona bien y no pierde pedidos, no queremos arriesgarnos con artículos caros. Pero si
descubrimos que a nuestros clientes les gusta poder hacer pedidos en línea, y si hacemos un buen trabajo en el sitio,
ampliaremos y venderemos el resto de nuestros productos en el sitio.
Ah, y lo último que dice el jefe es que el sitio debe estar activo en treinta días para que podamos
capturar el aumento de las ventas durante los meses de verano pico.
Identificando al cliente
El proyecto necesita un cliente que nos ayude a identificar y escribir historias. Los clientes de este producto
son los marineros que compran los libros y todos están afuera
191
192 T ÉL U SER R OLES
la compañia. Por lo tanto, necesitamos un cliente interno que pueda actuar como un proxy para los verdaderos
clientes finales. Para esto, el jefe designa a Lori, quien es la vicepresidenta de Ventas y Marketing.
En una reunión inicial con Lori, ella proporciona más antecedentes sobre el sistema que necesita. Ella quiere
una "librería típica / sitio de comercio electrónico". Quiere que los clientes puedan buscar libros de varias maneras
(no pedimos aclaraciones en este momento), quiere que los usuarios puedan mantener listas de libros que
comprarán más tarde, quiere que los usuarios califiquen y revisar los libros que compran, y ella quiere que los
usuarios verifiquen el estado de un pedido. Hemos visto muchos sitios como este, así que le decimos a Lori que
estamos listos para comenzar.
Identificar algunos roles iniciales
Lo primero que hacemos es reunir a algunos de los desarrolladores junto con Lori en una habitación con una
mesa grande. Lori ya ha investigado el mercado y conoce la demografía de nuestros clientes típicos. Lori y los
desarrolladores escriben las siguientes tarjetas de roles de usuario, que se colocan como se muestra en la
Figura 17.1:
• Marinero hardcore
• Marinero novato
• Nuevo marinero
• Comprador de regalos
• Cónyuge que no navega
• Administrador
• Vicepresidente de ventas
• Capitán de la Carta
• Marinero experimentado
• Escuela de vela
• Biblioteca
• Instructor
C SOLIDANTE Y norte FLECHA 193
Consolidando y Estrechando
Después de que los nombres de los roles de usuario estén escritos en las tarjetas, necesitamos eliminar duplicados
o casi duplicados, considerar si alguna función debe fusionarse y elaborar una lista refinada de roles de usuario con
los que comenzará el proyecto. La forma más fácil de comenzar es tratando de eliminar cualquier tarjeta que se
coloque completamente sobre otra tarjeta, lo que indica que su autor pensó que eran duplicados.
En este caso, la nueva carta de marinero se ha colocado encima de la carta de marinero novato. Los
autores de esas tarjetas explican lo que pretendían de ellos, y cualquier otra persona agrega cualquier
comentario que deseen. Resulta que hay una distinción entre un marinero novato y un nuevo marinero. Un
nuevo marinero es alguien nuevo en el deporte de la vela; tal vez ella esté tomando lecciones o haya
navegado algunas veces. El autor de la tarjeta de Marinero novato en realidad significaba ese papel para
representar a alguien que puede haber estado navegando durante años, pero no con la frecuencia
suficiente para ser bueno en eso. El grupo decide que aunque estos roles parecen ser ligeramente
diferentes, no son lo suficientemente diferentes como para que valga la pena tener dos roles para ellos. Se
fusionan en un solo papel, Marinero novato, y la nueva carta de Marinero se rompe y se tira.
Marinero novato Escuela de vela
Instructor
Nuevo marinero
Marinero hardcore
Capitán de la Carta
Marinero
experimentado
Biblioteca
Cónyuge que no
navega
Administrador VP de ventas Comprador de regalos
Figura 17.1 Posicionamiento de las tarjetas de rol de usuario.
A continuación, el grupo considera las tarjetas superpuestas de la Escuela de Vela y el Instructor. El autor de
la tarjeta de Instructor explica que el papel representa a los marineros que imparten clases de vela. Los
instructores, argumenta, con frecuencia compran copias de libros para sus estudiantes o tal vez compilan listas
de libros que los estudiantes son
requerido para leer. La autora de la tarjeta de roles de la Escuela de Vela indica que esto es en parte lo que
pretendía para esa tarjeta. Sin embargo, ella pensó que el uso típico sería un administrador de la escuela
en lugar del propio instructor de navegación. Lori, el cliente, nos aclara esto al decirnos que incluso si es un
administrador de la escuela, el administrador tendrá muchas de las mismas características de un Instructor.
Como un Instructor es más claramente una persona soltera que la Escuela de Vela, la tarjeta de la Escuela
de Vela está rota.
La tarjeta Hardcore Sailor se ha colocado de manera que se superpone parcialmente con las tarjetas de roles
de Instructor, Marinero experimentado e incluso las cartas de Capitán chárter. El grupo discute estos roles a
continuación y descubre que el rol de Marinero Hardcore fue escrito para capturar el tipo de marinero que
generalmente sabe exactamente qué libros quiere. El Hardcore Sailor conoce, por ejemplo, el nombre del mejor
libro sobre navegación. Por lo tanto, sus patrones de búsqueda serán bastante diferentes de los de un marinero
menos conocedor, incluso un marinero experimentado. El rol de marinero experimentado representa a personas
muy familiarizadas con los productos que ofrecerá el sitio pero que pueden no recordar automáticamente los
nombres de los mejores libros.
Después de hablar sobre Captain Captain, el equipo decide que el papel es esencialmente el mismo que
Hardcore Sailor y la tarjeta se rompe.
En este punto, el equipo ha decidido mantener a un marinero novato, un instructor, un marinero duro y un
marinero experimentado. Han eliminado New Sailor, Charter Captain y Sailing School. Y todavía tienen que
considerar al Comprador de regalos, el Cónyuge que no navega, el Administrador y el Vicepresidente de
ventas. Los autores de estas tarjetas de roles restantes explican su intención.
El rol Comprador de regalos representa a alguien que no es marinero pero que está comprando un regalo
para alguien que sí lo es. El autor de la función de cónyuge que no navega indica que esta fue la intención detrás
de esa tarjeta. Después de una discusión sobre las dos tarjetas de rol, el equipo decide romper ambas y
reemplazarlas con una tarjeta consolidada para el rol de Comprador de regalos sin vela.
El autor de la función Administrador explica que esta función representa el trabajo que realizarán uno o
más administradores que necesitarán cargar datos en el sistema y, de lo contrario, mantener el sistema en
funcionamiento. Este es el primer rol del que habla el equipo que representa a alguien que no está
comprando artículos del sitio. Después de discutirlo, deciden que el papel es importante, y Lori indica que
tendrá algunas historias sobre cómo se mantendrá el sistema y cómo se agregarán nuevos elementos al
inventario del sitio.
El papel del Vicepresidente de ventas se discute a continuación. Este es otro papel que no es de
compra. Sin embargo, el CEO ha ordenado que el nuevo sistema se observe de cerca para ver cómo está
afectando las ventas. El equipo considera dejar el papel fuera porque no cree que haya muchas historias
específicamente para el papel. En
R VIEJO METRO ODELING 195
Al final, deciden incluir el rol pero cambiarle el nombre al Visor de informes más genérico.
Se discute el rol de la Biblioteca. Por un momento, el equipo piensa que podría ser similar a una escuela de
vela o incluso a un cónyuge que no navega. Sin embargo, el grupo rechaza estas ideas y decide mantener la
Biblioteca como un rol. Sin embargo, de acuerdo con la directriz para crear roles que representen usuarios
discretos, la tarjeta de la Biblioteca se rompe y se reemplaza con una tarjeta de Bibliotecario.
En este punto, el equipo se ha decidido por los roles que se muestran en la Figura 17.2.
Marinero novato Instructor
Marinero hardcore
Marinero
bibliotecario
experimentado
Comprador de regalo que no Administrador Visor de informes

navega
Figura 17.2 Los roles después de la consolidación y la discusión inicial.
Modelo a seguir
Luego, el equipo considera cada rol y agrega detalles a las tarjetas de roles. Los detalles variarán según el
dominio y el tipo de software, pero los buenos factores generales a considerar incluyen:
• La frecuencia con la que el usuario usará el software.
• El nivel de experiencia del usuario con el dominio.
• El nivel general de competencia del usuario con las computadoras y el software.
• El nivel de competencia del usuario con el software que se está desarrollando.
• El objetivo general del usuario para usar el software. Algunos usuarios son convenientes, otros
prefieren una experiencia rica, etc.
El grupo discute estos problemas para cada tarjeta de rol. Actualizan las tarjetas de rol de usuario de la siguiente manera:
Marinero Novato: Comprador web experimentado. Se espera que realice 6 compras

durante los primeros 3 meses de navegación. A veces se refiere a un título específico; otras
veces necesita ayuda para seleccionar el libro correcto. Quiere más ayuda para seleccionar
libros apropiados (buen contenido escrito en el nivel apropiado) de lo que obtiene en una
librería física.
Instructor: Se espera que use el sitio web con frecuencia, a menudo una vez por semana. A
través del grupo de ventas telefónicas de la compañía, un instructor realiza pedidos similares
con frecuencia (por ejemplo, 20 copias del mismo libro). Competente con el sitio web pero
generalmente algo nervioso con las computadoras. Interesado en obtener los mejores precios.
No le interesan las reseñas u otros "adornos".
Marinero duro: Generalmente sin experiencia con las computadoras. Un gran comprador
de artículos del catálogo de la compañía, pero no un gran comprador de libros. Nos
compra muchos equipos adicionales. Por lo general, sabe exactamente lo que está
buscando. No quiere sentirse estúpido al intentar usar el sitio.
Marinero experimentado: Competente con las computadoras. Se espera ordenar una o dos veces
por trimestre, tal vez con mayor frecuencia durante el verano. Conocedor de la navegación, pero
generalmente solo para las regiones locales. Muy interesado en lo que otros navegantes dicen son los
mejores productos y los mejores lugares para navegar.
Comprador de regalo que no navega: Por lo general, es competente con las computadoras (o no elegiría
comprar un regalo en línea). No es marinero y tendrá una familiaridad pasajera en el mejor de los casos
con los términos de navegación. Por lo general, buscará un libro muy específico, pero puede estar
buscando un libro sobre un tema determinado.
Bibliotecario: Competente con las computadoras. Sabe exactamente lo que está buscando
y prefiere ordenar por ISBN en lugar de autor o incluso título. No está particularmente
interesado en adornos como envoltura de regalos o seguimiento de envíos. En general,
realizará un pequeño número de pedidos por año, pero cada pedido será para más libros
que un pedido individual típico.
Administrador: Muy competente con las computadoras. Tiene al menos una familiaridad pasajera
con la navegación. Accede diariamente al back-end del sistema como parte de su trabajo.
Interesado en aprender rápidamente el software pero querrá atajos de usuario avanzados más
adelante.
UNA DDING PAGS ERSONAS 197
Visor de informes: Competencia moderada con las computadoras, principalmente con

programas de negocios como hojas de cálculo y procesadores de texto. Interesado en
datos altamente detallados sobre cómo funciona el sistema, qué compran o no los
visitantes y cómo navegan o buscan en el sitio. Muy dispuesto a cambiar la velocidad por
potencia y profundidad.
Agregar personas
A veces vale la pena pasar unos minutos agregando una persona al trabajo realizado hasta ahora. El
equipo le pregunta a Lori cuál de estos roles de usuario debe estar absolutamente satisfecho con el nuevo
sitio web para que tenga éxito. Ella dice que los Hardcore Sailors son importantes debido a su longevidad
como clientes. Pero, aunque navegan con frecuencia, no son grandes compradores de libros. Por otro lado,
la gran población de marineros experimentados es importante y ese grupo compra una cantidad
significativa de libros. Lori agrega que quizás el papel más importante para satisfacer es el Instructor. Los
instructores pueden ser responsables de la venta de cientos de libros durante todo el año. De hecho,
continúa, con el nuevo sitio web que le gustaría investigar formas de eventualmente ofrecer incentivos
financieros a los instructores que remiten a sus estudiantes al sitio.
Con esta información en mente, el equipo decide desarrollar dos personas. La primera persona es Teresa.
Teresa ha estado navegando por cuatro años. Es la directora ejecutiva de una empresa de biotecnología que
cotiza en bolsa y se siente completamente cómoda al realizar pedidos en línea. Teresa navega principalmente
durante el verano, por lo que solo usará el sitio durante la primavera o el verano, cuando se prepare para un
crucero. Está muy ocupada y está interesada en utilizar nuestro sitio para ahorrar tiempo y encontrar libros que
no haya visto antes. Teresa está casada con Tom, que no navega solo, sino que la ha acompañado en dos
cruceros por el Mediterráneo.
La segunda persona es el Capitán Ron. El Capitán Ron ha estado navegando durante 40 años y dirige
una escuela de vela en San Diego. Se retiró de la enseñanza secundaria hace cinco años y ha sido
instructor de navegación desde entonces. Ha sido un cliente fiel del catálogo durante diez años. Todavía
está un poco intimidado por la computadora en su oficina, pero está lo suficientemente intrigado al ordenar
en la web que esperamos que lo pruebe.
Una advertencia sobre Teresa y el Capitán Ron

Es discutible si vale la pena agregar personas a este sistema. Solo agregue una persona si hacerlo ayuda a
su equipo a pensar en historias para un usuario crítico de su sistema. Para el sistema de suministros náuticos de
la costa sur descrito en estos capítulos, probablemente no valga la pena el esfuerzo extra.
Sin embargo, dado que las personas pueden ser una valiosa adición a su caja de herramientas, he incluido a
Teresa y al Capitán Ron para proporcionar un ejemplo más completo.
Capítulo 18
Las historias
Para generar la lista inicial de historias, el equipo decide convocar un taller de redacción de historias donde
dedicarán una o dos horas a escribir tantas historias como puedan. Durante un taller de redacción de
cuentos, un enfoque es simplemente escribir cuentos en cualquier orden, independientemente de qué rol o
persona pueda actuar en el cuento. Un enfoque alternativo es comenzar con un rol o persona de usuario
específico y escribir todas las historias que el equipo pueda pensar antes de pasar al siguiente rol o persona.
Los resultados deben ser los mismos con cualquier enfoque. En este caso, el equipo lo discute y elige
trabajar a través de cada rol y persona.
Cuentos para Teresa
El equipo decide comenzar con Teresa, una persona identificada en el capítulo anterior, ya que el miembro cliente
del equipo, Lori, ha dicho que es fundamental que el nuevo sitio web satisfaga a Teresa. El equipo sabe que
Teresa está buscando velocidad y conveniencia. Ella es una verdadera usuaria poderosa y no le importará un
poco de complejidad adicional siempre que la complejidad la ayude a encontrar lo que está buscando más
rápidamente. La primera historia que escriben es Story Card 18.1.
Un usuario puede buscar libros por autor, título o número ISBN.
■ Tarjeta de historia 18.1
Los desarrolladores tienen algunas preguntas sobre esta historia. Por ejemplo, ¿puede el usuario
buscar por autor, título y ISBN al mismo tiempo, o quiere Lori que busque por un solo criterio a la vez?
Dejan que estas preguntas se asienten por ahora y se centran en obtener más historias preliminares
escritas.
199
200 T ÉL S TORIES
A continuación, Lori dice que después de buscar un libro, un usuario puede ver información detallada
sobre un libro. Ella da algunos ejemplos del tipo de información que quiere decir y luego escribe Story Card
18.2.
Un usuario puede ver información detallada en un libro. Por ejemplo, número de páginas,
fecha de publicación y una breve descripción.
Probablemente haya más que quiera además de estos tres detalles, pero los desarrolladores pueden preguntarle más
tarde cuándo están listos para codificar esta historia.
Como un sitio de comercio electrónico típico, el equipo sabe que los usuarios necesitarán un "carrito de
compras" y que los usuarios comprarán los libros en sus carritos de compras. Lori, el cliente, también dice que
un usuario necesitará la oportunidad de eliminar libros del carrito de compras antes de que se procese el pedido.
Esto lleva a Story Card 18.3 y Story Card 18.4.
Un usuario puede poner libros en un "carrito de compras" y comprarlos cuando haya terminado
de comprar.
■ Carta de historia 18.3
Un usuario puede eliminar libros de su carrito antes de completar un pedido.
Para procesar realmente un pedido con una tarjeta de crédito, el sistema necesitará conocer la tarjeta de crédito
para cobrar y cierta información de dirección. Esto lleva a la tarjeta de historia 18.5.
Para comprar un libro, el usuario ingresa su dirección de facturación, la dirección de envío y la

información de la tarjeta de crédito.
S TORIES PARA T ERESA 201
Lori les recuerda a los desarrolladores que, dado que Teresa solo ha estado navegando durante cuatro años, no
siempre sabrá exactamente qué libro quiere. Para Teresa, el sitio debe incluir características para que los clientes
califiquen y revisen los artículos. Esto lleva a Lori a escribir la tarjeta de historia 18.6.
Un usuario puede calificar y revisar libros.
Como Teresa desea poder realizar el pedido lo más rápido posible, el equipo decide que el sistema necesita
recordar la información de envío y facturación. Es posible que algunos de los clientes del sitio, por ejemplo, el rol
de Comprador de regalos que no navegan, no compren con mucha frecuencia, por lo que estos clientes pueden no
querer crear una cuenta reutilizable. Del mismo modo, cualquier paso adicional la primera vez puede asustar al
Capitán Ron, que siempre está un poco tentativo con los nuevos sitios web. Entonces, Lori decide que un usuario
puede comprar libros con o sin una cuenta y escribe Story Card 18.7 y Story Card 18.8.
Un usuario puede establecer una cuenta que recuerde la información de envío y

facturación.
Un usuario puede editar la información de su cuenta (tarjeta de crédito, dirección de envío,

dirección de facturación, etc.).
El equipo también sabe que Teresa quiere poner artículos en una lista de deseos de artículos que quiere
pero que no está lista para comprar hoy. Los comprará para ella más tarde o le dirá a su esposo, Tom, y él
comprará artículos de su lista de deseos. Entonces, Lori escribe Story Card 18.9 y Story Card 18.10.
Queremos asegurarnos de que quien programa Story Card 18.10 sepa que un usuario puede seleccionar
elementos de su propia lista de deseos o la de otra persona. Nos aseguramos de anotar eso en la tarjeta (entre
paréntesis en este caso).
202 T ÉL S TORIES
Un usuario puede colocar libros en una "lista de deseos" que es visible para otros visitantes del
sitio.
Un usuario puede colocar un artículo de una lista de deseos (incluso de alguien más) en su
carrito de compras.
Debido a que la velocidad será importante para Teresa, Lori también identifica una restricción de rendimiento
relacionada con el tiempo que lleva ordenar un libro. Ella escribe Story Card 18.11.
Un cliente habitual debe poder encontrar un libro y completar un pedido en menos

de 90 segundos. (Restricción)
En este caso, Lori ha optado por centrarse en el tiempo que le toma a un cliente recurrente buscar un
libro y completar su pedido. Este es un buen requisito de rendimiento porque captura todos los aspectos de
la experiencia del usuario con el sitio. Las consultas rápidas de bases de datos y el middleware no cuentan
mucho si la interfaz de usuario es tan confusa para navegar que al usuario le lleva tres minutos llegar a la
pantalla de búsqueda. Esta historia refleja esto mejor que una historia como "Las búsquedas deben
completarse en dos segundos". Naturalmente, Lori puede agregar más restricciones de rendimiento, pero
generalmente es suficiente elegir algunas amplias como esta historia.
Historias para el Capitán Ron
Queda claro que el equipo se está quedando sin historias para Teresa, la marinera experimentada. Entonces,
acuerdan cambiar el enfoque al Capitán Ron, quien dirige una escuela de vela y es un poco más tentativo con
las computadoras que Teresa. Cuando Cap-
S TORIES PARA A norte OVICE S AILOR 203
Cuando Ron llega al sitio, normalmente sabe exactamente lo que está buscando. Esto lleva a Lori a escribir la
tarjeta de historia 18.12 y la tarjeta de historia 18.13.
Un usuario puede ver un historial de todos sus pedidos anteriores.
Un usuario puede volver a comprar artículos fácilmente al ver pedidos anteriores.
Estas historias le permitirán al Capitán Ron volver a mirar sus viejas órdenes y recomprar artículos de
esas órdenes. Sin embargo, Lori señala que el Capitán Ron también puede querer comprar un artículo que
miró recientemente, incluso si no lo ha comprado previamente. Ella escribe Story Card 18.14.
El sitio siempre le dice a un comprador cuáles son los últimos 3 (?) Artículos que vio
y proporciona enlaces a ellos. (Esto funciona incluso entre sesiones).
Historias para un marinero novato
A continuación, el equipo pasa a considerar el papel de marinero novato. Las necesidades de un marinero novato se
superponen en gran medida a las de Teresa y el capitán Ron. Pero Lori decide que sería útil que un marinero novato
pudiera ver una lista de nuestras recomendaciones. Aquí, el marinero novato podría encontrar los libros que
recomendamos sobre una variedad de temas. Ella escribe Story Card 18.15.
Un usuario puede ver qué libros recomendamos sobre una variedad de temas.
204 204 T ÉL S TORIES
Historias para un comprador de regalo que no navega
Cambiando al rol de Comprador de regalos sin navegación, el equipo discute cómo debe ser fácil para un
comprador encontrar la lista de deseos de otra persona. Comienzan a discutir varias soluciones de diseño y qué
campos se utilizarán para la búsqueda hasta que recuerden que las discusiones de diseño deben guardarse
para más adelante. En lugar de diseñar la función en esta reunión, Lori escribe Story Card 18.16.
Un usuario, especialmente un Comprador de regalos que no navega, puede encontrar fácilmente

las listas de deseos de otros usuarios.
Lori también sabe que el sistema debe admitir tarjetas de regalo y envoltorios. Ella escribe Story Card
18.17 y Story Card 18.18.
Un usuario puede elegir tener artículos envueltos para regalo.
Un usuario puede elegir incluir una tarjeta de regalo y puede escribir su propio mensaje para la
tarjeta.
Historias para un visor de informes
Lori dice que el sistema necesita generar informes sobre patrones de compra y tráfico, etc. Todavía no ha
pensado en los informes en detalle, por lo que los desarrolladores escriben una historia simple que les
recuerda que hay informes que desarrollar. Decidirán sobre el contenido del informe más tarde. Por ahora
ella escribe Story Card 18.19.
Pensar en los informes le recuerda a Lori que los informes son muy sensibles. Naturalmente, no
estarán disponibles en el sitio principal que ven los consumidores. Pero, ella dice que solo ciertas personas
dentro de la compañía pueden tener acceso a
S OME UNA DMINISTRACIÓN S TORIES 205
Un Visor de informes puede ver informes de compras diarias desglosados por

categoría de libro, tráfico, libros más vendidos y peores, etc.
informes. Esto podría significar que si puede acceder a un informe, puede acceder a todos, o podría significar que
algunos usuarios solo pueden acceder a algunos informes. Los desarrolladores no le preguntan a Lori sobre eso
ahora y Lori escribe Story Card 18.20.
Un usuario debe estar debidamente autenticado antes de ver los informes.
Para que los informes tengan sentido, Lori dice que la base de datos utilizada por el sitio web debe ser la misma
base de datos utilizada por nuestro sistema telefónico actual. Esto lleva a Lori a escribir la restricción que se muestra
en la Tarjeta de historia 18.21.
Los pedidos realizados en el sitio web deben terminar en la misma base de datos de pedidos que
los pedidos telefónicos. (Restricción)
Algunas historias de administración
En este punto, la atención cambia al rol de usuario Administrador. El equipo piensa instantáneamente en
Story Card 18.22 y Story Card 18.23.
Un administrador puede agregar nuevos libros al sitio.
206 T ÉL S TORIES
Un administrador debe aprobar o rechazar las reseñas antes de que estén

disponibles en el sitio.
La historia sobre la adición de nuevos libros les recuerda que los administradores deben eliminar libros y
también editar libros en caso de que se haya utilizado información incorrecta al agregar el libro. Entonces
escriben Story Card 18.24 y Story Card 18.25.
Un administrador puede eliminar un libro.
Un administrador puede editar la información sobre un libro existente.
Terminando
A estas alturas, Lori está empezando a quedarse sin historias. Hasta ahora, cada historia me viene a la
mente al instante, pero ahora tiene que pensar si hay alguna otra. Debido a que el proyecto se realizará
utilizando un proceso de desarrollo incremental e iterativo, no es importante que piense en cada historia
desde el principio. Pero debido a que quiere una estimación preliminar de cuánto tiempo llevará construir el
sistema, el equipo quiere pensar en todo lo que pueda sin gastar una cantidad excesiva de tiempo. Si a Lori
se le ocurre una nueva historia una vez que hayamos comenzado, tendrá la oportunidad de pasarla al
lanzamiento si deja la misma cantidad aproximada de trabajo.
Los desarrolladores le preguntan a Lori si hay alguna otra historia que ella haya olvidado hasta ahora.
Ella escribe Story Card 18.26.
Lori también les recuerda a los desarrolladores que las necesidades de escalabilidad no son enormes, pero que el
sitio necesita manejar al menos 50 usuarios concurrentes. Escriben esta restricción en la tarjeta de historia 18.27.
W GOLPECITOS U PAGS 207
Un usuario puede verificar el estado de sus pedidos recientes. Si un pedido no se ha

enviado, puede agregar o eliminar libros, cambiar el método de envío, la dirección de
entrega y la tarjeta de crédito.
El sistema debe admitir el uso máximo de hasta 50 usuarios simultáneos.
(Restricción)
Capítulo 19
Estimando las historias
El taller de redacción de historias dio como resultado 27 historias, que se resumen en la Tabla 19.1. El
próximo objetivo es crear un plan de lanzamiento que muestre a Lori al cliente lo que los desarrolladores
esperan lograr y si el sitio puede estar operativo dentro del plazo de treinta días del jefe. Debido a que
probablemente haya más trabajo del que se puede completar en esos treinta días, los desarrolladores
deberán trabajar estrechamente con Lori para priorizar las historias.
Tabla 19.1 La colección inicial de historias.
Texto de historia
Un usuario puede buscar libros por autor, título o número ISBN.
Un usuario puede ver información detallada en un libro. Por ejemplo, número de páginas, fecha de publicación y una
breve descripción.
Un usuario puede poner libros en un "carrito de compras" y comprarlos cuando haya terminado de comprar. Un usuario puede eliminar
libros de su carrito antes de completar un pedido. Para comprar un libro, el usuario ingresa su dirección de facturación, la dirección de
envío y la información de la tarjeta de crédito.
Un usuario puede calificar y revisar libros.
Un usuario puede establecer una cuenta que recuerde la información de envío y facturación. Un usuario puede editar la
información de su cuenta (tarjeta de crédito, dirección de envío, dirección de facturación, etc.).
Un usuario puede colocar libros en una "lista de deseos" que es visible para otros visitantes del sitio. Un usuario puede colocar un artículo
de una lista de deseos (incluso de alguien más) en su carrito de compras.
Un cliente habitual debe poder encontrar un libro y completar un pedido en menos de 90 segundos.
Un usuario puede ver un historial de todos sus pedidos anteriores. Un usuario puede volver a
comprar artículos fácilmente al ver pedidos anteriores.
209
210 mi ESTIMANDO EL S TORIES
Tabla 19.1 La colección inicial de historias. (Continuado)
Texto de historia
Un usuario, especialmente un Comprador de regalos que no navega, puede encontrar fácilmente las listas de deseos de otros usuarios. Un
usuario puede elegir tener artículos envueltos para regalo.
Un usuario puede elegir incluir una tarjeta de regalo y puede escribir su propio mensaje para la tarjeta. Un Visor de
informes puede ver informes de compras diarias desglosados por categoría de libro, tráfico, libros más vendidos y
peores, etc. Un usuario debe estar debidamente autenticado antes de ver los informes.
Los pedidos realizados en el sitio web deben terminar en la misma base de datos de pedidos que los pedidos telefónicos.
qué libros recomendamos sobre una variedad de temas.
Un administrador puede agregar nuevos libros al sitio.
Un administrador debe aprobar o rechazar las reseñas antes de que estén disponibles en el sitio.
Un administrador puede eliminar un libro.
Un administrador puede editar la información sobre un libro existente. Un usuario puede verificar el estado de sus pedidos
recientes. Si un pedido no se ha enviado, puede agregar o eliminar libros, cambiar el método de envío, la dirección de
entrega y la tarjeta de crédito. El sistema debe admitir el uso máximo de hasta 50 usuarios simultáneos.
(?) Artículos que vio y le proporciona enlaces a ellos. (Esto funciona incluso entre sesiones). Un usuario puede ver
Para crear el plan de lanzamiento, se necesita una estimación para cada historia. Como aprendimos en el
Capítulo 8, "Estimación de historias de usuarios", los desarrolladores van a estimar cada historia en puntos de
historia que representan el tiempo ideal, la complejidad o alguna otra medida significativa para el equipo.
busca tanto el autor como el título. Luego quiere un El sitio siempre le dice a un comprador cuáles son los últimos 3
La primera historia
No es necesario comenzar con la primera historia de esta lista ("Un usuario puede buscar libros por autor, título o
número ISBN"), pero en este caso la primera historia es buena para comenzar a estimar. Cuando Lori escribió
esta historia, los desarrolladores no estaban seguros de si Lori quería decir que un usuario podía buscar todos
estos campos al mismo tiempo o si un usuario podía buscar solo uno a la vez. Dado que la respuesta de Lori
podría tener un gran impacto en la estimación, vale la pena preguntarle.
Naturalmente, Lori dice que quiere los dos. Ella quiere un modo de búsqueda básico donde el valor en un campo
T ÉL F IRST S CONSERVADOR 211
pantalla de búsqueda avanzada donde cualquiera o todos estos campos se pueden usar en combinación.
Incluso con ambos modos de búsqueda, la historia no es tan grande; pero hay una división tan fácil entre
los modos que todos aceptan romper la historia y reemplazarla con Story Card 19.1 y Story Card 19.2.
Un usuario puede realizar una búsqueda simple básica que busca una palabra o frase en
los campos de autor y título.
Un usuario puede buscar libros ingresando valores en cualquier combinación

de autor, título y ISBN.
Para estimar las historias, tres programadores, Rafe, Jay y Maria, se reúnen en una habitación con
Lori, la clienta. Traen consigo las tarjetas de la historia y unas pocas docenas de tarjetas en blanco. Los
programadores hablan sobre Story Card 19.1, aclaran algunos detalles al hacer preguntas a Lori, y luego
cada programador escribe su estimación en una tarjeta de índice. Cuando todos hayan terminado, cada
programador levanta su tarjeta para que todos puedan verla. Han escrito:
Rafe: 1
Jay: ½
María: 2
Estos tres desarrolladores discuten sus estimaciones. María explica por qué cree que esta historia vale
dos puntos de historia. Ella habla sobre cómo necesitarán seleccionar un motor de búsqueda, incorporarlo y
solo entonces podrán escribir las pantallas para completar la historia. Jay dice que ya está familiarizado con
todas las opciones de búsqueda probables y está bastante seguro de la dirección que deben tomar, por lo
que su estimación es mucho menor.
Se les pide a todos que escriban una nueva estimación. Cuando están caídos, vuelven a mostrar sus
cartas. Esta vez las cartas dicen:
Rafe: 1
Jay: 1
maria: 1
Eso fue bastante fácil. Jay decidió subir su estimación y María estaba convencida de que podían hacer
la historia más rápido de lo que originalmente pensaba. Ellos
ahora tiene una estimación de puntos de una historia para usar en la Tarjeta de historia 19.1. Comienzan a escribir estimaciones
como se muestra en la Tabla 19.2.
Tabla 19.2 Comenzando a escribir las estimaciones.
Historia Estimar
Un usuario puede realizar una búsqueda simple básica que busca una palabra o frase en los campos 1
de autor y título.
Tenga en cuenta que Lori, el cliente, está presente mientras los programadores elaboran estas
estimaciones, pero no participa escribiendo sus estimaciones. Como Lori no es programadora en el proyecto,
no se le permite estimar. Además, no se le permite jadear o de otra manera expresar conmoción en una
estimación. Si lo hace, socavará el esfuerzo de estimación. Por supuesto, si Lori escucha una estimación que
suena muy fuera de línea (ya sea demasiado alta o demasiado baja), es posible que deba brindar alguna
orientación o aclaración. Por ejemplo, ella puede ofrecer algo en la línea de "Puedo ver cómo podrían ser diez
puntos de la historia mientras lo estás describiendo, pero creo que estoy pidiendo algo mucho, mucho más
simple". Todo lo que realmente quiero es ...
Búsqueda Avanzada
En Story Card 19.2, la búsqueda avanzada. Los programadores vuelven a escribir sus estimaciones en
tarjetas de índice y las entregan al mismo tiempo mostrando:
Rafe: 2
Jay: 1
maria: 2
Rafe dice que la búsqueda avanzada tomará un poco más de tiempo que la búsqueda básica porque hay
más para buscar. Jay está de acuerdo, pero dice que dado que la búsqueda básica ya habrá sido codificada, no
tomará mucho tiempo agregar las funciones de búsqueda avanzada. Sin embargo, María señala que las
historias son independientes y no sabemos qué historia se hará primero. Lori, la clienta, dice que no está segura
de qué quiere hacer primero. Ella está inclinada a hacer la búsqueda básica primero, pero no estará segura
hasta que sepa la estimación (es decir, el costo) de cada uno.
Después de otra ronda o dos de escribir estimaciones en tarjetas, todos están de acuerdo en que si bien hay un
poco más de trabajo en la búsqueda avanzada que en la búsqueda básica, no es mucho y deberían usar
nuevamente una estimación de un punto de la historia.
R ATING Y R EVIEWING 213
Las siguientes historias son fáciles de estimar y ninguna necesita ser dividida. Los desarrolladores llegan a
las estimaciones que se muestran en la Tabla 19.3.
Tabla 19.3 Elaboración de la lista de estimaciones.
Historia Estimar
de autor y título.
Un usuario puede buscar libros ingresando valores en cualquier combinación de autor, título y 1
ISBN.
Un usuario puede ver información detallada en un libro. Por ejemplo, número de páginas, fecha de 1
publicación y una breve descripción.
Un usuario puede poner libros en un "carrito de compras" y comprarlos cuando haya terminado de comprar. 1
Un usuario puede eliminar libros de su carrito antes de completar un pedido. ½
Para comprar un libro, el usuario ingresa su dirección de facturación, la dirección de envío y la información de la 2
tarjeta de crédito.
Calificación y revisión
La siguiente historia ("Un usuario puede calificar y revisar libros") es un poco más difícil. Antes de escribir estimaciones
y mostrarlas entre sí, los desarrolladores hablan sobre esta historia. La parte de calificación no parece difícil, pero las
revisiones parecen más complicadas. Necesitarán una pantalla para que los usuarios ingresen una revisión y tal vez
para obtener una vista previa. ¿Las revisiones serán texto sin formato o el revisor puede escribir en HTML? ¿Los
usuarios solo pueden revisar los libros que nos compraron?
Debido a que las revisiones están mucho más involucradas que solo calificar libros, decidimos dividir la
historia. Esto lleva a Story Card 19.3 y Story Card 19.4.
Un usuario puede calificar libros de 1 (malo) a 5 (bueno). El libro no tiene que ser uno que
el usuario nos haya comprado.
Los programadores estiman Story Card 19.3 como dos puntos y Story Card 19.4 como cuatro puntos de historia.
Un usuario puede escribir una reseña de un libro. Puede obtener una vista previa de la revisión
antes de enviarla. El libro no tiene que ser uno que el usuario nos haya comprado.
Mientras piensan en calificar y revisar libros, también consideran que "un administrador debe aprobar o
rechazar las reseñas antes de que estén disponibles en el sitio". Esto podría ser realmente simple, o podría
estar más involucrado y requerir que el administrador identifique la razón por la que rechaza una revisión o
posiblemente envíe un correo electrónico al revisor. Los programadores no creen que Lori quiera algo
complicado y su discusión conduce a una estimación de dos puntos de la historia.
Cuentas
La siguiente historia (“Un usuario puede establecer una cuenta que recuerda la información de envío y
facturación”) parece sencilla y los desarrolladores la estiman en dos puntos de la historia.
A continuación, los desarrolladores comienzan a estimar "Un usuario puede editar la información de su cuenta
(tarjeta de crédito, dirección de envío, dirección de facturación, etc.)". Esta historia no es muy grande, pero se divide
fácilmente. Dividir una historia como esta suele ser una buena idea porque permite una mayor flexibilidad durante la
planificación del lanzamiento y permite al cliente priorizar el trabajo a un nivel mucho más fino. En nuestro caso, por
ejemplo, Lori puede pensar que es crítico para los usuarios editar sus tarjetas de crédito, pero puede estar dispuesta a
esperar algunas iteraciones para que los usuarios puedan cambiar las direcciones. La historia original se divide, lo que
resulta en Story Card 19.5 y Story Card 19.6. Ninguno de
Un usuario puede editar la información de la tarjeta de crédito almacenada en su cuenta.
Un usuario puede editar las direcciones de envío y facturación almacenadas en su cuenta.
F INISHING THE mi ESTIMACIONES 215
estas historias parecen difíciles, por lo que los programadores estiman Story Card 19.5 como ½ punto de historia y
Story Card 19.6 como un punto.
Terminando las estimaciones
Este mismo proceso se repite para cada una de las historias restantes. Solo algunas de las historias restantes merecen una
mención específica. Primero está la vaga historia: "Un usuario, especialmente un Comprador de regalos que no navega, puede
encontrar fácilmente las listas de deseos de otros usuarios". Cuando se le preguntó sobre sus intenciones con respecto a cómo
los usuarios podían buscar una lista de deseos, Lori proporciona suficientes detalles para que la historia se pueda reescribir
como Story Card 19.7.
Un usuario, especialmente un Comprador de regalos que no navega, puede buscar una lista de
deseos basada en el nombre y el estado de su propietario.
Luego, todos aceptan dividir “Un usuario puede verificar el estado de sus pedidos recientes. Si un
pedido no se ha enviado, puede agregar o quitar libros, cambiar el método de envío, la dirección de entrega
y la tarjeta de crédito ". Una historia cubrirá verificar el estado de un pedido reciente; La segunda historia
cubre el cambio de pedidos que aún no se han enviado. Las historias se muestran en Story Card 19.8 y
Story Card 19.9.
Un usuario puede verificar el estado de sus pedidos recientes.
Si un pedido no se ha enviado, un usuario puede agregar o eliminar libros, cambiar el

método de envío, la dirección de entrega y la tarjeta de crédito.
Finalmente, estas tres historias son restricciones:
• Un cliente habitual debe poder encontrar un libro y completar un pedido en menos de 90 segundos.
• Los pedidos realizados en el sitio web deben terminar en la misma base de datos de pedidos que los pedidos telefónicos.
• El sistema debe admitir el uso máximo de hasta 50 usuarios simultáneos. Como restricciones,
influyen en otras historias, pero no requieren ninguna codificación específica.
Todas las estimaciones
La Tabla 19.4 muestra todas las estimaciones.
Tabla 19.4 La lista completa de historias y estimaciones.
Historia Estimar
de autor y título.
Un usuario puede buscar libros ingresando valores en cualquier combinación de autor, título y 1
ISBN.
Un usuario puede ver información detallada en un libro. Por ejemplo, número de páginas, fecha de 1
publicación y una breve descripción.
Un usuario puede poner libros en un "carrito de compras" y comprarlos cuando haya terminado de comprar. 1
Un usuario puede eliminar libros de su carrito antes de completar un pedido. ½
Para comprar un libro, el usuario ingresa su dirección de facturación, la dirección de envío y la información de la 2
tarjeta de crédito.
Un usuario puede calificar libros de 1 (malo) a 5 (bueno). El libro no tiene que ser uno que el usuario 2
nos haya comprado.
Un usuario puede escribir una reseña de un libro. Puede obtener una vista previa de la revisión antes de 44
enviarla. El libro no tiene que ser uno que el usuario nos haya comprado.
Un administrador debe aprobar o rechazar las reseñas antes de que estén disponibles en el sitio. 2
Un usuario puede establecer una cuenta que recuerde la información de envío y facturación. 2
Un usuario puede editar la información de la tarjeta de crédito almacenada en su cuenta. ½
Un usuario puede editar las direcciones de envío y facturación almacenadas en su cuenta. 1
UNA LL THE mi ESTIMACIONES 217
Tabla 19.4 La lista completa de historias y estimaciones. (Continuado)
Historia Estimar
Un usuario puede colocar libros en una "lista de deseos" que es visible para otros visitantes del sitio. 2
Un usuario, especialmente un Comprador de regalos que no navega, puede buscar una lista de deseos basada 1
en el nombre y el estado de su propietario.
Un usuario puede verificar el estado de sus pedidos recientes. ½
Si un pedido no se ha enviado, un usuario puede agregar o eliminar libros, cambiar el método de envío, 1
la dirección de entrega y la tarjeta de crédito.
Un usuario puede colocar un artículo de una lista de deseos (incluso de alguien más) en su carrito de compras. ½
Un cliente habitual debe poder encontrar un libro y completar un pedido en menos de 90 00
segundos.
Un usuario puede ver un historial de todos sus pedidos anteriores. 1
Un usuario puede volver a comprar artículos fácilmente al ver pedidos anteriores. ½
El sitio siempre le dice a un comprador cuáles son los últimos 3 (?) Artículos que vio y 1
proporciona enlaces a ellos. (Esto funciona incluso entre sesiones).
Un usuario puede ver qué libros recomendamos sobre una variedad de temas. 44
Un usuario puede elegir tener artículos envueltos para regalo. ½
Un usuario puede elegir incluir una tarjeta de regalo y puede escribir su propio mensaje para la tarjeta. ½
Un Visor de informes puede ver informes de compras diarias desglosados por categoría de 8
libro, tráfico, libros más vendidos y peores, etc.
Un usuario debe estar debidamente autenticado antes de ver los informes. 1
Los pedidos realizados en el sitio web deben terminar en la misma base de datos de pedidos que los pedidos 00
telefónicos.
Un administrador puede agregar nuevos libros al sitio. 1
Un administrador puede eliminar un libro. ½
Un administrador puede editar la información sobre un libro existente. 1
El sistema debe admitir el uso máximo de hasta 50 usuarios simultáneos. 00

User Stories Applied Mike Cohn 3.en - Es

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

User Stories Applied Mike Cohn 3.en - Es

Caricato da

Copyright:

Formati disponibili

138 W SOMBRERO S TORIES UNA RE norte Antiguo Testamento

Título del caso de uso: Pagar por un puesto de trabajo

Actor principal: Reclutador

Garantías mínimas: Ninguna

Escenario principal de éxito:

1. El reclutador envía el número de tarjeta de crédito, la fecha y la información de autenticación.

2) El sistema valida la tarjeta de crédito.

3) El sistema cobra el monto total de la tarjeta de crédito.

4) La publicación de empleos se hace visible para los solicitantes de empleo.

5. El reclutador recibe un número de confirmación único.

2a: La tarjeta no es de un tipo aceptado por el sistema:

tiene suficiente crédito disponible para publicar el anuncio.

3a1: El sistema carga lo más que puede a la tarjeta de crédito actual.

Figura 12.1 Un ejemplo de caso de uso para el pago de un puesto de trabajo.

• Prueba con Visa, MasterCard y American Express (pase).

• Prueba con Diner's Club (falla).

• Pruebe con números de identificación de tarjeta buenos, malos y faltantes.

• Prueba con tarjetas caducadas.

Título del caso de uso: Redactar y enviar un mensaje de correo electrónico.

Escenario principal de éxito:

1. El usuario selecciona el elemento del menú "Nuevo mensaje".

2) El sistema presenta al usuario el cuadro de diálogo "Redactar mensaje nuevo".

4. El usuario hace clic en el botón Enviar.

5) El sistema envía el mensaje.

Tabla 12.1 Un caso de uso esencial.

Intención del usuario Responsabilidad del sistema

Redactar mensaje de correo

electrónico Indicar destinatario (s)

Recopilar contenido de correo electrónico y destinatario (s)

Enviar mensaje de correo electrónico

Las historias de usuarios no son escenarios

• un usuario puede crear un currículum

• un usuario puede enviar su currículum para un trabajo coincidente

• un usuario puede buscar trabajo por región geográfica

simplemente se vincula a una página en el sitio con esa información?

escenarios de diseño de interacción.

• No importa cuánto pensemos, pensemos y pensemos, no podemos especificar completa y

¿Por qué historias de usuarios?

• Las historias de usuarios enfatizan la comunicación verbal.

• Las historias de usuario son comprensibles para todos.

• Las historias de usuarios son del tamaño adecuado para la planificación.

• Las historias de usuario funcionan para el desarrollo iterativo.

• Las historias de usuarios fomentan el aplazamiento de los detalles.

• Las historias de usuario respaldan el diseño oportunista.

• Las historias de usuarios fomentan el diseño participativo.

• Las historias de usuarios acumulan conocimiento tácito.

El plato principal viene con una opción de sopa o ensalada y pan.

Sopa o (Ensalada y Pan) (Sopa o

Buffalo Buffalo Buffalo. Buffalo Buffalo

• El usuario puede ingresar un nombre. Puede tener 127 caracteres.

Las historias de los usuarios son comprensibles

específica de dominio para que los desarrolladores puedan leerla.

4.6) El sistema permitirá reservar una habitación con tarjeta de crédito.

4.6.1) El sistema aceptará tarjetas Visa, MasterCard y American Express.

4.6.1.1) El sistema deberá verificar que la tarjeta no haya expirado.

4.7) El sistema le dará al usuario un número de confirmación único.

Las historias de usuarios funcionan para el desarrollo iterativo

esa historia en quizás una docena de otras historias:

• Un usuario puede redactar un mensaje de correo electrónico.

• Un usuario puede incluir gráficos en mensajes de correo electrónico.

• Un usuario puede enviar mensajes de correo electrónico.

Las historias fomentan los detalles diferidos

obligado a completar una especificación de requisitos de software de estilo IEEE 830.