Scrum-time.com
Scrum Master

Scrum Master


Índice:

  1. Primero – lo esencial
  2. Las relaciones recíprocas con otros participantes
  3. Con todo lujo de detalles:
  4. Ejemplo

Vamos a comprender qué y quién es el Scrum Master.

Jeff Southerland, como uno de los elaboradores de la metodología Scrum en seguida ha roto la comprensión habitual de los administradores. Aunque con la seguridad directa es posible decir que su filosofía sólo representa correctamente la esencia de las relaciones recíprocas sociales en las colectividades de trabajo en particular, así como en toda la sociedad en total.

Primero – lo esencial

Es posible decir bastante atrevidamente que Scrum Master es una de los peces gordos en la metodología Scrum. Es necesario comprender – Scrum Master no da las tareas pero elimina los problemas que aparecen adentro el Scrum Team.

Todas las preguntas, que surgen durante el proceso de trabajo inevitablemente engendran los problemas y el objetivo del Scrum Master revelarlos y hacerlos abiertos.

Esta abertura conduce directamente a la confianza dentro del equipo. La confianza dada engendra la atmósfera, que influye favorablemente en la velocidad y la cualidad del trabajo. Scrum Master es obligado a aplicar también la cantidad máxima de los esfuerzos para la creación de tal atmósfera.

La confianza, la revelación de las preguntas y la eliminación de los problemas llevan a unos procesos más puros de la ejecución de las tareas. Scrum Master sigue la ejecución de tales procesos.

La vigilancia por el proceso y el cambio de los estatus de las tareas en el Sprint se acuestan también a los hombros del Scrum Master.

Scrum Master cada día dirige Daily Scrum Meeting. Scrum Master debe organizar los meetings.

Él se ocupa del planteamiento de la comunicación correcta, la observación de los procesos, que permiten concentrarse en los objetivos correctos.

Scrum Master coopera no sólo con la orden, sino también con el Product Owner. Él puede ayudar el propietario del producto para crear Backlog.

Entonces es posible distinguir el funcionamiento básico del Scrum Master:

  • la eliminación de los problemas que se forman dentro del equipo;
  • la revelación de las preguntas escondidas;
  • la creación de las relaciones amistosas en el equipo;
  • la vigilancia por los procesos y su ejecución;
  • el cambio de los estatus de las tareas en el Sprint;
  • la realización de los Daily Scrum Meeting;
  • la organización de los encuentros ante los Sprints;
  • la ayuda del Product Owner con el Backlog.

Las relaciones recíprocas con otros participantes

Scrum Master ayuda al Product Owner:

  • Controla con el Product Owner como correctamente llevar el Backlog para el logro del valor máximo del producto;
  • Trata de encontrar unos métodos más eficaces de la gestión del Backlog;
  • Presta la ayuda al Scrum Team en la creación de los elementos convenientes y cualitativos del Backlog
  • Puede actuar como el facilitador en los encuentros por necesidad, así como a petición;
  • Usa los métodos flexibles en la elaboración y la dirección;

Scrum Master y la Organización

  • Coopera con otros Scrum Master para la utilización más efectiva de la metodología Scrum en la Organización;
  • Manifiesta la iniciativa en los cambios, que deben llevar a la eficiencia del Scrum Team;
  • Se ocupa de la ayuda a los empleados que son interesados en la metodología Scrum. Ayuda a introducir el Scrum.
  • Se ocupa del entrenamiento en la organización para la adaptación al Scrum;
  • Hace la planificación de las etapas de la introducción Scrum.

Con todo lujo de detalles:

Scrum Master – el ayudante, no el dueño

Si tomamos el destino básico del cobcepto de "el funcionario", nos llevará a una persona, que es el criado del pueblo y se ocupa de cualquier eliminación de todos los problemas en la esfera dada. Suena utópico ¿ verdad? Nosotros sabemos perfectamente que pasa, cuando un cierto funcionario deja de ser el criado del pueblo, e incluso no comprende el sentido principal del lugar y comienza a sentirse simplemente el administrador, por la parte superior del triángulo, a quién debe servir el pueblo y cumplir sus encargos. Claro que eso no es de nada bueno.

