Desplegar historias de usuario sin valor perceptible

[José Manuel Beas]

Estaba leyendo este artículo de Joshua Kerievsky que alguien tuiteó no hace mucho 

https://elearning.industriallogic.com/gh/submit?Action=PageAction&album=blog2009&path=blog2009/2011/horizontalSlicing&devLanguage=Java

y me gustaría compartir con vosotros una reflexión.

Cuando escribimos nuestras historias de usuario intentando que sean INVEST http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

nos encontramos con que deben ser independientes y que deben aportar valor. A veces no somos conscientes de esto y tendemos a hacer historias que no aportan valor por sí mismas sino hasta que llegamos a una que "cierra el círculo".

En este artículo, Kerievsky explica un caso muy claro de cómo el orden importa a la hora de implementar, pero IMHO esto no debe confundirse con que las historias son dependientes. En el ejemplo, persistir la última página visitada aporta valor por sí mismo, aunque éste no sea percibido directamente por el usuario hasta que no se implementa la última de las historias (la de la UI). Tened en cuenta que, en el contexto del ejemplo de Kerievsky, él trata cada funcionalidad como una historia porque está haciendo despliegue continuo. (Al menos yo lo entiendo así)

¿Cómo lo veis vosotros? 

P.S.

Ya sé que sería un tema interesante para el AOS2011, pero me gusta escuchar opiniones bien reflexionadas y la lista es un buen sitio para esto. También lo puede ser el AOS2011, pero el formato no lo propicia tanto. :-)

Un saludo,
Jose Manuel Beas

http://jmbeas.es

http://agilismo.es

http://twitter.com/jmbeas

[Abel Cuenca]

Mmm,

La definición del enlace que adjuntas dice que una historia INVEST da valor ... al usuario (y sí, aquí hay mucho tema de discusión con las historias técnicas y demás...)

Si no tuviera un sistema de despliegue continuo,¿creéis que habría desplegado solo el cambio de la parte de persistencia y que hubiera esperado las 2 o 3 semanas de la siguiente iteración para desplegar el resto de los cambios (UI,...)? Yo personalmente tengo mis dudas, me quedo con lo de que la historia de usuario es toda la funcionalidad completa (UI, persistencia,...). 

My 2 cents,

Abel.

--
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.

[Jorge Uriarte Aretxaga]

2011/6/16 Abel Cuenca <abel....@gmail.com>

Si no tuviera un sistema de despliegue continuo,¿creéis que habría desplegado solo el cambio de la parte de persistencia y que hubiera esperado las 2 o 3 semanas de la siguiente iteración para desplegar el resto de los cambios (UI,...)? Yo personalmente tengo mis dudas, me quedo con lo de que la historia de usuario es toda la funcionalidad completa (UI, persistencia,...). 

Yo le daría la vuelta a esa tortilla. Si pudieras, es decir, si te costara *muy poco* (en sus distintos ejes de tiempo, pasta, riesgo...) dar el ok a algo y ponerlo en producción. ¿Por qué esperarías dos o tres semanas? Tener esa capacidad te permite tácticas de desarrollo incremental muy interesantes.

Eso sí, estoy de acuerdo con Abel en que el primer día no desplegó una historia, sino una parte de ella que le permitía ponerla a prueba sin riesgos. En el momento en que tuvo un interfaz, entonces ya "compro" que sí, que había una historia entregada en una versión "verde" pero completa. Y en los dos días siguientes hizo el UI más adecuado, con lo que puedo darla por cerrada (o refinada).

En general... y su último párrafo (top-down...) me reafirma en esa impresión, creo que lo que pasa es que está usando un entorno productivo para prototipado, tanto técnico como funcional. Y no entraré a si eso está bien o mal, dependerá de todo el contexto del proyecto.

Yo sí comparto que a veces es mejor desplegar una historia/funcionalidad "a medias" para ver cómo evoluciona y obtener datos fiables antes de publicarla o incluso de completarla desde el punto de vista del usuario. El segundo enfoque... para eso prefiero hacer prototipos, pero para gustos están los colores :)

_

Jorge

_

Jorge

[German DZ]

Actualmente estoy haciendo despliegues que solo es ejecutar 2 comandos (porque soy un vago y no uní los 2 scripts). Al ser así, hago varios despliegues por hora.

¿Por qué hago eso? porque tenemos 3000 visitantes al día en ese sitio con 7 páginas vistas por cada uno. Durante el día son 170 visitante cada hora. Si no despliego, estoy privando a mucha gente de las cosas mejoradas que implica cada despliegue.

