User Stories Applied Mike Cohn 201 291.en - Es

178 UNA DDICIONAL T ÓPTICA
• reutilización
• mantenibilidad
• interoperabilidad
• disponibilidad
• usabilidad
• seguridad
• capacidad
Muchos requisitos no funcionales se pueden considerar como restricciones en el comportamiento del

sistema. Por ejemplo, no es raro que un proyecto incluya un requisito como "El sistema debe estar escrito en
Java". Esto es claramente una limitació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
ejecutar al menos una vez al día) para garantizar el cumplimiento de una restricción. Algunas limitaciones no se
pueden probar de manera realista o no vale la pena probarlas. Me viene a la mente la restricción "El sistema
debe estar escrito 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 las restricciones
de escritura en una tarjeta, si hay requisitos no funcionales adicionales que un sistema debe cumplir,
comuníquelos de la forma que sea apropiada o tradicional. Si, por ejemplo, el proyecto puede beneficiarse
de un diccionario de datos que muestre el tamaño y el tipo de todas las variables en el sistema, cree un
diccionario de datos.
Cuadro 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 partido de fútbol al menos el 55% del
tiempo.
Portabilidad El sistema no utilizará ninguna tecnología que dificulte la migración a Linux.
Reutilización La base de datos y el código de acceso a la base de datos se podrán reutilizar en futuras aplicaciones.
De la biblioteca de www.wowebook.com
PAG APER O S OFTWARE? 179
Cuadro 16.1 Restricciones de muestra escritas para una variedad de requisitos no funcionales comunes.
(Continuado)
Zona Restricción de muestra
Mantenibilidad Deben existir pruebas unitarias automatizadas para todos los componentes. Las pruebas unitarias
automatizadas deben ejecutarse en su totalidad al menos una vez cada 24 horas.
Interoperabilidad El sistema estará escrito 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.
¿Papel o software?
Incluso más común que preguntar "¿papel o plástico?" en la tienda de comestibles está la cuestión de si las
historias deben escribirse en tarjetas de notas 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. Extreme Programming da prioridad a las soluciones simples, y las tarjetas de notas de papel
son definitivamente simples. Además, las tarjetas fomentan la interacción y la discusión. Se pueden colocar
en una mesa en varias formaciones durante la planificación, se pueden apilar y clasificar, se pueden llevar
a cualquier reunión, etc.
Por otro lado, existen productos de software diseñados específicamente para rastrear historias (VersionOne, 1
XPlanner, 2 Seleccione Administrador de alcance 3) así como software de propósito general que se puede usar
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 adoptar la apariencia de requisitos de estilo IEEE 830 y los que escriben historias pueden agregar detalles
adicionales innecesarios debido a eso.
La tarjeta de notas típica puede contener una cantidad limitada de escritura. Esto le da un límite superior
natural en la cantidad de texto. Esta limitación no existe en la mayoría de las alternativas de software. Por
otro lado, una práctica común entre aquellos
1. Consulte 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 la parte posterior de la tarjeta. En
muchos casos, el tamaño de la tarjeta puede funcionar en su contra al escribir los casos de prueba.
Elegir 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 productos de ClickTactics, dice que una de las razones del cambio es que su fuerza
de ventas y la alta gerencia están distribuidas en múltiples sitios. Con las partes interesadas remotas, no podían decir "vaya a
mirar el tablero", por lo que dedicaron mucho tiempo a actualizar a la alta dirección y otras partes interesadas remotas.
Además, cuando usaban tarjetas de notas, tenían problemas con las tarjetas que ocasionalmente se perdían 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, brindan a algunos clientes una visibilidad limitada de sus iteraciones.
Luego, promueven la velocidad con la que pueden entregar nuevas versiones a los clientes diciéndoles:
"Podemos ofrecerles nuevas funciones 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 persiga 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 obtener la certificación ISO con tarjetas de notas escritas a mano,
pero la implementación y demostración de procedimientos de control de cambios adecuados en una baraja de
cartas probablemente supere las otras ventajas que pueden tener las tarjetas.
De manera similar, un equipo que no esté ubicado en el mismo lugar probablemente preferirá el software a las tarjetas de
notas. Cuando uno o más desarrolladores, o especialmente el cliente, está a distancia, es demasiado difícil trabajar con papel.
Una ventaja adicional de las tarjetas de notas es que son muy fáciles de clasificar y se pueden clasificar
de diversas formas. Una colección de historias se puede clasificar en pilas de prioridad alta, media y baja.
O podría ordenarse en un orden más preciso con la primera historia más prioritaria que la segunda y la
segunda más alta que la tercera y así sucesivamente.
A diferencia de muchos de los partidarios más devotos de cualquiera de las técnicas, mi opinión es que
ambos enfoques pueden ser apropiados. Recomiendo empezar con cartas
U SER S TORIES Y EL U SER yo NTERFACE 181
y ver cómo funcionan en su entorno. Entonces, si hay una razón convincente para usar software, cámbielo.
Uso de un wiki en Diaspar Software Services

JB Rainsberger es el fundador de Diaspar Software Services, un desarrollo de software
empresa opment y consultora. Como consultor, JB no siempre puede estar en el sitio con sus clientes. En esas
situaciones, JB usa una wiki para mejorar la comunicación entre él y su cliente remoto. Una 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 su 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ó muy bien en un pequeño proyecto reciente. Como había
preguntas sobre una historia, anotaba la pregunta en la página y agregaba el texto "todo". Varias veces a la
semana, su cliente consultaba la wiki, buscaba "todo" y respondía las preguntas. Los problemas urgentes se
manejaron por teléfono; pero debido a la eficiencia de usar una wiki, sorprendentemente hubo pocos problemas
urgentes. JB ha trabajado con tarjetas de notas de papel en otros proyectos, pero informa que en este proyecto,
con su cliente remoto, nunca hubo un momento en el que deseara tener las historias en tarjetas y en la wiki.
Aunque JB usa la wiki de FitNesse para escribir pruebas ejecutables para cada proyecto, señala que "tener
a todos en la sala hace que sea innecesario poner historias en una wiki".
Historias de usuario e interfaz de usuario
Se ha señalado que los métodos ágiles ignoran en gran medida los problemas del 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 bigbang con una gran dependencia del diseño inicial.
Es importante comprender los riesgos potenciales al buscar un enfoque ágil basado en historias para una aplicación
con una interfaz de usuario significativa o importante.
Uno de los principios del desarrollo ágil es que podemos refinar iterativamente un sistema. Las historias de
usuario nos permiten aplazar las conversaciones hasta poco antes de que los desarrolladores estén listos para
agregar soporte para la historia al programa. A veces, aplazar estas conversaciones hace que los desarrolladores
modifiquen ligeramente las partes existentes de una aplicación; pero la creencia es que el costo de estas ligeras
modificaciones está más que justificado por los ahorros al no tener discusiones sobre requisitos
sobre las características que luego se eliminarán y por los beneficios de permitir que el cliente dirija el
producto con muchas correcciones de rumbo más pequeñas.
Si estos cambios ocurren debajo de la interfaz de usuario de una aplicación, 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 la

apariencia) debe diseñarse para adaptarse a la gama 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 los pequeños ajustes en la ubicación o la forma de
las funciones pueden resultar problemáticos para los usuarios.
Esto significa que si la interfaz de usuario será importante para el éxito de nuestro producto, es posible
que debamos 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 el diseño ágil centrado en el uso como solución. El diseño ágil centrado
en el uso está impulsado por 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. Realice un modelo de roles de usuario.
2. Búsqueda de historias de usuarios de alto nivel.
3. Priorice las historias.
4. Refina las historias de prioridad alta y media.
5. Organice las historias en grupos.
6. Cree un prototipo de papel.
7. Refina el prototipo.
8. Inicie la programación.
El primer paso es realizar 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 escritura de historias como se
describe en el Capítulo 4, "Recopilación de historias". En el taller, concéntrese 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 NTERFACE 183
A continuación, 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. Deje de lado las historias de baja prioridad mientras
refina las historias de alta y mediana prioridad en historias más pequeñas. Estas historias deben tener el tamaño
con el que trabajará al planificar el lanzamiento.
A continuación, organice las historias de prioridad alta y media en grupos que tengan una alta probabilidad
de que se interpreten juntos. Luego, dibuja prototipos en papel para cada grupo de historias. Después de crear
los prototipos en papel, muéstrelos a los usuarios (o apoderados de 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 ligero posible. Algunas de
las historias que se identificaron y que se están creando como prototipos en una interfaz de usuario
podrían terminar eliminándose del proyecto antes de que se desarrollen. Evite gastar 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).
Escribe dos
Hace unos años estaba trabajando en un proyecto y contratamos a Ward Cunningham para que consultara y evaluara
el proyecto. En ese momento, el equipo estaba luchando con preguntas sobre la interfaz de usuario. Hubo muchos debates
acalorados y pesados sobre si los usuarios preferirían una interfaz basada en navegador o si preferirían una aplicación
nativa. Nuestro grupo de marketing había preguntado a los usuarios, pero no estábamos seguros de que hubieran
encuestado a suficientes usuarios o de que hubieran hecho la investigación de la manera correcta.
Ward resolvió la cuestión diciéndonos "Escriba 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 trasladaría de manera inapropiada al nivel de cliente si hacerlo significara que la
funcionalidad tendría que escribirse dos veces.
La sugerencia de Ward fue correcta. Nosotros, por supuesto, no escuchamos, pensando que sería demasiado caro
desarrollar dos interfaces de usuario completas. Cuando el producto estuvo terminado, nuestros clientes nos hicieron saber que
habíamos elegido la tecnología de interfaz de usuario incorrecta. Y rápidamente se inició un proyecto para agregar una
segunda interfaz de usuario.
Reteniendo las historias
Los argumentos sobre si las historias deben conservarse son comunes. Por un lado, están aquellos que
dicen que el placer de romper una tarjeta completa supera cualquier valor de retener la tarjeta. En el lado
opuesto está la multitud más conservadora que prefiere salvar la historia que arriesgarse a tirarla y
necesitarla más tarde.
Si está utilizando software para almacenar sus historias, hay muy pocas razones para deshacerse de las
historias completas. Puede obtener algo de placer y sensación de cierre al eliminar una historia electrónica, pero
probablemente no sea tan grande como el placer visceral de partir una tarjeta física por la mitad.
Si está utilizando tarjetas de notas de papel, entonces puede haber un placer tangible asociado con
terminar una tarjeta y partirla 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 en un libro, prefiero conservar las tarjetas y archivarlas en un estante con una goma
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 mantenido los requisitos. Éstos son algunos de los casos:
• Se estaba comprando la empresa para la que trabajaba. La empresa adquirente estaba intrigada por
nuestro proceso de desarrollo de software liviano, pero tenían su propio enfoque fuertemente
orientado en cascada con numerosas puertas y puntos de aprobación 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, finalmente pudimos hacer algunos avances en la difusión de nuestro proceso a
otras divisiones de la empresa.
• En varias ocasiones he estado involucrado en la reescritura completa de productos comerciales. En

un caso, la primera versión de un producto fue un fracaso comercial debido a algunas malas
decisiones tecnológicas. El producto se reescribió por completo y se convirtió en un éxito moderado.
Otro producto fue un éxito fenomenal como aplicación cliente-servidor, y cinco años más tarde la
empresa quería que se reescribiera y estuviera disponible en la web. Siempre que había historias o
requisitos obsoletos, era útil tenerlos a mano.
• En otra situación, estuve involucrado con una pequeña startup que estaba tratando de cerrar un trato
con una empresa mucho más grande. Si el trato se cerraba, llevaría a la empresa a un territorio
rentable, y el jefe también prometía bonificaciones altas de cinco dígitos a todos los desarrolladores.
Se nos pidió que
S TORIES PARA segundo 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 cambio nos enfocamos en la conversación y la
colaboración. Podía sentir que la conversación no iba a terminar bien y que la rentabilidad de la
empresa y las grandes bonificaciones a los desarrolladores se estaban evaporando. Cambié de tema
y les dije cómo escribimos los requisitos en forma de historias de usuarios. Les gustó la idea.
Afortunadamente, nuestras historias se almacenaron electrónicamente en ese proyecto. Los cortamos
del sistema en el que estaban, los pegamos en un documento de Word, agregamos una portada y una
página de firmas y todos quedaron felices.
Teniendo en cuenta la variedad de ocasiones en las que me ha resultado útil retener historias, mi
recomendación es que también lo hagas. Si está utilizando software, mantenga el software instalado o
imprima un informe y presente el informe en algún lugar. Si está usando tarjetas, guárdelas o fotocopielas
de tres en tres en papel.
Historias de errores
Una pregunta muy común es la relación entre las historias y los informes de errores. Lo que encontré que funciona
mejor es considerar cada informe de error como su propia historia. Si es probable que la corrección de un error
demore tanto 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 hacer esto fácilmente engrapando las tarjetas de historias junto con una tarjeta de portada. Luego,
para fines de planificación, la colección de errores puede tratarse como una sola historia.
¿Y 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 se pueden usar para historias normales. Las tarjetas rojas se pueden usar para errores, las
tarjetas azules se pueden usar para tareas de ingeniería, etc.
Para mí, usar tarjetas de colores siempre me parece una buena idea en teoría; pero en la práctica no vale la pena la
molestia adicional. En lugar de mantener un suministro de tarjetas blancas en mi bolsillo, tengo que asegurarme de llevar
siempre algunas de cada color. Si salgo corriendo y escribo la historia con lo que esté disponible, entonces necesito
reescribir la historia más tarde. Pero si crees que los colores te ayudarán a organizar tus historias, pruébalo. Me limitaré a lo
simple: una gran pila de cartas blancas.
Resumen
• Los requisitos no funcionales (como el rendimiento, la precisión, la portabilidad, la reutilización, el

mantenimiento, la interoperabilidad, la capacidad, etc.) a menudo se pueden manejar mediante la
creación de 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 es 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 la forma en que han aprendido a operar el software. Considere agregar algunas
prácticas de 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 por el lado seguro y retener las historias.
• Engrape los informes de errores pequeños junto con una tarjeta de portada y trátelos como una sola historia.
Responsabilidades del desarrollador
• Usted es responsable de sugerir y utilizar técnicas y métodos alternativos para expresar requisitos
cuando sea apropiado.
• Comparte la responsabilidad de decidir qué es lo correcto para su proyecto: tarjetas de notas o un sistema de
software.
• Comparte la responsabilidad de comprender las ventajas y desventajas de considerar la interfaz de

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

