Definir historias de usuario/pruebas de aceptación e integración de prototipado en el proceso...

[Pablo Alonso García]

Hola,

En mi relativamente corta carrera profesional como informático, todavía no he trabajado nunca en un proyecto que integre metodologías ágiles (desgraciadamente...). Gracias a mi curiosidad, y a través de Ruby On Rails y al libro The Art of Agile Development estoy descubriendo esto que no nos enseñan en la Universidad y que parece ser un buen comienzo para que los proyectos de software tengan éxito. Hasta ahora, los proyectos en los que he trabajado carecían de una metodología: sin testing, malas estimaciones, documentación nula o al final del proyecto como un mero trámite, etc... Nada nuevo.

Ahora tengo la oportunidad de introducir algunas técnicas en un nuevo proyecto en el que trabajo. Cansado de los infumables documentos de requisitos estamos definiendo historias de usuario usando Index Cards, siguiendo el formato: As a "role" I can "task" so that "goal". Un ejemplo:

Como visitante puedo registrarme en la aplicación para acceder a la parte privada.

Y los tests de aceptación podrían ser:

- El nombre de usuario es único en el sistema.

- La dirección de correo es único en el sistema.

- etc.

¿Os parece esta forma correcta de describir Historias de usuario/test de aceptación?

En algunos correos anteriores he leido el término "tarea" como descomposición de las Historias de usuario. Una primera duda que me surge es hasta donde descomponer las historias en sub-historias. ¿Alguien podría explicarme la diferencia entre tarea e historia? y ¿Qué relación tienen con los Epics?

También tengo la duda de si determinadas tareas técnicas se pueden crear como Historias de usuario, Por ejemplo: Montar un sistema de control de versiones Subversion, ¿podría ser una tarea? Al fin y al cabo es algo que hay que hacer, estimar y priorizar, pero no tiene valor para el cliente/usuario final... ¿Qué opinais?

Otra duda es ¿como se integran las fases de prototipado/diseño/maquetación con las historias de usuario? En mi caso, hemos escrito muchas historias de usuario y ahora estamos prototipando, y nos surgen nuevas historias al ver los prototipos. El problema es que este proceso se puede alargar hasta el infinito. ¿Cómo hacéis vosotros? 

Tengo pedido el libro sobre User Stories de Mike Cohn, que parece ser la eminencia en estos temas...

Un saludo y muchas gracias a todos!

--
Pablo Alonso García
http://alonsogarciapablo.com

[Alfredo Casado]

Hola pablo, 

Definición de historias

Me parece bien el formato que tenéis aunque para definir los test de aceptación podrías probar el given.when.then, por ejemplo en lugar de: 

El nombre de usuario es único en el sistema.

Dado un sistema donde existe un usuario con nombre FULANO

Cuando alguien intenta registrarse con nombre FULANO

Entonces el sistema muestra un mensaje indicando que el nombre FULANO ya existe.

Lo bueno de este formato es que aclaras el estado previo (given) lo que estas probando (when) y el rsultado esperado (then) y la futura automatización de estas pruebas es más obvia. Aunque esto que digo nosotros no lo hemos puesto todavía en practica como dios manda, tenemos un déficit importante en como definimos nuestras historias de usuario actualmente.

¿Alguien podría explicarme la diferencia entre tarea e historia? y ¿Qué relación tienen con los Epics?

Como yo lo entiendo, una historia es la unidad minima de funcionalidad que tiene valor para el usuario. Las historias se dividen en tareas para ayudar al equipo a estimarlas, por ejemplo puedes dividir la historia anterior en varias tareas "desarrollo del UI"/"Modificación del esquema de la base de datos"/"clase de registro de usuario". De esta manera también pueden trabajar varios miembros del equipo sobre la misma historia cogiendo cada uno una tarea.

determinadas tareas técnicas se pueden crear como Historias de usuario

