La I, la V y la S de las historias de usuario

[Jorge Muria]

Hola

Quería comentar un pequeño problema que me suele surgir cuando defino historias de usuario.

Está claro que las historias deben ser INVEST (http://es.wikipedia.org/wiki/Historias_de_usuario#Caracter.C3.ADsticas)

A mi parecer existe un poco de incompatibilidad entre la I, la V y la S. 

I: Independientes entre sí

V: Deben dar valor al usuario

S: Deben ser lo más pequeñas posibles. 

Cuando se intenta minimizar el tamaño de las historias se llega muchas veces a que aunque le ofrece algo de valor al usuario, este es mínimo. Otro efecto colateral es que esa historia pequeña con valor mínimo, sólo tiene sentido si se entrega junto a otra historia. Por lo tanto se crea dependencia entre ellas. Si por el contrario se intenta que la historia tenga valor compelto se llega a historias grandes que se tarda mucho en desarrollar, testear y se arriesga en no completarla a fin de sprint. 

En mi equipo desarrollamos usando Feature Toggles y aunque en cada Sprint hacemos entregas con funcionalidades nuevas, a veces algunas de estas funcionalidades están desactivadas por Toggle hasta que tenemos el Epic completo, o al menos con algo de de valor real completo al usuario. 

¿Qué haceis vosotros sobre esto? 

Gracias. 

[Gustavo Cebrian Garcia]

Hola,

Creo q he practicado y leido mucho de esto. Decir q veo q estàs solventando los problemas... parece... y siempre se tienen estos problemas.

Decir lo siguiente:

- Si no son pequeñas se estima.mal
- si no dan mucha funcionalidad díselo al cliente para q entienda el sprint
-incluso... si solo puedes dividir.en tareas y se da el caso q no puedes dar funcionaludad en un sprint ( intentqndolo en funcionalidad siempre ) explicale al usuario ( product owner ).

En definitiva... seguir invest aunque la vida no sea perfecta

( en el foro de scrumalliance comentaron una vez este problema y esta fue la conclusión )

Gustavo

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para ver este debate en la Web, visita https://groups.google.com/d/msg/agile-spain/-/7RC6KRxVY7gJ.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

[Daniel Ceillan]

Hola.

En realidad yo entiendo por S que se prefieren pequeñas. "Lo más pequeñas posible" no me suena lógico. 

He visto en algunos proyectos que todo lo expresan como user stories. Incluso los bugs. Y escriben user stories que tardas más en escribirlas que en implementarlas. 

Lo que más comunmente he visto, es que se habla de un "tamaño óptimo". 

Muy pequeño es micromanagement y muy grandes son ingestionables. 

Incluso en algunos proyectos no he usado user stories. 

Quizás lo más difícil es lograr que sean independientes. Pero no te sientas mal si te cuesta. No todo es importante, lo importante no es necesariamente urgente. Ni toda regla es ley. 

De las letras I, V y S la que nunca te debería faltar es la V. 

Saludos. 

Enviado desde mi iPad

[Juanma Gómez]

¡Buenas!

La verdad es que el tema de que sean Independientes es delicado, ya que, al hablar de desarrollo incremental, al ser algunas historias de usuario una evolución de otras, existe una clara dependencia. 

Yo creo que INVEST debe ser para nosotros una guía, un horizonte, pero no un fin en sí mismo. Así, como dice Daniel, no emplearemos más tiempo en escribir una historia de usuario que en implementarla. 

Por otro lado, y a raíz también del comentario de Daniel, parece que nos obcecamos por escribir toda funcionalidad como una historia de usuario por obligación. La realidad es que cuando hablamos de historia de usuario hablamos de un molde, una forma, cuyo eje central es el usuario de nuestro producto. Y con toda su potencia es tan solo eso, un molde, una aproximación, nada más. Por eso creo que tampoco es la mejor solución forzar la máquina. Un bug es un bug, y seguramente escribirlo como lo que es sea más eficiente y poderoso que forzarlo hacia una historia de usuario.

¡Buen jueves!

--

Juanma Gómez.

http://about.me/juanmagomezr

[Gustavo Cebrian Garcia]

Hola.

Hablàbamos de definir user stories. Bueno... ya sabéis lo q dice con de " as a ... i want ... so that... " y bueno la historia de usuario tiene su comunicación y charla y también sus criterios de.aceptación.   Os quería preguntar... Qué experiencia tenéis con Cucumber y "specification by example ?? " ?? ( quizá off.topic )

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.

[Gustavo Cebrian Garcia]

Quería decir Mike Cohn :-)

[Daniel Ceillan]

El 25 de abril de 2013 10:25, Gustavo Cebrian Garcia <g.cebria...@gmail.com> escribió:

Hola.

Hablàbamos de definir user stories. Bueno... ya sabéis lo q dice con de " as a ... i want ... so that... " y bueno la historia de usuario tiene su comunicación y charla y también sus criterios de.aceptación.   Os quería preguntar... Qué experiencia tenéis con Cucumber y "specification by example ?? " ?? ( quizá off.topic )

OffTopic extends InterestingTheme

Bueno pues yo creo que todo lo que hacemos tiene un costo asociado, y una generación de valor definida.

Todo lo que sea código, tests, documentación tiene su costo en creación y en mantenimiento. Siempre. Pero si cubre/genera valor, vale la pena. Sino es desperdicio.

Por ende la definición de los criterios de aceptación deberán tener un componente muy fuerte de sentido común. Priorizando más la calidad/efectividad por sobre la cantidad.

Saludos.

--
Daniel Ceillan

Blog: www.agile-patterns.com

[Jorge Muria]

Hola
Gracias a todos por los comentarios. Me ha quedado claro que estoy en el buen camino.
Escribir el desarrollo en forma de historia obliga a pensar en que al final el usuario tiene que hacer y obtener algo
Asi se evita desarrollar tareas que no sirven para nada claro a corto plazo y tener stock de código.
En mi opinión un bug siempre tiene al usuario involucrado porque esta en algo que el usuario puede usar, sino no ae habría detectado. :-)
Un saludo

[Antonio Martinez]

 Justo esta semana he leido un post muy bueno sobre historias de usuario,

http://java.dzone.com/articles/user-stories-practice

Viene el tema de INVEST y si tratar o no los bugs como historias de usuario, a mi me ha aclarado muchas dudas, lo recomiendo.

Saludos

[Gustavo Cebrian Garcia]

Daniel

cucumber quuere tener todo integrado... documentación y automatización de pruebas. y esto como dice cohn bien hecho... no es q solo no de valor... si no q acelera el desarrollo ( por la automatización de pruebas- si arreglas algo no provocar errores en la funcionaludad existete )

eso si. crro q todavía np hay muchos expertos en cucumber...

saludos.

--

[JJG]

Gustavo, nosotros tenemos un PDF de presentación de Cucumber (y otros parae JBehave, Behave para Python y Jasmine) que os puede servir a los que estéis empezando. Os paso la URL directa: http://goo.gl/QklqG

Perdón si es off-topic.

[Antonio Martinez]

Me lo acabo de bajar. No se si será off-topic pero es bastante útil para aquellos que hacemos TDD y estamos mirando como pasarnos a BDD de forma poco traumática. 

Muchas gracias Javier.