Historias de Usuario
Las historias de usuario se usan para capturar la esencia del
valor de negocio de un sistema, y estn escritas en un lenguaje
cotidiano. Por ejemplo:Como enfermera necesito cambiar mi ubicacin
predeterminada, para visualizar mis datos preferidos cuando ingreso
en la aplicacin de Enfermera.Y de ah podemos desprender el formato
bsico de una historia de usuario:Como [rol] quiero [caracterstica]
para [valor de negocio]La enfermera es el usuario que utilizar la
aplicacin de Enfermera. Ella necesita poder configurar su ubicacin
predeterminada para no tener que perder tiempo en seleccionar una
ubicacin cada vez que ingresa a la aplicacin. El valor de negocio
aqu es que no perder tiempo en hacer esto y en cambio podr trabajar
ms rpido sin odiar al software por no ser amigable :)Dependiendo qu
tanto lleven escribiendo historias de usuario, pueden que todava no
hayan descubierto un factor clave:los usuarios se meten en el
medio. No saben lo que quieren, e igualmente te lo van a pedir. Y
lo vas a odiar.No los ignores. Sin importar cmo se presenten,
debemos abordarlos con la mente abierta para encontrar la necesidad
real. Si piden un botn o algn campo para ingresar un nmero, debemos
determinarporqulo necesitan. Si slo lo quieren porque "queda
bonito" o por algn valor insignificante que a) deber retocarse el
resto del sistema, o b) lleva mucho tiempo hacerlo, probablemente
debamos ver si realmente lo necesita (a largo plazo van a quejarse
por cunto tiempo llevamos desarrollando el cambio, y ah vamos a
responderle con un "vos queras ese botn", y nadie va a estar muy
contento).Debemos averiguar lo que el usuario quiere, que propsito
sirve, y si le va a servir para el resto de las personas que usan
el software. No escribimos cdigoparalos casos frontera, escribimos
software quefuncioneen los casos frontera.El sistema es
desarrollado para el cliente, por lo tanto, el usuario es quien
decide que tareas realizar la aplicacin. Este planteamiento se
desarrolla a lo largo del proyecto: el cliente es quien decide que
hacer. Como primer paso, se debe proporcionar una idea clara de lo
que ser el proyecto en s.Las historias de usuario son utilizadas
como herramienta para dar a conocer los requerimientos del sistema
al equipo de desarrollo. Son pequeos textos en los que el cliente
describe una actividad que realizar el sistema; la redaccin de los
mismos se realiza bajo la terminologa del cliente, no del
desarrollador, de forma que sea clara y sencilla, sin profundizar
en detalles.Se puede considerar que las historias de usuario en XP
juegan un papel similar a los casos de uso en otras metodologas,
pero en realidad son muy diferentes. Las historias de usuario slo
muestran la silueta de una tarea a realizarse. Por esta razn es
fundamental que el usuario o un representante del mismo se
encuentren disponibles en todo momento para solucionar dudas, estas
no proporcionan informacin detallada acerca de una actividad
especfica.Las historias de usuario tambin son utilizadas para
estimar el tiempo que el equipo de desarrollo tomar para realizar
las entregas. En una entrega se puede desarrollar una o varias
historias de usuario, esto depende del tiempo que demore la
implementacin de cada una de las mismas.Las historias de usuarios
deben poder ser programadas en un tiempo entre una y tres semanas.
Si la estimacin es superior a tres semanas, debe ser dividida en
dos o ms historias. Si es menos de una semana, se debe combinar con
otra historia.
Estructura de una Historia de UsuarioFuente: sixservix.com
El modelo INVESTElmodelo INVESTes la clave para pensar y
escribir buenas historias de usuario. Las historias deben ser
Independientes, Negociables, Valiosas, Estimables, Pequeas y
Testeables. Independiente- una historia debera ser independiente de
otras (lo ms posible). Las dependencias entre las historias hace
que sea ms dificil planificar, priorizar y estimar. A menudo, se
puede reducir las dependencias haciendo una combinacin de
historias, o partiendo historias de forma diferente. Negociable-
una historia de usuario es negociable. La "tarjeta" de la historia
es tan slo una descripcin corta que no incluye detalles. Los
detalles se trabajan durante la etapa de "Conversacin". Una tarjeta
con demasiados detalles limita la conversacin con el cliente.
Valiosa- cada historia tiene que tener valor para el cliente (para
el usuario o para el comprador). Una forma muy buena de generar
historias valiosas es hacer que el cliente las escriba. Una vez que
el cliente se de cuenta que la historia no es un contrato y es
negociable, van a sentirse mucho ms cmodos para escribir historias.
Estimable- los desarrolladores necesitan poder estimar una historia
de usuario para permitir que se pueda priorizar y planificar la
historia. Los problemas que pueden impedirle a los desarrolladores
estimar una historia son: falta de conocimiento del dominio (en
cuyo caso se necesita ms Negociacin / Conversacin); o si la
historia es muy grande (en cuyo caso se necesita descomponer la
historia en historias ms pequeas). Pequea- una buena historia debe
ser pequea en esfuerzo, generalmente representando no ms de 2-3
personas/semana de trabajo. Una historia que es ms grande va a
tener ms errores asociados a la estimacin y alcance. Testeable- una
historia necesita poder probarse para que ocurra la etapa de
"Confirmacin". Recordemos que desarrollamos aquello que no podemos
probar. Si no podemos probarlo, nunca vamos a saber si lo
terminamos. Un ejemplo de historia no testeable sera: "el software
tiene que ser facil de usar".
ID:Identificador de la historia de usuario TTULO:Ttulo
descriptivo de la historia de usuario DESCRIPCIN:Descripcin
sintetizada de la historia de usuario ESTIMACIN:Estimacin del coste
de implementacin en unidades de desarrollo (estas unidades
representarn el tiempo terico de desarrollo/hombre que se estipule
al comienzo del proyecto) PRIORIDAD:Prioridad en la implementacin
de la historia de usuario respecto al resto de las historias de
usuario. A mayor nmero, mayor prioridad. Otra aproximacin a la
priorizacin de tareas se hace a travs delmtodo MoSCoW: M Must, se
debe completar este requerimiento para finalizar el proyecto S
Should, se debe completar este proyecto por todos los medios, pero
el xito del proyecto no depende de l. C Could, se debera completar
este requerimiento si su implementacin no afecta a la consecucin de
los objetivos principales del proyecto. W Would, se puede completar
este requerimiento si sobra tiempo de desarrollo (o en futuras
versiones del mismo) DEPENDENCIAS: Una historia de usuario no
debera ser dependiente de otra historia, pero a veces es
inevitable. En este apartado se indicaran los IDs de las tareas de
las que depende una tareaEl ciclo de vida de latarjetase compone de
tres fases, conocidas como Las 3 C por sus iniciales en ingls
(Card, Conversation, Confirmation):
TARJETA(Card), la creacin de la tarjeta en s, con la estructura
definida anteriormente y que sirve para determinar QU se debe hacer
y cmo planificarlo. CONVERSACION(Conversation), representado por
pequeos documentos y anotaciones que sirven para aportar detalles y
refinar los datos sobre las caractersticas del requerimiento.
CONFIRMACIN(Confirmation), opruebas de aceptacin. Pruebas
consensuadas entre el cliente y el desarrollador y que el cdigo
debe superar para dar como finalizada la implementacin del
requerimiento.
Historias de Usuario vs. Casos de Uso
Historia de Usuario
Numero:Nombre:
Usuario:
Modificacin de Historia N:Iteracin asignada
Prioridad en Negocio:(Alta,media,baja)Puntos Estimados:
Desarrollador encargado:
Descripcin:
Observaciones:
Historia de Usuario
Numero:Nombre:
Usuario:
Modificacin de Historia N:Iteracin asignada
Prioridad en Negocio:(Alta,media,baja)Puntos Estimados:
Desarrollador encargado:
Descripcin:
Observaciones:
