Dudas con los Sprints

[Jonathan Vila Lopez]

Hola.

Me estoy leyendo el libro Scrum & XP from the trenches y me surge alguna duda sobre los Sprints......

1. La definicion del Sprint BackLog esta cerrado completamente durante su desarrollo ?

2. Existen propuestas de mecanismos para abortar un Sprint ( o un Proyecto ) debido a cambios en el proyecto ?

3. Que mecanismos usais cuando un miembro del equipo se pone enfermo, se fastidia el servidor con el subversion, etc ... ?



Y por otro lado me surgen dudas de concepto que no consigo "solucionar"...... En el libro habla de la reunion del Sprint como algo de 4 a 8 horas........donde la parte de estimacion es de 1.5 horas.


4. como se hace si uno de los elementos del product backlog es "traspasar facturas a Contaplus"....si no tengo ni la mas remota idea de lo que implica, de si la tecnologia que tenemos me lo permite, o de la complejidad que me va a llevar ? como estimo esa tarea en una reunion de 2 horas ? Yo emplearia unas cuantas horas ( dias ) investigando hasta averiguar el orden de manitud de la tarea y por tanto a poder estimarla....

5. para definir el Sprint BackLog parece que primero hay que tener un buen Product backlog, luego definir y estimar unos cuantos elementos y luego decidir cuantos de ellos colocamos en el Sprint.......Por tanto, debo estimar muchos elementos del product backlog para que solo un subconjunto entre en el Sprint actual ?

6. como se define el product backlog ? hasta que nivel de detalle ? del tipo A) "modulo de facturas" o  B)"permitir varios tipos de IVA en las facturas" ?

7. en caso de ser el tipo B, como llegamos a conocer que existe esa funcionalidad ? entiendo que en algun momento se realiza por ejemplo un shadowing del usuario que va a usar la aplicacion para averiguar funcionalidades .... cuando se hace eso ?


Por otro lado.......en una mala comparacion...... el ciclo de vida de Scrum no seria lo mismo que un conjunto de "mini" Proyectos enlazados y cada uno de ellos construido en cascada ?


Muchas gracias de antemano :)


-----------------------------------------------
Slitzweitz !!!!!!

[German DZ]

Respondo irresponsablemente, ya que estoy ocupado, tengo poco tiempo pero me apetece responder rápido y ver que tal mi respuesta! (una especie de exámen express, soy un egoísta!)

1) durante el Sprint no se debe alterar el BackLog

2) Mi propuesta:
     a) El cliente y/o el PO avisan que ya no quieren el Spring
     b) El equipo hace una retrospectiva
     c) Se comunica el resultado

3) Son riesgos, siempre es recomendable tener una gestión de riesgos. Si se enferma alguien, en gral no será tan grave, si no podrá trabajar por más de 2 o 3 días, ya deberán pensar en modificar el equipo. Se fastidia el SVN? simple, le pedís a infraestructura que levante el backup, si tarda más de 2hs en hacerlo elevás un informe y pedido de mejoras a la dirección de la empresa, es una situación inaceptable.

Me suena que lo que planteas en el 4, 5, 6, 7 ocurriría si el Product Owner no hace su trabajo.

No! no son mini cascadas (aunque en otro momento te diría que se parecen). ¿por qué? porque en una cascada una vez finalizado el análisis, el analista deja de trabajar (se congela el modelo de análisis) y empieza el diseñador. En cambio en una iteración el análisis y el diseño se están haciendo contínuamente, si cuando diseñas quieres re-analizar algo lo haces. En las iteraciones se termina cuando se obtiene el resultado, no cuando pasé por todas las etapas (analisis, diseño, construcción, test).

2010/4/13 Jonathan Vila Lopez <jonath...@gmail.com>

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

[Eduardo Ferrández]

Hola:

Te cuento cómo lo resolvemos nosotros, que no tiene que ser la mejor manera ni la que más te guste:

