Tu organización tolera iteraciones?

[ogarcia]

El siguiente gráfico muestra un conjunto de historias de usuario desarrolladas modo iterativo. Por ejemplo story 1 tomó cuatro iteraciones antes de estar completamente lista para hacer release. 

Hipotéticamente cuáles piensan pueden ser las posibles causas de porque harían falta más de una iteración para llevar un story a su estado listo para deploy?

Tu organización tolera iteraciones? Por qué?

[Deivinson Tejeda]

En relación a la interrogante que planteas, pienso que puede ser por el tamaño de la story, eso me dispara una duda a nivel organizacional, Se describe bien el alcance de un story?, es decir sobre-describimos lo que queremos? A que nivel de las iteraciones era tolerable a release el story, sin caer en ciclos eternos?

Creo que muchas organizaciones pecamos a la hora de pensar en el feature que se quiere desarrollar, ya que no pensamos en un nivel que nos permita "usar" y a partir de este iterar para mejoras, pero esto ya supone que el feature entro en release.

No se si me equivoco, viene dado según mi experiencia, que piensan ustedes? 

Saludos,

2012/4/17 ogarcia <orlando...@gmail.com>

--
Deivinson Tejeda (CaChi)

 @DeivinsonTejeda | http://deivinson.tejeda.com.ve

[gbonalde]

Hola Orlando,
Interesante tu planteamiento,
A primera vista y sin mucha información, me atrevería a revisar el
tamaño y complejidad de las historias de usuario, podrían ser
"Epicas" en lugar Historias, lo cual podria ser una posible causa que
incida en la cantidad de iteraciones.
Saludos

> <https://lh4.googleusercontent.com/-tA67n51Hl4w/T42GKs9ET3I/AAAAAAAACR...>

[Carlos Peix]

Estoy de acuerdo con Gustavo y con Deivinson, parece que las historias son demasiado grandes.

Lo primero que intentaria (suponiendo que las iteraciones son de dos o tres semanas) es que el equipo y el cliente se esfuerce por definir user stories mas pequeñas.

Los desarrolladores somos muy perezosos a la hora de dividir, ya sea para escribir baby steps en TDD o para dividir una user story grande en varias pequeñas.

Con una user story cubriendo varias iteraciones se acota poco el riesgo al error.

Un saludo

Ing. Carlos Peix
carlo...@kleer.la
Cel: (+54 9 11) 4406 7571
Kleer - Agile Coaching & Training

web    | http://www.kleer.la

twitter | http://twitter.com/kleer_la

2012/4/17 gbonalde <gustavo...@gmail.com>

[gbonalde]

Deivinson,
El concepto que mencionas es importantisimo para los agilistas y se
llama Definition of Done DoD, o definición de hecho
http://www.jaestevan.com/definicion-de-hecho-dod-definition-of-done,
sino tenemos claro este concepto, podria ser una causa de lo
mencionado por Orlando.
Seguimos en contacto




On Apr 17, 11:16 am, Deivinson Tejeda <deivinsontej...@gmail.com>
wrote:

> En relación a la interrogante que planteas, pienso que puede ser por el
> tamaño de la story, eso me dispara una duda a nivel organizacional, Se
> describe bien el alcance de un story?, es decir sobre-describimos lo que
> queremos? A que nivel de las iteraciones era tolerable a release el story,
> sin caer en ciclos eternos?
>
> Creo que muchas organizaciones pecamos a la hora de pensar en el feature
> que se quiere desarrollar, ya que no pensamos en un nivel que nos permita
> "usar" y a partir de este iterar para mejoras, pero esto ya supone que el
> feature entro en release.
>
> No se si me equivoco, viene dado según mi experiencia, que piensan ustedes?
>
> Saludos,
>

> 2012/4/17 ogarcia <orlando.gar...@gmail.com>

>
>
>
>
>
>
>
>
>
> > El siguiente gráfico muestra un conjunto de historias de usuario
> > desarrolladas modo iterativo. Por ejemplo story 1 tomó cuatro iteraciones
> > antes de estar completamente lista para hacer release.
>
> > Hipotéticamente cuáles piensan pueden ser las posibles causas de porque
> > harían falta más de una iteración para llevar un story a su estado listo
> > para deploy?
>
> > Tu organización tolera iteraciones? Por qué?
>

> > <https://lh4.googleusercontent.com/-tA67n51Hl4w/T42GKs9ET3I/AAAAAAAACR...>
>
> --
> *Deivinson Tejeda (CaChi)*
>  @DeivinsonTejeda |http://deivinson.tejeda.com.ve

[Rafael Alvarez]

Aparte de la complejidad y alcance de la historia que ya todos han mencionado, otra  causa frecuente es el no tener una definicion clara de 'listo', lo que puede causar que en lugar de iterar se vayan agregando cosas 'necesarias' que aumentan el scope a mitad de iteracion.

