Categoría: Scrum

Una declaración de visión identifica dónde quiere o pretende estar la organización en el futuro o dónde debería estar para satisfacer mejor las necesidades de las partes interesadas. Todo proyecto necesita una visión para orientarse en la dirección adecuada. Una visión sirve de guía para elegir el rumbo actual y futuro de las acciones.

No todos los elementos del backlog del producto tendrán el mismo tamaño y nivel de detalle (es decir, características/eprics/ historias de usuario y tareas) al mismo tiempo. Los PBIs en los que planeamos trabajar pronto deben estar en la parte superior del backlog, de menor tamaño y muy detallados para que puedan ser trabajados en el sprint a corto plazo. Los PBIs en los que no trabajaremos durante algún tiempo deberían estar en la parte inferior del backlog, más grandes y menos detallados.

La filosofía de desarrollo de software «Release early, release often» hace hincapié en la importancia de los lanzamientos tempranos y frecuentes para crear un estrecho bucle de retroalimentación entre los desarrolladores y los probadores o usuarios, al contrario que una estrategia de lanzamiento basada en las características.

La colocación es útil para las reuniones que requieren una escucha atenta, como las discusiones de diseño. También es útil cuando los nuevos empleados se están formando y necesitan algún tipo de ayuda o estímulo. La pizarra es muy eficaz para el equipo colocado, pero también puede gestionarse con herramientas en línea.

Un equipo de desarrollo de Scrum tiene la autonomía para elegir la mejor manera de realizar su trabajo, en lugar de ser dirigido por otros fuera del equipo. A diferencia de los principios tradicionales de gestión, los equipos auto-organizados y empoderados no son dirigidos y controlados desde arriba, sino que evolucionan a partir de los miembros del equipo que participan activamente & colectivamente en todas las prácticas y eventos de Scrum.

Una Revisión del Sprint es más que una simple demostración; es una revisión del Sprint completado, del Product Backlog y del Marketplace. Es cierto que las demostraciones son una parte importante de la Revisión del Sprint. El propósito de la reunión de la Revisión del Sprint es que el equipo muestre a los clientes y a las partes interesadas el trabajo que han realizado a lo largo del sprint y lo compare con el compromiso adquirido al principio del mismo.

Un Product Owner que posee el producto en nombre de la empresa es una parte de un equipo Scrum. Sin embargo, un propietario del producto no tiene autoridad sobre otros miembros del equipo, al igual que el Scrum Master. Un Product Owner es responsable de cuidar de un producto durante un largo período de tiempo y es responsable de lograr el éxito del producto. Como propietario del producto, debe interactuar directamente con los clientes y usuarios, el equipo de desarrollo y otras partes interesadas clave, como muestra la imagen siguiente.

Un Scrum master es un miembro de un equipo Scrum. Su tarea es crear un ambiente de trabajo productivo y guiar a los demás a entender los valores, principios y prácticas de Scrum. los directores de scrum tienden a estar orientados a las personas, tienen un alto EQ, y encuentran alegría en ayudar a los miembros de su equipo a crecer.

Scrum es en sí mismo un marco sencillo para la colaboración eficaz del equipo en productos complejos. La Guía de Scrum para explicar scrum de forma clara y concisa. esta guía contiene una definición de scrum. Esta definición consiste en los roles, eventos y artefactos de Scrum, y las reglas que los unen. Cada componente del marco de trabajo tiene un propósito específico y es esencial para el éxito y el uso de Scrum. Las reglas de Scrum unen los roles, eventos y artefactos, gobernando las relaciones y la interacción

La Retrospectiva del Sprint tiene lugar después de la Revisión del Sprint y antes de la siguiente Planificación del Sprint. Se trata de una reunión de tres horas como máximo para los Sprints de un mes. La sesión de retrospectiva es básicamente una reunión de «mejora» que se celebra para encontrar formas y medios de identificar posibles escollos, errores del pasado y buscar nuevas formas de evitar esos errores, a la que asisten todos: el propietario del producto, el maestro de scrum, los miembros del equipo de desarrollo y, opcionalmente, las partes interesadas.