ScrumGuide ScrumDistribuido

SINOPSIS

Scrum Guide.

El documento presenta los aspectos generales y componentes de Scrum, un marco en el que se emplean diversas técnicas y procesos para desarrollar/crear productos mediante el acople y coordinación de equipos y herramientas de trabajo, una mención a su visión/enfoque general, personas que han estado involucradas, historia, y propósito, para tratar la teoría subyacente de Scrum, el “control empírico de procesos”, y abordar los tres pilares que sostienen la implementación del “control empírico de procesos”: la transparencia, la inspección y la adaptación.

A continuación se exponen los cuatro componentes de Scrum: equipos scrum, bloques de tiempo, artefactos y reglas.

En cuanto a los equipos scrum, se describen los tres roles que tienen: ScrumMaster, Propietario del Producto y Equipo; y se describen las características que deben poseer, tales como: auto-gestionados / auto-organizados, multifuncionales y trabajo por iteraciones.

En cuanto a los bloques de tiempo se menciona qué son y en qué consisten, así como su finalidad, que es crear regularidad, y se describen con mayor detalle los seis elementos de Scrum basados en bloques de tiempo: reunión de planificación de la entrega, reunión de planificación del Sprint, Sprint, Scrum diario, revisión del Sprint y retrospectiva del Sprint.

Se hace mención a las Reglas como la unión entre bloques de tiempo, roles y artefactos.

Se describen los cuatro artefactos de Scrum: product backlog, sprint backlog, burndown de versión y sprint burndown; éstos artefactos son documentos, los backlogs generalmente listas de tareas donde cada elemento consta de atributos descriptivos e informativos, y los burndowns diagramas de medición de avance de los backlogs.

Finalmente se expone el concepto de “hecho”, su tratamiento por las organizaciones y en el Scrum, y las categorías “hecho” y “sin hacer” de los backlogs, y cómo se reflejan estas categorías en los burndowns.

Scrum Distribuido. Trabajo de Investigación. v1.1.

El documento brinda una visión de lo que es la metodología ágil para la gestión de proyectos Scrum enfocada/aplicada/usada en entornos definidos como “distribuidos”, así como los retos, componentes, respuestas, estrategias, herramientas y soluciones a ésta particularidad/característica “distribuida”.

El documento presenta la naturaleza del texto/investigación, así como la plataforma en la que se enmarca, luego se da una visión introductoria generalizada al objetivo/escencia del documento, disposición a grosso modo del texto, y sustento con el que se aborda el texto.

A continuación se presentan definiciones generales acerca de agilismo, scrum, equipo/ambiente distribuido, y scrum distribuido, que es el tema central del texto.

Ahondando en el concepto de “distribución” se tratan diferentes tipologías (tipos, configuraciones, aspectos) de ambientes distrubuídos, los retos presentados, y la respuesta a éstos.

Después se revisan los componentes de Scrum (roles, artefactos y reuniones), su definición, comportamiento (estándar y distribuído), retos, estrategias y tácticas, herramientas, y respuestas/soluciones.

Como conclusión se destaca que además de haber repasado las problemáticas, desafíos, riesgos y esfuerzos implicados en la adopción de Scrum en un contexto de trabajo distribuído, ésto permite acceder a un gran rango de beneficios relevantes y de suficiente valor como para justificarlos; es decir, se han presentado las distintas dimensiones convergentes en la adopción de Scrum Distribuido, así como enfoques para afrontar sus dificultades y capitalizar sus beneficios, logrando así entender la filosofía original del modelo Scrum.

CITAS

es lo que ya hacemos cuando estamos entre la espada y la pared.

Esta guía describe cómo utilizar Scrum para desarrollar productos. Scrum no es un proceso o una técnica para desarrollar o crear productos, sino que es un marco en el que se pueden emplear diversos procesos y técnicas. El papel de Scrum es hacer aflorar la eficacia relativa de las prácticas de desarrollo empleadas por usted, para que pueda mejorarlas, a la vez que proporciona un marco dentro del cual se pueden desarrollar productos complejos.

control empírico del procesos

optimizar la previsibilidad y controlar los riesgos.

control empírico de procesos.

La frecuencia de inspección debe tener en cuenta que todos los procesos se cambian por el propio acto de inspección. El dilema se presenta cuando la frecuencia de inspección requerida excede la tolerancia del proceso a ser inspeccionado.

Hay tres puntos para la inspección y la adaptación en Scrum.

auto-gestionados, multifuncionales, y trabajan en iteraciones.

Scrum emplea bloques de tiempo para crear regularidad.

Un burndown es una medida del backlog restante a través del tiempo.

Los mecanismos de inspección y adaptación de la naturaleza empírica de Scrum le guiarán.

Las Reglas sirven de unión para los bloques de tiempo, los roles y los artefactos de Scrum,

El Equipo Scrum consiste en el ScrumMaster, el Propietario del Producto, el Equipo.

El ScrumMaster nunca debe ser el Propietario del Producto.

“eliminar impedimentos.” El papel del ScrumMaster es el de servidor y líder del equipo de Scrum. Sin embargo, el ScrumMaster no gestiona al Equipo Scrum; el equipo Scrum es auto-gestionado.

Sin embargo, el propietario del producto no puede ser nunca el ScrumMaster.

Esta visibilidad requiere que el Propietario del Producto dé lo mejor de sí mismo, y hace que Propietario del Producto sea un rol exigente además de gratificante.