Nosotros en ocasiones hemos realizado un sprint 0 donde se montan estas cosas. Aunque de todos modos, sobre todo si el proyecto es largo, surgen nuevas tareas técnicas, que no son funcionalidad que aporte valor al cliente de forma directa, pero si de forma indirecta porque aceleran o mejoran de algún modo el ciclo de desarrollo. En nuestro caso las metemos como historias y tenemos que convencer al PO de que esas historias técnicas merecen la pena para ganar en otros aspectos, no siempre es fácil convencerlo pero a veces lo conseguimos :P. Te pongo un ejemplo, nos toco dedicar casi una semana de todo el equipo a migrar el proyecto de ANT a Maven (un proyecto gordo, más de 70.000 lineas de código más otras tantas mas de test), al final ese tiempo lo hemos recuperado sobradamente gracias a todos los beneficios que nos a aportado el cambio, pero claro de esto hay que convencer al PO, en nuestro caso es más factible porque aunque no sea desarrollador si tiene background técnico y entendía las mejoras, en otros casos no tengo tan claro como habrá que tratarlo.

¿como se integran las fases de prototipado/diseño/maquetación con las historias de usuario? 

No hay prototipado, hay "working software". ¿Porque hacéis prototipos?, empezar con la primera historia de la pila. Si se trata de enseñar algo al usuario para que se haga una idea de "las pantallas" hacerlo con una herramienta de sketch's tipo balsamiq como parte incluso de la definición de las historias junto con el usuario. Y las tareas de diseño/maquetación, si agregan valor al cliente y son parte del producto, pues dentro de la pila como cualquier otra tarea de desarrollo, y con la gente que se dedique a esto integrada en el equipo claro.

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

[Juan Carlos Quijano Abad]

Gracias Pablo,

Me guardo este post en el cajón de las cosas buenas :)

--
Un saludo
Juan Quijano

--
Un saludo
Juan Quijano

[Pablo Alonso García]

Hola,

Muchas gracias por tu respuesta Alfredo.

El tema de los tests de aceptación, también he mirado la forma de definirlos como tú dices:

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

Tall y como describe Dan North en su artículo acerca de BDD. Me parece bien porque luego se pueden automatizar estos tests con herramientas tipo Cucumber (todavía no lo he probado). Lo que no me cuadra de definir los tests de aceptación de esta forma es que entonces dudo que quepan en una tarjeta 3x5... ¿?

Lo de las tareas técnicas supongo que se puede hacer así, definiendo alguna historia especial que incluya varias tareas y convencer a quien corresponda sobre su importancia/beneficios. Te entiendo perfectamente, yo tuve convencer a un equipo/director para incluir Ant en los proyectos Java de una antigua empresa y me costó, pero se ganó mucho tiempo después.

Por último, el tema del prototipado. Creo que me he expresado mal. No estamos prototipando, sino creando unos sketches o wireframes con powerpoint, para hacernos una idea del esqueleto de la aplicación, el número de pantallas, su estructura, etc. Igual esto debería ser una tarea las historias de usuario y deberíamos ir haciéndolo incrementalmente... La verdad es que hacerlo todo así, up-front, cuesta bastante...

Bueno, a ver si alguien más se anima y nos aporta sus experiencias sobre:

• forma de definir historias de usuario
• planificación de tareas técnicas
• integración del proceso de wireframing/diseño/maquetación
  

Muchas gracias de nuevo,

El 3 de marzo de 2010 00:42, Alfredo Casado <casado....@gmail.com> escribió:

[Ángel Medinilla]

Buen hilo, pardiez... :)

----------------------------------------------------
Ángel Medinilla
angel.m...@presionblogosferica.net
www.presionblogosferica.com

2010/3/3 Pablo Alonso García <alonsoga...@gmail.com>

[José Manuel Beas]

2010/3/3 Pablo Alonso García <alonsoga...@gmail.com>

Hola,

Muchas gracias por tu respuesta Alfredo.

El tema de los tests de aceptación, también he mirado la forma de definirlos como tú dices:

Given some initial context (the givens),
When an event occurs,
then ensure some outcomes.

Tall y como describe Dan North en su artículo acerca de BDD. Me parece bien porque luego se pueden automatizar estos tests con herramientas tipo Cucumber (todavía no lo he probado). Lo que no me cuadra de definir los tests de aceptación de esta forma es que entonces dudo que quepan en una tarjeta 3x5... ¿?

Justo. El formato que propone Alfredo iría mejor cuando automatizas los criterios de aceptación de la historia (plural, porque una historia tendrá en general más de un criterio de aceptación). La tarjeta es un recordatorio físico de conversaciones y confirmaciones: http://xprogramming.com/xpmag/expCardConversationConfirmation
 

