Community Blog

En Scrum la planificación no es una etapa o un evento único, es una actividad continua durante todo el Sprint.  La Adaptación continua no es sinónimo de desorden o improvisación.

Scrum es un marco flexible que ofrece muchas ventajas para el desarrollo de productos complejos, pero puede ser fácilmente mal interpretado. Justamente esa libertad puede llevar a distorsiones en su uso.

La agilidad puede verse como una estrategia de negocio, una estrategia empresarial a través del cual las empresas pueden mejorar, mantener y desarrollar su ventaja competitiva en el mercado.

El Framework Nexus de Scrum.org permite el escalamiento de Scrum a nivel de varios equipos, a nivel de varios productos y a nivel organización con varios Nexus usando Nexus+. Nexus es Scrum, Nexus no es un nuevo Framework.

Los criterios de terminado deben cubrir todos los aspectos del ciclo de vida de desarrollo y que permiten lograr un incremento de producto que potencialmente se puede lanzar al mercado.

En Scrum cada Sprint tiene como objetivo producir un incremento de producto completamente terminado y que potencialmente puede ser lanzado al mercado. La inspección de este incremento permite la adaptación del Product Backlog, así como evaluar el progreso hacia el objetivo del Sprint y los objetivos de negocio.

Scrum se basa en un proceso empírico. El empirismo se basa en tomar decisiones basados en la información concreta obtenida de la observación que muestra el progreso del desarrollo de producto, el empirismo se basa en la experimentación para validar las hipótesis.

El aspecto principal del desarrollo de un producto no debe ser el trabajo de UX, es importante como otros tipos de trabajo como arquitectura, pruebas, etc.

Scrum es un framework fácil de entender y difícil de dominar. Scrum no intenta ser una herramienta para solucionar todos los problemas, no es tampoco una receta completa que prescribe paso a paso lo que se debe hacer.

En Nexus no se requiere una reunión “Scrum of Scrums” ya que se usa el Nexus Daily Scrum. El Nexus Integration Team tiene la responsabilidad de gestionar las dependencias de un Nexus y es un equipo dedicado a esta labor entre otras responsabilidades.

Uno de los servicios del Scrum Master es eliminar los impedimentos que tiene el equipo de desarrollo. Pero no todos los problemas son impedimentos. Hay que entender que el Scrum Master no es un solucionador de problemas.

Scrum con “User Experience” es mucho más que “Dual Tracking”. La agilidad provee un contexto para el aprendizaje continuo.

Un Equipo de Desarrollo en Scrum no tiene roles, es “Cross-Functional” lo cual implica que el equipo se enfoca en lograr el objetivo del Sprint como equipo complementando sus competencias.

Scrum limita el riesgo, proporciona transparencia y ayuda a la adaptación a través de los Sprints y la entrega alto valor. Scrum funciona bien con equipos auto organizados que tienen todas las competencias para entregar el incremento de producto.

No hay necesariamente una relación directa entre la complejidad de un PBI definido en términos de puntos de historia y el tiempo de desarrollo. Es decir, un PBI o historia de usuario que tiene mayor complejidad en puntos de historia puede terminarse en menos tiempo que un Item que tenga menos puntos de historia.

En el desarrollo de un producto existe un sólo Product Backlog con un sólo Product Owner. El Product Owner es responsable de la visión, aclaración, ordenamiento y valor final que proporciona el software.

Cuando se trata de representar Scrum en muchas ocasiones se usan algunas imágenes que muestran los roles, eventos y artefactos para definir Scrum.

Priorizar puede indicar una posición de un item dentro del Product Backlog basado en algún tipo de técnica como por ejemplo ROI. El Product Owner no debería limitarse a usar el resultado priorizado mecánicamente. Existen muchas técnicas para priorizar el Product Backlog.

Scrum se ha convertido en el marco ágil de trabajo más usado en el desarrollo de software en el mundo. Uno de los beneficios de Scrum es la entrega de incrementos de producto en periodos de tiempo cortos. El trabajo se basa en la colaboración y trabajo en equipo.

El Sprint Review es una reunión de colaboración donde se busca “feedback” de todos los presentes fundamentalmente para crear transparencia sobre el incremento de producto y permitir la adaptación del “Product Backlog” el “Release Plan” si fuera el caso.

Un Scrum Master que le dice al equipo de desarrollo y al Product Owner que según alguna experiencia cada miembro del equipo de desarrollo solo puede desarrollar...

Scrum Una mejor manera de construir productos Descubrir lo que es Scrum en la Guía Scrum

El Daily Scrum es una reunión clave para la adopción del empirismo, es una oportunidad de inspección y adaptación para generar transparencia hacia el objetivo del Sprint.

Antes de iniciar la lectura del siguiente artículo sugiero la lectura de la guía de Scrum en http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf

Muchas veces sucede que la comunicación no es clara cuando se quiere definir que es terminado. Por ejemplo, cuándo un usuario especifica que requiere un reporte con cuatro columnas y que la última columna tenga un total parece algo sencillo.