1. En principio sí, pero puedes dotarte de cierta flexibilidad. Para ello introducimos el concepto de velocidad del equipo (o su inversa que sería "factor de ruido"). Esto sirve para absorber cualquier imprevisto, como los derivados de una especificación incompleta. Digamos que es una medida de la incertidumbre, que se calcula a partir de los datos obtenidos en el sprint anterior como referencia, aunque no es necesariamente obligatorio tomar el valor resultante (puede ser que el sprint n tenga objetivos muy diferentes al sprint n-1, con lo que tomar la velocidad del sprint n-1 puede ser absurdo.
2. Generalmente preferimos acortarlo, cerrando las tareas empezadas, aunque si las prioridades cambian radicalmente puede tener sentido tirarlo todo a la basura.
3. Incluido en la velocidad del equipo
4. Durante el sprint n, alguien del equipo adelanta trabajo con el product owner para el sprint n+1, para intentar reducir la incertidumbre en este aspecto. Si alguien conoce de antemano un problema complejo puede orientar al equipo en la descomposición de tareas.
5. Debería existir un product backlog lo suficientemente grande como para alimentar el sprint backlog sin problemas. En cuanto a la estimación del product backlog, preferimos trabajar con puntos y prioridades para calcular el ROI, pero no el tiempo.
6. Historias de usuario
7. El product owner decide ya que es la persona que conoce el negocio.

A lo último, comentarte que en un sprint no hay fases por lo que difícilmente puede ser un mini proyecto en cascada (que define fases y el orden en el que se ejecutan).

[Xavi Gost]

> 1. La definicion del Sprint BackLog esta cerrado completamente durante su
> desarrollo ?

Deberia .... nosotros soliamos poner una par de historias de usuario
de mas por si habiamos estimado mal

> 2. Existen propuestas de mecanismos para abortar un Sprint ( o un Proyecto )
> debido a cambios en el proyecto ?

No entiendo que mecanismo buscas pero si un Product Owner dice "pies
quietos" pues habra que parar. Y si hay un cambio en el proyecto mola
evaluar como evitar que afecte al sprint en cuestion lo menos posible
e incorporar el/los cambios en el sigiente sprint.

> 3. Que mecanismos usais cuando un miembro del equipo se pone enfermo, se
> fastidia el servidor con el subversion, etc ... ?

Vuelvo a no entender demasiado, si un tio esta enfermo, no afecta al
sprint, afectara al resultado y cuando este se evalue todos sabremos
que ha habido un tipo enfermo. Si se fastidia el servidor y hay que
parar, pues se para y se documenta el paron para la retro. Otra cosa
es si sale algo de infraestructura que tienes que solucionar y no es
evitable poniendolo en la deuda tecnica y hay que dedicar tiempo. En
mi implementacion del agilismo metemos unas trajetas rojas en el
kanban y no puede pasar nada a "ongoing" hasta que esas tarjetas no
esten en "done", estas tarjetas no las estimo pero si trackeo su
duracion.

> 4. como se hace si uno de los elementos del product backlog es "traspasar
> facturas a Contaplus"....si no tengo ni la mas remota idea de lo que
> implica, de si la tecnologia que tenemos me lo permite, o de la complejidad
> que me va a llevar ? como estimo esa tarea en una reunion de 2 horas ? Yo
> emplearia unas cuantas horas ( dias ) investigando hasta averiguar el orden
> de manitud de la tarea y por tanto a poder estimarla....

Siempre he solucionado ese tipo de situaciones marcando la historia de
usuario como epica y escribiendo una nueva para investigar el como
hacerlo , esta la estimo de manera arbritaria, simplemente
"TimeBoxeandola" y luego se descompone en tareas que se reparten este
tiempo asignado. A la siguiente iteracion ya sabemos cosas y podremos
estimar..

> 5. para definir el Sprint BackLog parece que primero hay que tener un buen
> Product backlog, luego definir y estimar unos cuantos elementos y luego
> decidir cuantos de ellos colocamos en el Sprint.......Por tanto, debo
> estimar muchos elementos del product backlog para que solo un subconjunto
> entre en el Sprint actual ?

Vaya cuanto mejor definido y estimado sea el backlog, mejor sera tu existencia

> 6. como se define el product backlog ? hasta que nivel de detalle ? del tipo
> A) "modulo de facturas" o  B)"permitir varios tipos de IVA en las facturas"
> ?