Lo de las tareas técnicas supongo que se puede hacer así, definiendo alguna historia especial que incluya varias tareas y convencer a quien corresponda sobre su importancia/beneficios. Te entiendo perfectamente, yo tuve convencer a un equipo/director para incluir Ant en los proyectos Java de una antigua empresa y me costó, pero se ganó mucho tiempo después.

Estoy con Alfredo en que se trata de algo a, en general, negociar. Lo importante es que de esta manera nos protegemos a nosotros mismos de trabajar en temas que sólo nos interesan a nosotros como técnicos pero que no aportan valor al producto. (Lo he visto demasiadas veces)

No me gusta el rollo sprint-0 pero cada maestrillo tiene su librillo. :-)
 

Por último, el tema del prototipado. Creo que me he expresado mal. No estamos prototipando, sino creando unos sketches o wireframes con powerpoint, para hacernos una idea del esqueleto de la aplicación, el número de pantallas, su estructura, etc. Igual esto debería ser una tarea las historias de usuario y deberíamos ir haciéndolo incrementalmente... La verdad es que hacerlo todo así, up-front, cuesta bastante...

En mi opinión, depende de cuánto tiempo tarda tu dueño de producto en validarte esos wireframes (y si requieres validación, claro). Si es algo que, en general, te retrasa y no te deja avanzar, sería mejor dejarlo como historias de usuario del tipo:

Como equipo quiero el wireframe de la pantalla de ... para poderla tener en la iteración que viene.

(O algo así). DISCLAIMER: Nunca lo he hecho así, pero no por falta de ganas. :-)

Bueno, a ver si alguien más se anima y nos aporta sus experiencias sobre:

• forma de definir historias de usuario
• planificación de tareas técnicas
• integración del proceso de wireframing/diseño/maquetación
  

Muchas gracias de nuevo,

My 2 cents

JMB

[Pablo Alonso García]

Hola,

Gracias por compartir tu experiencia JMB.. por lo que veo no lo estamos haciendo tan mal. Lo único que deberíamos mejorar es la descripción de los tests de aceptación si tuviésemos pensado automatizar con Cucumber, etc.

En cuanto a lo que comentas de una tarea tipo: Como equipo quiero el wireframe.... Mi idea era que en las historias, en la parte As a "role", se especifica un rol que representa a alguno de los usuarios de la aplicación. Nunca me he topado con un ejemplo en el que se indique como rol el equipo, jefe de proyecto, etc. Es bueno conocer también esa posibilidad ;-).

Los wireframes a mi me parece un muy buen "artefacto" para enseñar al cliente ya que rápidamente se puede hacer una idea del resultado. En mi caso no tenemos mucha prisa, por eso hemos usado esta técnica para plantear casi cada una de las pantallas. Entiendo que si hay poco tiempo, se podría ir haciendo de forma incremental en cada iteración (junto con el diseño y maquetación HTML y CSS), para poder ir incorporando posibles cambios y mejoras que vayan surgiendo.

Para no dar por terminado este hilo me gustaría pediros opinión sobre un ejemplo práctico que todos conocemos: Facebook. Podríamos crear una historia de usuario como:

Como usuario registrado puedo consultar el perfil de otro usuario para cotillear en la información que comparte. (¿¿epic??)

Sin embargo, cuando un usuario consulta el perfil de otro, se está incluyendo mucha información al mismo tiempo, y eso no se puede hacer todo del tirón como una historia de usuario. Me explico, igual habría que dividir la historia en varias.

Como usuario registrado puedo consultar la información de perfil de otro usuario para conocer su información personal.

Como usuario registrado puedo consultar la información de perfil de otro usuario para ver quiénes son sus amigos.

etc...

¿Debería hacerse de la segunda forma verdad?

Sin embargo, de hacerlo de esta segunda forma más granular, habría tests de aceptación que fuesen comunes. EJ: Un usuario no puedo consultar la información de otro si no son amigos y Un usuario no puede ver los amigos de otro si no son amigos.

Bueno, seguiré planteando mis dudas a medida que vayamos avanzando. Esta lista es super-interesante ;-)

Gracias y un saludo

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a agile-spain...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/agile-spain?hl=es.

[José Manuel Beas]

2010/3/3 Pablo Alonso García <alonsoga...@gmail.com>

Hola,

Gracias por compartir tu experiencia JMB.. por lo que veo no lo estamos haciendo tan mal. Lo único que deberíamos mejorar es la descripción de los tests de aceptación si tuviésemos pensado automatizar con Cucumber, etc.