Scrum Master juega al curling:

Un ejemplo bueno de la metodología Scrum es el juego curling. Nos interesa ahora desde la parte del Scrum Master.

Las reglas básicas del curling:

Scrum Master
Scrum Master 2
Scrum Master 3
  1. El juego tiene lugar en una cancha especial, con la senda y "el blanco".
  2. Un jugador hace un lanzamiento de la piedra, que rueda hacía el blanco.
  3. Durante el movimiento de la piedra por el hielo hay una fricción sobre el hielo y la piedra puede rodar antes del blanco o al contrario detrás del blanco. En este caso llegan los jugadores, que se ocupan del "sweeping". Sweeping es un proceso de la frotación del hielo, que abastece un deslizamiento más rápido de la piedra por el hielo gracias a la capa intermedia delgada que se forma del agua. El sweeper (que fricciona el hielo ) cumple en realidad las funciones siguientes:
    • no toca la piedra moviente;
    • organiza aquella senda para la piedra, que llevará la piedra máximamente exacto al objetivo.

¿Es posible decir que el sweeper mueve la piedra? Fisicamente un jugador la empuja y fisicamente los sweepers no tocan la piedra. Sin embargo gracias a los sweepers la piedra mueve de la manera necesaria.

Según parece, un sweeper es un análogo completo del Scrum Master. Sin tocar el trabajo del equipo el Scrum Master influye directamente en su movimiento al objetivo dado. En el ejemplo del curling se ve muy bien que el trabajo del Scrum Master es muy importante.

Ejemplo

Hemos hecho un ejemplo de nuestra base de la información y hemos tratado de mostrarlo desde el punto de vista de los papeles diferentes. En este caso miraremos al proyecto más de la parte del Scrum Master. En el ejemplo llevaremos algunas complicaciones, por esencia son triviales y decididos, pero fueron creados para dar a comprender la base de qué y cómo lo debe hacer el Scrum Master.

La elaboración de la tienda de Internet desde el punto de vista del Scrum Master.

Para hacer una tienda de Internet buena, es necesario determinar y decidir en primer lugar qué es necesario y como se verá. Esto es en realidad alguna lista de deseos.

Tal lista es compuesta por la persona llamado el Product Owner. La persona con el papel dado imagina en la cabeza un producto final. Hay que decir que casi siempre durante el proceso de trabajo y la aparición de los resultados, hay una comprensión de que alguna de las ideas no era acertada pero otra idea sería necesario incluir. No vamos a examinar detalladamente las funciones y el pensamiento del Product Owner aquí.

De un modo o de otro, la persona que ve el producto final por lo menos aproximado (Product Owner) hace la lista - la descripción de lo que debe ser en la tienda. La lista dada se llama el Product Backlog:

Temas Denominación Descripción Estado Valoración Emisión
La dirección del catálogo Adición del producto La elaboración de la forma de la creación del producto, que contiene la foto, el nombre, el precio, la rebaja o su ausencia... En la obra 2 Emisión 1
La dirección del catálogo Eliminación del producto La eliminación del producto de la página de la redacción y también de la lista En la obra 2 Emisión 1
Encargo Pago El uso de los sistemas de pago En la obra 10 Emisión 2
Encargo Acceso La entrada a través de las redes sociales En la obra 1 No planeado
... ... ... ... ... ...

Como recordamos de las exigencias del Scrum Master - la ayuda al Product Owner en la competencia de Product Backlog, en su regulación, el ajuste eficaz etc. El Scrum Master es obligado a mirar en primer lugar la lista dada y ayudar al Product Owner.

Vamos a ver que pueda decir el Scrum Master sobre el Backlog dado. Es necesario comprender en primer lugar la noción "los sistemas de pago", es una noción general y el objetivo no está claro. ¿Cuántos sistemas de pago deben ser conectados? ¿Cuáles son básicos? ¿Y las redes sociales? ¿Hay que conectar al Facebook? ¿Google +? ¿Qué es lo más importante y qué debe estar en la emisión?