el grano lo da la velocidad, cuantos puntos puedes meter en una
iteracion, si la tarjeta no cabe en una iteracion habra que
descomponerla, pero sin llegar a eso , necesitamos definir las
historias de usuario mejor para que sean utiles, estamos mas en la
opcion B pero a mi me gusta llegar a c) permitir tipo de iva al 6% y
toda s las que le siguen. Sobre todo que tengan una definicion de
hecho lo bastante buena.

> 7. en caso de ser el tipo B, como llegamos a conocer que existe esa
> funcionalidad ? entiendo que en algun momento se realiza por ejemplo un
> shadowing del usuario que va a usar la aplicacion para averiguar
> funcionalidades .... cuando se hace eso ?

Eso es la creacion del product Backlog se hace todo el rato

> Por otro lado.......en una mala comparacion...... el ciclo de vida de Scrum
> no seria lo mismo que un conjunto de "mini" Proyectos enlazados y cada uno
> de ellos construido en cascada ?

Vaya!! si que es una mala comparacion.

Xavier Gost

[Juan Carlos Quijano Abad]

Buenas,

1. La definicion del Sprint BackLog esta cerrado completamente durante su desarrollo ?

No, para nada. Nosotros vamos incrementando las tareas cuando el diseño emergente nos lo pide.

2. Existen propuestas de mecanismos para abortar un Sprint ( o un Proyecto ) debido a cambios en el proyecto ?

No, impensable.

3. Que mecanismos usais cuando un miembro del equipo se pone enfermo, se fastidia el servidor con el subversion, etc ... ?

Eso son riesgos y se gestionan como riesgos clásicos. Es decir apechugas como puedas y el sprint sufre.

4. como se hace si uno de los elementos del product backlog es "traspasar facturas a Contaplus"....si no tengo ni la mas remota idea de lo que implica, de si la tecnologia que tenemos me lo permite, o de la complejidad que me va a llevar ? como estimo esa tarea en una reunion de 2 horas ? Yo emplearia unas cuantas horas ( dias ) investigando hasta averiguar el orden de manitud de la tarea y por tanto a poder estimarla....

La estimación del product backlog , en mi caso, es dinámica. Es decir se va conformando según la estimación de todos los sprint item que lo componen o están enlazados con el.

5. para definir el Sprint BackLog parece que primero hay que tener un buen Product backlog, luego definir y estimar unos cuantos elementos y luego decidir cuantos de ellos colocamos en el Sprint.......Por tanto, debo estimar muchos elementos del product backlog para que solo un subconjunto entre en el Sprint actual ?

Si bien la primera parte es cierta, la segunda no la hacemos así nosotros. Estimamos a grosso modo, pero la estimación más fina del product backlog la obtenemos con las estimaciones de los items del srpint.

6. como se define el product backlog ? hasta que nivel de detalle ? del tipo A) "modulo de facturas" o  B)"permitir varios tipos de IVA en las facturas" ?

Según las historias de usuario que decidas. Cada maestrillo tiene su librillo, pero debiera ser ni muy grande para uqe te salgan cientos de work item para muchos sprint, ni demasiado detallado como para que parezca items de un sprint.

7. en caso de ser el tipo B, como llegamos a conocer que existe esa funcionalidad ? entiendo que en algun momento se realiza por ejemplo un shadowing del usuario que va a usar la aplicacion para averiguar funcionalidades .... cuando se hace eso ?

Yo lo hago en dos partes. Primeramente en la primera toma de visión y de requerimientos. Y despues durante el análisis de cada sprint que me va sacando de forma emergente la arquitectura al detalle.

Básicamente todo lo qeu preguntas se responde con: experiencia. Y ajustar el SCRUM a cada proyecto y equipo.

--
Un saludo
Juan Quijano

El 13 de abril de 2010 16:08, Eduardo Ferrández <eduardof...@gmail.com> escribió:

s

[Eduardo Ferrández]