usuario general al inicio del proyecto.
Preguntas
16,1 ¿Cómo debe manejar un requisito para que un sistema se amplíe para que lo utilicen 1000
usuarios simultáneos?
16,2 ¿Prefieres 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 Proporcione algunos ejemplos de sistemas que podrían beneficiarse de una consideración más directa
de la interfaz de usuario de la que normalmente se da en un proyecto ágil.
16,5 ¿Recomienda retener o desechar las historias una vez que se hayan desarrollado?
Defiende tu respuesta.
Esta página se dejó en blanco intencionalmente
PARTE IV
Un ejemplo
La parte IV reúne todo en un ejemplo completo. En los capítulos que siguen, conocerá a South Coast
Nautical Supplies y algunos de sus empleados mientras crean un sitio web para aumentar su catálogo
impreso. Tendrá la oportunidad de identificar los roles de los usuarios, escribir historias con Lori
(vicepresidente de Ventas y Marketing de South Coast y el cliente de 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 de usuario
En el transcurso de los próximos cinco capítulos emprenderemos un pequeño e hipotético proyecto. En este
capítulo, comenzaremos identificando los roles clave de los usuarios. 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 incluyen 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 sitio simple de una página que indica a las personas que llamen a un
número gratuito para solicitar un catálogo.
Nuestro jefe ha decidido que finalmente deberíamos adaptarnos a los tiempos y empezar a vender cosas por
Internet. Sin embargo, en lugar de comenzar vendiendo algunos de nuestros artículos más importantes, quiere que
comencemos vendiendo solo libros. Algunos artículos de nuestro catálogo cuestan más de $ 10,000 y hasta que
sepamos que nuestro sitio funciona bien y no pierde pedidos, no queremos correr ningún riesgo con artículos costosos.
Pero si descubrimos que a nuestros clientes les gusta poder realizar 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 un
aumento de las ventas durante los meses pico de navegación del verano.
Identificación del 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 fuera
191
192 T ÉL U SER R OLES
la compañia. Por lo tanto, necesitamos un cliente interno que pueda actuar como representante de los
usuarios finales reales. Para ello el jefe designa a Lori, quien es la vicepresidenta de Ventas y Marketing.
En una reunión inicial con Lori, ella brinda más información sobre el sistema que necesita. Quiere un "sitio
típico de librería / comercio electrónico". Quiere que los clientes puedan buscar libros de varias formas (no
presionamos para que se aclare en este momento), quiere que los usuarios puedan mantener listas de libros que
comprarán más adelante, quiere que los usuarios califiquen y revisar los libros que compran, y 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.
Identificación de algunos roles iniciales
Lo primero que hacemos es reunir a algunos de los desarrolladores junto con Lori en una sala 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 incondicional
• Marinero novato
• Nuevo marinero
• Comprador
regalos de
• Cónyuge que no navega
• Administrador
• Vicepresidente de ventas
• Capitán de alquiler
• Marinero experimentado
• Escuela de vela
• Biblioteca
• Instructor
C ONSOLIDANTE Y norte FLECHA 193
Consolidar y estrechar
Una vez que los nombres de los roles de usuario se escriben en las tarjetas, debemos eliminar los duplicados o
casi duplicados, considerar si se deben fusionar los roles y generar una lista refinada de roles de usuario con la
que comenzará el proyecto. La forma más fácil de comenzar es intentar quitar cualquier tarjeta que esté colocada
completamente encima de otra tarjeta, lo que indica que su autor pensó que eran duplicados.
En este caso, la tarjeta New Sailor se ha colocado encima de la tarjeta Novice Sailor. Los autores de
esas tarjetas explican lo que pretendían con ellas, y cualquier otra persona agrega cualquier comentario
que desee. Resulta que hay una distinción entre un marinero novato y un marinero nuevo. Un nuevo
marinero es alguien que es nuevo en el deporte de la vela; tal vez esté tomando lecciones actualmente o
haya navegado varias veces. El autor de la tarjeta Novice Sailor en realidad se refería a ese papel para
representar a alguien que puede haber estado navegando durante años, pero no lo suficiente como para
haberse vuelto bueno en eso. El grupo decide que, aunque estos roles parecen ser levemente 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 carta de marinero nuevo se rompe y se tira.
Marinero novato Escuela de vela
Instructor
Nuevo marinero
Marinero hardcore
Capitán Charter
Experimentado
Marinero
Biblioteca
No navegar
Esposa
Administrador Vicepresidente de ventas Comprador de regalos
Figura 17.1 Posicionamiento de las tarjetas de rol de usuario.
A continuación, el grupo considera las tarjetas de Instructor y Escuela de Vela que se superponen. El autor de
la tarjeta de Instructor explica que el papel representa a los marineros que imparten clases de vela. Los
instructores, argumenta, frecuentemente compran copias de libros para sus estudiantes o tal vez ensamblan listas
de libros que los estudiantes están
requerido para leer. El autor de la tarjeta de rol de Escuela de Vela indica que esto es parcialmente lo que
pretendía para esa tarjeta. Sin embargo, pensó que el uso típico lo haría un administrador de la escuela y
no el propio instructor de vela. Lori, la clienta, nos aclara esto diciéndonos que incluso si es un
administrador de la escuela, el administrador tendrá muchas de las mismas características de un Instructor.
Dado que un Instructor es más claramente una sola persona que una Escuela de Vela, la tarjeta de la
Escuela de Vela está rota.
La carta de Marinero incondicional se ha colocado de modo que se superponga parcialmente a las cartas de
Instructor, Marinero experimentado e incluso las cartas de rol de Capitán Charter. A continuación, el grupo analiza
estos roles y descubre que el papel de Marinero incondicional se escribió para capturar el tipo de marinero que
normalmente 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 a los de un marinero con
menos conocimientos, 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 Charter Captain, el equipo decide que el rol es esencialmente el mismo que el de
Hardcore Sailor y la carta se rompe.
En este punto, el equipo ha decidido mantener a Marinero novato, Instructor, Marinero incondicional y
Marinero experimentado. Se han deshecho de New Sailor, Charter Captain y Sailing School. Y todavía tienen
que considerar al comprador de regalos, cónyuge no navegante, administrador y vicepresidente de ventas.
Los autores de estas tarjetas de roles restantes explican su intención.
El rol de Comprador de regalos representa a alguien que no es un marinero pero que está comprando un regalo
para alguien que lo es. El autor del papel de cónyuge no navegante indica que esta era la intención detrás de esa
tarjeta. Después de un poco de 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 que no navega.
El autor del rol de Administrador explica que este rol 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 en el sitio. Después de discutirlo, deciden que el rol 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 rol de Vicepresidente de Ventas se analiza a continuación. Este es otro rol que no es de compra. Sin
embargo, el CEO ha ordenado que el nuevo sistema se vigile muy de cerca para ver cómo está afectando
las ventas. El equipo considera dejar el papel porque no creen que haya muchas historias específicas 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 no navegante. Sin embargo, el grupo rechaza estas ideas y decide mantener a
Biblioteca como un papel. Sin embargo, de acuerdo con la pauta para crear roles que representen a usuarios
discretos, la tarjeta de la biblioteca se rompe y se reemplaza por 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
Experimentado
bibliotecario
Marinero
Regalo sin navegar Administrador Visor de informes

Comprador
Figura 17.2 Los roles después de la consolidación y discusión inicial.
Modelo a seguir
A continuación, el equipo considera cada función y agrega detalles a las tarjetas de función. 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 utilizará el software.
• El nivel de experiencia del usuario con el dominio.
• El nivel general de competencia del usuario con computadoras y 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 buscan la comodidad, otros prefieren
una experiencia enriquecedora, etc.
El grupo analiza estos problemas para cada tarjeta de función. Actualizan las tarjetas de función de usuario de la siguiente manera:
Marinero novato: Comprador web experimentado. Se espera realizar 6 compras durante los
primeros 3 meses de navegación. A veces se hace referencia a un título específico; otras
veces necesita ayuda para seleccionar el libro correcto. Quiere más ayuda para seleccionar
los libros apropiados (buen contenido escrito en el nivel apropiado) de la que recibe en una
librería física.
Instructor: Se espera que utilice el sitio web con frecuencia, a menudo una vez a la semana.
A través del grupo de ventas telefónicas de la empresa, un Instructor suele realizar pedidos
similares (por ejemplo, 20 copias del mismo libro). Competente con el sitio web, pero
generalmente algo nervioso con las computadoras. Interesado en conseguir los mejores
precios. No me interesan las reseñas ni otros "adornos".
Marinero de núcleo duro: Generalmente sin experiencia con computadoras. Un gran

comprador de artículos del catálogo de la empresa, pero no un gran comprador de libros.
Nos compra muchos equipos adicionales. Normalmente sabe exactamente lo que busca.
No quiere sentirse estúpido al intentar usar el sitio.
Marinero experimentado: Competente con las computadoras. Se espera que ordene una o dos
veces por trimestre, quizás más a menudo 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 regalos que no navega: Suele ser competente con las computadoras (o no elegiría
comprar un regalo en línea). No es marinero y, en el mejor de los casos, estará familiarizado con los
términos de navegación. Por lo general, buscará un libro muy específico, pero es posible que busque
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 me interesan especialmente
los adornos como el envoltorio de regalo o el seguimiento de envíos. Por lo general, se
realizarán una pequeña cantidad de pedidos por año, pero cada pedido será de 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 al back-end del sistema diariamente como parte de su trabajo. Interesado en
aprender rápidamente el software, pero querrá accesos directos de usuario avanzados más adelante.
UNA DDING PAG ERSONAS 197
Visor de informes: Competencia moderada con computadoras, principalmente con

programas comerciales como hojas de cálculo y procesadores de texto. Interesado en
datos muy detallados sobre cómo funciona el sistema, qué compran o no compran los
visitantes y cómo navegan o buscan en el sitio. Muy dispuesto a cambiar velocidad por
potencia y profundidad.
Agregar personas
A veces vale la pena dedicar unos minutos a agregar una personalidad 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 rol más importante a satisfacer es el de Instructor. Los
instructores pueden ser responsables de la venta de cientos de libros durante el año. De hecho, continúa,
con el nuevo sitio web le gustaría investigar formas de ofrecer eventualmente incentivos financieros a los
instructores que remiten a sus estudiantes al sitio.
Con esta información en mente, el equipo decide desarrollar dos personajes. La primera persona es Teresa.
Teresa navega desde hace cuatro años. Es la directora ejecutiva de una empresa de biotecnología que cotiza en
bolsa y se siente completamente cómoda haciendo 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 prepara para un crucero. Está
muy ocupada y está interesada en utilizar nuestro sitio para ahorrar tiempo y encontrar libros que no ha visto
antes. Teresa está casada con Tom, que no navega él mismo, pero ha acompañado a Teresa 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 en la escuela secundaria hace cinco años y ha sido
instructor de vela desde entonces. Ha sido un cliente leal 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 hacer pedidos 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 para satisfacer 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 adicional.
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 brindar 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 hora o dos a escribir tantas historias como puedan. Durante un taller de escritura de
historias, un enfoque es escribir historias en cualquier orden, independientemente del rol o persona que
pueda actuar en la historia. Un enfoque alternativo es comenzar con un rol o personaje de usuario
específico y escribir todas las historias que el equipo pueda pensar antes de pasar al siguiente rol o
personaje. Los resultados deberían ser los mismos con cualquier enfoque. En este caso, el equipo lo
discute y elige trabajar en cada rol y persona.
Historias 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 busca velocidad y comodidad. Es una verdadera usuaria avanzada y no le importará un poco de
complejidad adicional siempre que la complejidad la ayude a encontrar lo que busca más rápidamente. La
primera historia que escriben es la Ficha de historias 18.1.
Un usuario puede buscar libros por autor, título o número ISBN.
■ Ficha de historia 18.1
Los desarrolladores tienen algunas preguntas sobre esta historia. Por ejemplo, ¿puede el usuario
buscar por autor, título e ISBN al mismo tiempo, o Lori quiere que busquen solo por un criterio a la vez?
Dejan estas preguntas por ahora y se enfocan en escribir más historias preliminares.
199
200 T ÉL S TORIES
A continuación, Lori dice que después de buscar un libro, el usuario puede ver información detallada
sobre un libro. Da algunos ejemplos del tipo de información que quiere decir y luego escribe el Story Card
18.2.
Un usuario puede ver información detallada sobre un libro. Por ejemplo, número de
páginas, fecha de publicación y una breve descripción.
Probablemente querrá más además de estos tres detalles, pero los desarrolladores pueden preguntarle más tarde
cuando 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 conduce a
la Tarjeta de historia 18.3 y la Tarjeta de historia 18.4.
Un usuario puede poner libros en un "carrito de compras" y comprarlos cuando termine de

comprar.
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 a cargar y cierta información de la dirección. Esto nos lleva a la Story Card 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 navegado durante cuatro años, no
siempre sabrá exactamente qué libro quiere. Para Teresa, el sitio debe incluir funciones para que los clientes
califiquen y revisen los artículos. Esto lleva a Lori a escribir Story Card 18.6.
Un usuario puede calificar y revisar libros.
Dado que Teresa quiere poder realizar pedidos lo más rápido posible, el equipo decide que el sistema debe
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 navega, no compren con mucha frecuencia, por lo que es posible que estos clientes
no quieran crear una cuenta reutilizable. Del mismo modo, cualquier paso adicional la primera vez puede asustar al
Capitán Ron, que siempre es 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 no está lista para comprar hoy. Ella se los comprará más tarde o se lo 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 programe Story Card 18.10 sepa que un usuario puede seleccionar
elementos de su propia lista de deseos o de otra persona. Nos aseguramos de anotarlo 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 sea visible para otros visitantes del
sitio.
Un usuario puede colocar un artículo de una lista de deseos (incluso la de otra persona) en su
carrito de compras.
Debido a que la velocidad será importante para Teresa, Lori también identifica una restricción de desempeño
relacionada con el tiempo que se tarda en pedir un libro. Escribe la Ficha descriptiva 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 lleva a un cliente habitual buscar un libro y
completar su pedido. Este es un requisito de buen rendimiento porque captura todos los aspectos de la
experiencia del usuario con el sitio. Las consultas de base de datos y el middleware ultrarrápidos no cuentan
mucho si la interfaz de usuario es tan confusa para navegar que un usuario tarda tres minutos en 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 del 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, que dirige una escuela de vela y es un poco más tentativo con
las computadoras que Teresa. Cuando Cap-
S TORIES PARA UN norte OVICE S AILOR 203
tain Ron llega al sitio que normalmente sabe exactamente lo que está buscando. Esto lleva a Lori a escribir la
Ficha de historia 18.12 y la Ficha 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 permitirán al Capitán Ron mirar hacia atrás en sus antiguas ó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 anteriormente. Escribe la Ficha descriptiva 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 puede encontrar los libros que
recomendamos sobre una variedad de temas. Escribe la Ficha descriptiva 18.15.
Un usuario puede ver qué libros recomendamos sobre una variedad de temas.
204 T ÉL S TORIES
Historias para un comprador de regalos que no navega
Al cambiar al rol de Comprador de regalos que no navega, el equipo analiza cómo debe ser fácil para un
comprador encontrar la lista de deseos de otra persona. Empiezan 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. Escribe el Story Card
18.17 y el Story Card 18.18.
Un usuario puede optar por envolver los artículos para regalo.
Un usuario puede optar por adjuntar 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 tráfico y compras, etc. Ella aún no ha
pensado en los informes en detalle, por lo que los desarrolladores escriben una historia simple de
mantenimiento de lugares que les recordará que hay informes que desarrollar. Decidirán sobre el contenido
del informe más tarde. Por ahora, 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 empresa pueden tener acceso al
S OME UNA DMINISTRACIÓN S TORIES 205
Un visor de informes puede ver informes de compras diarias desglosadas por categoría
de libros, tráfico, libros más vendidos y más vendidos, etc.
informes. Esto podría significar que si puede acceder a un informe, puede acceder a todos ellos, 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 sean significativos, 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 Ficha 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 se traslada al rol de usuario administrador. El equipo piensa instantáneamente en la Carta de
Historia 18.22 y la Carta de Historia 18.23.
Un administrador puede agregar libros nuevos al sitio.
206 T ÉL S TORIES
Un administrador debe aprobar o rechazar las revisiones antes de que estén

disponibles en el sitio.
La historia sobre la adición de libros nuevos les recuerda que los administradores deben eliminar libros y también
editarlos en caso de que se haya utilizado información incorrecta cuando se agregó el libro. Así que escriben la Ficha
de historia 18.24 y la Ficha de historia 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 le ha venido a la
mente instantáneamente, pero ahora tiene que pensar si hay otras. Debido a que el proyecto se realizará
mediante un proceso de desarrollo incremental e iterativo, no es importante que ella piense en cada historia
desde el principio. Pero debido a que quiere una estimación preliminar de cuánto tiempo tardará en
construirse 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 empezado, tendrá la oportunidad de
trasladarla al lanzamiento si realiza la misma cantidad aproximada de trabajo.
Los desarrolladores le preguntan a Lori si hay otras historias que cree que se han olvidado hasta ahora.
Escribe la Ficha descriptiva 18.26.
Lori también recuerda a los desarrolladores que las necesidades de escalabilidad no son tremendas, pero que el
sitio necesita manejar al menos 50 usuarios concurrentes. Escriben esta restricción en la Ficha de historias 18.27.
W GOLPECITOS U PAG 207
Un usuario puede comprobar 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.
El sistema debe admitir un uso máximo de hasta 50 usuarios simultáneos.
(Restricción)
Capítulo 19
Estimando las historias
El taller de escritura de historias resultó en 27 historias, que se resumen en la Tabla 19.1. El siguiente
objetivo es crear un plan de lanzamiento que le 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 en
estrecha colaboración con Lori para priorizar las historias.
Cuadro 19.1 La colección inicial de historias.
Texto de la historia
Un usuario puede buscar libros por autor, título o número ISBN.
Un usuario puede ver información detallada sobre 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 termine 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 sea visible para otros visitantes del sitio.
Un usuario puede colocar un artículo de una lista de deseos (incluso la de otra persona) 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
Cuadro 19.1 La colección inicial de historias. (Continuado)
Texto de la historia
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).
Un usuario, especialmente un comprador de regalos que no navega, puede encontrar fácilmente las listas de deseos de otros usuarios. Un
usuario puede optar por envolver los artículos para regalo.
Un usuario puede optar por adjuntar una tarjeta de regalo y puede escribir su propio mensaje para la tarjeta.
Un visor de informes puede ver informes de compras diarias desglosadas por categoría de libros, tráfico, libros más
vendidos y más vendidos, 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.
Un administrador debe aprobar o rechazar las revisiones antes de que estén disponibles en el sitio.
Un usuario puede comprobar 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.
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 la
historia que representan el tiempo ideal, la complejidad o alguna otra medida significativa para el equipo.
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 ambos. Quiere un modo de búsqueda básico en el que el valor de un
campo busque tanto el autor como el título. Entonces ella quiere un
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 sencilla entre
los modos que todos aceptan romper la historia y reemplazarla con Story Card 19.1 y Story Card 19.2.
Un usuario puede hacer una búsqueda básica simple que busca una palabra o frase tanto en el
campo de autor como en el de título.
Un usuario puede buscar libros ingresando valores en cualquier combinación