La indeterminación en el Product Backlog es el problema básico, que aporta la misma indeterminación al trabajo desl Scrum Team. Como recordamos - una de las funciones esenciales del Scrum Master es la aclaración de las vaguedades y su eliminación. Un defecto más es la referencia del trabajo sobre la paga en la Emision 2. En realidad, la paga en la tienda de Internet es el funcionamiento más importante.

Vamos a ver cómo podemos mejorar el Product Backlog:

Temas Denominación Descripción Estado Valoración Emisión
La dirección del catálogo Adición del producto La elaboración de la forma de la creación del producto, que contiene la foto, el nombre, el precio, la rebaja o su ausencia... En la obra 2 Emisión 1
La dirección del catálogo Eliminación del producto La eliminación del producto de la página de la redacción y también de la lista En la obra 2 Emisión 1
Encargo Pago Pago contra reembolso En la obra 10 Emisión 1
Encargo Pago El pago con tarjetas Visa и Mastercard En la obra 10 Emisión 1
Encargo Pago El pago con el sistema El Yandex Dinero En la obra 10 Emisión 2
Encargo Acceso Apuntarse por el Facebook En la obra 1 No planeado
Encargo Acceso Apuntarse por el Google+ En la obra 1 No planeado
... ... ... ... ... ...

Ahora podemos ver que el Product Backlog es más concreto. Por supuesto hemos dado como ejemplo unos Backlogs no ideales sino sólo los que en la variación simple pueden mostrar lo esencial.

Después de que un Backlog está formado comienzan los Sprints. El Scrum Master toma parte en todos los ciclos de la vida del Sprint. Ahora podemos ver que el Product Backlog es más concreto. Por supuesto hemos dado como ejemplo unos Backlogs no ideales sino sólo los que en la variación simple pueden mostrar lo esencial.

El segundo meeting llevan ya el Scrum Master y el Scrum Team. En esta etapa serán aportadas las tareas al Sprint Backlog, que el equipo será capaz a cumplir a tiempo.

Si durante el Sprint rusulta que el equipo no puede cumplir todas las tareas, el Scrum Master debe quedarse con el Product Owner para decidir qué tareas se puede excluir del sprint y al mismo tiempo alcanzar el objetivo. En nuestro ejemplo imaginario, es posible suponer que el Scrum Master decide excluir las tareas de la formalización final de los productos. Entonces el objetivo básico del sprint - organizar la adición y la eliminación de la producción con todos los parámetros necesarios y las intercomunicaciones todo - será exactamente alcanzada.

Cada día el Scrum Master lleva Daily Scrum Meeting.

En el ejemplo el Scrum Master hace siempre las mismas preguntas:

  1. ¿Qué hicieron ayer?
  2. ¿Que van a hacer hoy?
  3. ¿Con que problemas se han encontrado?

El Scrum Master puede oír unas respuestas así:

  1. Las tablas de la producción en la base de datos;
  2. La forma para la adición del producto;
  3. No está formado por completo el esquema sobre las rebajas acumuladas.

Después de la recepción de las respuestasel Scrum Master compone un cierto "Action Items". Allí está indicado habitualmente: qué, quién, cuándo hay que decidir.

¿Qué hay que hacer? ¿Con quién hay que consultar? Plazos
Resolver lo de las rebajas Aleksey 24 horas

El período final en el Sprint es la demostración del producto - Sprint Review Meeting. Lo lleva el Scrum Master. Dura 4 horas. El Scrum Team compone el plan de escenario (agenda) y el Scrum Master dirige lo de quién y qué comenta.

Scrum Team

Scrum Team

Product Owner

Product Owner

Sprints

Sprints

Sprint Backlog

Sprint Backlog

Daily Scrum Meeting

Daily Scrum Meeting

Sprint Review Meeting

Sprint Review Meeting
Project Manegement
Project Manegement

Tiempo Scrum Time

keyboard_arrow_up