La verdad es que está quedando una buena encuesta. Si ganamos volumen ¿alguien se anima a hacer un resumen/comparativa de las prácticas que aquí se enumeran? Me gusta especialmente lo de la historia épica de Xavi :)

[Jonathan Vila Lopez]

Pues sinceramente yo estoy aprendiendo un monton........... desde la practica es como se ven las cosas, al menos yo..............y veo que bajo la "misma" definicion hay quien hace las cosas de una forma y otros de otras..... y todas validas porque las respalda la experiencia..........

A lo que dice Eduardo yo me suscribo....muy buena idea..........incluso seria interesante describir el entorno/contexto de cada uno.......


-----------------------------------------------
Slitzweitz !!!!!!

2010/4/13 Eduardo Ferrández <eduardof...@gmail.com>

[Alfredo Casado]

1. La definicion del Sprint BackLog esta cerrado completamente durante su desarrollo ?

Si, esta cerrada. Esto es importante respetarlo para marcar los ritmos del proyecto, en caso de dejarla demasiado abierta corres el riesgo de que el PO se acostumbre "a colar" historias. Es importante que el PO entienda que no puede colar historias para que haga su trabajo de definición del backlog antes del sprint planning, si no es muy frecuente que PO nuevos o poco implicados no preparen el backlog lo suficiente y vayan "improvisando". Otro tema es lo que comenta xavi, puedes estimar alguna de más por si vas con tiempo y pueden entrar.

2. Existen propuestas de mecanismos para abortar un Sprint ( o un Proyecto ) debido a cambios en el proyecto ?

En teoría un sprint sólo se debe romper si el objetivo del sprint ha dejado de tener sentido, si por ejemplo llamas al sprint "informes de contabilidad" y el usuario decide a medio camino que los informes de contabilidad los va a realizar con otra herramienta, entonces no tiene sentido seguir y paras. Se hace un retro, una nueva planificación y se comienza un nuevo sprint. De todos modos no es o no debería ser una situación muy habitual, en caso de serlo tienes un problema serio a tratar en las retrospectivas.

3. Que mecanismos usais cuando un miembro del equipo se pone enfermo, se fastidia el servidor con el subversion, etc ... ?

No pasa nada, se terminarán menos historias. Lo bueno es que esto lo detectas en los daily y el PO esta enterado de la situación desde que empieza a degradarse la cosa, no se lleva la sorpresa al final del sprint. Es importante no intentar terminar "como sea" y a costa de degradar la calidad y el ritmo del equipo, si haces esto (alguna vez lo hemos echo, y no por imposiciones del management sino por un exceso de implicación o una implicación mal entendida) al final lo pagas en el siguiente sprint con una bajada de ritmo por "compensación" (algo inevitable, leer peopleware) o bien que bajaste la calidad del sofware y ahora lo pagas. Otro tema es que practicas como la "propiedad colectiva del código" y el "pair programming" ayudan a que la baja de un determinado miembro no sea un drama, todo el mundo es capaz de asumir cualquier tarea.

4. como se hace si uno de los elementos del product backlog es "traspasar facturas a Contaplus"....si no tengo ni la mas remota idea de lo que implica, de si la tecnologia que tenemos me lo permite, o de la complejidad que me va a llevar ? como estimo esa tarea en una reunion de 2 horas ? Yo emplearia unas cuantas horas ( dias ) investigando hasta averiguar el orden de manitud de la tarea y por tanto a poder estimarla....

Si en realidad no tienes ni idea de cuanto cuesta, entonces nosotros hacemos algo como lo que propone xavi, se crea una historia estimada con un "timebox" para investigar el tema y en los siguientes sprnts cuando se tenga más información se estima y se subdivide en tareas. Por ejemplo en el sprint en el que estamos actualmente tenemos una historia para estudiar la integración de un API para control de licencias por llaves hardware, no teníamos ni idea y hemos delicado X tiempo a estudiar alternativas, en siguientes sprints ya podremos estimar lo que nos cuesta con más información. Cuanto más cortos sean tus sprints de nuevo mejor para temas como estos, si teneis habitualmente mucha incertidumbre en las tareas plantearos una semana dos como muchísimo.