de autor, título e 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 cuentos y algunas docenas de tarjetas en blanco. Los
programadores hablan sobre Story Card 19.1, aclaran algunos detalles al hacerle preguntas a Lori, y luego
cada programador escribe su estimación en una tarjeta de índice. Cuando todos terminan, cada
programador levanta su tarjeta para que todos puedan verla. Han escrito:
Rafe: 1
Arrendajo: ½
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 de 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 posibles opciones de búsqueda y está bastante seguro de la dirección en la que deben ir, razón por la
cual su estimación es mucho menor.
Se 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
Arrendajo: 1
María: 1
Eso fue bastante fácil. Jay decidió aumentar su estimación y María estaba convencida de que podían
hacer la historia más rápido de lo que pensaba originalmente. Ellos
ahora tenga una estimación de puntos de un piso para usar en la Tarjeta de Historia 19.1. Empiezan a escribir estimaciones
como se muestra en la Tabla 19.2.
Cuadro 19.2 Empezando a anotar las estimaciones.
Historia Estimar
Un usuario puede hacer una búsqueda básica simple que busca una palabra o frase tanto en el campo de autor 1
como en el de título.
Tenga en cuenta que Lori, la cliente, está presente mientras los programadores realizan estas
estimaciones, pero no participa escribiendo sus estimaciones. Dado que Lori no es programadora en el
proyecto, no puede hacer estimaciones. Además, no se le permite jadear o expresar conmoción por una
estimación. Si lo hace, socavará el esfuerzo de estimación. Por supuesto, si Lori escucha una estimación
que suena fuera de lugar (ya sea demasiado alta o demasiado baja), es posible que deba brindar alguna
orientación o aclaración. Por ejemplo, puede ofrecer algo como: “Puedo ver cómo eso podría ser diez
puntos de la historia mientras la 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
fichas y les dan la vuelta al mismo tiempo mostrando:
Rafe: 2
Arrendajo: 1
María: 2
Rafe dice que la búsqueda avanzada llevará 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 estará 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é querrá que se haga primero. Ella se inclina a hacer la búsqueda básica primero, pero no estará
segura hasta que sepa la estimación (es decir, el costo) de cada una.
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 no es necesario dividir ninguna. Los desarrolladores llegan a
las estimaciones que se muestran en la Tabla 19.3.
Cuadro 19.3 Elaboración de la lista de estimaciones.
Historia Estimar
Un usuario puede buscar libros ingresando valores en cualquier combinación de autor, título e 1
ISBN.
Un usuario puede ver información detallada sobre 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 termine 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
mostrárselas entre sí, los desarrolladores hablan de esta historia. La parte de la calificación no parece difícil, pero las
revisiones parecen más complicadas. Necesitarán una pantalla para que los usuarios ingresen una reseña y tal vez para
obtener una vista previa. ¿Las reseñas serán solo texto sin formato o el revisor puede escribir en HTML? ¿Los usuarios
solo pueden revisar los libros que nos compraron?
Debido a que las reseñas son mucho más complejas que solo calificar libros, decidimos dividir la historia.
Esto conduce a la Tarjeta de historia 19.3 y la Tarjeta de historia 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 la Ficha de historia 19.3 como dos puntos y la Ficha de historia 19.4 como cuatro puntos de historia.
Un usuario puede escribir una reseña de un libro. Puede obtener una vista previa de la reseña
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 "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
ser más complicado 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 nada
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 recuerde 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 extensa, 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 en un nivel mucho más fino. En nuestro caso, por ejemplo, Lori puede
pensar que es fundamental que los usuarios editen sus tarjetas de crédito, pero puede estar dispuesta a esperar algunas
iteraciones para que los usuarios puedan cambiar de dirección. La historia original se divide, lo que da como resultado la
Carta de historia 19.5 y la Carta de historia 19.6. Ninguna 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 ACABADO EL mi ESTIMA 215
estas historias parecen difíciles, por lo que los programadores estiman la Ficha de historia 19.5 como ½ punto de historia y la
Ficha de historia 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 historia vaga: "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ó acerca de sus intenciones con respecto a
cómo los usuarios podrían buscar una lista de deseos, Lori proporciona suficientes detalles para que la historia pueda
reescribirse como Story Card 19.7.
Un usuario, especialmente un comprador de regalos que no navega, puede buscar una lista de
deseos según el nombre y el estado de su propietario.
A continuación, 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á la verificación del 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 comprobar 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 limitaciones:
• 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 un uso máximo de hasta 50 usuarios simultáneos.
Como limitaciones, influyen en otras historias, pero no requieren ninguna codificación específica.
Todas las estimaciones
La tabla 19.4 muestra todas las estimaciones.
Cuadro 19.4 La lista completa de historias y estimaciones.
Historia Estimar
ISBN.
Un usuario puede ver información detallada sobre un libro. Por ejemplo, número de páginas, fecha de 1
publicación y una breve descripción.
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 reseña antes de enviarla. 4
El libro no tiene que ser uno que el usuario nos haya comprado.
Un administrador debe aprobar o rechazar las revisiones 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 ESTIMA 217
Cuadro 19.4 La lista completa de historias y estimaciones. (Continuado)
Historia Estimar
Un usuario puede colocar libros en una "lista de deseos" que sea visible para otros visitantes del sitio. 2
Un usuario, especialmente un comprador de regalos que no navega, puede buscar una lista de deseos según 1
el nombre y el estado de su propietario.
Un usuario puede comprobar 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 1

envío, la dirección de entrega y la tarjeta de crédito.
Un usuario puede colocar un artículo de una lista de deseos (incluso la de otra persona) en su carrito de compras. ½
Un cliente habitual debe poder encontrar un libro y completar un pedido en menos de 90 0

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. Un usuario puede optar 4
por envolver los artículos para regalo. ½
Un usuario puede optar por adjuntar una tarjeta de regalo y puede escribir su propio mensaje para la tarjeta. ½
Un visor de informes puede ver informes de compras diarias desglosadas por categoría de 8
libros, tráfico, libros más vendidos y más vendidos, 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 0
telefónicos.
Un administrador puede agregar libros nuevos al sitio. Un 1
administrador puede eliminar un libro. ½
Un administrador puede editar la información sobre un libro existente. El sistema debe 1
admitir un uso máximo de hasta 50 usuarios simultáneos. 0
Capítulo 20
El plan de lanzamiento
Los siguientes pasos son necesarios para crear el plan de lanzamiento:
1. Seleccione una longitud de iteración.
2. Estime la velocidad.
3. Priorice las historias.
4. Asignar historias a una o más iteraciones.
Debido a que las nuevas funciones del sitio web deben estar disponibles en cuatro semanas, el equipo
decide utilizar iteraciones de dos semanas. Esto les dará la oportunidad de ejecutar dos iteraciones antes
de la fecha límite. Darán prioridad a las características de mayor prioridad en la primera iteración para
asegurarse de que se completen. Después de la primera iteración, podrán evaluar su velocidad y decidir
cuánto trabajo pueden aportar a la segunda iteración.
Estimación de la velocidad
María y Rafe serán los programadores del proyecto. Jay ayudó a estimar, pero otros compromisos le impiden
ayudar a desarrollar el sitio web. Dado que el proyecto es diferente a los sitios web anteriores que han
desarrollado los programadores, no pueden estimar una velocidad para el nuevo proyecto basándose en la
velocidad de un proyecto anterior. Por lo tanto, deberán realizar una suposición fundamentada.
Cuando calcularon las historias, María y Rafe definieron vagamente un punto de la historia como un día
ideal de programación. Ahora deciden que les llevará entre dos y tres días reales hacer un día ideal de
trabajo. Con iteraciones de dos semanas (diez días) y dos programadores, habrá veinte días de
programador por iteración. Maria y Rafe estiman que podrán completar entre siete y diez puntos de historia
durante cada iteración. Decidiendo ser conservadores para la primera iteración, estiman la velocidad en
ocho.
219
220 T ÉL R Por favor PAG LAN
Priorizar las historias
Lori, la clienta, prioriza las historias. El factor principal para determinar la prioridad de una historia es el valor
que brindará a la empresa. Sin embargo, Lori también debe considerar la estimación de la historia.
Ocasionalmente, las historias muy deseadas se vuelven menos deseables cuando se considera su costo
(las estimaciones).
Para comenzar a priorizar, Lori clasifica las tarjetas de historias en cuatro pilas según su importancia para
la fecha de lanzamiento prevista en cuatro semanas: debe tener, debería tener, podría tener y no tener. Las
historias imprescindibles de Lori se muestran en la tabla 20.1.
Cuadro 20.1 Las historias imprescindibles para el lanzamiento inicial en cuatro semanas.
Historia Estimar
Un usuario puede establecer una cuenta que recuerde la información de envío y facturación. 2
Los pedidos realizados en el sitio web deben terminar en la misma base de datos de pedidos que los pedidos 0
telefónicos.
Un administrador puede agregar libros nuevos al sitio. Un 1
administrador puede eliminar un libro. ½
Un administrador puede editar la información sobre un libro existente. El sistema debe 1
admitir un uso máximo de hasta 50 usuarios simultáneos. 0
La suma de las estimaciones de las historias imprescindibles de Lori es nueve. Dado que la velocidad se estima en
ocho por iteración y habrá dos iteraciones, esto deja espacio para sumergirse en algunas de las historias que debería
tener Lori. Lori extrae las historias que se muestran en la tabla 20.2 de su pila de historias imprescindibles. Entre sus
historias imprescindibles y las que debería tener, ahora ha identificado 15½ puntos, lo que es lo suficientemente
cercano a
T ÉL F ACABADO R Por favor PAG LAN 221
los dieciséis puntos que los programadores creen que pueden completar en dos iteraciones.
Cuadro 20.2 Las historias que debería tener Lori agrega al plan de lanzamiento.
Historia Estimar
ISBN.
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. Un usuario puede 1
ver qué libros recomendamos sobre una variedad de temas. 4
El plan de lanzamiento terminado
El plan de lanzamiento terminado se prepara como se muestra en la Tabla 20.3 y se comunica al resto de
la organización de esa manera. Maria y Rafe harán todo lo posible para completar el trabajo planeado para
la primera iteración. Si lo hacen bien, trabajarán con Lori para mover una nueva historia o dos a la primera
iteración. Si se atrasan, trabajarán con Lori para mover una historia o dos de la primera iteración a la
segunda.
Cuadro 20.3 El plan de lanzamiento terminado.
Iteración 1 Iteración 2
Un usuario puede hacer una búsqueda básica simple que busca Un administrador puede editar la información
una palabra o frase tanto en el campo de autor como en el de sobre un libro existente.
título.
Un usuario puede poner libros en un "carrito de Un usuario puede buscar libros ingresando valores en
compras" y comprarlos cuando termine de comprar. cualquier combinación de autor, título e ISBN.
Un usuario puede eliminar libros de su carrito antes de Un usuario puede editar la información de la tarjeta de crédito
completar un pedido. almacenada en su cuenta.
Para comprar un libro, el usuario ingresa su dirección de Un usuario puede editar las direcciones de envío y facturación
facturación, la dirección de envío y la información de la tarjeta de almacenadas en su cuenta.
crédito.
Los pedidos realizados en el sitio web deben terminar en la misma Un usuario puede ver qué libros recomendamos
base de datos de pedidos que los pedidos telefónicos. sobre una variedad de temas.
222 T ÉL R Por favor PAG LAN
Cuadro 20.3 El plan de lanzamiento terminado. (Continuado)
Iteración 1 Iteración 2
Un usuario puede establecer una cuenta que recuerde la

información de envío y facturación.
El sistema debe admitir un uso máximo de hasta 50

usuarios simultáneos.
Capítulo 21
Las pruebas de aceptación
Las pruebas de aceptación de una historia se utilizan para determinar si la historia está completa hasta el
punto en que el cliente puede aceptar esa parte del software como completa. Esto significa que el cliente
es responsable de especificar las pruebas. A menudo, sin embargo, el cliente contará con la ayuda de un
evaluador asignado al proyecto. Dado que este proyecto es pequeño y sin un probador dedicado, Lori
solicita la ayuda de Maria y Rafe. Un beneficio adicional de esto es que, más allá de generar una lista de
pruebas de aceptación, conduce a más conversaciones entre Lori y los programadores.
Las pruebas de búsqueda
Las funciones de búsqueda que Lori dio prioridad en la primera versión se muestran en la Tarjeta de historias 21.1 y la
Tarjeta de historias 21.2. Las pruebas para Story Card 21.1 son:
• Busque una palabra que se sepa que es parte de un título pero que es poco probable que sea un autor; por
ejemplo, "navegación".
• Busque una palabra que probablemente sea un autor pero que es poco probable que sea un título; por ejemplo,
"John".
• Busque una palabra que probablemente no esté en ninguno de los dos; por ejemplo, "wookie".
Un usuario puede hacer una búsqueda básica simple que busca una palabra o frase tanto en el
campo de autor como en el de título.
223
224 T ÉL UNA ACEPTACIÓN T ESTS
Las pruebas para Story Card 21.2 son:
• Utilice valores para autor y título que coincidan con al menos un libro.
• Utilice valores para autor y título que no coincidan con ningún libro.
• Pruebe una búsqueda de ISBN.
Un usuario puede buscar libros ingresando valores en cualquier combinación

de autor, título e ISBN.
Pruebas de carrito de compras
La Ficha de Historia 21.3 y la Ficha de Historia 21.4 cubren el uso del carrito de compras.
Un usuario puede poner libros en un "carrito de compras" y comprarlos cuando termine de

comprar.
Un usuario puede eliminar libros de su carrito antes de completar un pedido.
Lori y los programadores hablan sobre estas historias y se dan cuenta de que tienen algunas preguntas
abiertas: ¿Pueden los usuarios poner libros agotados en los carritos de compras? ¿Qué pasa con los libros que aún
no se han impreso? Además, el equipo se da cuenta de que Story Card 21.4 cubre cambiar la cantidad de un
artículo a 0, pero no hay una historia explícita para aumentar la cantidad de un artículo. Podrían escribir esto como
una historia separada, pero en su lugar, decidir romper la Tarjeta de Historia 21.4 y reemplazarla con la Tarjeta de
Historia 21.5.
Un resultado importante de esta discusión es que el sistema se ha simplificado. Al decidir que no

necesitan una historia separada para eliminar un artículo de una compra
segundo UYING segundo OK 225
Un usuario puede ajustar la cantidad de cualquier artículo en su carrito. Establecer la

cantidad en 0 elimina el artículo del carrito.
carrito, el equipo ha mejorado la usabilidad del sistema y ha evitado posibles trabajos futuros.
• Ponga un libro agotado en el carrito. Verifique que se le diga al usuario que el libro se enviará cuando
esté disponible.
• Coloque un libro que aún no se haya publicado en el carrito. Verifique que se le indique al usuario que el libro se
enviará cuando esté disponible.
• Coloque un libro en existencia en el carrito.
• Ponga una segunda copia de un libro en el carrito. Verifique que el conteo suba. Las pruebas para Story
Card 21.5 son
• Cambie la cantidad de un libro de uno a diez.
• Cambie la cantidad de diez a uno.
• Quite un libro cambiando la cantidad a cero.
Compra de libros
Story Card 21.6 cubre la compra real de libros. Al discutir esta historia, los programadores aclaran algunos
aspectos con Lori, la clienta. Lori quiere que los usuarios puedan ingresar direcciones de envío y
facturación separadas o indicar que las direcciones son las mismas. El sitio solo aceptará Visa y
MasterCard.
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.
• Ingrese una dirección de facturación e indique que la dirección de envío es la misma.
• Ingrese direcciones de envío y facturación separadas.
• Pruebe con un estado y un código postal que sea de otro estado y verifique que se detecta la
inconsistencia.
• Verifique que la dirección a la que se enviarán los libros es la dirección de envío, no la dirección de facturación.
• Pruebe con una tarjeta Visa válida.
• Pruebe con una MasterCard válida.
• Prueba con una tarjeta American Express válida (falla).
• Prueba con una visa vencida.
• Pruebe con una MasterCard que supere su límite de crédito.
• Pruebe con una visa a la que le falten dígitos.
• Prueba con una visa con dígitos transpuestos.
• Pruebe con una Visa con un número completamente inválido.
Cuentas de usuario
Story Card 21.7 cubre la creación de cuentas de usuario. Las pruebas para esta tarjeta son:
• Los usuarios pueden realizar pedidos sin crear una cuenta.
• Cree una cuenta, luego recupérela y vea si la información se ha guardado.
Un usuario puede establecer una cuenta que recuerde la información de envío y