Saludos,

[ogarcia]

Imaginen por ejemplo un feature: Mantener al día un cronograma de vuelos

Que story 1 es algo así como:

Con el fin de mantener al día un cronograma de vuelos

Como planificador de vuelos

Quisiera poder registrar un vuelo nuevo cuando un piloto lo solicite

Y que además tienes los siguientes escenarios que cubrir en testing:

1. El vuelo no debe chocar con otro vuelo de la misma aeronave en el bloque de tiempo registrado
   
2. El vuelo debe tener una diferencia mínima de dos horas con respecto al vuelo anterior de la aeronave
   
3. El registro debe producir una notificación en el calendario de vuelos global
   
4. El registro debe enviar un email de vuelo planeado a los tripulantes del vuelo
   

Entonces, se deberían cubrir todos los escenarios en una sola iteración o se pudiera resolver todo el story 1 en cuatro iteraciones?

Que sucede si el cliente descubre que quiere el escenario 2 sólo cuando termina la iteración 1, y el escenario 3 cuando termina iteración 2, and so on...tolerarían esto?

[Demian Gutierrez]

Yo no veo en realidad mayor problema. Creo que el escenario/historia principal es poder registrar un nuevo vuelo. El resto son reglas/escenarios/historias asociadas. Algunas de ellas quizá se conozcan de antemano, otras quizá surjan (se descubran) durante la iteración en la que se desarrolla el escenario principal.

Inclusive, suponiendo que inicialmente se conozcan todas las reglas, nada nos impide verlas como historias diferentes que se pueden desarrollar en iteraciones diferentes.

Por ejemplo, quizá en la siguiente iteración se puede desarrollar la parte de registrar vuelos y las reglas 1 y 2 (porque el cliente decide que son prioritarias), o quizá según las prioridades del cliente es suficiente sólo con el registro del vuelo, sin las otras reglas, que se pueden implementar en iteraciones posteriores según las prioridades definidas.

Pienso que depende mucho de la si la historia se puede separar o no (y en este caso se puede) y de las prioridades del cliente.

Respondiendo a la pregunta concreta, de si toleraría eso, la respuesta en este caso particular es si, si lo toleraría.

Saludos,
Demián

2012/4/18 ogarcia <orlando...@gmail.com>

--

// --------------------------------------------------
Brick walls are there for a reason.
They let us prove how badly we want things.
-- Randy Pausch
// --------------------------------------------------

[Carlos Peix]

Yo escribiria:

User story 1:

Con el fin de mantener al día un cronograma de vuelos

Como planificador de vuelos

Quisiera poder registrar un vuelo nuevo cuando un piloto lo solicite

User story 2:

Con el fin de mantener al día un cronograma de vuelos

Como planificador de vuelos

Quisiera ser avisado del conflicto de horarios de dos vuelos
    Criterio: se considera conflicto la superposicion franca o de menos de dos horas entre llegada y salida

User story 3:

Con el fin de cumplir con normativa de notificacion

Como planificador de vuelos

Quisiera que la tripulacion y sistema global sean notificados del vuelo.

Mas o menos de esa manera, cada historia debe ampliarse con criterios de aceptacion

Ing. Carlos Peix
carlo...@kleer.la
Cel: (+54 9 11) 4406 7571
Kleer - Agile Coaching & Training

web    | http://www.kleer.la

twitter | http://twitter.com/kleer_la

2012/4/18 ogarcia <orlando...@gmail.com>

[ogarcia]

Yo también creo que es necesario tolerarlo. Entiendo que de esto se trata el desarrollo iterativo. A mi parecer, las causas de porque un story puede requerir más de una iteración para llegar a un estado lista para deploy no obligatoriamente reflejan deficiencias en el desarrollo. Para mí lo importante en este punto es que la organización tenga la apertura y capacidad de ir adaptando el story incrementalmente a las necesidades de quien la ha pedido sin caer en el pensamiento del todo-o-nada o sólo-un-chance de soportar adecuadamente el feature. Mi respuesta a la pregunta también es sí, sí lo toleraría.

[ogarcia]

Esta respuesta al post me puso a pensar full. Dividirlas de esta manera al principio me daba un cierto temor de estar perdiendo el motivo principal de porque quieres ser notificado o avisado de cualquier eventualidad al registro del vuelo. Sin embargo luego me hizo poner más en contacto con quiénes realmente se beneficiarían con las notificaciones y avisos. Me facilito ver quien espera este comportamiento del sistema. Gracias Carlos

[Carlos Peix]

Gracias a ti por compartir el resultado, a todos nos sirve.

----------------------------------
Carlos Peix

2012/4/27 ogarcia <orlando...@gmail.com>