Duda sobre actividades de Infraestructura (chore)
25 views
Skip to first unread message
ChilliCoder
Jun 11, 2011, 2:05:07 PM6/11/11
to comunidad-s...@googlegroups.com
Hola,
En un pequeño backlog que estoy haciendo para un proyecto, hay una tarea que se incluyó. La tarea es montar el ambiente de staging de la aplicación. No está asignada a alguien del equipo de desarrollo, es una tarea que se acordó corresponde al cliente.
¿Es un error incluirlo en el backlog? Si la tarea no se cumple en el sprint donde fue incluída ¿se arrastra al siguiente sprint? ¿cómo se considera al momento de hacer los reportes de avance?
Saludos,
alberto...@gmail.com
Jun 11, 2011, 2:18:36 PM6/11/11
to comunidad-s...@googlegroups.com
Hola, aunque nunca he visto tareas en el backlog que no correspondan al equipo de desarrollo de software la verdad es que hoy día Scrum es usado en diferentes áreas. Para tu caso seria factible quitar del backlog esa tarea y simplemente no incluirla en ninguna iteración.
Saludos
Carlos D.
--
You received this message because you are subscribed to the Google Groups "Comunidad Scrum México" group.
To view this discussion on the web visit https://groups.google.com/d/msg/comunidad-scrum-mexico/-/1PKcwLWCWa0J.
To post to this group, send email to comunidad-s...@googlegroups.com.
To unsubscribe from this group, send email to comunidad-scrum-m...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/comunidad-scrum-mexico?hl=en.
Saludos
Carlos D.
Enviado desde mi oficina móvil BlackBerry® de Telcel
From: ChilliCoder <chilli...@gmail.com>
Sender: comunidad-s...@googlegroups.com
Date: Sat, 11 Jun 2011 11:05:07 -0700 (PDT)
ReplyTo: comunidad-s...@googlegroups.com
Subject: Duda sobre actividades de Infraestructura (chore)
You received this message because you are subscribed to the Google Groups "Comunidad Scrum México" group.
To view this discussion on the web visit https://groups.google.com/d/msg/comunidad-scrum-mexico/-/1PKcwLWCWa0J.
To post to this group, send email to comunidad-s...@googlegroups.com.
To unsubscribe from this group, send email to comunidad-scrum-m...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/comunidad-scrum-mexico?hl=en.
caof2005
Jun 11, 2011, 3:44:48 PM6/11/11
to comunidad-s...@googlegroups.com
Chilli
Puede ser.
No necesariamente es un error.
De hecho el pensar siempre que una HU debe estar asociada con algo "visual" de construcción no siempre es conveniente.
Por eso tambien hay HU No Funcionales
Y por supuesto hay HU que no son ni Funcionales ni no Funcionales.
Ejem:
- Que un equipo realize una sesion de entrenamiento.
- Instalar un servidor.
etc.
La pregunta entonces quedaría ¿Cómo describirla?, es decir ¿Cuál sería la narrativa?:
Recordar el concepto básico:
Como <ROL> deseo <X> (Feature o Servicio o Capacidad o Meta)
(para que o con el fin de) <Razón o Beneficio>
En tu caso quizas podría ser algo así como:
<Lider del Equipo o Lider de Control de Configuración> deseo tener ubicado o definido el ambiente X con el fin fin de que la aplicación pueda ser probada, depurada etc.
Es importante recordar 4 cosas:
a) Entonces es posible que todo sea descrito como HU .. si es puede llegar a ser pero NO siempre es conveniente, es algo similar a considerar que por cualquier tarea se tenga que tener algun registro, ejem: Si recibes un email o una llamada de parte de soporte diciendo que el servidor que se cayo ya está arriba, entonces deberias de tener un registro, minuta o algo... pues lo mas posible es que sea valido pero no conveniente....Como siempre depende de tu equipo y de tu situacióin.
b) La HU es un descripción que indica la capacidad servicio o meta a la que se debe llegar o lo que se tiene que cubrir, pero es igual de importante tener siempre en mente el ROL que quiere esa capacidad, servicio o meta asi como el BENEFICIO porque este último (el BENEFICIO) es uno de los factores que te ayudará a priorizar y decidir en que iteración te conviene desarrollar la HU.
c) Así como es importante definir la 1ar parte de la HU "Como tal ROL deseo tal COSA"... también es importante descripbir los criterios de aceptación para que puedas definir cuando se ha finalizado la HU.
De hecho estos criterios pueden llegar a dar lugar a otras HU.
d) La HU debe tener tener caracteristicas INVEST: Independent, Negotiable, Valuable, Estimable, Size appropriately, Testable
e) El Rol no necesariamente es quien desarrolla o es el owner de la HU.
Las HU no son contratos inflexibles sino promesas para volverse a sentar a platicar con mas precisión de lo que se trata. Sin embargo quedaría la duda que onda entonces no hay Cambios de Alcance? y si si lo hay ¿Cómo se manejan?
Aquí es importante que el equipo defina de ANTEMANO ( al principio del proyecto ) que se debe considerar como un cambio de alcance y definir el proceso o flujo correspondiente.
"Se considerará como un cambio de alcance tal y tal cosa bajo estas circunstancias X, Y, Z, y si suceden se deberá hacer tal y tal cosa y generar tal y tal evidencia que debera estar firmada o aprobada por tal y tal gente, esto ocasionara tal y tal efecto en terminos de tiempo y/o dinero"
Es importante incluir tanto detalle como sea necesario, ejemplos y diagramas.
El no hacerlo seguramente le acarreará al equipo muchos problemas!
Ahora finalmente para tu caso, lo mas facil sería pasar esa HU a un Sprint subsecuente y hacer la negociación correspondiente.
Respecto a los reportes de avance el tamaño de esa HU no se tomaria en cuenta es decir sería 0 (aun cuando hayas avanzado mucho) y por supuesto esto afectará tus graficas de quemado teniendo una pendiente menor a lo esperado, y lo mas posible es que en el siguiente sprint la velocidad se incremente (la pendiente será mayor) porque el equipo lograria completar ese conjunto de puntos de la HU pendiente en muy poco tiempo.
Espero que esto te sea úitl Chilli
Salu2
Carlos
Puede ser.
No necesariamente es un error.
De hecho el pensar siempre que una HU debe estar asociada con algo "visual" de construcción no siempre es conveniente.
Por eso tambien hay HU No Funcionales
Y por supuesto hay HU que no son ni Funcionales ni no Funcionales.
Ejem:
- Que un equipo realize una sesion de entrenamiento.
- Instalar un servidor.
etc.
La pregunta entonces quedaría ¿Cómo describirla?, es decir ¿Cuál sería la narrativa?:
Recordar el concepto básico:
Como <ROL> deseo <X> (Feature o Servicio o Capacidad o Meta)
(para que o con el fin de) <Razón o Beneficio>
En tu caso quizas podría ser algo así como:
<Lider del Equipo o Lider de Control de Configuración> deseo tener ubicado o definido el ambiente X con el fin fin de que la aplicación pueda ser probada, depurada etc.
Es importante recordar 4 cosas:
a) Entonces es posible que todo sea descrito como HU .. si es puede llegar a ser pero NO siempre es conveniente, es algo similar a considerar que por cualquier tarea se tenga que tener algun registro, ejem: Si recibes un email o una llamada de parte de soporte diciendo que el servidor que se cayo ya está arriba, entonces deberias de tener un registro, minuta o algo... pues lo mas posible es que sea valido pero no conveniente....Como siempre depende de tu equipo y de tu situacióin.
b) La HU es un descripción que indica la capacidad servicio o meta a la que se debe llegar o lo que se tiene que cubrir, pero es igual de importante tener siempre en mente el ROL que quiere esa capacidad, servicio o meta asi como el BENEFICIO porque este último (el BENEFICIO) es uno de los factores que te ayudará a priorizar y decidir en que iteración te conviene desarrollar la HU.
c) Así como es importante definir la 1ar parte de la HU "Como tal ROL deseo tal COSA"... también es importante descripbir los criterios de aceptación para que puedas definir cuando se ha finalizado la HU.
De hecho estos criterios pueden llegar a dar lugar a otras HU.
d) La HU debe tener tener caracteristicas INVEST: Independent, Negotiable, Valuable, Estimable, Size appropriately, Testable
e) El Rol no necesariamente es quien desarrolla o es el owner de la HU.
Las HU no son contratos inflexibles sino promesas para volverse a sentar a platicar con mas precisión de lo que se trata. Sin embargo quedaría la duda que onda entonces no hay Cambios de Alcance? y si si lo hay ¿Cómo se manejan?
Aquí es importante que el equipo defina de ANTEMANO ( al principio del proyecto ) que se debe considerar como un cambio de alcance y definir el proceso o flujo correspondiente.
"Se considerará como un cambio de alcance tal y tal cosa bajo estas circunstancias X, Y, Z, y si suceden se deberá hacer tal y tal cosa y generar tal y tal evidencia que debera estar firmada o aprobada por tal y tal gente, esto ocasionara tal y tal efecto en terminos de tiempo y/o dinero"
Es importante incluir tanto detalle como sea necesario, ejemplos y diagramas.
El no hacerlo seguramente le acarreará al equipo muchos problemas!
Ahora finalmente para tu caso, lo mas facil sería pasar esa HU a un Sprint subsecuente y hacer la negociación correspondiente.
Respecto a los reportes de avance el tamaño de esa HU no se tomaria en cuenta es decir sería 0 (aun cuando hayas avanzado mucho) y por supuesto esto afectará tus graficas de quemado teniendo una pendiente menor a lo esperado, y lo mas posible es que en el siguiente sprint la velocidad se incremente (la pendiente será mayor) porque el equipo lograria completar ese conjunto de puntos de la HU pendiente en muy poco tiempo.
Espero que esto te sea úitl Chilli
Salu2
Carlos
Emilio Osorio García
Jun 11, 2011, 6:09:04 PM6/11/11
to comunidad-s...@googlegroups.com
Hola a todos,
--
En el caso que no sea factible integrar a personal del cliente como parte del equipo, apoyo la idea de que la saques del producto backlog y lo manejen como un obstáculo por separado, los ScrumMasters generalmente se encargan de lidiar con eso. Sin embargo, si es posible que el cliente pueda y quiera colaborar en las iteraciones entonces seria conveniente hacerlo e incluirla como una historia mas.
Los beneficios de incluir al área de infraestrutura en el SCRUM es que podrán liberar mas rápido y con menos re-trabajos, fortaleciendo el trabajo en equipo y el aprendizaje de todos. Confieso sin embargo que esta opción en una relación cliente/proveedor es normalmente imposible.
Saludos,
Emilio
--
You received this message because you are subscribed to the Google Groups "Comunidad Scrum México" group.
To view this discussion on the web visit https://groups.google.com/d/msg/comunidad-scrum-mexico/-/1PKcwLWCWa0J.
To post to this group, send email to comunidad-s...@googlegroups.com.
To unsubscribe from this group, send email to comunidad-scrum-m...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/comunidad-scrum-mexico?hl=en.
--
Emilio Osorio García
Consultor Principal
SistemasHumanos
Cel: 55.3233.2476
Tel: 55.1328.1868 x111 Nuevo!
Consultor Principal
SistemasHumanos
Cel: 55.3233.2476
Tel: 55.1328.1868 x111 Nuevo!
oemilio
Dx
Jun 11, 2011, 11:13:37 PM6/11/11
to Comunidad Scrum México
Hola!
Estoy de acuerdo con Emilio, si no es una tarea del equipo de
desarrollo, no debería estar en el backlog del equipo.
Sin embargo sí es algo que el Scrum Master debe darle seguimiento.
Dx.
Estoy de acuerdo con Emilio, si no es una tarea del equipo de
desarrollo, no debería estar en el backlog del equipo.
Sin embargo sí es algo que el Scrum Master debe darle seguimiento.
Dx.
Martin Trejo
Jun 13, 2011, 10:46:25 AM6/13/11
to comunidad-s...@googlegroups.com
Hola a todos,
Muchas gracias por los comentarios. Todavía no tengo una decisión al respecto pero leyendo con más detenimiento sus mensajes y considerando otros temas llegaré a una decisión.
--
You received this message because you are subscribed to the Google Groups "Comunidad Scrum México" group.
Reply all
Reply to author
Forward
0 new messages