facturación.
Story Card 21.8 y Story Card 21.9 permiten a los usuarios modificar la información almacenada en sus
cuentas. Las pruebas para Story Card 21.8 son:
UNA DMINISTRACIÓN 227
• Edite el número de tarjeta para convertirlo en un número no válido. Verifique que el usuario esté advertido.
• Edite la fecha de vencimiento a una anterior. Verifique que el cambio no se guarde.
• Cambie el número de la tarjeta de crédito por un nuevo número válido y asegúrese de que se guarde el cambio.
• Cambie la fecha de vencimiento a una fecha futura y asegúrese de guardar el cambio.
Un usuario puede editar la información de la tarjeta de crédito almacenada en su cuenta.
■ Tarjeta de historia 21.8
Prueba para Story Card 21.9 son
• Cambie varias partes de la dirección de envío y verifique que los cambios se guarden.
• Cambie varias partes de la dirección de facturación y verifique que los cambios se guarden.
Un usuario puede editar las direcciones de envío y facturación almacenadas en su cuenta.
Administración
Story Card 21.10 permite a un administrador agregar libros nuevos al sitio. Las pruebas para esta historia son:
• Pruebe que un administrador puede agregar un libro al sitio.
• Pruebe que una persona que no sea un administrador no pueda agregar un libro.
• Pruebe que solo se puede agregar un libro si los datos requeridos están presentes.
Story Card 21.11 permite a un administrador eliminar un libro. Las pruebas para esta historia son:
• Verifique que un administrador pueda eliminar un libro.
• Verifique que alguien que no sea administrador no pueda eliminar un libro.
• Elimine un libro y luego verifique que los pedidos pendientes del libro aún se enviarán.
Story Card 21.12 permite a un administrador cambiar información sobre un libro. Cuando los
programadores y Lori discuten la Ficha de historias 21.12, discuten cómo manejar los pedidos no enviados
que incluyen un libro cuyo precio cambia. Esta se convierte en una de las pruebas de la historia:
• Verifique que elementos como nombre, autor, número de páginas, etc. puede ser cambiado.
• Verifique que el precio se pueda cambiar pero que los cambios de precio no afecten a los pedidos realizados anteriormente (pero a
los pedidos no facturados y no enviados).
Prueba de las restricciones
Entre las historias que Lori ha priorizado en el lanzamiento, hay dos restricciones, que se muestran como
Story Card 21.13 y Story Card 21.14.
AF INAL S CONSERVADOR 229
Los pedidos realizados en el sitio web deben terminar en la misma base de datos de pedidos que
los pedidos telefónicos.
La única prueba para Story Card 21.13 es examinar la base de datos y verificar que un pedido enviado
desde el sitio web se almacena en la base de datos:
• Realizar un pedido. Abra la base de datos de entrada de pedidos telefónicos y verifique que el pedido se haya almacenado
en esa base de datos.
Lori toma la Carta de historia 21.14, le da la vuelta a la carta de historia y escribe:
• Prueba con cincuenta usuarios simulados que realizan una variedad de búsquedas y realizan pedidos. Asegúrese de
que ninguna pantalla tarde más de cuatro segundos en mostrarse y de que no se pierdan pedidos.
Una historia final
La única historia que queda se muestra en la Ficha de historias 21.15.
Lori y los desarrolladores hablan sobre Story Card 21.15 y deciden que será una página estática simple
que incluye una lista de recomendaciones para una variedad de temas. Escriben estas pruebas:
• Seleccione un tema (por ejemplo, navegación o crucero) y vea las recomendaciones para ese tema.
Asegúrese de que tengan sentido.
• Haga clic en un elemento de la lista para verificar que el navegador vaya a una página de información de
ese libro.
PARTE V
Apéndices
No es necesario que sepa mucho sobre la programación extrema para leer y beneficiarse de este libro. Sin
embargo, dado que las historias de usuarios tuvieron su origen en la Programación extrema, el Apéndice A
proporciona una breve introducción. El Apéndice B contiene respuestas a las preguntas que concluyeron la
mayoría de los capítulos.
Apéndice A
Una descripción general de la

programación extrema
Este apéndice sirve como una breve introducción a las ideas principales de Extreme Programming (XP). Si
ya está familiarizado con XP, puede omitir este apéndice con seguridad. De lo contrario, utilice este
apéndice como una introducción a XP y luego continúe con uno de los excelentes libros que explican XP en
detalle. 1
Primero veremos a las personas (o roles) involucrados en un proyecto de XP. A continuación, veremos las
doce prácticas principales de XP. Concluiremos considerando los valores de un equipo de XP.
Roles
El rol de cliente de XP es responsable de escribir historias, priorizar historias y escribir y ejecutar pruebas que
demuestren que las historias se desarrollaron como se esperaba. El cliente de XP puede ser un usuario del
sistema que se está construyendo, pero eso no es necesario. Si no es un usuario, el cliente de XP suele ser un
gerente de producto, un gerente de proyecto o un analista comercial.
En algunos proyectos, la función del cliente puede ser desempeñada por un equipo de clientes, que
estaría compuesto por varias personas muy interesadas. El equipo del cliente a menudo incluirá
probadores que ayudarán a crear las pruebas de aceptación. Cuando un proyecto tiene varios clientes, es
importante que hablen con una sola voz. Pueden lograr esto de muchas maneras, pero más comúnmente
designando a una persona en el equipo del cliente como la primera entre iguales.
1. En particular, ver Explicación de la programación extrema: Adopte el cambio ( Arroyo

2000), Programación extrema instalada ( Jeffries, Anderson y Hendrickson
2000), o Programación extrema explorada ( Wake 2002).
233
234 UNA PÉNDICE UNA
El rol de programador de XP abarca una amplia gama de habilidades técnicas. Los proyectos de XP tienden a
no hacer distinciones entre programadores, diseñadores, administradores de bases de datos, etc. Se espera que
todos los programadores trabajen en equipo y compartan muchas responsabilidades que, de otro modo, podrían
asignarse a personas específicas en un proyecto que no sea de XP. Casi todos los procesos esperan que los
programadores realicen pruebas unitarias de su código; XP toma esta expectativa en serio y se espera que los
programadores desarrollen pruebas unitarias automatizadas para todo lo que escriben.
Finalmente, muchos equipos de XP se benefician del uso de un entrenador de XP y posiblemente de un

gerente de proyecto. Los roles a veces se combinan dentro de un solo individuo. El entrenador es
responsable de monitorear el uso que hace el equipo de las prácticas de XP y de empujarlos suavemente
hacia el camino cuando se desvían. El gerente de proyecto es más líder que gerente y es responsable de
proteger al equipo de la burocracia y eliminar tantos obstáculos como sea posible.
Las Doce Prácticas
La programación extrema se caracteriza por las doce prácticas descritas en el “libro blanco” original de
Kent Beck (Beck 2000). Si elige probar XP en un proyecto, se le recomienda encarecidamente que adopte
todas las prácticas. Las doce prácticas de XP son altamente sinérgicas e interdependientes. Las prácticas
se apoyan y habilitan unas a otras. Por ejemplo, la práctica de la refactorización se facilita mediante las
prácticas de programación de pares, diseño simple, propiedad colectiva, integración continua y pruebas.
Las doce prácticas no son una colección aleatoria de buenas ideas de las que un equipo de XP puede
elegir sus favoritas. Después de adquirir experiencia con XP, puede optar por abandonar o modificar una
práctica, pero realmente debería retrasar la personalización de XP hasta que tenga experiencia con XP
estándar.
En este apéndice consideraremos las siguientes doce prácticas de XP:
• pequeños lanzamientos
• el juego de la planificación
• refactorización
• prueba
• programación en pareja
• Marcha sostenible
• propiedad del código de equipo
T ÉL PAG LANNING GRAMO AME 235
• estándar de codificación
• diseño simple
• metáfora
• integración continua
• cliente in situ
Pequeños lanzamientos
Los proyectos de XP progresan en una serie de iteraciones, cada una de las cuales suele durar de una a tres semanas.
Las funciones, tal como las describen las historias de los usuarios, se entregan completamente en una sola iteración.
Un equipo no puede entregar la mitad de una función. De manera similar, un equipo no puede ofrecer la función
completa, pero con la mitad de la calidad. Al final de cada iteración, el equipo es responsable de entregar código
funcional y probado que se puede poner en uso de inmediato.
Al inicio del proyecto, el equipo selecciona una duración de iteración que utilizará durante la duración
del proyecto. La duración de la iteración suele ser de una o dos semanas y nunca más de cuatro. El equipo
debe seleccionar una duración de iteración que sea lo más corta posible pero que aún brinde valor tangible
al negocio. Cuando esté indeciso entre dos duraciones, elija la más corta.
Las iteraciones son cajas de tiempo firmes. Un equipo no puede llegar al último día planeado de una
iteración y decide que necesita dos días más. La iteración finaliza el día programado. La cantidad de
trabajo que hace el equipo (pero no la calidad de ese trabajo) se ajusta para adaptarse a la iteración.
El juego de la planificación
El "juego de planificación" es el nombre de XP para la planificación de versiones e iteraciones durante el cual

los desarrolladores y el cliente hacen predicciones sobre el futuro en colaboración. Antes de iniciar la
planificación, el cliente ha escrito historias de usuarios en tarjetas de notas y los desarrolladores han estimado
el costo o la magnitud de cada historia y han escrito la estimación en la tarjeta de historias.
Para comenzar a planificar, los desarrolladores estiman cuánto trabajo pueden completar en una iteración
de la duración seleccionada para el proyecto. Luego, el cliente revisa todas las tarjetas de historias y
selecciona sus historias de máxima prioridad para incluirlas en la primera iteración. Se le permite seleccionar
historias que sumen pero no excedan la cantidad de trabajo que los desarrolladores estiman que pueden hacer
en la iteración. Una vez que la primera iteración está llena de trabajo, el cliente pasa a seleccionar historias
para la segunda iteración y las siguientes.
Después de algunas iteraciones, el cliente decide que se han colocado suficientes historias en iteraciones
que, en conjunto, definen un lanzamiento. Es casi seguro que el plan de lanzamiento no refleja con precisión
lo que se desarrollará y en qué orden. El plan de lanzamiento es una hipótesis sobre cómo puede proceder el
desarrollo, pero se actualizará al comienzo de cada iteración a medida que cambien las prioridades, a medida
que el equipo se conozca más sobre la tasa de progreso y a medida que los desarrolladores aprendan más
sobre los verdaderos costos esperados. de cada historia.
Antes del inicio de cada iteración, el equipo y el cliente planifican la iteración. Esto implica seleccionar
las historias de mayor prioridad que se pueden completar en la iteración y luego identificar las tareas
específicas necesarias para completar la historia.
Refactorización
La refactorización (Fowler 1999; Wake 2003) se refiere a la reestructuración o reescritura del código para mejorar
el código sin cambiar su comportamiento externo. Con el tiempo, el código puede volverse feo. Un método
diseñado para un propósito se cambia ligeramente para manejar una condición especial. Luego, dado que ya
maneja esa condición especial, se cambia nuevamente para manejar otra condición especial. Y así sucesivamente
hasta que el método se vuelva demasiado frágil como para ser modificado.
XP aboga por una atención constante a la refactorización. Siempre que un programador realiza un
cambio en el código que debería ser refactorizado, debe refactorizarlo. No se anima a refactorizarlo; ella está
obligada a refactorizarlo. De esta manera, el código evita el deterioro lento, a veces difícil de detectar, que
eventualmente resulta en obsolescencia.
La refactorización es una de las técnicas utilizadas por XP para reemplazar el diseño inicial. En lugar de
pasar tiempo pensando en un sistema antes de codificarlo y, por lo tanto, adivinar algunos aspectos de su
comportamiento, los sistemas XP se refactorizan y mantienen en un estado que cumple perfectamente con los
requisitos conocidos e implementados.
Pruebas
Una práctica interesante de XP es su enfoque en las pruebas. En un proyecto de XP, los desarrolladores escriben
pruebas unitarias automatizadas y los clientes escriben pruebas de aceptación, que a menudo son automatizadas por
los propios clientes o con ayuda de los desarrolladores. Muchos desarrolladores de XP realmente han descubierto los
beneficios de las pruebas tempranas y frecuentes. Además, la resistencia tradicional de los desarrolladores a las
pruebas ha disminuido porque las pruebas unitarias de XP generalmente se automatizan escribiendo código de prueba
que ejercita el código operativo, es decir, incluso mientras se prueba que están programando.
PAG AIRE PAG ROGRAMAR 237
En el desarrollo tradicional, las pruebas se escriben después del código (si es que están escritas). Esto se
convierte en un problema porque una vez que el código está escrito y parece funcionar, puede ser parte de la
naturaleza humana no presionar demasiado el código. Entonces, muchos desarrolladores presionan suavemente su
código y lo llaman probado. (Lo sé: yo solía ser uno de ellos). XP cambia esto y pone las pruebas al principio en una
práctica llamada desarrollo impulsado por pruebas ( Beck 2003; Astels 2003).
En el desarrollo basado en pruebas, las pruebas se escriben antes del código. Los desarrolladores siguen un ciclo
corto (minutos, no horas) de prueba-código-prueba-código y así sucesivamente. Siguen la regla de que no se puede
escribir ningún código operativo excepto en respuesta a una prueba fallida. Entonces, escriben una prueba que falla. El
programa se ejecuta para verificar que la prueba falla. Solo entonces un programador escribe el código que hace que el
programa pase la prueba.
El desarrollo impulsado por pruebas garantiza que el código permanecerá bien factorizado y comprobable. También
conduce a un código más fácil de mantener, ya que el código está efectivamente en modo de mantenimiento desde el
principio.
Además de las pruebas de la unidad del programador, las pruebas de los clientes son una parte importante de
XP. Para cada historia, el cliente es responsable de definir una serie de pruebas que se utilizan para determinar si
la historia se desarrolló de acuerdo con las expectativas y suposiciones del cliente. En muchos sentidos, estas
pruebas de aceptación escritas por el cliente reemplazan los documentos de requisitos de un proceso en
cascada.
Programación en pareja
Una de las prácticas más controvertidas de XP es la programación en pareja. La programación en pareja se

refiere a dos programadores que comparten un teclado y un monitor, pero que utilizan sus dos cerebros para
escribir código. Mientras un programador escribe en el teclado (y piensa mentalmente unas líneas más adelante
en su código), el segundo programador observa cómo se desarrolla el código y piensa de manera más amplia
sobre a dónde puede conducir el código y qué problemas puede encontrar. Las parejas cambian roles y socios a
menudo.
Si bien la programación por pares puede parecer tremendamente ineficaz, Alistair Cockburn y Laurie
Williams (2001) la han estudiado y han descubierto que no es así. Descubrieron que para un aumento del 15%
en el tiempo total de programación, la programación por pares conduce a:
• menor número de defectos
• se escribe menos código para resolver el mismo problema
• problemas que se resuelven más rápidamente
• más personas entienden cada fragmento de código
• un aumento en la satisfacción laboral del desarrollador
La programación de pares es importante para XP porque muchas de las otras prácticas de XP requieren
disciplina. Se requiere una gran cantidad de disciplina para refactorizar cada vez que observe un código mal
estructurado o escribir siempre pruebas antes de escribir código operativo. Sin un par, puede ser demasiado
tentador omitir una refactorización o una prueba con el pensamiento de "Solo por esta vez ..."
Marcha sostenible
Se anima a los equipos de XP a trabajar a un ritmo sostenible. La creencia es que un equipo de XP que se mueve
a un ritmo constante pero rápido logrará más durante un período de tiempo que un equipo que trabaja a un ritmo
que no puede mantener durante un período prolongado. Esto no significa que un equipo de XP trabaje
exactamente cuarenta horas a la semana y luego se vaya a casa. Depende del equipo determinar su ritmo
sostenido, y es probable que sea diferente para los diferentes miembros del equipo.
La programación de pares y el desarrollo impulsado por pruebas son efectivos porque enfocan las mentes de
los pares de manera muy intensa en el código que están creando. Pocas personas son capaces de mantener
este nivel de intensidad durante períodos prolongados. Por lo general, un equipo dedicará alrededor de seis horas
al día al emparejamiento y pasará el resto del día en otras actividades.
Un entrenador de XP es responsable de monitorear al equipo en busca de agotamiento. Si el entrenador siente

