Artículos Boletín TenStep

Estamos conscientes de que el Scrum Master juega el rol de líder servicial quien ayuda con las necesidades del Equipo Scrum. Un Scrum Master no se involucra en el desarrollo de los entregables del proyecto, y deja que el Equipo funcione por su cuenta. Un Scrum Master prepara a la organización y a los miembros del equipo para que adopte el marco Scrum para entregar los proyectos exitosamente. A parte de estas responsabilidades, un Scrum Master también tiene la habilidad de actuar como agente de cambio dentro de la organización. Ahora, veamos cómo.

La guía Scrum, o SBOK (Guía del Cuerpo de Conocimiento Scrum), sostiene que el Scrum Master sirve a la organización en varias maneras, incluyendo:

* Siendo Mentor del equipo Scrum en la adopción de Scrum.
* Es responsable de la implementación de Scrum en la organización.
* Ayuda a los miembros no esenciales para entender Scrum y acostumbrarse a la idea del desarrollo empírico del producto.
* Preparar un ambiente propicio que incremente la productividad en el Equipo Scrum.
* Colaborar con los Scrum Masters de otros equipos con el fin de incrementar la eficiencia en la aplicación de Scrum en la organización.

La Guía Scrum no tiene identificada explícitamente al Scrum Master como un agente de cambio, pero de acuerdo con muchos coaches Ágiles, si alguien tiene la capacidad de traer el cambio al sistema en un ambiente ágil, ése es el Scrum Master.

Consideremos un ejemplo: El Scrum Master, siendo un facilitador, identifica varios problemas que deben ser resueltos antes del siguiente sprint. De acuerdo a expertos en Scrum, el Scrum Master debería reportar los problemas a los miembros de la gerencia senior, Ejemplo.: al Jefe de Tecnología. Sin embargo, todos conocemos que la accesibilidad a la gerencia senior de una manera oportuna, puede ser un problema en sí mismo. Así que, ¿cómo puede un Scrum Master solucionar esta situación compleja?

Una manera de solucionar este tema es definir un panel o grupo de Scrum Masters que trabajen en diferentes proyectos de la organización y reúnen información sobre todos los problemas que cada Scrum Master está enfrentando. Los problemas que ellos enfrentan pueden ser los mismos o diferentes, y el truco aquí es no amontonarlos, sino mirar la imagen completa acerca de por qué se están generando los problemas. A este proceso de identificar y recopilar los impedimentos le sigue una serie de pequeñas discusiones con los miembros del equipo en pequeños grupos. Los participantes de los grupos son quienes tienen la responsabilidad directa o indirecta sobre los problemas. Ahora, al combinar los puntos de vista puedes escalar el tema al jefe de tecnología o a cualquier persona con autoridad para tomar decisiones.

Esta manera de escalar los problemas es especialmente recomendada para las organizaciones que tienen estructura jerárquica o una organización con muchos niveles. Uno de los mayores beneficios de esta técnica es que las organizaciones permitan a su personal que exprese su voz y su opinión, sin inhibiciones, acerca de los problemas existentes en la estructura de la organización y el sistema.

Con respecto a la Guía Scrum, el Scrum Master es un facilitador, quien asegura que al Equipo Scrum se le provea del ambiente propicio para el desarrollo del producto. El Scrum Master debería explorar todas las posibilidades a su alcance para permitir la entrega exitosa del proyecto. Así que, un Scrum Master debe minimizar todos los obstáculos que tuvieren la posibilidad de reducir la velocidad del sprint. Al actuar como un agente de cambio, el Scrum Master solo trata de asegurar una coordinación sin problemas y evita en lo posible la visión de túnel, lo que no es más que dar pasos firmes hacia alcanzar la agilidad.

Autor: SCRUMstudy

Traducción y adaptación: Enrique Ledesma M.Sc., PMP, TSPM, STC, SPOC, SMC, SDC

_{Director Ejecutivo de TenStep Ecuador}

Referencia: https://luis-goncalves.com/scrum-master-as-change-agent/

Como marco Ágil, Scrum es una herramienta de procesos altamente flexible y puede ser “estirada y doblada” para enfrentar requisitos de proyectos de cualquier naturaleza. Es más adecuada para proyectos a los que se requiere descomponer.  Basados en las prioridades del negocio, un proyecto muy grande con poca planeación previa, puede descomponerse en pedazos de trabajo manejables. Por lo tanto, el marco Scrum puede usarse para cualquier proyecto y por cualquier equipo.

La agilidad de Scrum, para proyectos, se demuestra en aquellos que tienen una o varias de las siguientes características:

1.- Cuando estamos trabajando en un proyecto cuyo alcance cambia rápidamente y emergen nuevos requisitos saltando un día. El modelo de ejecución iterativo e incremental de Scrum permite introducir los cambios necesarios, rápidos y responsables en el sistema del proyecto.

2.- Cuando no hay un consenso en la mejor aproximación para enfrentar la dirección de un proyecto, el equipo puede empezar con Scrum ya que combina algunos de los mejores y más flexibles principios de Dirección de Proyecto, lo cual ayudará a todos a sentirse más a gusto.

3.- Cuando existe una indecisión y ambigüedad marcadas en relación a cómo ejecutar el proyecto de acuerdo a los requisitos de la industria; ya que el incremento en la productividad y la reducción del riesgo que resultan al aplicar Scrum lo convierten en la alternativa más lógica.

Ciertamente, podemos afirmar que Scrum es la aproximación de Dirección de Proyectos ideal para proyectos de desarrollo y creación de Software. Cuando te sacuda el atractivo de Scrum, es pertinente mantener ciertos puntos en mente antes de escogerlo como el marco adecuado para un proyecto en particular.