En cuanto a lo que comentas de una tarea tipo: Como equipo quiero el wireframe.... Mi idea era que en las historias, en la parte As a "role", se especifica un rol que representa a alguno de los usuarios de la aplicación. Nunca me he topado con un ejemplo en el que se indique como rol el equipo, jefe de proyecto, etc. Es bueno conocer también esa posibilidad ;-).

 

Cuidado, porque un gran poder conlleva una gran responsabilidad. Si abres esa caja te puedes encontrar con cosas como: "Como responsable de recursos humanos quiero que todos los empleados cumplan con el horario de 40 horas semanales". ;)

Como usuario registrado puedo consultar el perfil de otro usuario para cotillear en la información que comparte. (¿¿epic??)

Sin embargo, cuando un usuario consulta el perfil de otro, se está incluyendo mucha información al mismo tiempo, y eso no se puede hacer todo del tirón como una historia de usuario. Me explico, igual habría que dividir la historia en varias.

Como usuario registrado puedo consultar la información de perfil de otro usuario para conocer su información personal.

Como usuario registrado puedo consultar la información de perfil de otro usuario para ver quiénes son sus amigos.

etc...

¿Debería hacerse de la segunda forma verdad?

Yo he oido opiniones al respecto. Para empezar, que sepas que yo soy más de tu enfoque, pero hay gente que opina que te vale el mismo enunciado pero simplemente cambias la "definition of done". Bueno, supongo que para gustos hay colores. A mi me gusta que sean más explícitos. Aunque es cierto que es un pelín difícil distinguir entre:

Como usuario registrado puedo consultar la información de perfil de otro usuario para conocer su información personal (sólo nombre y apellidos)
Como usuario registrado puedo consultar la información de perfil de otro usuario para conocer su información personal (nombre, apellidos, email, foto)

Es el enfoque incremental del desarrollo el que nos lleva en este caso a "reutilizar" la historia de usuario pero simplemente añadiendo más campos a la ficha del usuario (y por tanto a la "definition of done").

Sin embargo, de hacerlo de esta segunda forma más granular, habría tests de aceptación que fuesen comunes. EJ: Un usuario no puedo consultar la información de otro si no son amigos y Un usuario no puede ver los amigos de otro si no son amigos.

¿Y cuál es el problema? ;-)
 

Bueno, seguiré planteando mis dudas a medida que vayamos avanzando. Esta lista es super-interesante ;-)

Lo es gracias no sólo a las respuestas sino a las preguntas. ;-D

Un saludo,
JMB

[Abel Muiño Vizcaino]

El 03/03/2010, a las 18:02, Pablo Alonso García escribió:

Como usuario registrado puedo consultar el perfil de otro usuario para cotillear en la información que comparte. (¿¿epic??)

Sin embargo, cuando un usuario consulta el perfil de otro, se está incluyendo mucha información al mismo tiempo, y eso no se puede hacer todo del tirón como una historia de usuario. Me explico, igual habría que dividir la historia en varias.

Como usuario registrado puedo consultar la información de perfil de otro usuario para conocer su información personal.

Como usuario registrado puedo consultar la información de perfil de otro usuario para ver quiénes son sus amigos.

etc...

La granularidad (opinión personal) debería ser la que te permitiera aboradar la historia en un sprint y presentarla al cliente.

Y con un poco de "reescritura" te quedan tareas menos redundantes:

"Como amigo de X puedo ver su información personal"

"Como amigo de Y puede ver sus amigos"

(Eliminas el "puedo consultar la información de perfil", que es lo que introduce ambigüedad)

¿Debería hacerse de la segunda forma verdad?

Depende del tiempo. Si puedes hacerlo todo en un sprint, para que "molestarte" en gestionar dos historias (con sus dos listas de tareas)?

Sin embargo, de hacerlo de esta segunda forma más granular, habría tests de aceptación que fuesen comunes. EJ: Un usuario no puedo consultar la información de otro si no son amigos y Un usuario no puede ver los amigos de otro si no son amigos.

La repetición es un "bad smell" de testing. Si pruebas mediante un "script" (un guión que lleva paso a paso hasta lo que quieres probar) verás que se repiten ciertas partes ("Saving the Communication Gap" trata bastante bien este tema).