que un equipo se está quemando, ayudará al equipo a volver a trabajar a un ritmo sostenible.
Propiedad del código del equipo
Ha sido común entre los equipos que no son de XP que los desarrolladores individuales "posean" o asuman la
responsabilidad total por partes del código de un sistema. De esta manera, cada parte de un sistema sería
propiedad de un desarrollador, al menos hasta que un desarrollador pase a otro proyecto y su código se quede sin
propietario. Esta visión de la propiedad del código también lleva a los equipos a hacer comentarios como "No
podemos cambiar el código fuente de facturación hasta que Eli regrese de las vacaciones". Además, si se
convence a un desarrollador de que cambie el código mientras Eli está de vacaciones, es probable que Eli se
enoje por los cambios realizados en “su código” cuando regrese.
Los equipos de XP adoptan un enfoque completamente diferente para la propiedad del código: todo el código es propiedad
de todos. Bajo este modelo de propiedad del equipo, cualquier par de desarrolladores puede cambiar cualquier código. De
hecho, debido a la práctica de refactorización, se espera que los pares cambien el código que no escribieron.
Se practica la propiedad individual para garantizar un diseño coherente y mantener equilibradas todas las
responsabilidades de un módulo. En XP, esta carga la soportan las pruebas
METRO ETAPHOR 239
desarrollo. Un conjunto sólido de pruebas unitarias garantiza que los cambios no introduzcan efectos secundarios
imprevistos.
Estándares de codificación
Debido a que los equipos de XP poseen colectivamente su código fuente, es importante que sigan un estándar de
codificación. El estándar de codificación establece las principales reglas y convenciones que los miembros del equipo
seguirán al escribir código: ¿cómo se nombrarán las variables y los métodos? ¿Cómo se formatearán las líneas? y
así.
Un equipo pequeño y muy unido puede arreglárselas sin un estándar de codificación formalizado y escrito.
Pueden construir y compartir estándares a través del folclore en equipo. Más allá de un puñado de desarrolladores,
la mayoría de los equipos se beneficiarán escribiendo sus estándares de codificación, pero manteniéndolos lo más
breves y esenciales posible.
Diseño simple
Los equipos de XP persiguen el objetivo de tener el diseño más simple posible que ofrezca las características que
necesita un cliente. Kent Beck (2000) define cuatro restricciones que indican cuándo un diseño es lo más simple que
puede ser:
1. El código operativo y el código de prueba transmiten completamente la intención del programador para el
comportamiento de ese código.
2. No hay código duplicado.
3. El sistema utiliza el menor número de clases.
4. El sistema utiliza el menor número de métodos.
Metáfora
Los equipos de XP apoyan la búsqueda de un diseño simple al encontrar una metáfora que se pueda
utilizar para todo el sistema. La metáfora proporciona un marco de referencia de cómo piensan sobre el
sistema. Por ejemplo, en un proyecto, nuestra metáfora fue que el sistema era como una pizarra y que
varias partes del sistema podían escribir en la pizarra. Cuando el usuario terminaba con el sistema,
guardaba el contenido de la pizarra o lo borraba. Esta forma muy simplificada de pensar sobre el sistema
nos ayudó al brindarnos una forma cómoda y sencilla de pensar sobre el comportamiento del sistema.
Integración continua
Recientemente me involucré en una discusión con un ejecutivo de una de las empresas de comercio
electrónico más grandes. Me dijo que integrar el trabajo de varios desarrolladores era el mayor problema
para la mayoría de los equipos de desarrollo de software. Le gustaba que sus equipos integraran su
software una vez al mes para que pudieran evitar los problemas mayores de integrarse con menos
frecuencia. Le pregunté qué pasaría si sus equipos se integraran a diario.
Los equipos de XP conocen la respuesta y se integran al menos a diario. Aprendimos hace mucho tiempo sobre los
beneficios de una prueba diaria de construcción y humo (Cusumano y Selby
1995). Los equipos de XP han llevado esto hasta el punto en que el código se integra de forma más o menos continua.
Por ejemplo, un desarrollador completa un pequeño cambio, lo registra en el repositorio de código fuente donde un
proceso nota el cambio e inicia una compilación completa. Cuando se completa la compilación, se ejecuta un conjunto
de pruebas automatizadas. Si alguna de las pruebas falla, se envía un correo electrónico al desarrollador y se le
informa sobre la falla. Los problemas de integración se solucionan de uno en uno en lotes extremadamente pequeños
tan pronto como ocurren.
Cliente in situ
Solía ser común que un cliente escribiera un documento de requisitos, lo arrojara sobre una pared a los
programadores que escribían el código y luego arrojara el sistema sobre otra pared a algunos probadores.
Con XP, los muros desaparecieron y se espera que el cliente se siente y sea parte del equipo de
desarrollo. El cliente escribe las historias y las pruebas de aceptación y también está disponible para
responder preguntas tan pronto como surjan.
El cliente en el sitio es esencial para el uso exitoso del enfoque de historia de usuario debido a las
muchas conversaciones que deben producirse entre el cliente y los desarrolladores. Si el cliente no está en
el sitio, las demoras interrumpirán el progreso predecible del equipo de XP.
Valores de XP
Además de sus prácticas, XP aboga por cuatro valores: comunicación, simplicidad, retroalimentación y coraje.
XP valora la comunicación, pero no todos los modos de comunicación son iguales. Lo más deseable es la
comunicación cara a cara en la que podamos hablar, responder, hacer gestos y dibujar en una pizarra. Menos
deseables son los documentos escritos. XP enfatiza la comunicación a través de prácticas como la
programación por pares.
T ÉL PAG RINCIPIOS DE XP 241
La simplicidad es un valor de los equipos de XP porque mantiene su enfoque en la creación de una

solución al problema que enfrentan hoy, no el problema anticipado mañana. Los equipos de XP no diseñan
un sistema con soporte para características más allá de las necesarias para desarrollar las características de
la iteración actual. Permanecen constantemente enfocados en hacer lo más simple que pueda funcionar.
Los equipos de XP valoran la retroalimentación, y cuanto más inmediata sea la retroalimentación, mejor. Los
desarrolladores de XP dan y reciben comentarios durante la programación de parejas cuando un desarrollador señala un
problema potencial a su pareja. Obtienen comentarios de las pruebas automatizadas que ejecutan con tanta frecuencia.
Reciben retroalimentación de su proceso de integración continuo (o al menos diario). Los clientes son parte del equipo,
incluso sentados en el mismo espacio con los desarrolladores, y brindan retroalimentación a través de la interacción
constante con el equipo y a través de las pruebas de aceptación que escriben.
Finalmente, los equipos de XP valoran el coraje. Por ejemplo, tienen el valor de refactorizar su código
(porque tienen pruebas automatizadas para respaldar ese valor). Tienen el valor de continuar sin una
arquitectura maestra general porque usarán una metáfora y mantendrán un diseño simple a través de la
refactorización y el desarrollo basado en pruebas.
Los principios de XP
Además de sus valores y prácticas, XP se puede caracterizar por sus cinco principios básicos:
retroalimentación rápida, asumir simplicidad, cambio incremental, aceptar el cambio y hacer un trabajo de
calidad (Beck 2000). Desde la introducción de XP, ha surgido un debate sobre si un equipo puede estar
haciendo XP si solo hace once de las doce prácticas originales. ¿Un equipo que no empareja el programa está
haciendo XP? ¿Es un equipo que persigue un diseño simple pero comienza con algunas semanas de
modelado haciendo XP?
Creo que la respuesta es sí. Estos equipos están haciendo XP si se rigen por los principios de XP. Un
equipo que:
• proporciona retroalimentación rápida a sus clientes y aprende de esa retroalimentación
• favorece la simplicidad y siempre intenta una solución simple antes de pasar a una más compleja
• mejora el software mediante pequeños cambios incrementales
• acepta el cambio porque sabe que es verdaderamente experto en adaptarse y adaptarse
• e insiste en que el software exhibe constantemente el más alto nivel de mano de obra de calidad
Ciertamente debe estar haciendo XP, incluso si faltan una práctica o dos.
Resumen
• El rol de cliente de XP es responsable de escribir historias y pruebas de aceptación para cada historia,
y forma parte del equipo de desarrollo.
• En un proyecto XP, la distinción entre programador y probador es borrosa. Los programadores escriben pruebas
unitarias de su propio código; Los probadores programan pruebas de aceptación automatizadas.
• Los proyectos de XP incluyen un entrenador y posiblemente un gerente de proyecto independiente que es

responsable de guiar al equipo y eliminar obstáculos en su camino.
La programación extrema implica las siguientes prácticas:
• pequeños lanzamientos
• el juego de la planificación
• refactorización
• prueba
• programación en pareja
• Marcha sostenible
• propiedad colectiva del código
• estándar de codificación
• diseño simple
• metáfora
• integración continua
• cliente in situ
Y tiene estos valores:
• comunicación
• simplicidad
S UMMARY 243
• retroalimentación
• coraje
Y tiene estos principios clave:
• retroalimentación rápida
• asumir la simplicidad
• cambio incrementado
• aceptar el cambio
• trabajo de calidad
apéndice B
Respuestas a preguntas
Capítulo 1, Descripción general
1.1. ¿Cuáles son las tres partes de una historia de usuario?
Responder: Tarjeta, conversación y confirmación.

1.2. ¿Quién está en el equipo del cliente?
Responder: El equipo del cliente incluye a aquellos que se aseguran de que el software
satisfará las necesidades de los usuarios previstos. Esto puede incluir probadores, un gerente de
producto, usuarios reales y diseñadores de interacción.
1.3. ¿Cuáles de las siguientes no son buenas historias? ¿Por qué?

Responder: Consulte la Tabla B.1.
Cuadro B.1 Respuesta a la pregunta 1.3.
Historia Responder
a. El usuario puede ejecutar el sistema en Win- Esta es una buena historia. dows XP y
Linux.
segundo. Todos los gráficos y diagramas se realizarán Ésta no es una buena historia. A los usuarios no les importará
utilizando una biblioteca de terceros. cómo se hagan los gráficos y los gráficos.
C. El usuario puede deshacer hasta cincuenta comandos. Esta es una buena historia.
re. El software se lanzará en junio Ésta no es una buena historia. Es una restricción que deberá
30. tenerse en cuenta durante la planificación del lanzamiento.
mi. El software estará escrito en Java. Probablemente esta no sea una buena historia, pero depende
del producto. Si el producto es una biblioteca de clases que se
comercializa para programadores de Java, esos usuarios se
preocuparán por el lenguaje.
245
246 UNA PÉNDICE segundo
Cuadro B.1 Respuesta a la pregunta 1.3. (Continuado)
Historia Responder
F. El usuario puede seleccionar su país de una buena historia, pero puede ser una pequeña lista desplegable.
pequeño.
gramo.
El sistema utilizará Log4J para registrar todos Esta no es una buena historia como está escrita. Eso
mensajes de error a un archivo. no debe especificar que Log4J se utilice como

mecanismo de registro.
h. Se le pedirá al usuario que la guarde. Esta es una buena historia. trabajar si no lo ha

guardado durante 15 minutos
utes.
yo. El usuario puede seleccionar una función "Exportar Esta es una buena historia.
a XML".
j. El usuario puede exportar datos a XML. Esta es una buena historia.
1.4. ¿Qué ventajas tienen las conversaciones sobre requisitos sobre los documentos de requisitos?
Responder: Los documentos escritos implican una precisión que no pueden respaldar. Las historias de
usuario, con tarjetas como recordatorio para mantener conversaciones, evitan la falsa
apariencia de ser muy precisas. Escribir las cosas no es garantía de que los clientes
obtengan lo que quieren; en el mejor de los casos, los clientes obtendrán lo que se escribió.
Las conversaciones frecuentes, especialmente las cercanas y durante el desarrollo de la
función que se está discutiendo, conducen a una comprensión mayor y compartida entre los
desarrolladores y los clientes.
1.5. ¿Por qué querrías escribir pruebas en el reverso de una tarjeta de historia?
Responder: Escribir pruebas en el reverso de una tarjeta es una excelente manera para el cliente
comunicar sus expectativas y suposiciones sobre una historia.
Capítulo 2, Escribir historias
2.1. Para las siguientes historias, indique si es una buena historia o no. Si no, ¿por qué?
2.2. Divida esta epopeya en historias de componentes del tamaño adecuado: "Un usuario puede crear y cambiar agentes de
búsqueda de empleo automatizados".
Responder: Como mínimo, esta epopeya debería dividirse en dos historias, una para hacer
y otro para cambiar de agente. Sin embargo, podría dividirse de muchas formas diferentes,
dependiendo del tiempo que sea posible que se tarde en implementar las historias. Una posible
desagregación es:
• Un usuario puede hacer un agente de búsqueda de empleo automatizado.
C HAPTER 3, U SER R VIEJO METRO ODELING 247
• Un usuario puede editar los parámetros de búsqueda de un agente de búsqueda de empleo
automatizado.
• Un usuario puede cambiar las horas en las que se ejecutará un agente automatizado de búsqueda de
empleo.
• Un usuario puede cambiar la forma en que se informarán los resultados de un agente de búsqueda de
empleo automatizado.
Historia Responder
a. Un usuario puede dominar rápidamente el sistema. Esta historia debería cambiarse. No se definen
ni "rápido" ni "maestro".
segundo. Un usuario puede editar la dirección en un Esta historia probablemente sea demasiado pequeña, pero podría
currículum. estar bien dependiendo de cuánto tiempo les tomaría a los
desarrolladores implementarla.
C. Un usuario puede agregar, editar y eliminar múltiples currículos. Esta es una historia compuesta y debe dividirse en
varias historias.
re. El sistema puede calcular aproximaciones de punto Si el cliente escribió esta historia, probablemente sepa lo
de silla para distribuciones de formas cuadráticas en que significa. Sin embargo, si los desarrolladores no
variables normales. comprenden esta historia, el cliente debería considerar
reescribirla (o al menos tener una buena conversación al
respecto) para que los desarrolladores puedan estimarla.
mi. Todos los errores de tiempo de ejecución se registran de Esta historia está bien tal como está.
manera coherente.
Capítulo 3, Modelado de roles de usuario
3.1. Eche un vistazo al sitio web de eBay. ¿Qué roles de usuario puede identificar?
Responder: Su lista debe incluir algunos roles similares a estos: Una vez
Vendedor, pequeño vendedor, vendedor frecuente, comprador poco frecuente, comprador frecuente,
vendedor corporativo, fabricante, procesador de pagos, coleccionista, miembro del club, desarrollador
de software, afiliado, vendedor inalámbrico, comprador inalámbrico
3.2. Consolide los roles que se le ocurrieron en la pregunta anterior y muestre cómo distribuiría las
tarjetas de roles. Explica tu respuesta.
Responder: De mi lista, consolidé a los vendedores en un rol de vendedor genérico y
tres vendedores más especializados: vendedor pequeño, vendedor frecuente y
Vendedor corporativo. De manera similar, tenía un rol de Comprador genérico especializado en

Comprador infrecuente, Comprador frecuente y Recopilador. También mantuve Procesador de pagos,
Afiliado y un Usuario inalámbrico genérico.
3.3. Escriba descripciones de personajes para el rol de usuario más importante.

Responder: Brenda es un comprador frecuente. Durante una semana normal, visita el sitio al menos una vez
al día y realiza una media de una o dos compras por semana. Normalmente compra películas y
libros, pero también ha comprado artículos de jardinería y cocina. Ella es una agente de bienes
raíces y se siente muy cómoda en nuestro sitio, pero se siente un poco incómoda al aprender la
mayoría del software nuevo. Por lo general, accede al sitio desde su conexión de acceso
telefónico en casa, pero ocasionalmente lo hace desde su conexión de oficina más rápida.
Capítulo 4, Recopilación de historias
4.1. ¿Qué problemas esperaría si un equipo solo reuniera los requisitos mediante el uso de
cuestionarios?
Responder: Los cuestionarios pueden tardar más en completarse, por lo que el proyecto tardará más
en completarse. Alguien necesitará agregar e interpretar los resultados, lo que significa
que habrá algún grado de mala interpretación. Debido a que los cuestionarios no brindan
una verdadera comunicación bidireccional, será extremadamente difícil para un equipo
obtener comentarios sobre si está en el camino correcto.
4.2. Reformule las siguientes preguntas para que sean libres de contexto y abiertas. ¿Crees que el usuario debería tener
que ingresar una contraseña? ¿Debería el sistema guardar automáticamente el trabajo del usuario cada 15
minutos? ¿Puede un usuario ver las entradas de la base de datos guardadas por otro usuario?
Responder: Hay muchas formas de reformularlos. Aquí hay unos ejemplos:
• Describa cómo el sistema debe proteger los datos confidenciales.
• ¿Qué haría un usuario si el sistema fallara mientras lo estaba usando?
• Cuéntame sobre la accesibilidad de los datos guardados por un usuario.
4.3. Por que es ¿Es mejor hacer preguntas abiertas y sin contexto?
Responder: Las preguntas libres de contexto no implican una respuesta (“¿Cuándo dejaste de golpear
a tu esposa?”), Por lo que el entrevistado no siente la necesidad de dar la respuesta
“correcta”. Las preguntas abiertas permiten respuestas detalladas que van más allá de un
simple sí o no. Las preguntas abiertas y sin contexto son las mejores porque no influyen
en la
C HAPTER 7, G UIDELINES PARA GRAMO OOD S TORIES 249
respuesta y permiten una gama más amplia de respuestas que sí o no.
Capítulo 5, Trabajo con proxies de usuario
5.1. ¿Qué problemas pueden surgir al utilizar el administrador de usuarios como proxy para los usuarios?
Responder: Incluso si el administrador de usuarios es un usuario actual del software, su

es casi seguro que las necesidades difieran de las necesidades de los usuarios. Peor aún, si ella es un
usuario anterior, su conocimiento del sistema está desactualizado.
5.2. ¿Qué problemas pueden surgir al utilizar un experto en el dominio como proxy para los usuarios?
Responder: Un problema es que el experto en el dominio puede no ser un usuario del

sistema. Si es así, su uso del sistema puede diferir del de los usuarios menos expertos. Un
segundo problema es que puede terminar con un sistema que es perfecto para expertos, pero
que no es utilizable por aquellos con conocimientos de dominio de nivel inferior al experto.
Capítulo 6, Historias de usuarios de pruebas de aceptación
6.1. ¿Quién especifica las pruebas? ¿Quien ayuda?

Responder: El cliente especifica las pruebas. El cliente normalmente trabajará
con un programador o probador para crear realmente las pruebas, pero como mínimo el cliente
necesita especificar las pruebas que se utilizarán para saber cuándo se ha desarrollado
correctamente una historia.
6.2. ¿Por qué especificar pruebas antes de codificar las historias?