Primero, Scrum no es un método, es un marco, una herramienta de procesos, para la dirección de un proyecto. Segundo, existen unos valores centrales que deben observarse en la teoría y en la práctica, para que Scrum pueda optimizar tus resultados con mejor trabajo de equipo, comunicaciones mejoradas y resultados más rápidos.

Autor: SCRUMstudy

Traducción y adaptación: Enrique Ledesma M.Sc., PMP, TSPM, STC, SPOC, SMC, SDC

_{Director Ejecutivo de TenStep Ecuador}

Una Historia de Usuario es básicamente lo que el usuario debe realizar como parte de las responsabilidades de su trabajo. Indica la información de quién, qué y por qué, concerniente a un Requisito, en una manera simple y consisa, en una tarjeta o nota adhesiva; se escriben por o para el usuario del negocio, y las puede también escribir el Desarrollador.

Las Historias de Usuarios son la manera sencilla de ocuparse de los requisitos de los clientes sin la necesidad de hacer un requisito documentado formal, y sin tener que desempeñar tareas a las que hay que administrar y mantener. La principal intensión es la respuesta rápida y de manera mucho más económica, ante la dinámica de cambio constante de los requisitos en la realidad.

Básicamente, una Historia de Usuario es un documento informal de los requisitos, en caso de ausencia de comunicación, con relación al proceso de Prueba y Aceptación. En necesario que el cliente transcriba un procedimiento de aceptación para asegurar, a través de pruebas u otros métodos, para asegurar el cumplimiento de los objetivos pertenecientes a la historia de usuario, antes de su creación.

Hay muchos beneficios en el uso de las Historias de Usuarios:

1.- Buena comunicación.
2.- No ocurre corrupción de la información.
3.- Hace más fácil estimar el esfuerzo de desarrollo.
4.- Necesita menos mantenimiento.
5.- Tiene un contacto cercano con el cliente.

Formato de Historia de Usuarios:

Como <rol/persona>, Debería ser capaz de <requerimiento> para que <beneficio>.

Ejemplo de Historias de Usuarios:

Como Administrador de Base de Datos, debería ser capaz de revertir un número seleccionado de actualizaciones de la base de datos para que se restaure la versión deseada de la base de datos.

“Las puertas deben ser de al menos 1m de ancho por 2.1m de alto, los pasillos deben tener el camino libre en al menos 1.6m.”

En lugar de tener requisitos como este, la Historia de Usuarios diría:

“Los usuarios del servicio deberían ser capaces de arrastrar el coche de servicio en cualquier lugar del edificio, sin obstáculos, para que todos los clientes puedan hacer uso del coche de servicio.”

Autor: SCRUMstudy

Traducción y adaptación: Enrique Ledesma M.Sc., PMP, TSPM, STC, SPOC, SMC, SDC

_{Director Ejecutivo de TenStep Ecuador}

Conforme las organizaciones progresivamente adoptan Scrum como método de Dirección de Proyectos sobre el método tradicional en cascada, el “mapeo de roles" se vuelve crítico. Tal ves, uno de los mayores retos que enfrentan las organizaciones al moverse a Scrum es la pregunta: ¿Dónde encaja el Director de Proyecto en Scrum?

Estamos tan acostumbrados al rol tradicional del Director de Proyecto que nos olvidamos que se trata de un rol, no necesariamente representa la posición en la jerarquía organizacional. La palabra “Director de Proyecto o Gerente de Proyecto” se ha vuelto tan común que en muchas estructuras organizacionales las personas son permanentemente designadas como Directores de Proyecto. Debemos comprender que ser “Director de Proyecto” no es un tener un título permanente en una organización; mas bien es un rol que una persona tiene cuando dirige un proyecto a su cargo.

Una persona puede tener las competencias necesarias para dirigir un proyecto pero no es Director de Proyecto hasta que no se le encargue esa responsabilidad. El rol del Director de Proyecto es definido por las responsabilidades a desempeñar en ese proyecto y un individuo responsable (Director de Proyecto) ejecuta ese rol.

Cuando estamos transitando de Cascada a Scrum, muchas veces cometemos el error de tratar de encajar al Director de Proyecto asignado dentro de diferentes roles Scrum. No trates de encajar un Director de Proyecto dentro de un Proyecto Dirigido con Scrum; más bien debes mapear los roles y responsabilidades de un Director de Proyecto tradicional con roles y responsabilidades Scrum y de esa manera la persona asignada jugará su rol de acuerdo a sus competencias.

Muchas veces vemos que las personas intentan encontrar sinergias entre los roles de un Director de Proyecto tradicional con los roles de un Scrum Master. En la práctica, ambos son muy diferentes. Un Director de Proyecto tradicional, para el ciclo de vida en cascada, trabaja como un Director o Líder para el proyecto. El planifica, toma decisiones y dirige el proyecto y es responsable de alcanzar los objetivos del Proyecto. El Scrum Master, en cambio, solo trabaja como un facilitador y el o ella está al mismo nivel jerárquico que cualquiera del equipo Scrum. Cualquier persona que aprende a facilitar proyectos Scrum puede convertirse en Scrum Master para un proyecto o un Sprint (iteración).

Las tareas y responsabilidades de un Director de Proyecto tradicional han sido descompuestas en los tres roles principales de un proyecto Scrum. La Guía para el Cuerpo de Conocimiento de Scrum SBOK captura claramente las diferencias entre los role del Director de Proyecto y los roles de Scrum.

Autor: SCRUMstudy

Traducción y adaptación: Enrique Ledesma M.Sc., PMP, TSPM, STC, SPOC, SMC, SDC

_{Director Ejecutivo de TenStep Ecuador}