Interrupciones En Scrum - Historial de revisiones

Marianocifre: Corrección menor

2010-04-10T16:37:32Z

Corrección menor

190.174.68.182: "typo" en responsabilidades del Scrum Master en el primer párrafo. "quitas" por "quitar"

2010-02-06T22:43:48Z

"typo" en responsabilidades del Scrum Master en el primer párrafo. "quitas" por "quitar"

201.251.182.130 en 13:44 28 ago 2008

2008-08-28T13:44:41Z

Admin en 19:05 31 jul 2008

2008-07-31T19:05:35Z

Admin en 19:05 31 jul 2008

2008-07-31T19:05:14Z

190.172.86.173 en 20:53 26 jul 2008

2008-07-26T20:53:02Z

190.172.86.173: /* Tipos de interrupciones */

2008-07-26T20:52:45Z

‎Tipos de interrupciones

190.172.86.173: Página nueva: El proceso de Scrum habla de tener un mínimo de interferencia durante el Sprint, de manera que los Miembros Del Equipo De Scrum puedan abocarse completamente al cumplimie...

2008-07-26T20:51:22Z

Página nueva: El proceso de Scrum habla de tener un mínimo de interferencia durante el Sprint, de manera que los Miembros Del Equipo De Scrum puedan abocarse completamente al cumplimie...

Página nueva

El proceso de [[Scrum]] habla de tener un mínimo de interferencia durante el [[Sprint]], de manera que los [[Miembros Del Equipo De Scrum]] puedan abocarse completamente al cumplimiento del objetivo del [[Sprint]]. El [[ScrumMaster]] es el responsable de quitas estos impedimientos del camino, de manera de no afectar la velocidad del equipo.

Sin embargo, en la práctica, es común que, mientras el equipo está trabajando en su [[Sprint]], tengan que dar soporte a producción por diversos temas. Estas interrupciones pueden parecer interferencias que afecten al equipo, pero son impedimentos importantes para los usuarios del sistema y para el [[Dueño Del Producto]]. De hecho, de poco le servirá al [[Dueño Del Producto]] que se agregue nueva funcionalidad al sistema si el producto actual no funciona correctamente.

===Tipos de interrupciones===

Durante el proceso de [Scrum] pueden surgir diferentes tipos de interrupciones, que atentan contra la entrega de software para el [Sprint] en curso. Estas interrupciones puede ser:
* Soporte técnico que no puede ser resuelto por la primer línea de soporte de la empresa
* Tareas de mantenimiento del sistema.
* Pedidos de investigación de comportamientos extraños en el sistema.
* Pedidos de información del sistema que no se consiguen facilmente, y requieren la dedicación de un desarrollador.
* Problemas en el entorno productivo (por ejemplo, mala performance o caidas) que requieren la atención de desarrolladores.

==Gestión de interrupciones==

Todos estos aspectos (y algunos más) puede ser potencialmente más importantes que completar nuevas historias. Entonces, ¿cómo ma}nejar estas interrupciones en el [[Sprint]]?

Hay varias formas de llevar adelante las interrupciones, y depende de la cultura de la empresa y las características de la propia interrupción.

*'''Usar dos Backlog''': tener un backlog para las características del producto, y otro para temas relacionados al soporte de producción. El [[Dueño Del Producto]] define la cantidad de trabajo que se realiza en cada backlog. En este escenario, se puede llevar un gráfico burn-down para el backlog del producto, y un gráfico burn-up para el soporte a producción.

*'''Bugs como historias''': se ubican las interrupciones como historias dentro del backlog del producto, y se estiman de la misma manera, incluso los problemas productivos. El [[Dueño Del Producto]] luego las prioriza según sus necesidades, y elige acorde.

*'''Emergencias''': son interrupciones que deben ser resueltas en forma inmediata. El [[Scrum Master]] y el [[Dueño Del Producto]] son quienes mejor pueden juzgar una emergencia. Si el tema es una emergencia real, el [[Dueño Del Producto]] puede jugar la "carta de emergencia", siempre y cuando sea consciente del costo de hacerlo: no llegar a completar los items planificados y, quizás, hacer peligrar el objetivo del Sprint.