Responder: Las pruebas se especifican antes de que comience la codificación porque son útiles
y método eficaz para comunicar las suposiciones del cliente sobre la nueva
funcionalidad.
Capítulo 7, Pautas para las buenas historias
7.1. Suponga que la historia "Una persona que busca empleo puede buscar puestos vacantes" es demasiado grande para caber en
una iteración. ¿Cómo lo dividirías?
Responder: Esta historia probablemente se pueda dividir en función de los parámetros de búsqueda
admitido, como ubicación, palabras clave, título del trabajo, salario, etc. Además, puede
haber diferentes formas de presentar los resultados.
Una historia inicial podría cubrir una lista muy simple de cada trabajo combinado. Esa historia
podría ampliarse con una historia para mejorar la visualización de los resultados, tal vez con
más detalles sobre cada trabajo, lo que permite al usuario seleccionar un orden de
clasificación o qué campos se muestran, o proporcionar un enlace a más detalles sobre el
trabajo.
7.2. ¿Cuál de estas historias tiene el tamaño adecuado y se puede considerar una historia cerrada?
Historia Responder
a. Un usuario puede guardar sus preferencias. Esta historia puede o no estar cerrada, según el sistema. Si
guardar preferencias es algo que un usuario puede querer
hacer, probablemente se pueda considerar cerrado. Puede
que sea algo pequeño, pero probablemente esté bien, de
nuevo dependiendo del sistema y del equipo que lo
construya.
segundo. Un usuario puede cambiar la tarjeta de crédito Esta es una historia cerrada y de tamaño apropiado.
predeterminada utilizada para compras.
C. Un usuario puede iniciar sesión en el sistema. Esta historia no está cerrada y probablemente sea demasiado
pequeña.
7.3. ¿Qué cambios simples podrían mejorar la historia "Los usuarios pueden publicar sus currículums"?
Responder: Tal como está escrito, no está claro si un usuario puede publicar varios currículums. Esta
indudablemente saldrá a la luz durante las conversaciones sobre la historia, pero es mejor escribir la
historia con más claridad ya que "Un buscador de empleo puede publicar uno o más currículums".
7.4. ¿Cómo probaría la restricción "El software será fácil de usar"?

Responder: Para probar esto, primero debe definir qué significa "fácil de usar". ¿Significa que un
usuario experto puede completar tareas comunes con un número mínimo de pulsaciones
de teclas? ¿O significa que un nuevo usuario puede alcanzar rápidamente un nivel
determinado de competencia con el software? Lo más común es que se refiera a lo
último. Si es así, defina una o más pruebas como:
• Un nuevo usuario puede buscar un trabajo, registrarse en el sistema y publicar su currículum dentro
de los 30 minutos de haber visto el sistema por primera vez.
Pruebas como estas no se pueden realizar como parte de las compilaciones nocturnas de un proyecto,
pero se pueden verificar mediante pruebas de usabilidad ocasionales durante las cuales se muestra el
software y se observa a los nuevos usuarios.
C HAPTER 9, P LANNING A R Por favor 251
Capítulo 8, Estimación de historias de usuarios
8.1. Durante una reunión de estimación, tres programadores están estimando una historia. De forma
individual, estiman la historia en dos, cuatro y cinco puntos. ¿Qué estimación deberían utilizar?
Responder: Deben continuar discutiendo la historia hasta que sus estimaciones sean
más cerca.
8.2. ¿Cuál es el propósito de triangular estimaciones?

Responder: La triangulación mejora las estimaciones al asegurarse de que cada
mate tiene sentido en relación con muchas otras estimaciones. Si una historia de dos puntos
parece ser dos veces una historia de un punto, también debería parecer la mitad de una historia de
cuatro puntos.
8.3. Defina la velocidad.

Responder: La velocidad es el número de puntos de la historia completados por un equipo en un
iteración.
8.4. El equipo A terminó 43 puntos de historia en su última iteración de dos semanas. El equipo B está trabajando en un
proyecto separado y tiene el doble de desarrolladores. También completaron 43 puntos de historia en su última
iteración de dos semanas. ¿Como puede ser?
Responder: Los puntos de la historia de un equipo no son comparables a la historia.

puntos de cualquier otro equipo. A partir de la información de esta pregunta, no podemos inferir que el
equipo A sea dos veces más productivo que el equipo B.
Capítulo 9, Planificación de un lanzamiento
9.1. ¿Cuáles son las tres formas de estimar la velocidad inicial de un equipo?
Responder: Puede utilizar valores históricos, adivinar o ejecutar un itera-
ción y use la velocidad de esa iteración.
9.2. Suponiendo iteraciones de una semana y un equipo de cuatro desarrolladores, ¿cuántas iteraciones
necesitará el equipo para completar un proyecto con 27 puntos de historia si tienen una velocidad de 4?
Responder: Con una velocidad de 4 y 27 puntos de historia en el proyecto, se necesitarán

el equipo 7 iteraciones para terminar.
Capítulo 10, Planificación de una iteración
10.1. Desglose esta historia en sus tareas constitutivas: un usuario puede ver información detallada sobre
un hotel.
Responder: Por supuesto, hay muchas formas de hacer esto, pero aquí hay una:
• Diseña el aspecto de estas páginas web.
• Codifique el HTML para mostrar fotos de habitaciones y hoteles.
• Codifique el HTML para mostrar un mapa que muestre dónde está el hotel.
• Codifique el HTML para mostrar una lista de comodidades y servicios del hotel.
• Descubra cómo estamos generando mapas.
• Escriba SQL para recuperar información de la base de datos. Y así.
Capítulo 11, Medición y control de la velocidad
11.1. Una historia estimada en un punto de la historia en realidad tardó dos días en completarse. ¿Cuánto
contribuye a la velocidad cuando se calcula al final de la iteración?
Responder: Aporta un punto.

11.2 ¿Qué puede aprender de un gráfico de evolución diario que no puede ver en un gráfico de evolución de
iteración?
Responder: Los gráficos de evolución diaria muestran el progreso del equipo durante la iteración.
Puede utilizar esta información para evaluar si todo el trabajo planificado se completará
al final de la iteración. Si resulta evidente que no se puede completar todo el trabajo, el
equipo y el cliente pueden hablar durante la iteración sobre qué trabajo debe aplazarse.
11.3 ¿Qué conclusiones debería sacar de la figura 11.7? ¿Parece que el proyecto terminará antes,
tarde o según lo programado?
Responder: Este equipo empezó un poco mejor de lo previsto en el primer
iteración. Esperaban que la velocidad mejorara en la segunda y tercera iteraciones y luego
se estabilizara. Después de dos iteraciones, ya han alcanzado la velocidad que esperaban
después de tres iteraciones. En este punto, están adelantados a lo programado, pero
debería ser reacio a sacar demasiadas conclusiones firmes después de solo dos
iteraciones.
C HAPTER 12, W SOMBRERO S TORIES UNA RE norte Antiguo Testamento 253
11.4 ¿Cuál es la velocidad del equipo que terminó la iteración que se muestra en la tabla 11.3?
Responder: Dieciséis. Las historias parcialmente completadas no contribuyen a la velocidad.
11.5 ¿Qué circunstancias harían que un gráfico de evolución de iteraciones refleje una tendencia ascendente?
Responder: Un gráfico de evolución de iteraciones tendrá una tendencia ascendente si se

agregar más rápido de lo que se completa el trabajo conocido, o si el equipo decide que
se ha subestimado una cantidad significativa de trabajo futuro.
11.6. Complete la tabla 11.4 escribiendo los valores faltantes en la tabla.

Responder: La tabla completa aparece como Tabla B.4.
Iteración 1 Iteración 2 Iteración 3
Puntos de historia al inicio de la iteración 100 76 34
Completado durante la iteración 35 40 36
Estimaciones modificadas 5 -5 0
Puntos de historia de nuevas historias 6 3 2
Puntos de historia al final de la iteración 76 34 0
Capítulo 12, Qué historias no son
12.1 ¿Cuáles son las diferencias clave entre las historias de usuario y los casos de uso?
Responder: Una historia de usuario generalmente abarca un alcance menor que un caso de uso.
Las historias de usuario no incluyen tantos detalles como los casos de uso. Las historias de usuario no
están destinadas a ser útiles después de la iteración en la que se desarrollan; Los casos de uso a menudo
están pensados como artefactos permanentes de un proyecto.
12.2 ¿Cuáles son las diferencias clave entre las historias de usuario y las declaraciones de requisitos de
IEEE 830?
Responder: Las declaraciones de requisitos de estilo IEEE 830 se centran en los atributos de la solución, mientras
que las historias de los usuarios se centran en los objetivos del usuario. Las especificaciones de
requisitos de IEEE 830 alientan a los equipos a escribir todas las declaraciones de requisitos por
adelantado en lugar de hacerlo de manera iterativa, como ocurre con las historias de usuario. Se tiene
mucho cuidado al escribir las declaraciones de requisitos para asegurarse de que las palabras transmitan
el significado correcto; Las historias de usuarios reconocen la superioridad de las conversaciones para
aclarar detalles.
12.3 ¿Cuáles son las diferencias clave entre las historias de usuario y los escenarios de diseño de interacción?
Responder: Los escenarios de diseño de interacción son mucho más detallados que los
historias, que a menudo describen la persona y el contexto del uso del sistema con gran detalle.
Además, un escenario a menudo describe un alcance más amplio que una historia de usuario.
12.4. Para un proyecto no trivial, ¿por qué es imposible escribir todos los requisitos al inicio del proyecto?
Responder: Intentar escribir todos los requisitos al inicio de un proyecto

ignora un ciclo de retroalimentación importante. Cuando los usuarios previstos de un sistema
comienzan a ver e interactuar con el sistema, surgen nuevos requisitos.
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?
Responder: Una lista de atributos no le da al lector el mismo nivel general
comprensión de un producto que hacen las historias y las conversaciones. Además, si nuestro
trabajo se basa en una lista de atributos del producto, cuando terminamos, lo mejor que
podemos decir es que el producto entregado posee los atributos de la lista. Esto no es lo mismo
que decir que el producto entregado cumple con todos los objetivos del usuario.
Capítulo 13, ¿Por qué las historias de usuarios?
13.1 ¿Cuáles son las cuatro buenas razones para utilizar historias de usuarios para expresar requisitos?
Responder: Las historias de usuario enfatizan la comunicación verbal, son comprensibles

que todos puedan tener el tamaño adecuado para la planificación, apoyan el desarrollo
iterativo, fomentan el aplazamiento de los detalles, apoyan el diseño oportunista, fomentan el
diseño participativo y acumulan conocimiento tácito.
13.2 ¿Cuáles pueden ser los dos inconvenientes de utilizar historias de usuarios?
Responder: En proyectos grandes, puede resultar difícil mantener organizados cientos o miles de historias;
las historias pueden necesitar ser aumentadas con documentos adicionales para la trazabilidad;
y, si bien son excelentes 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 proyectos grandes.
13.3 ¿Cuál es la diferencia clave entre diseño participativo y empírico?

Responder: En el diseño participativo, los usuarios previstos de un sistema se convierten en
parte del equipo que diseña el comportamiento de ese sistema. En empiri-
C HAPTER 15, U CANTA S TORIES CON S CRUM 255
cal, los usuarios previstos son estudiados u observados por los diseñadores del
software, quienes luego toman todas las decisiones de diseño.
13.4 ¿Qué hay de malo en la declaración de requisitos, "Todos los informes de varias páginas deben estar
numerados"?
Responder: No está claro qué significa "deben numerarse". Esto significa
que los programadores deberían codificar esta funcionalidad pero no tienen que hacerlo?
¿Significa que las páginas deben estar numeradas si hay espacio en la página?
Capítulo 14, Un catálogo de olores de historias
14.1 ¿Qué debe hacer si al equipo le resulta constantemente difícil planificar la próxima iteración?
Responder: Puede haber otras razones, pero debe considerar si

demasiadas historias son interdependientes, o son demasiado pequeñas o demasiado grandes.
14.2 ¿Qué debe hacer el equipo si constantemente se está quedando sin espacio para escribir en las tarjetas de
historias?
Responder: Deben usar tarjetas más pequeñas para hacer cumplir la disciplina de mantener
detalles de las descripciones de la historia.
14.3 ¿Qué puede hacer que el cliente tenga dificultades para priorizar las historias?
Responder: Las historias pueden tener un tamaño incorrecto (demasiado grandes o demasiado pequeñas)
o las historias pueden no expresar claramente el valor para los usuarios o clientes.
14.4. ¿Cómo saber si está dividiendo demasiadas historias?

Responder: Tienes que confiar en tu instinto. Las historias son a menudo y legítimas
maly divididos porque fueron escritos intencionalmente como epopeyas para empezar, o porque son
demasiado grandes para caber en una iteración. Si se encuentra dividiendo historias con frecuencia
por otras razones, es posible que lo esté haciendo con demasiada frecuencia.
Capítulo 15, Uso de historias con Scrum
15.1. Describa las diferencias entre un proceso incremental y uno iterativo.

Responder: Un proceso iterativo es aquel que avanza a través de sucesivas
refinamiento. Un proceso incremental es aquel en el que el software se construye y se
entrega en piezas.
15.2 ¿Cuál es la relación entre la cartera de pedidos del producto y la cartera de pedidos del sprint?
Responder: Los elementos se mueven de la cartera de productos a la cartera de trabajos pendientes

al comienzo de un sprint.
15.3 ¿Qué se entiende por incremento de producto potencialmente enviable?

Responder: Al final de cada sprint, un equipo Scrum es responsable de crear
un incremento de producto potencialmente enviable. Esto significa que el software está codificado,
probado y podría entregarse a los usuarios.
15.4 ¿Quién es responsable de priorizar el trabajo y de seleccionar el trabajo que realizará el equipo
durante un sprint?
Responder: El Product Owner prioriza el trabajo pero el equipo selecciona el
trabajo que realizarán durante un sprint. Naturalmente, se espera que seleccionen entre
los elementos de máxima prioridad.
15.5 ¿Qué preguntas responde cada miembro del equipo en el scrum diario?
Responder: ¿Qué hiciste ayer? ¿Qué vas a hacer hoy? Qué hay dentro
¿a tu manera?
Capítulo 16, Temas adicionales
16.1. ¿Cómo debe manejar un requisito para que un sistema se amplíe para ser usado por
1.000 usuarios concurrentes?
Responder: Debe escribir esto como una restricción y luego complementarlo con las pruebas
adecuadas. Dependiendo del sistema, es posible que desee comenzar con una prueba
para 100 usuarios simultáneos en una iteración y aumentarla progresivamente a 1,000
usuarios en varias iteraciones.
16.2. Vos si ¿Prefiere escribir historias en tarjetas de notas o en un sistema de software? tu respuesta.
Defender
Responder: La simplicidad de baja tecnología de las tarjetas de notas las hace ideales para muchos proyectos. Las
tarjetas también ofrecen una cantidad limitada de espacio, lo que ayuda a que las historias sean breves.
Debido a que se pueden mover fácilmente sobre una mesa o pared, son ideales para planificar. Sin
embargo, es posible que un equipo que no esté ubicado en una ubicación conjunta o que tenga requisitos
de trazabilidad estrictos prefiera trabajar con software.
16.3 ¿Qué impacto tiene un proceso iterativo en la interfaz de usuario de una aplicación?
Responder: El refinamiento iterativo del sistema puede dificultar que los usuarios
aprender el sistema. Cuando los sistemas de menús cambian o las funciones aparecen en diferentes lugares, los
usuarios deben volver a aprender su sistema.
C HAPTER 16, A DDICIONAL T ÓPTICA 257
16.4. Proporcione algunos ejemplos de sistemas que podrían beneficiarse de una consideración más directa de la
interfaz de usuario de la que normalmente se da en un proyecto ágil.
Responder: Puede haber muchos ejemplos, pero aquí hay algunos:
• un producto comercial que compite en una industria madura principalmente a través de

la facilidad de uso
• software dirigido a usuarios novatos
• software que se utilizará con poca frecuencia, pero durante períodos intensos (como para la preparación de
impuestos sobre la renta)
• software para usuarios de baja visión o usuarios con trastornos del movimiento
Referencias
Libros y articulos
Adolph, Steve, Paul Bramble y col. Patrones para casos de uso eficaces. Leyendo,
Mass .: Addison-Wesley, 2002.
Antón, Annie I. y Colin Potts. “El uso de metas para hacer emerger los requisitos
for Evolving Systems ”, en Actas de la 20ª Conferencia Internacional sobre Ingeniería de Software
(ICSE 98), abril de 1998: 157–166.
Astels, Dave. Desarrollo basado en pruebas: una guía práctica. Río Upper Saddle,
Nueva Jersey: Prentice Hall, 2003.
Beck, Kent. Explicación de la programación extrema: Adopte el cambio. Boston: Addi-

hijo-Wesley, 2000.
- - -. Desarrollo basado en pruebas. Reading, Mass .: Addison-Wesley, 2003. Beck, Kent y Martin
Fowler. Planificación de la programación extrema. Leyendo,
Mass .: Addison-Wesley, 2000.
Beedle, Mike y col. "SCRUM: un lenguaje de patrones para software hiperproductivo
Desarrollo de productos ". En Neil Harrison et al. (Eds.), Lenguajes de patrones de diseño de programas 4. Addison-Wesley:
1999, págs. 637–651.
Boehm, Barry. "Un modelo en espiral de desarrollo y mejora". IEEE
Computadora 28, No. 5 (Mayo de 1988): 61–72.
- - -. Economía de la Ingeniería de Software. Englewood Cliffs, Nueva Jersey: PrenticeHall, 1981.
Bower, GH, JB Black y TJ Turner. "Secuencias de comandos en la memoria para texto". Diente-
Psicología nitiva 11 ( 1979): 177–220.