Por otra parte, justo el ejemplo que pones no me parece repetido... a fin de cuentas los amigos y la información personal está en distintas pestañas en Facebook (si recuerdo bien). En todo caso, son distintos componentes con distintas pruebas.

La parte común, llegar hasta el perfil, no debería ser parte de la prueba (si puedes evitarlo...) si no de una diferente ("si A y B son amigos, A puede navegar al perfil de B" vs "si A y B son amigos, cuando A puede ver sus amigos de B en su perfil").

Un par de ideas "en abstracto"... mis pruebas de aceptación reales son mucho más flojitas de lo que yo querría :-)

--

Abel Muiño - http://ramblingabout.wordpress.com/

[Albert Cumplido]

Hola a todos,

Primero, comentar que soy bastante nuevo en el ámbito del agile, así
que más que respuestas, tengo un par de preguntas/comentarios:
> ....

> Como usuario registrado puedo consultar la información de perfil de
> otro usuario para conocer su información personal.
> Como usuario registrado puedo consultar la información de perfil de
> otro usuario para ver quiénes son sus amigos.
> etc...

> La granularidad (opinión personal) debería ser la que te permitiera
> aboradar la historia en un sprint y presentarla al cliente.

Dado el siguiente caso: historia bastante grande (15 puntos) y que se
puede "meter" en un sprint (se estima hacer 20 puntos en el sprint).
¿Cómo soy capaz de ver el progreso del sprint? Mi historia se se
divide en diferentes tareas que están relacionadas y que no puedo dar
por ok hasta que no finalicen todas. Así pues, hasta que no finalice
la historia no voy a conocer realmente el estado del sprint. ¿Cómo
soluciono esto?

En cuanto al tema del prototipado:
Quiero dejar claro que creo que es la manera de hacerlo, pero no he
conseguido que hacerlo como es debido
En alguna ocasión he hecho wireframes y se ha convertido en un vaivén
de "propuesta-nuevo feedback del cliente". ¿Se debe poner un límite de
"feedbacks"?
Una vez ya aprobado el wireframe y creada la historia de maquetar el
wireframe, qué hacéis cuando vosotros dáis por bueno el resultado,
pero el cliente no piensa igual. Creo que el diseño y maquetación
puede ser algo muy subjetivo y difícil de delimitar.

Saludos,
albert

[harr...@gmail.com]

Para prototipado te recomiendo www.justinmind.com. Es una herramienta especifica para hacer maquetas, tiene librerias para diferentes UI y lo han curado en lo que es usabilidad. Ademas, es software espanol.

Un saludo,
Harald

Enviado desde mi BlackBerry® de Vodafone

---

From: Pablo Alonso García <alonsoga...@gmail.com>

Date: Wed, 3 Mar 2010 08:34:35 +0100

To: <agile...@googlegroups.com>

Subject: Re: [agile-spain] Definir historias de usuario/prueb as de aceptación e integración de prototipado en el proces o...

[Abel Muiño Vizcaino]

El 03/03/2010, a las 21:55, Albert Cumplido escribió:

>> La granularidad (opinión personal) debería ser la que te permitiera
>> aboradar la historia en un sprint y presentarla al cliente.
> Dado el siguiente caso: historia bastante grande (15 puntos) y que se
> puede "meter" en un sprint (se estima hacer 20 puntos en el sprint).
> ¿Cómo soy capaz de ver el progreso del sprint? Mi historia se se
> divide en diferentes tareas que están relacionadas y que no puedo dar
> por ok hasta que no finalicen todas. Así pues, hasta que no finalice
> la historia no voy a conocer realmente el estado del sprint. ¿Cómo
> soluciono esto?

A mi me dio buen resultado que el equipo "re-estimase" cada día las
tareas en las que había trabajado el día anterior. Sólo tienes que
tener en cuenta que, como todas las estimaciones, esta también es
mentira (i.e. aunque digan "queda 1 día", ese día puede durar toda la
semana).

No es exacto pero te permite aproximar. Como decía Jorge Uriarte en
otro hilo el burndown del sprint "suele tener unos picos
divertidísimos" (y es que no será raro que una tarea a punto de
terminarse crezca de repente :-) )

Otra opción es descomponer la historia, pero puede resultar
artificial. ¿O quizá -estoy especulando, no lo sé- usar tallas de
camiseta en lugar de puntos? (como decía Ángel, cuanto más basta la
estimación, mejor el resultado).