====Atención de las interrupciones====
Otro tema importante a resolver es quién deberá trabajar en las interrupciones. El soporte de producción puede ser aburrido, y en general nadie del equipo quiere hacerlo. Es por esto que tener un equipo dedicado al soporte no es buena idea. Además, un equipo dedicado a soporte genera una división de las tareas, con la confusión que esto trae.

Una opción es contar con un "rol de soporte" que vaya cambiando de Sprint a Sprint, o semanalmente. Esto ayuda a reforzar el sentido de equipo, y como beneficio adicional aumenta el conocimiento general del sistema.

Otra opción para atender las interrupciones es utilizar el concepto de "Sacrificar una persona". con este concepto, la solución del problema se asigna a una persona que se dedica en forma exclusiva a la interrupción. Si bien esta persona queda "sacrificada", el resto del equipo puede seguir progresando en su actividad principal.

En resumen, cuando llegue el momento de gestionar interrupciones, considerar el ubicarlas en el backlog del producto, y priorizarlas. Esto ayuda a asegurarse de que el equipo siempre esté realizando el trabajo correcto. De todas formas, si la interrupción es una emergencia, entonces ocurrirá un costo para el Sprint, y la decisión dependerá de evaluar este costo versus una resolución inmediata.

==Ver también==
* [[Proceso De Desarrollo Con Scrum]]