Carroll, John M. "Hacer uso de una representación de diseño". Comunicaciones de
el ACM 37, No. 12 (Diciembre de 1994): 29–35.
- - -. Haciendo uso: Diseño basado en escenarios en la interacción persona-computadora.
Cambridge, Mass .: The MIT Press, 2000.
- - -. "Hacer uso
(2002): es más que una cuestión de análisis de tareas". Interacción con computadoras 14, No. 5
619–627.
259
260 R EFERENCIAS
Carroll, John M., Mary Beth Rosson, George Chin Jr. y Jürgen Koenemann.
"Desarrollo de requisitos en diseño basado en escenarios". Transacciones IEEE sobre ingeniería de
software 24, No. 12 (Diciembre de 1998): 1156–1170.
Cirillo, Francesco. “XP: Ofreciendo la ventaja competitiva en la post-Internet
Era." En www.communications.xplabs.com/paper2001-3.html. Laboratorios XP,
2001.
Cockburn, Alistair. Redacción de casos de uso eficaz. Upper Saddle River, Nueva Jersey: Add-
ison-Wesley, 2001.
Cockburn, Alistair y Laurie L. Williams. “Los costos y beneficios del par
Programación." En Giancarlo Succi y Michele Marchesi (Eds.), Programación extrema examinada. Upper
Saddle River, Nueva Jersey: Addison-Wesley, 2001. Cohn, Mike. "La ventaja de la reducción de personal". Prueba
de software e ingeniería de calidad
neering 5, No. 1 (Enero de 2003): 18–21.
Constantine, Larry. "Esquinas de corte." Desarrollo de software (febrero
2000).
- - -. "Agilidad de procesos y usabilidad del software: hacia un diseño ligero y centrado en el uso". Edad de
información ( Agosto-septiembre de 2002). Constantine, Larry L. y Lucy AD Lockwood. Software de
uso: una práctica
guía de los modelos y métodos de diseño centrado en el uso. Reading, Mass .: Addison-Wesley, 1999.
- - -. "Ingeniería centrada en el uso para aplicaciones web". Software IEEE

19, No. 2 (marzo / abril de 2002): 42–50. Cooper, Alan. Los internos están manejando el asilo. Indianápolis:
SAMS,
1999.
Cusumano, Michael A. y Richard W. Selby. Secretos de Microsoft: cómo
La compañía de software más poderosa del mundo crea tecnología, da forma a los mercados y
administra a las personas. Nueva York: The Free Press, 1995. Davies, Rachel. "El poder de las historias".
XP 2001. Cerdeña, 2001. Djajadiningrat, JP, WW Gaver y JW Frens. "Reetiquetado de interacción y
Personajes extremos: métodos para explorar interacciones estéticas ". Simposio sobre diseño de
sistemas interactivos 2000, 2000: 66–71. Fowler, Martin. "El Todopoderoso Thud". Computación
distribuída ( noviembre
1997).
Fowler, Martin y col. Refactorización: mejora del diseño del código existente, Leer-
ing, Mass .: Addison-Wesley, 1999. Gilb, Tom. Principios de la gestión de la ingeniería de software. Reading,
Mass .:
Addison-Wesley, 1988.
Guindon, Raymonde. "Diseñar el proceso de diseño: aprovechar las oportunidades
pensamientos ". Interacción persona-computadora 5, 1990.
R EFERENCIAS 261
Grudin, Jonathan y John Pruitt. “Personas, diseño participativo y producción

Desarrollo de uct: una infraestructura para el compromiso ". En Thomas Binder, Judith Gregory e Ina
Wagner (Eds.), Participación y Diseño: Indagando en las políticas, contextos y prácticas del trabajo de
diseño colaborativo, Actas de la Conferencia de Diseño Participativo 2002: 2002: 144-161. Sociedad de
Informática IEEE. Práctica recomendada por IEEE para requisitos de software
Especificaciones técnicas. Nueva York, 1998. Jacobson, Ivar. Ingeniería de Software Orientada a
Objetos. Río Upper Saddle,
Nueva Jersey: Addison-Wesley, 1992.
Jacobson, Ivar, Grady Booch y James Rumbaugh. El software unificado

Proceso de desarrollo. Reading, Mass: Addison-Wesley, 1999. Jeffries, Ron. "Essential XP: tarjeta,
conversación y confirmación". XP Mag-
la azina 30 de agosto de 2001).
Jeffries, Ron, Ann Anderson y Chet Hendrickson. Programación extrema

Instalado. Boston: Addison-Wesley, 2000.
Kensing, Finn y Andreas Munk-Madsen. "PD: Estructura en la caja de herramientas".
Comunicaciones de la ACM 36, no. 6 (Junio de 1993): 78–85.
Kovitz, Ben L. Requisitos prácticos de software: manual de contenido y estilo.
Greenwich, Connecticut: Manning, 1999.
Kuhn, Sarah y Michael J. Muller. “Introducción a la Sección Especial sobre
Diseño participativo ”. Comunicaciones del ACM 36, No. 6 (Junio de 1993): 24–28.
Lauesen, Soren. Requisitos de software: estilos y técnicas. Londres: Addi-

hijo-Wesley, 2002.
Lundh, Erik y Martin Sandberg. “Motor de requisitos de tiempo limitado
neering con Extreme Programming: un informe de experiencia ". En Armin Eberlein y Julio Cesar
Sampaio do Prado Leite (Eds.), Actas del Taller internacional sobre ingeniería de requisitos de tiempo
limitado,
2002.
Newkirk, James y Robert C. Martin. Programación extrema en la práctica.
Upper Saddle River, Nueva Jersey: Addison-Wesley, 2001.
Parnas, David L. y Paul C. Clements. “Un proceso de diseño racional: cómo y

por qué fingirlo ". Transacciones IEEE sobre ingeniería de software 12, No. 2 (Febrero de 1986): 251–7.
Patton, Jeff. "Alcanzando el objetivo: agregar diseño de interacción al software ágil

desarrollo." Conferencia sobre Lenguajes y Aplicaciones de Sistemas de Programación Orientados a
Objetos (OOPSLA 2002). Nueva York: ACM Press, 2002. Poppendieck, Tom. El kit de herramientas del
cliente ágil. En Larry L. Constantine
(Ed.), Actas de forUSE 2003. Rowley, Mass .: Ampersand Press: 2003.
262 R EFERENCIAS
Potts, Colin, Kenji Takahashi y Annie I. Antón. "Requisito basado en consultas

Análisis de mentos ". Software IEEE 11, No. 2 (marzo / abril de 1994): 21–32. Robertson, Suzanne y
James Robertson. Dominar el programa de requisitos
impuesto. Reading, Mass .: Addison-Wesley, 1999. Schuler, Douglas y Aki Namioka (Eds.). Diseño
participativo: principios y
prácticas. Hillsdale, Nueva Jersey: Erlbaum, 1993. Schwaber, Ken y Mike Beedle. Desarrollo de
software ágil con Scrum.
Upper Saddle River, Nueva Jersey: Prentice Hall, 2002. Stapleton, Jennifer. DSDM: Desarrollo centrado
en el negocio. Reading, Mass .:
Addison-Wesley, 2003.
Swartout, William y Robert Balzer. “Sobre el inevitable entrelazamiento de espec-
ificación e implementación ”. Comunicaciones del ACM 25, No. 7 (julio
1982): 438–440.
Wagner, Larry. "Ingeniería de requisitos extremos". Cutter IT Journal 14, No.
12 (diciembre de 2001).
Despierta, William C. Programación extrema explorada. Lectura, Misa: Addison-
Wesley, 2002.
- - -. "INVIERTA en buenas historias y tareas INTELIGENTES". Atwww.xp123.com, 2003a.
- - -. Libro de trabajo de refactorización. Reading, Mass .: Addison-Wesley, 2003b. Weidenhaupt,

Klaus, Klaus Pohl, Matthias Jarke y Peter Haumer. "Escenarios
en Desarrollo de Sistemas: práctica actual ". Software IEEE 15, No. 2 (marzo / abril de 1998): 34–45.
Wiegers, Karl E. Requisitos de Software. Redmond, Washington: Microsoft Press,

1999.
Williams, Marian G. y Vivienne Begg. "Traducción entre software
diseñadores y usuarios ". Comunicaciones del ACM 36, No. 6 (Junio de 1993): 102–3.
Sitios web
www.agilealliance.com
www.controlchaos.com
www.foruse.com
www.mountaingoatsoftware.com
www.userstories.com
www.xprogramming.com
www.xp123.com
Índice
UNA Procesos ágiles, 111 con prototipo de baja fidelidad

Prueba de aceptación, 12-13, 15, Diseño ágil centrado en el uso, ing, 49
67–74 182
responsabilidades del cliente, Anderson, Ann, 233 años C
73 Astels, Dave, 237 Captura, 43
especificación del cliente de Tarjeta, 4, Ver también Tarjetas de notas;
las pruebas, 69 segundo Tarjetas de historia
responsabilidades del desarrollador, Malos olores: anotaciones en, 6–7

73 responsabilidades del cliente, escrito en la parte de atrás de 7
Marco para Integrado 163 Carroll, John M., 135,
Prueba (FIT), 70–71 el cliente no escribe y 141-142
Soporte Náutico de la Costa Sur priorizar las historias, Teorema del límite central, 92
plies (ejemplo 162 Certificación, 180
proyecto), 223–230 responsabilidades del desarrollador, Cambio de prioridades, 110
administración, 227–228 163 Clements, Paul C., 151 ClickTactics,
comprar libros, 225–226 enchapado en oro, 158-159 eligiendo soft-
pruebas de restricción, incluida la interfaz de usuario loza en, 180
228–229 detalle demasiado pronto, Cuentos cerrados, 76–77
historia final, 229-230 159–160 Cockburn, Alistair, 137, 140,
pruebas de búsqueda, 223–224 historias interdependientes, 150, 237
pruebas de carrito de compras, 157-158 Cohn, Mike, 173
224–225 priorizar las dificultades, Equipo compartido, 105
cuentas de usuario, 226–227 161–162 Colores, 185
pruebas como parte del programa pequeñas historias, 157 Historias combinadas, 18, 26–27
ceso, 69–70 dividiendo demasiadas historias, Análisis competitivo, 65
tipos de pruebas, 72 pruebas de 160-161 Historias complejas, 24-26
redacción, 12-13 pensando demasiado en el futuro, 160 dividir, 25
antes de codificar, 68–69 demasiados detalles, 159 Historias compuestas, 24-25
escribiendo demasiadas pruebas, Beck, Kent, 97, 136, 233–234, desagregando, 25
70 236, 239 Confirmación, 4
Cuentas, South Coast Nauti- Beedle, Mike, 165, 171 Berczuk, Grupos de conexiones, 5
Suministros cal (ejemplo Steve, 136 Iteraciones consistentes, 103
proyecto), 214–215 Historia de ejemplo de BigMoneyJobs, Constantine, Larry, 31, 59,
Voz activa, escritura en, 81 historias de 4-6, 23 140, 148, 181–182
la administración, Sur Negro, JB, 148 Restricciones, ejemplos de,
Soporte Náutico de la Costa Boehm, Barry, 88, 101 Bower, 77–78
plies (ejemplo GH, 148 Lluvia de ideas: Preguntas libres de contexto, 46–47
proyecto), 205-206 Cooper, Alan, 135
Desarrollo ágil con conjunto inicial de roles de usuario, Productividad de escritorio corporativa
Scrum ( Schwaber / Abeja 33–34 software de ity, 59
dle), 165 Costo y prioridad 100
263
264 yo NDEX
Funciones posibles, lanzamiento Servicios de software Diaspar, integración continua,

plan, 98–99 181 240
Validez de la tarjeta de crédito, 71 Desglose, 25, 94, metáfora, 239
Cunningham, Ward, 70, 183 111–112 cliente in situ, 240
Responsabilidades del cliente: directrices, 112 programación en pareja,
malos olores, 163 Expertos en el dominio, 58–59, 65 237–238
recopilación de historias, 53 Conocimiento del dominio, falta de, Juego de planificación, 235-236
planificación de iteraciones, 116 23 refactorización, 236
planificación de lanzamiento, 107 Reglas DSDM y MoSCoW, diseño simple, 239
proxies de usuario, 65 98 pequeños lanzamientos, 235
remodelación de roles de usuario, 41 historias DSDM: centrado en el negocio ritmo sostenible, 238
de usuario, estimación, 95 velocidades, Desarrollo ( Grapa- propiedad del código de equipo,
medición / monitoreo tonelada), 98 238–239

toring, 127 pruebas, 236–237
escribir historias, 28 mi valores, 240–241
Equipo cliente, 8, 15 Lanzamientos tempranos, 63, 65
constituyendo, 63–64 Elicitación, 43 F
escritura de cuentos por, 9 Diseño empírico, 152 Factores críticos para el éxito del proyecto
Clientes, como proxy de usuario, 65 Épicas, 6, 94 ceso, determinante, 64

categorías de, 24 Primera iteración, 9
re Casos de uso esenciales, 140 FitNesse, 71, 181
Gráfico de quemado diario, historias estimadas, 22–23 Fowler, Martin, 150, 236 Marco para
123-126 Estimación: pruebas integradas
Scrum diario, 166, 171-172 Davies, enfoque, 88–90 (AJUSTE), 70–71
Rachel, 4, 140 en equipo, 88
Toma de decisiones, base de, 4 rastreadores triangular una estimación, GRAMO
de defectos, 179 90–91 Reunir relatos, 43–52

Aplazamiento de detalles, 14, 150 Proyecto de ejemplo, Ver Sur responsabilidades del cliente,
Dependencias entre historias, Soporte Náutico de la Costa 53
17-18 plies (ejemplo responsabilidades del desarrollador,
Detalles, 5-7 proyecto): 53

equipo de desarrollo – cus- Ejemplo de historia de usuario, 4-5 elicitación y captura,
discusiones de tomer Maximización de expectativas, 43–44
aproximadamente, 6–7 101 observación, 48–49
como pruebas, 20 Detalle extra, 19 cuestionarios, 47–48
demasiados detalles, tan mal Personajes extremos, 39 talleres de escritura de cuentos,
olor, 159 Programación extrema 49–52
historias de usuario con demasiado Explicado: Abrazo técnicas, 45
detalle, 19-20 Cambio ( Beck), 233 entrevistas con usuarios, 45–47
Responsabilidades del desarrollador: Programación extrema escribir historias a diferentes niveles

prueba de aceptación almacenamiento del usuario Explorado ( Wake), 17, los detalles, 44–45 Gilb,
ries, 73 233 Tom, 101
malos olores, 163 Programación extrema Historias de goles, comenzando con 75
recopilación de historias, 53 Instalado ( Jeffries, Chapado en oro, 158–159
planificación de iteraciones, 115 Anderson y Hen- ejemplo de 158
tarjetas de notas, 186, 187 drickson), 233 Buenas historias:
planificación de lanzamiento, 106 Programación extrema (XP), atributos de, 17
sistema de software, 186, 187 proxies de 8, 22, 88, 179, directrices para, 75–83
usuario, 65 233–243 voz activa, escribiendo en,
remodelación de roles de usuario, 40 entrenador, 234 81
historias de usuario, 155 rol de cliente, 233 historias cerradas, 76–77
historias de usuario, estimación, 94 principios de 241–242 cliente como redactor del
velocidad, medición / monitoreo papel de programador, 234 cuentos, 81–82
toring, 127 roles, 233–234 incluyendo roles de usuario en el
escribir historias, 28 equipos, 26 cuentos, 80–81
Gerentes de desarrollo, 57, doce prácticas de XP, poner restricciones en
64 234–240 tarjetas, 77–78
estándares de codificación, 239 dimensionando la historia, 78–79
yo NDEX 265
tarjetas de cuentos, numeración, Duración de la iteración, selección, 103 norte
82 Planificación de la iteración, 10-12, Namioka, Aki, 152

interfaz de usuario, 79–80 109-116 Historias negociables, 18-19
utilizando otros formatos, 80 aceptar la responsabilidad, Newkirk, James, 77
escritura para un usuario, 81 pautas 113 Requerimientos no funcionales:
para la escritura: responsabilidades del cliente, precisión, 178
historias de objetivos, comenzando 116 capacidad, 179
con, 76 responsabilidades del desarrollador, como restricciones en el sistema
dividiendo historias 115 comportamiento, 177-179
Grenning, James, 137 desagregar en tareas, manipulación, 177-179
Guindon, Raymonde, 151 111–112 interoperabilidad, 179
discutir las historias, 110 estimación mantenibilidad, 179
H y confirmación rendimiento, 178
Hendrickson, Chet, 233 ción, 113-114 portabilidad, 179
Historias altamente dependientes, secuencia general de actividades reutilización, 178
17-18 vínculos para la reunión de tipos de, 177-178
Historias de alta prioridad, 183 planificación iterativa, 109 Tarjetas de notas, 4
Valores históricos e iniciales Iteraciones, 9-10 colores de, 185