A mi no me cuesta nada desplegar constantemente, porque ya invertí en automatizarlo. Y además eso me permite "arriesgar" un poco más, ya que si me equivoco en algo puedo arreglarlo igual de rápido y es más beneficioso probar las cosas y si funciona insistir sobre eso y si no.. dejarlo.

2011/6/16 Jorge Uriarte Aretxaga <jorge....@gailen.es>

--

[Enrique Amodeo]

Yo lo veo claro, se entregan incrementos de funcionalidad, no
artefactos. Como norma general una UI o una capa de persistencia por
si misma son artefactos no funcionalidades. La excepción puede ser que
el PO tras hablar con el cliente, decida que tener la UI sin
persistencia (por ejemplo) sí que aporta algo al negocio.
Es interesante, porque podemos usar BDD (aunque al final no lleguemos
a automatizar las pruebas) para investigar si algo tiene valor o no.
Si eres capaz de escribir una feature que por si sóla de valor al
negocio de forma independiente entonces ok. Si terminas con una
narrativa cogida por los pelos (sobre todo la parte del "in order to")
tal vez es que no tienes un incremento de funcionalidad entre manos.
En el caso de la persistencia o la UI por separado que comenta JMB,
¿cómo sería la historia de usuario?
Normalmente en el DoD solemos incluir que por cada historia su BDD sea
exitoso (aunque lo tengamos que probar a mano). Por lo que no se puede
tener nada hecho que no tenga un BDD asociado y por lo tanto que no
tenga valor.
Salud !

2011/6/16 German DZ <ge...@ndz.com.ar>:

[Enrique Amodeo]

Se me olvidaba, sobre el despliegue continuo, está muy bien, pero no
implica que tengamos que subir cada incremento de funcionalidad como
locos a producción:
a) No en todas las áreas de negocio se pueden desplegar en producción
estos incrementos tan pequeños, hay que agruparlos en MMFs para
subirlos a producción.
b) ¿Subis a producción sin que el PO y los usuarios clave den el ok?
Por mucho automatismo que tengamos, que yo sepa hay que enseñarle el
resultado al cliente antes de entrar en producción, tal vez hubo un
malentendido con la funcionalidad, o la usabilidad no le acaba de
gustar....
Salud !

2011/6/17 Enrique Amodeo <eamode...@gmail.com>:

[Jorge Uriarte Aretxaga]

On Friday, June 17, 2011, Enrique Amodeo <eamode...@gmail.com> wrote:
> b) ¿Subis a producción sin que el PO y los usuarios clave den el ok?
> Por mucho automatismo que tengamos, que yo sepa hay que enseñarle el
> resultado al cliente antes de entrar en producción, tal vez hubo un
> malentendido con la funcionalidad, o la usabilidad no le acaba de
> gustar....

Jejé por eso decía yo que el concepto "me cuesta poco subir" tiene
muchos ejes ;)

_
Jorge

--
_
Jorge Uriarte Aretxaga
http://www.gailen.es
http://www.linkedin.com/in/jorgeuriarte

[Juan Antonio G. Lebrijo]

En #lebrijocom Labs hemos  creado una máquina virtual con virtualbox que nos ayudará a gestionar nuestros proyectos de desarrollo de software.

Hemos tratado de elegir los subsistemas más utilizados actualmente (Subversion, Nexus, Jenkins, Sonar), con la idea de poder programar con los principios de la programación extrema: integración contínua, control de versiones, calidad de código y control de la configuración. 100% Open Source.

Además hemos instalado un magnífico software de gestión de proyectos como es RedMine:

Podéis descargar la imagen en en este enlace. Espero que la disfrutéis !!

[José Manuel Beas]

Interesante (y útil), igual sería buena idea también hablar de esto en la lista ecosistemas-software. :-)

https://groups.google.com/group/ecosistemas-software

[Rubén Martínez Candela]

Yo utilizo el mismo paquete, cambiando svn por git. Desde que lo uso soy mucho más feliz ^^

--
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.

--
Rubén Martínez Candela
www.rubenmartinez.info

[PEDRO BALLESTEROS HERRANZ]

Para el control de la configuración yo usaría GIT y me olvidaría ya de SVN, sin lugar a dudas. SVN tiene serias limitaciones en cuanto a gestión de ramas, renames y moves que GIT supera con creces.

---

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

[PEDRO BALLESTEROS HERRANZ]

Perdón, he visto que con control de la configuración os referíais a Maven, bueno, yo quería decir GIT para el SCM

 

S2,

                Pedro

[Mario Nunes]

Me gustaría poder reflotar esta conversación, yo estoy haciendo lo mismo con la idea de montar una ISO para su puesta en marcha en un servidor, sin pensar en virtualizaciones.



Salu2.