==Más información==
* [http://www.infoq.com/news/2008/07/interruption-driven-development Interruption Driver Development]

@@ Línea 1: / Línea 1: @@
 [[Category:Scrum]]
-El proceso de [[Scrum]] habla de tener un mínimo de interferencia durante el [[Sprint]], de manera que los [[Miembros Del Equipo De Scrum]] puedan abocarse completamente al cumplimiento del objetivo del [[Sprint]]. El [[Scrum Master]] es el responsable de quitas estos impedimientos del camino, de manera de no afectar la velocidad del equipo.
+El proceso de [[Scrum]] habla de tener un mínimo de interferencia durante el [[Sprint]], de manera que los [[Miembros Del Equipo De Scrum]] puedan abocarse completamente al cumplimiento del objetivo del [[Sprint]]. El [[Scrum Master]] es el responsable de quitar estos impedimientos del camino, de manera de no afectar la velocidad del equipo.
 Sin embargo, en la práctica, es común que, mientras el equipo está trabajando en su [[Sprint]], tengan que dar soporte a producción por diversos temas. Estas interrupciones pueden parecer interferencias que afecten al equipo, pero son impedimentos importantes para los usuarios del sistema y para el [[Dueño Del Producto]]. De hecho, de poco le servirá al [[Dueño Del Producto]] que se agregue nueva funcionalidad al sistema si el producto actual no funciona correctamente.

← Revisión anterior		Revisión del 13:44 28 ago 2008
Línea 24:		Línea 24:

	*'''Emergencias''': son interrupciones que deben ser resueltas en forma inmediata. El [[Scrum Master]] y el [[Dueño Del Producto]] son quienes mejor pueden juzgar una emergencia. Si el tema es una emergencia real, el [[Dueño Del Producto]] puede jugar la "carta de emergencia", siempre y cuando sea consciente del costo de hacerlo: no llegar a completar los items planificados y, quizás, hacer peligrar el objetivo del Sprint.		*'''Emergencias''': son interrupciones que deben ser resueltas en forma inmediata. El [[Scrum Master]] y el [[Dueño Del Producto]] son quienes mejor pueden juzgar una emergencia. Si el tema es una emergencia real, el [[Dueño Del Producto]] puede jugar la "carta de emergencia", siempre y cuando sea consciente del costo de hacerlo: no llegar a completar los items planificados y, quizás, hacer peligrar el objetivo del Sprint.
−

	====Atención de las interrupciones====		====Atención de las interrupciones====

← Revisión anterior		Revisión del 19:05 31 jul 2008
Línea 1:		Línea 1:
		+	[[Category:Scrum]]
	El proceso de [[Scrum]] habla de tener un mínimo de interferencia durante el [[Sprint]], de manera que los [[Miembros Del Equipo De Scrum]] puedan abocarse completamente al cumplimiento del objetivo del [[Sprint]]. El [[Scrum Master]] es el responsable de quitas estos impedimientos del camino, de manera de no afectar la velocidad del equipo.		El proceso de [[Scrum]] habla de tener un mínimo de interferencia durante el [[Sprint]], de manera que los [[Miembros Del Equipo De Scrum]] puedan abocarse completamente al cumplimiento del objetivo del [[Sprint]]. El [[Scrum Master]] es el responsable de quitas estos impedimientos del camino, de manera de no afectar la velocidad del equipo.

← Revisión anterior		Revisión del 20:53 26 jul 2008
Línea 1:		Línea 1:
−	El proceso de [[Scrum]] habla de tener un mínimo de interferencia durante el [[Sprint]], de manera que los [[Miembros Del Equipo De Scrum]] puedan abocarse completamente al cumplimiento del objetivo del [[Sprint]]. El [[~~ScrumMaster~~]] es el responsable de quitas estos impedimientos del camino, de manera de no afectar la velocidad del equipo.	+	El proceso de [[Scrum]] habla de tener un mínimo de interferencia durante el [[Sprint]], de manera que los [[Miembros Del Equipo De Scrum]] puedan abocarse completamente al cumplimiento del objetivo del [[Sprint]]. El [[Scrum Master]] es el responsable de quitas estos impedimientos del camino, de manera de no afectar la velocidad del equipo.

	Sin embargo, en la práctica, es común que, mientras el equipo está trabajando en su [[Sprint]], tengan que dar soporte a producción por diversos temas. Estas interrupciones pueden parecer interferencias que afecten al equipo, pero son impedimentos importantes para los usuarios del sistema y para el [[Dueño Del Producto]]. De hecho, de poco le servirá al [[Dueño Del Producto]] que se agregue nueva funcionalidad al sistema si el producto actual no funciona correctamente.		Sin embargo, en la práctica, es común que, mientras el equipo está trabajando en su [[Sprint]], tengan que dar soporte a producción por diversos temas. Estas interrupciones pueden parecer interferencias que afecten al equipo, pero son impedimentos importantes para los usuarios del sistema y para el [[Dueño Del Producto]]. De hecho, de poco le servirá al [[Dueño Del Producto]] que se agregue nueva funcionalidad al sistema si el producto actual no funciona correctamente.

@@ Línea 15: / Línea 15: @@
 ==Gestión de interrupciones==
-Todos estos aspectos (y algunos más) puede ser potencialmente más importantes que completar nuevas historias. Entonces, ¿cómo ma}nejar estas interrupciones en el [[Sprint]]?
+Todos estos aspectos (y algunos más) puede ser potencialmente más importantes que completar nuevas historias. Entonces, ¿cómo manejar estas interrupciones en el [[Sprint]]?
 Hay varias formas de llevar adelante las interrupciones, y depende de la cultura de la empresa y las características de la propia interrupción.

@@ Línea 37: / Línea 37: @@
 ==Ver también==
 * [[Proceso De Desarrollo Con Scrum]]
 * [http://www.infoq.com/news/2008/07/interruption-driven-development Interruption Driver Development]

@@ Línea 5: / Línea 5: @@
 ===Tipos de interrupciones===
-Durante el proceso de [Scrum] pueden surgir diferentes tipos de interrupciones, que atentan contra la entrega de software para el [Sprint] en curso. Estas interrupciones puede ser:
+Durante el proceso de [[Scrum]] pueden surgir diferentes tipos de interrupciones, que atentan contra la entrega de software para el [[Sprint]] en curso. Estas interrupciones puede ser:
 * Soporte técnico que no puede ser resuelto por la primer línea de soporte de la empresa
 * Tareas de mantenimiento del sistema.
@@ Línea 11: / Línea 11: @@
 * Pedidos de información del sistema que no se consiguen facilmente, y requieren la dedicación de un desarrollador.
 * Problemas en el entorno productivo (por ejemplo, mala performance o caidas) que requieren la atención de desarrolladores.
 ==Gestión de interrupciones==