velocidad, 104 longitud, 9, 103 limitaciones de, 179–180
planificación, 10-12, 109-116 Nota, tarjeta de historia con 7
yo Desarrollo iterativo y
IEEE 830: historias de usuario, 149–150 O
en comparación con las historias de usuarios, Proceso iterativo, 14 Observación, 48–49
133-136 definido, 165 Usuarios en el sitio, 39–40
requisitos, 135-136 Scrum como, 165-166 Preguntas abiertas, 46 a 47
Proceso incremental:
definido, 166 J PAG
Scrum como, 166 Jacobson, Ivar, 137 Programación en pareja, 92–93,

Historias independientes, 17-18 Jeffries, Ron, 4, 233 Diseño de 237–238
Propiedad individual, aplicaciones conjuntas Parnas, David L., 151 Diseño
238–239 (JAD) sesiones, 49 participativo, 152
Necesidades de infraestructura y Pruebas de rendimiento, 72
oritización de necesidades, K Asistente personal digital
101-103 Kerievsky, Joshua, 87 (PDA) computadora de mano
Colección inicial de historias, Kuhn, Sarah, 152 ordenador, 39
209 Personas, 38–39

Conjunto inicial de roles de usuario: L Soporte Náutico de la Costa Sur
lluvia de ideas, 33–34 Grandes historias, temporalmente plies (ejemplo
organización, 34–35 saltar, 11-12 proyecto), 197-198
Historias iniciales, 9 Lockwood, Lucy, 31, 59, 140, Velocidad planificada, 119–120
Velocidad inicial, 104-105 148, 182 Lanzamientos de planificación, 97–107
Los reclusos están ejecutando el Asy- Prototipo de baja fidelidad, 49–50 e iteraciones, 10-12
lum, el ( Cobre), tirar, 51 Poppendieck, Tom, 147, 159 Posicionamiento de
135 tarjetas de función de usuario,
Instituto de Electricidad y Electricidad METRO 193

ingenieros de tronics Loco por ti, 89 Grupo de Producto potencialmente enviable
(IEEE), 133 marketing, 64 incremento, 170
Historias interdependientes, malas Martín, Bob, 71, 77 Martín, Precisión y tamaño de la historia, 93
olores, 157-158 Micah, 71 Procesos prescriptivos, 44
ISO (Organización Internacional Prioridades mixtas, 100–101 Prioridades, cambiantes, 110
ción para la estandarización Reglas de MoSCoW, 98 Dar prioridad a las historias, 98–101
ción), 180 Muller, Michael J., 152 Proxies de el cliente tiene problemas a priori
Gráficos de burndown de iteración, múltiples usuarios, usando, tizing, 161–162
121-123 sesenta y cinco historias de alto nivel, 183
tamaño del gráfico, 126 Funciones imprescindibles, lanzamiento necesidades de infraestructura,
gráfico de quemado diario, plan, 98 101-103

123-125 velocidad inicial, 104-105
utilidad de, 122
266 yo NDEX
longitud de iteración, selección, Tarjetas de rol, 33 historias de administración,

103 Pasos del modelo a seguir, 33–37 205–206
prioridades mixtas, 100–101 búsqueda avanzada, 212–213
historias de riesgo, 101 S lista completa de historias y
desde los puntos de la historia hasta Vendedores, 64 estimaciones, 216–217
duración esperada, Escenarios, 137 consolidar y estrechar
103 en comparación con las historias de usuarios, ing, 193-195
Proceso, 8-10 141-142 definido, 191
Pila de producto, 166, Schuler, Douglas, 152 estimando las historias,
167–168 Schwaber, Ken, 165–166 209–217
lista de muestra, 168 Scrum, 9 finalizar las estimaciones, 215
e historias de usuarios, 173 agregar historias a, 173-174 conceptos identificar roles iniciales, 192 identificar
Camino de desarrollo de productos básicos de, 166 al cliente,
mapa, 97 como iterativo e incremental 191-192
Dueño del producto, 167 proceso mental, personas, agregando, 197–198
Campeón del proyecto, identificando, 165-166 priorizando las historias,
64 estudio de caso, 174-175 220-221
Fallos del proyecto, 3 reglas principales de, 169 equipo calificación y revisión,
Comprador, distinción entre Scrum, 166-167 213–214
usuario y, 20-21 reunión de planificación de sprint, plan de lanzamiento, 219–222
168–169 terminado, 221–222
Q reunión de revisión de sprint, 169, historias para un no navegante
Cuestionarios, 47–48 170-171 Comprador de regalos, 204
usando historias con, 165–176 historias para un marinero novato,

R ScrumMaster, 167–168, 203
Rainsberger, JB, 181 170-172 historias para un visor de informes,
Libro de trabajo de refactorización Seleccione Administrador de alcance, 179 204-205
(Despierta), 17 iteraciones cortas, 103 historias para el capitán Ron,
Plan de lanzamiento, 9-12, 15 Funciones que debería tener, lanzamiento 202-203
características posibles, 98–99 plan, 98–99 historias para Teresa, 199–202 modelo de
creando, 105–106 Pequeñas historias, malos olores, 157 roles de usuario,
responsabilidades del cliente, Manual de configuración de software 195-197
107 patrones de envejecimiento ( Ber- roles de usuario, 191-198
responsabilidades del desarrollador, czuk), 136 velocidad, estimación, 219
106 Desarrollo de software Spike, 22
iniciando, 97 proyectos, predicción, 3 poner en un itera-
Reglas de MoSCoW, 98 Software de uso ( Constantino ción, 26
características imprescindibles, 98 y Lockwood), 311 Modelo en espiral (Boehm), 101
priorizar historias, 10, Requisitos de software, como historias divididas, 18, 23,
98–101 problema de comunicación 24-26, 75-76
poniendo demasiada fe en lem, 3 dividiendo demasiadas historias,
106 Sistema de software, desarrollador como mal olor, 160-161
fecha de lanzamiento, 98 responsabilidades, 186, Cartera de Sprint, 166-167, 170 Objetivo de
características imprescindibles, 98–99 187 Sprint, 168
Soporte Náutico de la Costa Sur Ordenar historias, 99 Reunión de planificación de Sprint,
plies (ejemplo Soporte Náutico de la Costa Sur 168-170

proyecto), 219-222 plies (ejemplo historias de usuarios en, 173–174 Reunión
plan terminado, 221-222 proyecto): de revisión de Sprint, 169,
no tendrá funciones, 98 a 99 versiones, pruebas de aceptación, 223–230 170-171, 174
planificación, 9 a 10 administración, 227–228 historias de usuario en, 174
Recordatorios, tarjetas de historias como, comprar libros, 225–226 Sprints, 166
18-20 pruebas de restricción, Stapleton, Jennifer, 98
"Ingeniería de requisitos" 228–229 Tarjetas de historia:
esfuerzos, 160 pruebas de búsqueda, 223–224 definido, 18

Retener historias de usuarios, pruebas de carrito de compras, limitaciones de, 179–180
184-185 224–225 propósito principal de, 82
Historias de riesgo, 101 cuentas de usuario, 226–227 numeración, 82
Atributo de rol, 36–37 cuentas, 214–215 como recordatorios, 18-20, 82
yo NDEX 267
escribiendo notas en la parte de atrás Historias inestables, 27 identificar roles que representen
de, 67 Pruebas de usabilidad, 72 envió un solo usuario, 34 incluso
escritura en la parte posterior de, 7 prueba de Resumen de casos de uso, 140 en historias de usuarios,
escritura en la parte posterior de, Usuario, distinción entre fines 80–81
13 chaser y, 20-21 conjunto inicial de:
Costo de la historia, 10-11 Directrices de interfaz de usuario, 80 pruebas lluvia de ideas, 33–34
Puntos de la historia, 87–88, 91–92, de interfaz de usuario, 72 interfaz de usuario organización, 34–35
94 (UI): refinamiento, 36–37
Tamaño de la historia, 23 a 27 detalles, incluido demasiado pronto, atributo de rol, 36–37
y precisión, 93 159–160 Soporte Náutico de la Costa Sur
Los olores de la historia, consulte Malos olores: escribiendo dos, 183 plies (ejemplo
proceso de escritura de la historia, 8–10 Entrevistas con usuarios, 45–47 proyecto), 191-198
historias iniciales, 9 abierto y contextual Historias del usuario:
Proyectos basados en historias, procesos, preguntas gratuitas, 46–47 ventajas sobre la alternativa
8-10 Proxies de usuario, 55–66 enfoques, 13-14
Talleres de escritura de cuentos, responsabilidades del cliente, aspectos de, 4
49–52 sesenta y cinco aumentando en requerimiento
colaboradores de, 52 clientes, 59–60 documentación de mentos
foco de, 51–52 responsabilidades del desarrollador, estilo, 6
Prueba de estrés, 72 sesenta y cinco comprensibilidad de, 148
Encuestas, 46 gerente de desarrollo, 57 responsabilidades del cliente,
Roles del sistema, 35 expertos en dominios, 58–59 155
antiguos usuarios, 59 y la reunión diaria de Scrum
T grupo de marketing, 59 ing, 174
Personal de soporte técnico, vendedores, 57–58 y diferir detalles, 150 definidos, 4-5
61 formadores y soporte técnico
Descripciones de pruebas, 7-8 personal portuario, 61 descripciones, 4
Historias comprobables, 27 administrador de usuarios, 55–56 responsabilidades del desarrollador,
Desarrollo impulsado por pruebas, 237 que hacer al trabajar 155

Pruebas: con, 61–63 estimación, 87–95
aceptación, 12-13, 15, Tarjetas de función de usuario, 33–36, 192 enfoque, 88–90
67–74 posicionamiento, 193 responsabilidad del cliente
para insectos, 72 muestra, 37 corbatas, 95
Marco para Integrado Modelado de roles de usuario, 9, 31–41 responsabilidad del desarrollador
Prueba (FIT), 70–71 consolidar roles, 35–36 corbatas, 94
rendimiento, 72 responsabilidades del cliente, programación en pareja,

estrés, 72 41 92–93
como un proceso de dos pasos, 67 responsabilidades del desarrollador, puntos de la historia, 87–88,
usabilidad, 72 40 91–92
interfaz de usuario, 72 personajes extremos, 39 en equipo, 88
Pruebas, escritura antes de codificar, conjunto inicial de roles de usuario: triangular una estimación,
68–69 lluvia de ideas, 33–34 90–91
Temas, 97 organización, 34–35 IEEE 830 en comparación con,
Timebox, 22 usuarios en el sitio, 39–40 133-136
Proyectos con limitaciones de tiempo, personas, 38–39 y desarrollo iterativo,
y detalle diferido, refinando roles, 36–37 149-150
150 atributos de rol, 36 y diseño participativo,
Zapatillas, 61 Soporte Náutico de la Costa Sur 152
Formadores y soporte técnico plies (ejemplo priorización, 98–101
personal portuario, como apoderados de proyecto), 195-197 y la cartera de productos,
usuarios, 65 interviene, 33–37 173
Pesca de arrastre por necesidades, roles de usuario, 31–33 relación entre error
43–44 Roles del usuario: informes y, 185
Turner, TJ, 148 atributos, 36–37 que representa la funcionalidad
Doce prácticas de XP, 234-240 lluvia de ideas un conjunto inicial valorado por los usuarios, 5
de, 33–34 reteniendo, 184-185
U consolidación, 35–36 escenarios en comparación con,
Proceso unificado, 8, 137 identificando, 33 141-142
268 yo NDEX
tamaño para la planificación, 148–149 tamaño historias combinadas, 18

de, 6 combinando historias, 26-27
división, 6, 12 responsabilidades del cliente,
en la reunión de planificación del sprint 28
ing, 173-174 responsabilidades del desarrollador,
en la reunión de revisión de sprint 28

ing, 174 historias estimables, 22-23
apoyo para oportunistas historias altamente dependientes,
desarrollo, 151-152 17-18
conocimiento tácito, acumular historias independientes, 17-18
de, 153 historias negociables, 18-19
y jerga técnica, 14 descripciones historias pequeñas, 23-27
de pruebas, 7-8 dividiendo historias, 18
con demasiado detalle, 19 casos de uso tamaño de la historia, 23-27
en comparación con, historias comprobables, 27
137-141
y la interfaz de usuario (UI), X
26, 79–80, 139–140, XP, ver programación extrema
159–160, 181–183 (XP)
y comunicación verbal, XPlanner, 179
145-148
Grupos de trabajo de usuarios, 62, 65
Administrador de usuarios, 64
Historias de usuarios, colección inicial

de, 209–210
V
Valor para compradores / usuarios,
20-22
Velocidad, 9-10, 15, 91-92, 113
actual, 119–120
cálculos, 119
adivinando, 104-105
inicial, 104-105
gráficos de evolución de iteraciones,
121-123
medir, 117-119
medición / seguimiento:
responsabilidad del cliente
corbatas, 127
responsabilidad del desarrollador
corbatas, 127
planeado, 119–120
Comunicación verbal,
145-148
VersiónOne, 179
W
Wake, Bill, 17, 76, 233 Proceso
orientado a la cascada, 8
"Libro blanco" (Beck), enfoque Delphi
de banda ancha 234,
88
Wikis, 179
Williams, Laurie, 237
No tendrá funciones, lanzamiento
plan, 98–99
Escribir cuentos, 17–29

User Stories Applied Mike Cohn 201 291.en - Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

User Stories Applied Mike Cohn 201 291.en - Es

Cargado por

Copyright:

Formatos disponibles

178 UNA DDICIONAL T ÓPTICA

Muchos requisitos no funcionales se pueden considerar como restricciones en el comportamiento del

Zona Restricción de muestra

Portabilidad El sistema no utilizará ninguna tecnología que dificulte la migración a Linux.

Zona Restricción de muestra

automatizadas deben ejecutarse en su totalidad al menos una vez cada 24 horas.

Interoperabilidad El sistema estará escrito en Java.

Capacidad La base de datos será capaz de almacenar 20 millones de miembros en el hardware

Elegir software en ClickTactics

Mantener historias en el software VersionOne permitió a ClickTactics promover su uso de XP como

Uso de un wiki en Diaspar Software Services

Historias de usuario e interfaz de usuario

Para las interfaces de usuario, la arquitectura (la organización general, la navegación y la

historias en el diseño centrado en el uso ágil:

1. Realice un modelo de roles de usuario.

2. Búsqueda de historias de usuarios de alto nivel.

3. Priorice las historias.

4. Refina las historias de prioridad alta y media.

5. Organice las historias en grupos.

6. Cree un prototipo de papel.

más alto nivel, probablemente no más de dos docenas.

Reteniendo las historias

haber mantenido los requisitos. Éstos son algunos de los casos:

• En varias ocasiones he estado involucrado en la reescritura completa de productos comerciales. En

• Los requisitos no funcionales (como el rendimiento, la precisión, la portabilidad, la reutilización, el

Responsabilidades del desarrollador

• Comparte la responsabilidad de comprender las ventajas y desventajas de considerar la interfaz de

Responsabilidades del cliente

• Comparte la responsabilidad de comprender las ventajas y desventajas de considerar la interfaz de

16,2 ¿Prefieres escribir historias en tarjetas de notas o en un sistema de software? Defiende tu

Los roles de usuario

número gratuito para solicitar un catálogo.

el sitio, ampliaremos y venderemos el resto de nuestros productos en el sitio.

Identificación del cliente

Identificación de algunos roles iniciales

• Cónyuge que no navega

Marinero novato Escuela de vela

Figura 17.1 Posicionamiento de las tarjetas de rol de usuario.

Marinero novato Instructor

Regalo sin navegar Administrador Visor de informes

Figura 17.2 Los roles después de la consolidación y discusión inicial.

• La frecuencia con la que el usuario utilizará el software.

• El nivel de experiencia del usuario con el dominio.

• El nivel general de competencia del usuario con computadoras y software.

• El nivel de competencia del usuario con el software que se está desarrollando.

Marinero de núcleo duro: Generalmente sin experiencia con computadoras. Un gran

Visor de informes: Competencia moderada con computadoras, principalmente con

Una advertencia sobre Teresa y el capitán Ron

Historias para Teresa

Un usuario puede buscar libros por autor, título o número ISBN.

■ Ficha de historia 18.1

■ Ficha de historia 18.2

cuando estén listos para codificar esta historia.

la Tarjeta de historia 18.3 y la Tarjeta de historia 18.4.

Un usuario puede poner libros en un "carrito de compras" y comprarlos cuando termine de

■ Ficha de historia 18.3

Un usuario puede eliminar libros de su carrito antes de completar un pedido.

■ Ficha de historia 18.4

Para comprar un libro, el usuario ingresa su dirección de facturación, la dirección de envío y la

■ Ficha de historia 18.5

Un usuario puede calificar y revisar libros.

■ Ficha de historia 18.6

Un usuario puede establecer una cuenta que recuerde la información de envío y