Sin embargo, las habilidades que el miembro del Equipo comparte - es decir, la habilidad de tratar con un requisito y convertirlo en un producto utilizable - tienden a ser más importantes que aquellas que no comparte.

La sinergia resultante mejora la eficiencia global de todo el Equipo, y la eficacia.

Los equipos grandes generan demasiada complejidad como para que pueda ser gestionada por un proceso empírico.

Por esta razón se debe tener cuidado al cambiar la composición del equipo.

Un Sprint es una iteración.

Scrum es un marco para un proyecto cuyo horizonte no es superior a un mes, y en el cual hay suficiente complejidad para que un horizonte más largo sea demasiado arriesgado.

La información de entrada para esta reunión es el Product Backlog, el último incremento del producto, la capacidad del Equipo y el rendimiento anterior del Equipo.

Las Tareas se deben descomponer para que se puedan completar en menos de un día. Esta lista de tareas se llama Sprint Backlog.

esta reunión no debe consumir más de 5% del total del Sprint.

El propósito de la Retrospectiva es inspeccionar cómo fue el último Sprint en lo que respecta a las personas, relaciones, procesos y herramientas.

Estos cambios se convierten en la adaptación derivada de la inspección empírica.

El Scrum Diario no es una reunión de seguimiento del estado del proyecto. No es para cualquiera, sino sólo para la gente que trabaja en transformar los elementos del Product Backlog en un incremento (el Equipo).

La intención es optimizar la probabilidad de que el equipo logre su Objetivo. Ésta es una reunión clave de revisión y adaptación en el proceso empírico de Scrum.

Mientras existe un producto, el Product Backlog también existe.

Se trata de una lista de todas las características, funciones, tecnologías, correcciones mejoras de errores y que constituyen los cambios que se harán al producto para futuras versiones.

El Product Backlog es un documento vivo.

A medida que se va trabajando o se terminan tareas, se actualizan las horas de trabajo estimado restante para cada tarea.

La inspección y adaptación llevada a cabo en la Revisión del Sprint, serán tan precisas como lo sea esta transparencia.

y se describen las características que deben poseer, tales como: auto-gestionados / auto-organizados, multifuncionales y trabajo por iteraciones.

recurso educativo abierto (OER)

apoyándonos en sus principios, con la firme creencia de que son estos los que hacen posible obtener los mayores beneficios de la agilidad.

dinamismo e incertidumbre

Esto hace necesario incorporar enfoques de desarrollo que sean flexibles y adaptables a los cambios,

Lista de requisitos del sistema que evoluciona a lo largo del desarrollo.

Tareas a realizar por el Equipo de Desarrollo.

y las posibles necesidades o impedimentos que tenga para continuar el trabajo.

trabajando de manera cohesionada y autoorganizada, buscan alcanzar un objetivo común.

diferentes configuraciones entre los distintos miembros, atendiendo a diversos parámetros que a veces pueden solaparse.

en la comunicación entre los miembros del equipo

Uno de los principales objetivos de Scrum es facilitar la comunicación entre todos los integrantes del proyecto para minimizar el riesgo de que aparezcan trabas, debido a suposiciones y malos entendidos durante el desarrollo.

Es necesario usar un lenguaje común, lo más plano posible, sin jerga o neologismos y tratar de disminuir en lo posible nuestros acentos.

permiten poner cara a las personas que participan, se ven gestos, como se reacciona ante lo que se está hablando,

Un equipo distribuido corporativo,

Un equipo distribuido multi-empresa,

(Uniones Temporales de Empresas)

Esto agrega la complejidad adicional de la gestión contractual e incluso la necesidad de contar con acuerdos adecuados para garantizar el funcionamiento del equipo.

Ambas divisiones no son excluyentes sino que pueden darse de forma unísona.

En definitiva, podemos afirmar que no hay dos organizaciones iguales.

La condición de equipo distribuido está relacionada con la imposibilidad de realizar un trabajo regular y conjunto en un mismo lugar y en una misma franja horaria.

“El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara”

la comunicación y la implicación.

multidisciplinar y auto-organizado

Uno de los factores clave para el éxito de un equipo Scrum es el compromiso de sus miembros.

puede ocasionar que la relación que surja no sea más que la de un grupo de personas que comparten unas tareas en común.

“yendo a Abilene”

unidad de medida del esfuerzo o valor de las historias y tareas

resultará recomendable realizarla tras una revisión del Sprint, o antes de una reunión de planificación del Sprint.

Puede parecer algo rudo, pero descongestiona posicionamientos individuales que, si no se admiten positivamente por el equipo, pueden generar problemas de colaboración en el medio plazo.

distribución soft, distrubución hard

facilitando tanto la obtención de métricas como análisis posteriores para facilitar la gestión de los procesos.

TÉRMINOS

tres pilares, transparencia, inspección, adaptación, auto-gestionado, multifuncional, iteración, regularidad, product backlog, sprint backlog, burndown, burndown de versión, sprint burndown, auto-gestión, multidisciplinar, multifuncional, inspección, revisión, adaptación, dinamismo, dinámico, incertidumbre, incierto, mejora continua, autoorganizada, objetivo común, atañen, atañer, suposición, malos entendidos, jerga, neologismo, offshore, taxativo, comunicación, implicación, autogestión, multidisciplinar, auto-organizado, pila del producto, compromiso, pertenencia, distribución soft, distrubución hard.

REFERENCIAS