5. para definir el Sprint BackLog parece que primero hay que tener un buen Product backlog, luego definir y estimar unos cuantos elementos y luego decidir cuantos de ellos colocamos en el Sprint.......Por tanto, debo estimar muchos elementos del product backlog para que solo un subconjunto entre en el Sprint actual ? 

Cuantos más mejor, aunque dependerá de lo claro que tenga el PO la dirección del producto y lo que realmente quiere, no creo que exista una recomendación general que aplique para todos los proyectos. Eso sí, estas estimaciones son de grano muy gordo, simplemente que el PO pueda decidir con algún criterio (coste de desarrollo frente a valor aportado para el cliente) que historias tienen más prioridad.

6. como se define el product backlog ? hasta que nivel de detalle ? del tipo A) "modulo de facturas" o  B)"permitir varios tipos de IVA en las facturas" ?

Generalmente con historias de usuario, de tipo "As a x, i want to x, so that x" o algo similar. Luego según se acerca a la cola de la pila se puede ir ampliando esta definición introduciendo escenarios de ejemplo, considerando escenarios de error etc,etc. Una practica recomendada es hacer una reunión "timebox" durante el sprint i para ir refinando las historias que previsiblemente entrarán en el sprint i+1.En nuestro caso particular la definición de historias es uno de los puntos donde más tenemos que mejorar, para este tema los libros de mike cohn o el "bridging the communication gap" de godjo adjic aportan ideas muy valiosas.

7. en caso de ser el tipo B, como llegamos a conocer que existe esa funcionalidad ? entiendo que en algun momento se realiza por ejemplo un shadowing del usuario que va a usar la aplicacion para averiguar funcionalidades .... cuando se hace eso ?

Ese es el trabajo del PO, saber que producto quiere construir. También acuerda del principio ágil "colaboración con el cliente frente a seguimiento de un plan", se trata de entregar cosas que funcionen frecuentemente para que el usuario final evalué como se ajusta el producto que se esta desarrollando a sus necesidades y proponga cambios y mejoras.

Por otro lado.......en una mala comparacion...... el ciclo de vida de Scrum no seria lo mismo que un conjunto de "mini" Proyectos enlazados y cada uno de ellos construido en cascada ?

Si de scrum sólo te quedas con el "proceso" puede serlo, lo que diferencia a scrum o al desarrollo ágil de un conjunto de "minicascadas" son los principios ágiles. Por ejemplo no tienes separación de roles (analista, diseñador, programador, arquitecto y demás vainas) sino que todo el equipo trabaja y colabora para la consecución de un objetivo común, el trabajo de uno no acaba en un "documento" que luego pasa al siguiente de la cadena, el trabajo de todos como equipo acaba con historias completas que funcionan y aportan valor al cliente. 

Además un sprint no pasa por fases (análisis, diseño, implementación y test) donde tienes X historias abiertas a la vez en análisis, y luego pasan a diseño y luego... se intenta terminar una historia de forma COMPLETA antes de pasar a la siguiente, sólo en caso de que un miembro del equipo no pueda ayudar a completar una historia abierta (porque ya hay suficiente gente trabajando en esa historia) coge una tarea de la siguiente por orden de prioridad. La idea es tener "abiertas" el menor número de historias posibles, si alguien puede echar una mano en una historia comenzada esto siempre es más prioritario que comenzar una nueva. De este modo se consigue llegar al final del sprint no con 20 cosas en las que "falta sólo la fase de test y algunos detalles" sino con X's historias realmente completadas.

Incluso si haces TDD se podría decir que cada ciclo RED-GREEN-REFACTOR es una "minicascada":

análisis y diseño: implementación del test dejándolo en RED

implementacion: escribir el código para que pase (GREEN) y refactorizar.

test: esta implícito porque escribes especificaciones ejecutables.

así que más que cada Sprint una "minicascada" se podría decir que en el desarrollo ágil bien aplicado (con tdd of course) hay cientos de "minicascadas" por Sprint.