Scrum Manager BoK - User contributions [en]

ICE Score

2025-02-17T08:11:24Z

Smanager: Created page with "Próximamente"

Próximamente

WSJF

2025-02-09T16:55:09Z

Smanager: Created page with "'''Weighted Shortest Job First (WSJF)''' es un método de priorización utilizado en la gestión ágil de productos y desarrollo de software. Su objetivo principal es optimizar la entrega de valor minimizando el impacto del tiempo de espera de las funcionalidades más importantes. WSJF es especialmente útil en la planificación de productos cuando se debe decidir qué características implementar primero en un Producto Mínimo Viable (MVP) o en nuevas versiones de un pr..."

'''Weighted Shortest Job First (WSJF)''' es un método de priorización utilizado en la gestión ágil de productos y desarrollo de software. Su objetivo principal es optimizar la entrega de valor minimizando el impacto del tiempo de espera de las funcionalidades más importantes. WSJF es especialmente útil en la planificación de productos cuando se debe decidir qué características implementar primero en un Producto Mínimo Viable (MVP) o en nuevas versiones de un producto existente.

== Concepto ==
El método WSJF prioriza las tareas en función de la relación entre el valor que generan y el esfuerzo necesario para completarlas. Se basa en la siguiente fórmula:

WSJF = Costo del Retraso / Tamaño del trabajo

Donde:
* '''Costo del Retraso (CoD)''': Representa el impacto negativo de postergar la implementación de una funcionalidad, considerando:
** Valor para el negocio o el usuario.
** Urgencia temporal.
** Oportunidad de mercado.
* '''Tamaño del Trabajo''': Esfuerzo requerido para completar la tarea, medido en tiempo, complejidad o recursos necesarios.

Las funcionalidades con mayor WSJF se priorizan primero, maximizando la entrega de valor con el menor esfuerzo posible.

== Beneficios ==
* Optimización del valor entregado.
* Reducción de la subjetividad en la toma de decisiones.
* Adaptabilidad a cambios en el negocio o mercado.

== Limitaciones ==
* Dificultad en la estimación precisa del Costo del Retraso.
* No considera dependencias entre tareas.
* Puede favorecer tareas pequeñas en detrimento de otras más estratégicas.

== Aplicación en proyectos ágiles ==
El método WSJF se aplica en la planificación y priorización del backlog en metodologías ágiles. Su implementación sigue estos pasos:

# Identificación de funcionalidades o historias de usuario.
# Estimación del Costo del Retraso en función de su impacto.
# Evaluación del Tamaño del Trabajo.
# Cálculo del WSJF y ordenación de tareas de mayor a menor valor.
# Revisión iterativa conforme cambian las necesidades del negocio.

== Ejemplo práctico ==
Un equipo de desarrollo prioriza las siguientes funcionalidades de una aplicación de comercio electrónico:

{| class="wikitable"
! Historia !! Valor para el negocio !! Urgencia temporal !! Oportunidad de mercado !! CoD !! Tamaño del Trabajo !! WSJF
|-
| Implementar pago con criptomonedas || 8 || 5 || 6 || 19 || 5 || 3.8
|-
| Mejorar velocidad de carga || 7 || 8 || 7 || 22 || 7 || 3.1
|-
| Añadir reseñas y calificaciones || 5 || 6 || 5 || 16 || 4 || 4.0
|-
| Integrar chatbot de atención al cliente || 6 || 7 || 8 || 21 || 6 || 3.5
|}

Tras el cálculo, el equipo decide priorizar la historia de usuario con mayor WSJF, asegurando la entrega más eficiente del valor al negocio.

== Referencias ==
* SAFe Framework. "Weighted Shortest Job First (WSJF)". Scaled Agile Inc.
* Reinertsen, Donald G. ''The Principles of Product Development Flow: Second Generation Lean Product Development''. Celeritas Publishing, 2009.

[[Category:Glosario de términos]]

MoSCoW

2025-01-29T11:56:55Z

Smanager: Smanager moved page MoScoW to MoSCoW without leaving a redirect

MoSCoW es un enfoque empleado para determinar la prioridad de los requisitos (funcionalidades, [[epic|epics]] o [[historia de usuario|historias de usuario]]).
==Origen y evolución==
El enfoque MoSCoW se originó en el contexto de la metodología DSDM (Desarrollo de Sistemas Dinámicos y Adaptativos). DSDM es un enfoque ágil que promueve la entrega rápida y flexible de proyectos, y MoSCoW se convirtió en una herramienta esencial para la priorización de requisitos en esta metodología.

A lo largo del tiempo, MoSCoW se ha popularizado y ha sido adoptado en diversos marcos de trabajo y metodologías de desarrollo de software.

==Descripción==
Proporciona una estructura clara para clasificar los requisitos en cuatro categorías según su importancia y necesidad, lo que ayuda a los equipos de desarrollo y a los interesados a tomar decisiones informadas sobre qué funcionalidades o características implementar primero y cuáles pueden posponerse o incluso descartarse.

El nombre "MoSCoW" es un acrónimo que representa cuatro niveles de prioridad:
#''Must have'' (es necesario).
#''Should have'' (es recomendable).
#''Could have'' (podría implementares).
#''Won't have'' (no lo queremos... quizá en un futuro).

==Objetivos==
*Priorizar de manera efectiva los requisitos de un proyecto para garantizar que los elementos más críticos se aborden primero.
*Ayudar a los equipos de desarrollo y a los interesados a tomar decisiones informadas sobre la asignación de recursos y el cronograma del proyecto.
*Mejorar la satisfacción del cliente al enfocarse en la entrega de funcionalidades esenciales y valiosas de manera temprana.
*Facilitar la gestión de cambios al permitir una comprensión clara de las implicaciones de agregar o modificar requisitos en diferentes etapas del proyecto.
==Cuatro niveles de prioridad==
===''Must have'' (es necesario)===
Son aquellos que son esenciales para el éxito del proyecto. Son funcionalidades, características o elementos que deben implementarse en la primera fase del desarrollo, y su ausencia podría comprometer la utilidad del producto o servicio. Son requisitos no negociables y deben abordarse con la máxima prioridad.
===''Should have'' (es recomendable)===
Son requisitos importantes, pero no críticos para el funcionamiento básico del producto. Se espera que estos requisitos se implementen después de los "Must have". Su incorporación mejora la calidad o la usabilidad del producto, pero el proyecto podría avanzar sin ellos si es necesario.
===''Could have'' (podría implementarse)===
Son requisitos opcionales y se consideran deseables, pero no son esenciales para la entrega inicial. Estos requisitos se abordan si hay tiempo y recursos disponibles después de satisfacer los requisitos "Must have" y "Should have". Su inclusión puede aumentar la satisfacción del usuario o brindar funcionalidades adicionales.
===''Won't have'' (no lo queremos... quizá en un futuro)===
Son aquellos que se han decidido deliberadamente no incluir en la versión actual del producto. Esto puede deberse a limitaciones de tiempo, recursos o a la falta de relevancia en el contexto actual del proyecto. Estos requisitos se pueden reconsiderar en futuras iteraciones o versiones, pero no son parte de la entrega actual.
==Método de aplicación==
#'''Identificación de requisitos:''' enumerar todos los requisitos, funcionalidades o características que se consideran para el proyecto.
#'''Clasificación de requisitos:''' cada requisito se clasifica en una de las cuatro categorías: ''Must have, Should have, Could have'' o ''Won't have''.
#'''Discusión y consenso:''' el equipo de proyecto y los interesados discuten y acuerdan la clasificación de cada requisito. Es fundamental obtener un consenso para evitar malentendidos posteriores.
#'''Priorización de actividades:''' basándose en la clasificación MoSCoW, se planifican las actividades del proyecto, dando prioridad a los requisitos ''Must have'' y ''Should have'' en las etapas iniciales.
#'''Seguimiento y ajuste:''' a medida que avanza el proyecto, se monitorea la implementación de los requisitos según su prioridad. Se pueden realizar ajustes a medida que se obtiene más información o surgen cambios en las necesidades del cliente.
==Véase también==
*[[Requisitos ágiles]].
*[[Historia de usuario]].
*[[Epic]].
[[Category:Glosario de términos]]

Kano

2025-01-29T11:21:44Z

Smanager:

= Método Kano =

== Introducción ==
El método Kano es una técnica para identificar y clasificar las necesidades del cliente en función con el impacto en la satisfacción del usuario.

== Componentes del Modelo Kano ==
El modelo Kano se representa gráficamente en un sistema de coordenadas que muestra cómo las diferentes características del producto influyen en la satisfacción del cliente. Las categorías en las que clasifica el modelo las características del producto son:

=== Necesidades Básicas (Imprescindibles) ===
* Estas son expectativas mínimas que los usuarios dan por sentadas. Su ausencia genera insatisfacción significativa, pero su implementación completa no incrementa notablemente la satisfacción.
* Ejemplo: Seguridad en el acceso a un sistema.

=== Necesidades de Desempeño (Unidimensionales) ===
* La satisfacción del usuario aumenta proporcionalmente con el nivel de implementación de estas características. Estas necesidades suelen ser expresadas claramente por los usuarios.
* Ejemplo: Velocidad de respuesta de una aplicación.

=== Excitadores (Atractivos) ===
* Estas características no son esperadas por el usuario, pero su presencia genera un alto nivel de satisfacción o "deleite". Su ausencia no provoca insatisfacción.
* Ejemplo: Funcionalidades innovadoras o un diseño atractivo inesperado.

=== Indiferencia ===
* Estas características no afectan ni la satisfacción ni la insatisfacción del usuario.
* Ejemplo: Un cambio estético menor en la interfaz sin impacto funcional.

=== Insatisfactorias o Inversas ===
* Estas características generan insatisfacción si están presentes y satisfacción si se eliminan. Es importante identificarlas para evitar que afecten negativamente la experiencia del usuario.
* Ejemplo: Publicidad intrusiva dentro de una aplicación.

== Representación Gráfica ==
El diagrama adjunto muestra cómo se distribuyen estas categorías en relación con los niveles de implementación y el impacto en la satisfacción del cliente. Las curvas ilustran claramente las diferencias entre necesidades básicas, necesidades de desempeño, excitadores y la zona de indiferencia.

[[File:kano.png|center|600px]]

== Uso del Modelo Kano en proyectos ágiles ==
El método Kano es especialmente útil para priorizar la [[pila del producto]], ayudando a los product owners a tomar decisiones estratégicas sobre qué [[historia de usuario|historias de usuario]] desarrollar primero. Su uso mejora la asignación de recursos y la experiencia de usuario.

=== Pasos para aplicar el Modelo Kano ===
# '''Identificar características:''' Recopilar requisitos de los usuarios mediante entrevistas o encuestas.
# '''Clasificar necesidades:''' Utilizar cuestionarios diseñados según el modelo Kano para categorizar las características.
# '''Priorización:''' Enfocar el desarrollo en excitadores y necesidades de desempeño antes de mejorar características básicas.
# '''Iterar:''' Evaluar regularmente las necesidades según la retroalimentación del cliente.

== Herramienta en Línea ==
Para facilitar la implementación del modelo, puedes acceder a una herramienta en línea disponible en [https://scrummanager.com/resources/modelo-kano.html este enlace].

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

File:Kano.png

2025-01-29T11:20:30Z

Smanager:

Kano

2025-01-29T11:13:55Z

Smanager:

= Método Kano =

== Introducción ==
El método Kano es una técnica para identificar y clasificar las necesidades del cliente en función con el impacto en la satisfacción del usuario.

== Componentes del Modelo Kano ==
El modelo Kano se representa gráficamente en un sistema de coordenadas que muestra cómo las diferentes características del producto influyen en la satisfacción del cliente. Las categorías en las que clasifica el modelo las características del producto son:

=== Necesidades Básicas (Imprescindibles) ===
* Estas son expectativas mínimas que los usuarios dan por sentadas. Su ausencia genera insatisfacción significativa, pero su implementación completa no incrementa notablemente la satisfacción.
* Ejemplo: Seguridad en el acceso a un sistema.

=== Necesidades de Desempeño (Unidimensionales) ===
* La satisfacción del usuario aumenta proporcionalmente con el nivel de implementación de estas características. Estas necesidades suelen ser expresadas claramente por los usuarios.
* Ejemplo: Velocidad de respuesta de una aplicación.

=== Excitadores (Atractivos) ===
* Estas características no son esperadas por el usuario, pero su presencia genera un alto nivel de satisfacción o "deleite". Su ausencia no provoca insatisfacción.
* Ejemplo: Funcionalidades innovadoras o un diseño atractivo inesperado.

=== Indiferencia ===
* Estas características no afectan ni la satisfacción ni la insatisfacción del usuario.
* Ejemplo: Un cambio estético menor en la interfaz sin impacto funcional.

=== Insatisfactorias o Inversas ===
* Estas características generan insatisfacción si están presentes y satisfacción si se eliminan. Es importante identificarlas para evitar que afecten negativamente la experiencia del usuario.
* Ejemplo: Publicidad intrusiva dentro de una aplicación.

== Representación Gráfica ==
El diagrama adjunto muestra cómo se distribuyen estas categorías en relación con los niveles de implementación y el impacto en la satisfacción del cliente. Las curvas ilustran claramente las diferencias entre necesidades básicas, necesidades de desempeño, excitadores y la zona de indiferencia.

[[File:Modelo kano.png|center|600px]]

== Uso del Modelo Kano en proyectos ágiles ==
El método Kano es especialmente útil para priorizar la [[pila del producto]], ayudando a los product owners a tomar decisiones estratégicas sobre qué [[historia de usuario|historias de usuario]] desarrollar primero. Su uso mejora la asignación de recursos y la experiencia de usuario.

=== Pasos para aplicar el Modelo Kano ===
# '''Identificar características:''' Recopilar requisitos de los usuarios mediante entrevistas o encuestas.
# '''Clasificar necesidades:''' Utilizar cuestionarios diseñados según el modelo Kano para categorizar las características.
# '''Priorización:''' Enfocar el desarrollo en excitadores y necesidades de desempeño antes de mejorar características básicas.
# '''Iterar:''' Evaluar regularmente las necesidades según la retroalimentación del cliente.

== Herramienta en Línea ==
Para facilitar la implementación del modelo, puedes acceder a una herramienta en línea disponible en [https://scrummanager.com/resources/modelo-kano.html este enlace].

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

Backlog

2025-01-29T10:42:58Z

Smanager: Redirected page to Pila del producto

#REDIRECT [[Pila del producto]]

Kano

2025-01-29T10:38:25Z

Smanager:

= Método Kano =

== Introducción ==
El método Kano es una técnica para identificar y clasificar las necesidades del cliente en función con el impacto en la satisfacción del usuario.

== Componentes del Modelo Kano ==
El modelo Kano se representa gráficamente en un sistema de coordenadas que muestra cómo las diferentes características del producto influyen en la satisfacción del cliente. Las categorías en las que clasifica el modelo las características del producto son:

=== Necesidades Básicas ===
* Estas son expectativas mínimas que los usuarios dan por sentadas. Su ausencia genera insatisfacción significativa, pero su implementación completa no incrementa notablemente la satisfacción.
* Ejemplo: Seguridad en el acceso a un sistema.

=== Necesidades de Desempeño ===
* La satisfacción del usuario aumenta proporcionalmente con el nivel de implementación de estas características. Estas necesidades suelen ser expresadas claramente por los usuarios.
* Ejemplo: Velocidad de respuesta de una aplicación.

=== Excitadores ===
* Estas características no son esperadas por el usuario, pero su presencia genera un alto nivel de satisfacción o "deleite". Su ausencia no provoca insatisfacción.
* Ejemplo: Funcionalidades innovadoras o un diseño atractivo inesperado.

=== Indiferencia ===
* Estas características no afectan ni la satisfacción ni la insatisfacción del usuario.
* Ejemplo: Un cambio estético menor en la interfaz sin impacto funcional.

== Representación Gráfica ==
El diagrama adjunto muestra cómo se distribuyen estas categorías en relación con los niveles de implementación y el impacto en la satisfacción del cliente. Las curvas ilustran claramente las diferencias entre necesidades básicas, necesidades de desempeño, excitadores y la zona de indiferencia.

[[File:Modelo kano.png|center|600px]]

== Uso del Modelo Kano en proyectos ágiles ==
El método Kano es especialmente útil para priorizar la [[pila del producto]], ayudando a los product owners a tomar decisiones estratégicas sobre qué [[historia de usuario|historias de usuario]] desarrollar primero. Su uso mejora la asignación de recursos y la experiencia de usuario.

=== Pasos para aplicar el Modelo Kano ===
# '''Identificar características:''' Recopilar requisitos de los usuarios mediante entrevistas o encuestas.
# '''Clasificar necesidades:''' Utilizar cuestionarios diseñados según el modelo Kano para categorizar las características.
# '''Priorización:''' Enfocar el desarrollo en excitadores y necesidades de desempeño antes de mejorar características básicas.
# '''Iterar:''' Evaluar regularmente las necesidades según la retroalimentación del cliente.

== Herramienta en Línea ==
Para facilitar la implementación del modelo, puedes acceder a una herramienta en línea disponible en [https://scrummanager.com/resources/modelo-kano.html este enlace].

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

File:Modelo kano.png

2025-01-29T10:23:45Z

Smanager:

Kano

2025-01-29T08:33:15Z

Smanager: Created page with "Próximamente"

Próximamente

AgiLevel Canvas

2025-01-11T14:04:46Z

Smanager:

AgiLevel Canvas es una herramienta visual y práctica diseñada por Nicolás Escobar para diagnosticar y representar el grado de agilidad en una organización. Basada en el modelo [[AgiLevel]], evalúa y categoriza el estado actual de la agilidad organizacional considerando tres dimensiones clave: la dimensión operativa, la dimensión organizativa y el soporte que la organización brinda para el desarrollo ágil. Es un recurso fundamental para identificar áreas de mejora y guiar procesos de transformación ágil.
* [[Media:AgiLevel Canvas v1.0.pdf|Descargar AgiLevel Canvas]] 

== Componentes ==
'''Dimensión Operativa''': Evalúa los principios ágiles relacionados con la creación de productos o servicios. Incluye aspectos como:

* Entrega de valor.
* Mejora continua.
* Desarrollo iterativo e incremental.
* Ritmo de trabajo sostenible.
* Atención continua a la excelencia.
* Operativa visible.
* Cadencia y sincronización global.
* Enfoque en las personas sobre los procesos. 

'''Dimensión Organizativa''': Analiza los valores culturales y la estructura de la empresa. Se centra en:

* Asertividad.
* Valoración del talento.
* Claridad.
* Confianza.
* Propósito común.
* Estructura desjerarquizada. 

'''Soporte''': Mide los factores que facilitan o dificultan la adopción de la agilidad, incluyendo:

* Implicación directiva.
* Compatibilidad cultural.
* Recursos disponibles.
* Formación.
* Acompañamiento (coaching). 

[[File:Agilevel canvas.png|center]] 

== Propósito y uso ==
El AgiLevel Canvas es utilizado para:

Presentar una “fotografía” clara del estado de agilidad en una empresa.
* Detectar desafíos, oportunidades y riesgos asociados a la transformación ágil.
* Diseñar planes de mejora adaptados a las necesidades específicas de la organización. 

Gracias a su representación visual, facilita el diálogo entre equipos, directivos y stakeholders, convirtiéndose en un punto de partida para planificar estrategias de escalado ágil.
== Beneficios ==

Ofrece un diagnóstico integral y estructurado.
Identifica áreas críticas de mejora para priorizar esfuerzos.
* Promueve un enfoque iterativo y adaptativo en las transformaciones ágiles.
* Permite visualizar y gestionar riesgos asociados al proceso de cambio. 

== Referencias y recursos ==
AgiLevel es un modelo para la evaluación y mejora de la agilidad organizacional desarrollado por [https://scrummanager.com Scrum Manager®].

AgiLevel Canvas es una herramienta creada por Nicolás Escobar.

Información y recursos sobre AgiLevel, disponible en [https://www.agilevel.com agilevel.com].

AgiLevel Canvas

2025-01-11T08:17:52Z

Smanager: Created page with "AgiLevel Canvas es una herramienta visual y práctica diseñada por Nicolás Escobar para diagnosticar y representar el grado de agilidad en una organización. Basada en el modelo AgiLevel, evalúa y categoriza el estado actual de la agilidad organizacional considerando tres dimensiones clave: la dimensión operativa, la dimensión organizativa y el soporte que la organización brinda para el desarrollo ágil. Es un recurso fundamental para identificar áreas de mejo..."

AgiLevel Canvas es una herramienta visual y práctica diseñada por Nicolás Escobar para diagnosticar y representar el grado de agilidad en una organización. Basada en el modelo [[AgiLevel]], evalúa y categoriza el estado actual de la agilidad organizacional considerando tres dimensiones clave: la dimensión operativa, la dimensión organizativa y el soporte que la organización brinda para el desarrollo ágil. Es un recurso fundamental para identificar áreas de mejora y guiar procesos de transformación ágil.
* [[Media:AgiLevel Canvas v1.0.pdf|Descargar AgiLevel Canvas]] 

== Componentes ==
'''Dimensión Operativa''': Evalúa los principios ágiles relacionados con la creación de productos o servicios. Incluye aspectos como:

* Entrega de valor.
* Mejora continua.
* Desarrollo iterativo e incremental.
* Ritmo de trabajo sostenible.
* Atención continua a la excelencia.
* Operativa visible.
* Cadencia y sincronización global.
* Enfoque en las personas sobre los procesos. 

'''Dimensión Organizativa''': Analiza los valores culturales y la estructura de la empresa. Se centra en:

* Asertividad.
* Valoración del talento.
* Claridad.
* Confianza.
* Propósito común.
* Estructura desjerarquizada. 

'''Soporte''': Mide los factores que facilitan o dificultan la adopción de la agilidad, incluyendo:

* Implicación directiva.
* Compatibilidad cultural.
* Recursos disponibles.
* Formación.
* Acompañamiento (coaching). 

[[File:Agilevel canvas.png|center]] 

== Propósito y uso ==
El AgiLevel Canvas es utilizado para:

Presentar una “fotografía” clara del estado de agilidad en una empresa.
* Detectar desafíos, oportunidades y riesgos asociados a la transformación ágil.
* Diseñar planes de mejora adaptados a las necesidades específicas de la organización. 

Gracias a su representación visual, facilita el diálogo entre equipos, directivos y stakeholders, convirtiéndose en un punto de partida para planificar estrategias de escalado ágil.
== Beneficios ==

Ofrece un diagnóstico integral y estructurado.
Identifica áreas críticas de mejora para priorizar esfuerzos.
* Promueve un enfoque iterativo y adaptativo en las transformaciones ágiles.
* Permite visualizar y gestionar riesgos asociados al proceso de cambio. 

== Referencias y recursos ==
AgiLevel Canvas forma parte del modelo AgiLevel desarrollado por [https://scrummanager.com Scrum Manager®]. Su creador, Nicolás Escobar, lo diseñó como una herramienta no prescriptiva y adaptable a distintos contextos organizacionales. Toda la información y recursos sobre AgiLevel y el Canvas están disponibles en [https://www.agilevel.com agilevel.com] Es especialmente útil para coaches, gestores y directivos interesados en implementar o mejorar estrategias ágiles en sus organizaciones.

File:Agilevel canvas.png

2025-01-11T07:50:57Z

Smanager: Imagen de AgiLevel Canvas

== Summary ==
Imagen de AgiLevel Canvas

File:AgiLevel Canvas v1.0.pdf

2025-01-11T07:47:47Z

Smanager: AgiLevel Canvas

== Summary ==
AgiLevel Canvas

VUCA

2024-01-23T18:11:39Z

Smanager: Created page with "Los entornos V.U.C.A. son contextos caracterizados por la Volatilidad, Incertidumbre, Complejidad y Ambigüedad. ==Origen del término== El término proviene del ámbito militar, y se ha adoptado ampliamente en el mundo de la gestión de proyectos, especialmente en metodologías ágiles. En un entorno VUCA, los cambios ocurren rápidamente y a menudo de manera impredecible, la información disponible puede ser insuficiente o contradictoria, y las situaciones pueden ser..."

Los entornos V.U.C.A. son contextos caracterizados por la Volatilidad, Incertidumbre, Complejidad y Ambigüedad.

==Origen del término==
El término proviene del ámbito militar, y se ha adoptado ampliamente en el mundo de la gestión de proyectos, especialmente en metodologías ágiles. En un entorno VUCA, los cambios ocurren rápidamente y a menudo de manera impredecible, la información disponible puede ser insuficiente o contradictoria, y las situaciones pueden ser complejas debido a la interconexión de múltiples factores. La gestión ágil de proyectos en entornos VUCA implica adaptabilidad, flexibilidad y un enfoque colaborativo para navegar eficazmente en estos escenarios cambiantes y a menudo desafiantes.

==Características==

===Volatilidad===
La volatilidad en los entornos VUCA se refiere a la naturaleza rápida y en constante cambio del mundo moderno. Esto implica que los planes y estrategias pueden quedar obsoletos rápidamente, lo que requiere una capacidad de adaptación continua. En gestión de proyectos, esto significa estar preparado para cambios repentinos y ser capaz de ajustar rápidamente los recursos y las direcciones estratégicas.

===Incertidumbre===
La incertidumbre en estos entornos significa que la información disponible es a menudo incompleta o poco clara, lo que hace difícil predecir futuros acontecimientos y tendencias. Esto desafía a los líderes y equipos a desarrollar habilidades para manejar lo desconocido, tomando decisiones informadas con información limitada y manteniendo flexibilidad en sus planes.

===Complejidad===
La complejidad se refiere a la interconexión de múltiples factores, que pueden ser tanto internos como externos a la organización. Esto crea situaciones donde las soluciones simples rara vez son efectivas. En entornos VUCA, se requiere una comprensión profunda de estas interconexiones y cómo pueden afectar los proyectos y decisiones.

===Ambigüedad===
La ambigüedad se manifiesta en la falta de claridad y en la posibilidad de múltiples interpretaciones de la misma situación. Esto puede llevar a confusiones y malentendidos en la toma de decisiones. En la gestión de proyectos, esto significa fomentar una comunicación clara y efectiva, y estar preparado para ajustar las estrategias conforme se recibe nueva información.

Paradigmas culturales

2024-01-15T12:10:42Z

Smanager:

Frederic Laloux expone en su libro ''Reinventar las organizaciones'' varios '''modelos de organización que la humanidad ha ido creando''', en orden cronológico.

Cada uno viene '''codificado con un color:''' desde los prehistóricos «infrarrojo» y «magenta» hasta los 5 posteriores que centran nuestra atención, porque son los que modelan las organizaciones actuales; los denominados «rojo», «ámbar», «naranja», «verde» y «esmeralda» o «teal».

El modelo de Laloux se inspira en el código de 8 estados desarrollado por Don Beck basado a su vez en la teorı́a de la Dinámica Espiral (''Spiral Dynamics'') de Clare W. Graves.

 
[[File:Evolucion paradigmas laloux.png|x300px|center|link=]]


__TOC__

==Tipos de paradigmas==

===Paradigma rojo o impulsivo===

Hace unos 10.000 años surgieron las primeras formas de organización, con un paradigma cultural al que nos podemos referir como "impulsivo" o "rojo".
====Características====
*'''La fuerza es lo más valioso.''' Los poderosos exigen y los menos poderosos se someten a cambio de seguridad.
*Presentes en '''sociedades tribales y sectores marginales''' de la sociedad actual (pandillas callejeras o mafias).
*La autoridad se mantiene demostrando '''poder absoluto'''.
*Las '''relaciones emocionales''' entre las personas son muy '''toscas''' y la '''empatía escasa o nula'''.
*Produce organizaciones muy reactivas a nuevas oportunidades y amenazas, pero al mismo tiempo muy '''cortoplacistas'''. Es decir, se adaptan bien en entornos caótico-catastróficos, pero no resultan útiles para desarrollar resultados complejos en entornos estables.

===Paradigma ámbar o conformista===
Hace unos 5.000 años comenzamos a comprender la causalidad y hacer planificaciones a futuro. Surge la agricultura, que requiere anticipación y proceso: recoger y guardar las semillas para garantizar la próxima cosecha. Los cacicazgos van dando paso a una sociedad de clases sociales, rígidamente estratificada en dirigentes, funcionarios, sacerdotes, guerreros y artesanos.
====Características====
*Son apropiadas para contextos estables en los que se puede '''planificar''' el futuro '''sobre la base de la experiencia pasada'''.</li>
*Pueden planificar y poner en marcha '''proyectos a medio y largo plazo''', como edificar catedrales o crear extensos y complejos circuitos comerciales.
*'''Todo gira en torno al inmovilismo:''' no se acepta el cambio porque el mundo es inmutable y solo hay una forma correcta de hacer las cosas: como se hizo en el pasado. Dicho de otro modo, lo que funcionó bien en el pasado también lo hará en el futuro.
*Se da peso a valores como '''el orden y la predictibilidad''', lo que genera una falsa sensación de seguridad.
*El '''poder''' se encuentra '''jerarquizado''' en organigramas piramidales inamovibles con estratos de jefes y subordinados.
*Los estratos y castas con títulos formales fomenta la '''adopción de máscaras sociales'''.
*'''Se crean rangos y uniformes para institucionalizar y marcar las diferentes funciones.''' La imagen y vestimenta de las personas refleja su identidad funcional dentro de la organización, y en la misma línea las personas adoptan y muestran comportamientos adecuados a su casta.

===Paradigma logro o naranja===
El paradigma naranja surgió cuando empezamos a considerar que no estábamos en un universo fijo ordenado por leyes inmutables, sino en un sistema que funciona como un mecanismo complejo, cuya articulación interna es posible estudiar y comprender.

Al entender mejor la forma en la que operan las cosas, se pueden alcanzar más logros.

Este paradigma ha dado como frutos la investigación científica, la innovación y el emprendimiento. Es el más extendido actualmente entre empresarios y políticos. En los dos últimos siglos ha alargado la esperanza de vida y producido niveles de prosperidad hasta ahora desconocidos.
====Características====
*Este tipo de organizaciones han aportado '''tres avances importantes:''' la innovación, la rendición de cuentas y la meritocracia.
*A estos avances se suman '''aspectos más negativos''', tales como: codicia corporativa, cortoplacismo estratégico y político, sobre-consumo, endeudamiento y sobreexplotación de recursos.

===Paradigma pluralista o verde===
El paradigma pluralista (verde) '''surge como antítesis a las sombras del paradigma del logro (naranja):''' desigualdad social, obsesión materialista y pérdida del sentido de comunidad.

Actualmente el paradigma naranja es el que predomina en la política y las empresas. El verde se está abriendo camino en organizaciones sin ánimo de lucro, entre activistas, trabajadores sociales y en general en organizaciones de personas que operan valorando las relaciones por encima de los resultados.
====Características====
*Aporta '''alternativas''' a los modelos organizacionales naranjas como son la descentralización, el empoderamiento, la cultura impulsada por valores y el foco en múltiples grupos de interés: además de los accionistas también proveedores, clientes, comunidades locales, medio ambiente, etcétera.
*En su inicio lo relevante de este paradigma fue su '''carácter rompedor'''. En la práctica, autores como Laloux consideran que no tienen éxito debido a las dificultades que existen al tratar de lograr el consenso entre un grupo grande de personas. Es fácil que se llegue a un punto muerto donde se intenta volver a los juegos de poder para volver a poner en marcha las cosas.
<blockquote>''A posteriori, sabemos que estas formas extremas de organización igualitaria no han tenido éxito ni a escala significativa ni por un lapso significativo de tiempo. Lograr el consenso entre un grupo grande de personas es intrínsecamente difícil. Muchas veces la iniciativa termina en extenuantes sesiones de conversación y un eventual punto muerto. A modo de respuesta se cuelan los juegos de poder en un intento de que las cosas vuelvan a moverse.''

Laloux, ''Reinventar las organizaciones'' (2016)</blockquote>
*Este tipo de paradigmas suelen usar marcos de '''agilidad técnica como scrum''' o de '''agilidad organizativa como la gobernanza dinámica o sociocracia'''. En algunos casos también se emplean para conducir la evolución hacia el paradigma ''teal''.

===Paradigma evolutivo o ''teal''===
La evolución a una cultura ''teal'' (también llamada "esmeralda") implica la '''desidentificación de nuestro propio ego'''. El éxito, el reconocimiento o la riqueza son trampas para el ego. En la cultura teal el éxito o el reconocimiento no son el objetivo. El objetivo es una vida bien vivida y es posible que la consecuencia de ello sea éxito, reconocimiento, riqueza y amor.
====Características====
Las tres aportaciones de las organizaciones evolutivas – ''teal'' son:
*'''Autogestión:''' la cultura verde aporta empoderamiento, pero el empoderamiento implica que un gestor de rango superior delega parte de su poder, mientras que para ''teal'' la autoridad no forma parte de un sistema de suma cero. En las estructuras de las organizaciones ''teal'' no hay miembros con poder de decisión y miembros ejecutores. Por naturaleza, y no por delegación, '''todos tienen poder de decisión''' y la estructura de la organización incluye procesos holocráticos para la regulación del flujo de información y decisiones.
<blockquote>''Cada decisión que se toma en la sede central le quita responsabilidad a la gente de otras partes de la organización y reduce el número de personas que sienten que están haciendo una contribución real a la organización.''

Dennis Bakke</blockquote>
*'''Plenitud:''' en las organizaciones ''teal'' no hay ascensos por los que pelear ni jefes a los que contentar. Las personas se muestran de forma plena, siendo ellos mismos. Son organizaciones que invierten mucho tiempo en la selección de personal, informando a los candidatos de los valores y formas de trabajo para que puedan decidir si quieren ser parte de la organización o no. En este sentido es conocido el caso de Zappos.com, que ofrece a los recién incorporados un cheque de 3.000 dólares si se arrepienten durante el periodo de prueba y prefieren abandonar la empresa.
*'''Propósito evolutivo:''' para las organizaciones ''teal'', el beneficio es un subproducto de un trabajo bien hecho. La finalidad de la organización no es el valor para los accionistas ni maximizar las ganancias, sino su propósito evolutivo. Brian Robertson, fundador de Holacracy emplea la metáfora padre-hĳo para explicar el concepto:
<blockquote>''¿Cuál es la identidad de la organización? ¿Y qué es lo que desea? [...] La metáfora es como el viaje padre-hĳo: reconocemos que nuestro hĳo tiene su propia identidad camino y propósito. Y si realmente me entusiasma que llegue a ser médico, no lo programo. Si lo hago, tiene lugar un proceso dañino y codependiente. [...] Pero la clave tiene que ver con separar identidades y descubrir cuál es la vocación de la organización. No para qué queremos usar la organización en tanto que propietarios, sino más bien ¿cuál es el potencial creativo de esta vida, de este sistema viviente?''</blockquote>

 
<youtube>https://www.youtube.com/watch?v=_-BtfKHASsY</youtube>


==Referencias==
*1Laloux, Frederic (2016): ''Reinventar las organizaciones'', ARPA EDITORES.
*[https://www.scrummanager.com/website/c/info/docs-media.php Scrum Manager web: Libro ''Scrum Level'' y ''Guía para evaluadores''].
*[https://www.youtube.com/watch?v=AYoh3SJjkQU&ab%20channel=ScrumManager '''Video-libro''' de Scrum Level disponible en Youtube].

[[Category:Glosario de términos]]

Paradigmas culturales

2024-01-15T12:05:01Z

Smanager:

Frederic Laloux expone en su libro ''Reinventar las organizaciones'' varios '''modelos de organización que la humanidad ha ido creando''', en orden cronológico.

Cada uno viene '''codificado con un color:''' desde los prehistóricos «infrarrojo» y «magenta» hasta los 5 posteriores que centran nuestra atención, porque son los que modelan las organizaciones actuales; los denominados «rojo», «ámbar», «naranja», «verde» y «esmeralda» o «teal».

El modelo de Laloux se inspira en el código de 8 estados desarrollado por Don Beck basado a su vez en la teorı́a de la Dinámica Espiral (''Spiral Dynamics'') de Clare W. Graves.

 
[[File:Evolucion paradigmas laloux.png|x300px|center|link=]]


__TOC__

==Tipos de paradigmas==

===Paradigma rojo o impulsivo===

Hace unos 10.000 años surgieron las primeras formas de organización, con un paradigma cultural al que nos podemos referir como "impulsivo" o "rojo".
====Características====
*'''La fuerza es lo más valioso.''' Los poderosos exigen y los menos poderosos se someten a cambio de seguridad.
*Presentes en '''sociedades tribales y sectores marginales''' de la sociedad actual (pandillas callejeras o mafias).
*La autoridad se mantiene demostrando '''poder absoluto'''.
*Las '''relaciones emocionales''' entre las personas son muy '''toscas''' y la '''empatía escasa o nula'''.
*Produce organizaciones muy reactivas a nuevas oportunidades y amenazas, pero al mismo tiempo muy '''cortoplacistas'''. Es decir, se adaptan bien en entornos caótico-catastróficos, pero no resultan útiles para desarrollar resultados complejos en entornos estables.

===Paradigma ámbar o conformista===
Hace unos 5.000 años comenzamos a comprender la causalidad y hacer planificaciones a futuro. Surge la agricultura, que requiere anticipación y proceso: recoger y guardar las semillas para garantizar la próxima cosecha. Los cacicazgos van dando paso a una sociedad de clases sociales, rígidamente estratificada en dirigentes, funcionarios, sacerdotes, guerreros y artesanos.
====Características====
*Son apropiadas para contextos estables en los que se puede '''planificar''' el futuro '''sobre la base de la experiencia pasada'''.</li>
*Pueden planificar y poner en marcha '''proyectos a medio y largo plazo''', como edificar catedrales o crear extensos y complejos circuitos comerciales.
*'''Todo gira en torno al inmovilismo:''' no se acepta el cambio porque el mundo es inmutable y solo hay una forma correcta de hacer las cosas: como se hizo en el pasado. Dicho de otro modo, lo que funcionó bien en el pasado también lo hará en el futuro.
*Se da peso a valores como '''el orden y la predictibilidad''', lo que genera una falsa sensación de seguridad.
*El '''poder''' se encuentra '''jerarquizado''' en organigramas piramidales inamovibles con estratos de jefes y subordinados.
*Los estratos y castas con títulos formales fomenta la '''adopción de máscaras sociales'''.
*'''Se crean rangos y uniformes para institucionalizar y marcar las diferentes funciones.''' La imagen y vestimenta de las personas refleja su identidad funcional dentro de la organización, y en la misma línea las personas adoptan y muestran comportamientos adecuados a su casta.

===Paradigma logro o naranja===
El paradigma naranja surgió cuando empezamos a considerar que no estábamos en un universo fijo ordenado por leyes inmutables, sino en un sistema que funciona como un mecanismo complejo, cuya articulación interna es posible estudiar y comprender.

Al entender mejor la forma en la que operan las cosas, se pueden alcanzar más logros.

Este paradigma ha dado como frutos la investigación científica, la innovación y el emprendimiento. Es el más extendido actualmente entre empresarios y políticos. En los dos últimos siglos ha alargado la esperanza de vida y producido niveles de prosperidad hasta ahora desconocidos.
====Características====
*Este tipo de organizaciones han aportado '''tres avances importantes:''' la innovación, la rendición de cuentas y la meritocracia.
*A estos avances se suman '''aspectos más negativos''', tales como: codicia corporativa, cortoplacismo estratégico y político, sobre-consumo, endeudamiento y sobreexplotación de recursos.

===Paradigma pluralista o verde===
El paradigma pluralista (verde) '''surge como antítesis a las sombras del paradigma del logro (naranja):''' desigualdad social, obsesión materialista y pérdida del sentido de comunidad.

Actualmente el paradigma naranja es el que predomina en la política y las empresas. El verde se está abriendo camino en organizaciones sin ánimo de lucro, entre activistas, trabajadores sociales y en general en organizaciones de personas que operan valorando las relaciones por encima de los resultados.
====Características====
*Aporta '''alternativas''' a los modelos organizacionales naranjas como son la descentralización, el empoderamiento, la cultura impulsada por valores y el foco en múltiples grupos de interés: además de los accionistas también proveedores, clientes, comunidades locales, medio ambiente, etcétera.
*En su inicio lo relevante de este paradigma fue su '''carácter rompedor'''. En la práctica, autores como Laloux consideran que no tienen éxito debido a las dificultades que existen al tratar de lograr el consenso entre un grupo grande de personas. Es fácil que se llegue a un punto muerto donde se intenta volver a los juegos de poder para volver a poner en marcha las cosas.
<blockquote>''A posteriori, sabemos que estas formas extremas de organización igualitaria no han tenido éxito ni a escala significativa ni por un lapso significativo de tiempo. Lograr el consenso entre un grupo grande de personas es intrínsecamente difícil. Muchas veces la iniciativa termina en extenuantes sesiones de conversación y un eventual punto muerto. A modo de respuesta se cuelan los juegos de poder en un intento de que las cosas vuelvan a moverse.''

Laloux, ''Reinventar las organizaciones'' (2016)</blockquote>
*Este tipo de paradigmas suelen usar marcos de '''agilidad técnica como scrum''' o de '''agilidad organizativa como la gobernanza dinámica o sociocracia'''. En algunos casos también se emplean para conducir la evolución hacia el paradigma ''teal''.

===Paradigma evolutivo o ''teal''===
La evolución a una cultura ''teal'' (también llamada "esmeralda") implica la '''desidentificación de nuestro propio ego'''. El éxito, el reconocimiento o la riqueza son trampas para el ego. En la cultura teal el éxito o el reconocimiento no son el objetivo. El objetivo es una vida bien vivida y es posible que la consecuencia de ello sea éxito, reconocimiento, riqueza y amor.
====Características====
Las tres aportaciones de las organizaciones evolutivas – ''teal'' son:
*'''Autogestión:''' la cultura verde aporta empoderamiento, pero el empoderamiento implica que un gestor de rango superior delega parte de su poder, mientras que para ''teal'' la autoridad no forma parte de un sistema de suma cero. En las estructuras de las organizaciones ''teal'' no hay miembros con poder de decisión y miembros ejecutores. Por naturaleza, y no por delegación, '''todos tienen poder de decisión''' y la estructura de la organización incluye procesos holocráticos para la regulación del flujo de información y decisiones.
<blockquote>''Cada decisión que se toma en la sede central le quita responsabilidad a la gente de otras partes de la organización y reduce el número de personas que sienten que están haciendo una contribución real a la organización.''

Dennis Bakke</blockquote>
*'''Plenitud:''' en las organizaciones ''teal'' no hay ascensos por los que pelear ni jefes a los que contentar. Las personas se muestran de forma plena, siendo ellos mismos. Son organizaciones que invierten mucho tiempo en la selección de personal, informando a los candidatos de los valores y formas de trabajo para que puedan decidir si quieren ser parte de la organización o no. En este sentido es conocido el caso de Zappos.com, que ofrece a los recién incorporados un cheque de 3.000 dólares si se arrepienten durante el periodo de prueba y prefieren abandonar la empresa.
*'''Propósito evolutivo:''' para las organizaciones ''teal'', el beneficio es un subproducto de un trabajo bien hecho. La finalidad de la organización no es el valor para los accionistas ni maximizar las ganancias, sino su propósito evolutivo. Brian Robertson, fundador de Holacracy emplea la metáfora padre-hĳo para explicar el concepto:
<blockquote>''¿Cuál es la identidad de la organización? ¿Y qué es lo que desea? [...] La metáfora es como el viaje padre-hĳo: reconocemos que nuestro hĳo tiene su propia identidad camino y propósito. Y si realmente me entusiasma que llegue a ser médico, no lo programo. Si lo hago, tiene lugar un proceso dañino y codependiente. [...] Pero la clave tiene que ver con separar identidades y descubrir cuál es la vocación de la organización. No para qué queremos usar la organización en tanto que propietarios, sino más bien ¿cuál es el potencial creativo de esta vida, de este sistema viviente?''</blockquote>

 
<embedvideo service="youtube">https://www.youtube.com/watch?v=_-BtfKHASsY</embedvideo>


==Referencias==
*1Laloux, Frederic (2016): ''Reinventar las organizaciones'', ARPA EDITORES.
*[https://www.scrummanager.com/website/c/info/docs-media.php Scrum Manager web: Libro ''Scrum Level'' y ''Guía para evaluadores''].
*[https://www.youtube.com/watch?v=AYoh3SJjkQU&ab%20channel=ScrumManager '''Video-libro''' de Scrum Level disponible en Youtube].

[[Category:Glosario de términos]]

Paradigmas culturales

2024-01-15T12:03:19Z

Smanager:

Frederic Laloux expone en su libro ''Reinventar las organizaciones'' varios '''modelos de organización que la humanidad ha ido creando''', en orden cronológico.

Cada uno viene '''codificado con un color:''' desde los prehistóricos «infrarrojo» y «magenta» hasta los 5 posteriores que centran nuestra atención, porque son los que modelan las organizaciones actuales; los denominados «rojo», «ámbar», «naranja», «verde» y «esmeralda» o «teal».

El modelo de Laloux se inspira en el código de 8 estados desarrollado por Don Beck basado a su vez en la teorı́a de la Dinámica Espiral (''Spiral Dynamics'') de Clare W. Graves.

 
[[File:Evolucion paradigmas laloux.png|x300px|center|link=]]


__TOC__

==Tipos de paradigmas==

===Paradigma rojo o impulsivo===

Hace unos 10.000 años surgieron las primeras formas de organización, con un paradigma cultural al que nos podemos referir como "impulsivo" o "rojo".
====Características====
*'''La fuerza es lo más valioso.''' Los poderosos exigen y los menos poderosos se someten a cambio de seguridad.
*Presentes en '''sociedades tribales y sectores marginales''' de la sociedad actual (pandillas callejeras o mafias).
*La autoridad se mantiene demostrando '''poder absoluto'''.
*Las '''relaciones emocionales''' entre las personas son muy '''toscas''' y la '''empatía escasa o nula'''.
*Produce organizaciones muy reactivas a nuevas oportunidades y amenazas, pero al mismo tiempo muy '''cortoplacistas'''. Es decir, se adaptan bien en entornos caótico-catastróficos, pero no resultan útiles para desarrollar resultados complejos en entornos estables.

===Paradigma ámbar o conformista===
Hace unos 5.000 años comenzamos a comprender la causalidad y hacer planificaciones a futuro. Surge la agricultura, que requiere anticipación y proceso: recoger y guardar las semillas para garantizar la próxima cosecha. Los cacicazgos van dando paso a una sociedad de clases sociales, rígidamente estratificada en dirigentes, funcionarios, sacerdotes, guerreros y artesanos.
====Características====
*Son apropiadas para contextos estables en los que se puede '''planificar''' el futuro '''sobre la base de la experiencia pasada'''.</li>
*Pueden planificar y poner en marcha '''proyectos a medio y largo plazo''', como edificar catedrales o crear extensos y complejos circuitos comerciales.
*'''Todo gira en torno al inmovilismo:''' no se acepta el cambio porque el mundo es inmutable y solo hay una forma correcta de hacer las cosas: como se hizo en el pasado. Dicho de otro modo, lo que funcionó bien en el pasado también lo hará en el futuro.
*Se da peso a valores como '''el orden y la predictibilidad''', lo que genera una falsa sensación de seguridad.
*El '''poder''' se encuentra '''jerarquizado''' en organigramas piramidales inamovibles con estratos de jefes y subordinados.
*Los estratos y castas con títulos formales fomenta la '''adopción de máscaras sociales'''.
*'''Se crean rangos y uniformes para institucionalizar y marcar las diferentes funciones.''' La imagen y vestimenta de las personas refleja su identidad funcional dentro de la organización, y en la misma línea las personas adoptan y muestran comportamientos adecuados a su casta.

===Paradigma logro o naranja===
El paradigma naranja surgió cuando empezamos a considerar que no estábamos en un universo fijo ordenado por leyes inmutables, sino en un sistema que funciona como un mecanismo complejo, cuya articulación interna es posible estudiar y comprender.

Al entender mejor la forma en la que operan las cosas, se pueden alcanzar más logros.

Este paradigma ha dado como frutos la investigación científica, la innovación y el emprendimiento. Es el más extendido actualmente entre empresarios y políticos. En los dos últimos siglos ha alargado la esperanza de vida y producido niveles de prosperidad hasta ahora desconocidos.
====Características====
*Este tipo de organizaciones han aportado '''tres avances importantes:''' la innovación, la rendición de cuentas y la meritocracia.
*A estos avances se suman '''aspectos más negativos''', tales como: codicia corporativa, cortoplacismo estratégico y político, sobre-consumo, endeudamiento y sobreexplotación de recursos.

===Paradigma pluralista o verde===
El paradigma pluralista (verde) '''surge como antítesis a las sombras del paradigma del logro (naranja):''' desigualdad social, obsesión materialista y pérdida del sentido de comunidad.

Actualmente el paradigma naranja es el que predomina en la política y las empresas. El verde se está abriendo camino en organizaciones sin ánimo de lucro, entre activistas, trabajadores sociales y en general en organizaciones de personas que operan valorando las relaciones por encima de los resultados.
====Características====
*Aporta '''alternativas''' a los modelos organizacionales naranjas como son la descentralización, el empoderamiento, la cultura impulsada por valores y el foco en múltiples grupos de interés: además de los accionistas también proveedores, clientes, comunidades locales, medio ambiente, etcétera.
*En su inicio lo relevante de este paradigma fue su '''carácter rompedor'''. En la práctica, autores como Laloux consideran que no tienen éxito debido a las dificultades que existen al tratar de lograr el consenso entre un grupo grande de personas. Es fácil que se llegue a un punto muerto donde se intenta volver a los juegos de poder para volver a poner en marcha las cosas.
<blockquote>''A posteriori, sabemos que estas formas extremas de organización igualitaria no han tenido éxito ni a escala significativa ni por un lapso significativo de tiempo. Lograr el consenso entre un grupo grande de personas es intrínsecamente difícil. Muchas veces la iniciativa termina en extenuantes sesiones de conversación y un eventual punto muerto. A modo de respuesta se cuelan los juegos de poder en un intento de que las cosas vuelvan a moverse.''

Laloux, ''Reinventar las organizaciones'' (2016)</blockquote>
*Este tipo de paradigmas suelen usar marcos de '''agilidad técnica como scrum''' o de '''agilidad organizativa como la gobernanza dinámica o sociocracia'''. En algunos casos también se emplean para conducir la evolución hacia el paradigma ''teal''.

===Paradigma evolutivo o ''teal''===
La evolución a una cultura ''teal'' (también llamada "esmeralda") implica la '''desidentificación de nuestro propio ego'''. El éxito, el reconocimiento o la riqueza son trampas para el ego. En la cultura teal el éxito o el reconocimiento no son el objetivo. El objetivo es una vida bien vivida y es posible que la consecuencia de ello sea éxito, reconocimiento, riqueza y amor.
====Características====
Las tres aportaciones de las organizaciones evolutivas – ''teal'' son:
*'''Autogestión:''' la cultura verde aporta empoderamiento, pero el empoderamiento implica que un gestor de rango superior delega parte de su poder, mientras que para ''teal'' la autoridad no forma parte de un sistema de suma cero. En las estructuras de las organizaciones ''teal'' no hay miembros con poder de decisión y miembros ejecutores. Por naturaleza, y no por delegación, '''todos tienen poder de decisión''' y la estructura de la organización incluye procesos holocráticos para la regulación del flujo de información y decisiones.
<blockquote>''Cada decisión que se toma en la sede central le quita responsabilidad a la gente de otras partes de la organización y reduce el número de personas que sienten que están haciendo una contribución real a la organización.''

Dennis Bakke</blockquote>
*'''Plenitud:''' en las organizaciones ''teal'' no hay ascensos por los que pelear ni jefes a los que contentar. Las personas se muestran de forma plena, siendo ellos mismos. Son organizaciones que invierten mucho tiempo en la selección de personal, informando a los candidatos de los valores y formas de trabajo para que puedan decidir si quieren ser parte de la organización o no. En este sentido es conocido el caso de Zappos.com, que ofrece a los recién incorporados un cheque de 3.000 dólares si se arrepienten durante el periodo de prueba y prefieren abandonar la empresa.
*'''Propósito evolutivo:''' para las organizaciones ''teal'', el beneficio es un subproducto de un trabajo bien hecho. La finalidad de la organización no es el valor para los accionistas ni maximizar las ganancias, sino su propósito evolutivo. Brian Robertson, fundador de Holacracy emplea la metáfora padre-hĳo para explicar el concepto:
<blockquote>''¿Cuál es la identidad de la organización? ¿Y qué es lo que desea? [...] La metáfora es como el viaje padre-hĳo: reconocemos que nuestro hĳo tiene su propia identidad camino y propósito. Y si realmente me entusiasma que llegue a ser médico, no lo programo. Si lo hago, tiene lugar un proceso dañino y codependiente. [...] Pero la clave tiene que ver con separar identidades y descubrir cuál es la vocación de la organización. No para qué queremos usar la organización en tanto que propietarios, sino más bien ¿cuál es el potencial creativo de esta vida, de este sistema viviente?''</blockquote>

 



==Referencias==
*1Laloux, Frederic (2016): ''Reinventar las organizaciones'', ARPA EDITORES.
*[https://www.scrummanager.com/website/c/info/docs-media.php Scrum Manager web: Libro ''Scrum Level'' y ''Guía para evaluadores''].
*[https://www.youtube.com/watch?v=AYoh3SJjkQU&ab%20channel=ScrumManager '''Video-libro''' de Scrum Level disponible en Youtube].

[[Category:Glosario de términos]]

Paradigmas culturales

2024-01-15T12:02:36Z

Smanager:

Frederic Laloux expone en su libro ''Reinventar las organizaciones'' varios '''modelos de organización que la humanidad ha ido creando''', en orden cronológico.

Cada uno viene '''codificado con un color:''' desde los prehistóricos «infrarrojo» y «magenta» hasta los 5 posteriores que centran nuestra atención, porque son los que modelan las organizaciones actuales; los denominados «rojo», «ámbar», «naranja», «verde» y «esmeralda» o «teal».

El modelo de Laloux se inspira en el código de 8 estados desarrollado por Don Beck basado a su vez en la teorı́a de la Dinámica Espiral (''Spiral Dynamics'') de Clare W. Graves.

 
[[File:Evolucion paradigmas laloux.png|x300px|center|link=]]


__TOC__

==Tipos de paradigmas==

===Paradigma rojo o impulsivo===

Hace unos 10.000 años surgieron las primeras formas de organización, con un paradigma cultural al que nos podemos referir como "impulsivo" o "rojo".
====Características====
*'''La fuerza es lo más valioso.''' Los poderosos exigen y los menos poderosos se someten a cambio de seguridad.
*Presentes en '''sociedades tribales y sectores marginales''' de la sociedad actual (pandillas callejeras o mafias).
*La autoridad se mantiene demostrando '''poder absoluto'''.
*Las '''relaciones emocionales''' entre las personas son muy '''toscas''' y la '''empatía escasa o nula'''.
*Produce organizaciones muy reactivas a nuevas oportunidades y amenazas, pero al mismo tiempo muy '''cortoplacistas'''. Es decir, se adaptan bien en entornos caótico-catastróficos, pero no resultan útiles para desarrollar resultados complejos en entornos estables.

===Paradigma ámbar o conformista===
Hace unos 5.000 años comenzamos a comprender la causalidad y hacer planificaciones a futuro. Surge la agricultura, que requiere anticipación y proceso: recoger y guardar las semillas para garantizar la próxima cosecha. Los cacicazgos van dando paso a una sociedad de clases sociales, rígidamente estratificada en dirigentes, funcionarios, sacerdotes, guerreros y artesanos.
====Características====
*Son apropiadas para contextos estables en los que se puede '''planificar''' el futuro '''sobre la base de la experiencia pasada'''.</li>
*Pueden planificar y poner en marcha '''proyectos a medio y largo plazo''', como edificar catedrales o crear extensos y complejos circuitos comerciales.
*'''Todo gira en torno al inmovilismo:''' no se acepta el cambio porque el mundo es inmutable y solo hay una forma correcta de hacer las cosas: como se hizo en el pasado. Dicho de otro modo, lo que funcionó bien en el pasado también lo hará en el futuro.
*Se da peso a valores como '''el orden y la predictibilidad''', lo que genera una falsa sensación de seguridad.
*El '''poder''' se encuentra '''jerarquizado''' en organigramas piramidales inamovibles con estratos de jefes y subordinados.
*Los estratos y castas con títulos formales fomenta la '''adopción de máscaras sociales'''.
*'''Se crean rangos y uniformes para institucionalizar y marcar las diferentes funciones.''' La imagen y vestimenta de las personas refleja su identidad funcional dentro de la organización, y en la misma línea las personas adoptan y muestran comportamientos adecuados a su casta.

===Paradigma logro o naranja===
El paradigma naranja surgió cuando empezamos a considerar que no estábamos en un universo fijo ordenado por leyes inmutables, sino en un sistema que funciona como un mecanismo complejo, cuya articulación interna es posible estudiar y comprender.

Al entender mejor la forma en la que operan las cosas, se pueden alcanzar más logros.

Este paradigma ha dado como frutos la investigación científica, la innovación y el emprendimiento. Es el más extendido actualmente entre empresarios y políticos. En los dos últimos siglos ha alargado la esperanza de vida y producido niveles de prosperidad hasta ahora desconocidos.
====Características====
*Este tipo de organizaciones han aportado '''tres avances importantes:''' la innovación, la rendición de cuentas y la meritocracia.
*A estos avances se suman '''aspectos más negativos''', tales como: codicia corporativa, cortoplacismo estratégico y político, sobre-consumo, endeudamiento y sobreexplotación de recursos.

===Paradigma pluralista o verde===
El paradigma pluralista (verde) '''surge como antítesis a las sombras del paradigma del logro (naranja):''' desigualdad social, obsesión materialista y pérdida del sentido de comunidad.

Actualmente el paradigma naranja es el que predomina en la política y las empresas. El verde se está abriendo camino en organizaciones sin ánimo de lucro, entre activistas, trabajadores sociales y en general en organizaciones de personas que operan valorando las relaciones por encima de los resultados.
====Características====
*Aporta '''alternativas''' a los modelos organizacionales naranjas como son la descentralización, el empoderamiento, la cultura impulsada por valores y el foco en múltiples grupos de interés: además de los accionistas también proveedores, clientes, comunidades locales, medio ambiente, etcétera.
*En su inicio lo relevante de este paradigma fue su '''carácter rompedor'''. En la práctica, autores como Laloux consideran que no tienen éxito debido a las dificultades que existen al tratar de lograr el consenso entre un grupo grande de personas. Es fácil que se llegue a un punto muerto donde se intenta volver a los juegos de poder para volver a poner en marcha las cosas.
<blockquote>''A posteriori, sabemos que estas formas extremas de organización igualitaria no han tenido éxito ni a escala significativa ni por un lapso significativo de tiempo. Lograr el consenso entre un grupo grande de personas es intrínsecamente difícil. Muchas veces la iniciativa termina en extenuantes sesiones de conversación y un eventual punto muerto. A modo de respuesta se cuelan los juegos de poder en un intento de que las cosas vuelvan a moverse.''

Laloux, ''Reinventar las organizaciones'' (2016)</blockquote>
*Este tipo de paradigmas suelen usar marcos de '''agilidad técnica como scrum''' o de '''agilidad organizativa como la gobernanza dinámica o sociocracia'''. En algunos casos también se emplean para conducir la evolución hacia el paradigma ''teal''.

===Paradigma evolutivo o ''teal''===
La evolución a una cultura ''teal'' (también llamada "esmeralda") implica la '''desidentificación de nuestro propio ego'''. El éxito, el reconocimiento o la riqueza son trampas para el ego. En la cultura teal el éxito o el reconocimiento no son el objetivo. El objetivo es una vida bien vivida y es posible que la consecuencia de ello sea éxito, reconocimiento, riqueza y amor.
====Características====
Las tres aportaciones de las organizaciones evolutivas – ''teal'' son:
*'''Autogestión:''' la cultura verde aporta empoderamiento, pero el empoderamiento implica que un gestor de rango superior delega parte de su poder, mientras que para ''teal'' la autoridad no forma parte de un sistema de suma cero. En las estructuras de las organizaciones ''teal'' no hay miembros con poder de decisión y miembros ejecutores. Por naturaleza, y no por delegación, '''todos tienen poder de decisión''' y la estructura de la organización incluye procesos holocráticos para la regulación del flujo de información y decisiones.
<blockquote>''Cada decisión que se toma en la sede central le quita responsabilidad a la gente de otras partes de la organización y reduce el número de personas que sienten que están haciendo una contribución real a la organización.''

Dennis Bakke</blockquote>
*'''Plenitud:''' en las organizaciones ''teal'' no hay ascensos por los que pelear ni jefes a los que contentar. Las personas se muestran de forma plena, siendo ellos mismos. Son organizaciones que invierten mucho tiempo en la selección de personal, informando a los candidatos de los valores y formas de trabajo para que puedan decidir si quieren ser parte de la organización o no. En este sentido es conocido el caso de Zappos.com, que ofrece a los recién incorporados un cheque de 3.000 dólares si se arrepienten durante el periodo de prueba y prefieren abandonar la empresa.
*'''Propósito evolutivo:''' para las organizaciones ''teal'', el beneficio es un subproducto de un trabajo bien hecho. La finalidad de la organización no es el valor para los accionistas ni maximizar las ganancias, sino su propósito evolutivo. Brian Robertson, fundador de Holacracy emplea la metáfora padre-hĳo para explicar el concepto:
<blockquote>''¿Cuál es la identidad de la organización? ¿Y qué es lo que desea? [...] La metáfora es como el viaje padre-hĳo: reconocemos que nuestro hĳo tiene su propia identidad camino y propósito. Y si realmente me entusiasma que llegue a ser médico, no lo programo. Si lo hago, tiene lugar un proceso dañino y codependiente. [...] Pero la clave tiene que ver con separar identidades y descubrir cuál es la vocación de la organización. No para qué queremos usar la organización en tanto que propietarios, sino más bien ¿cuál es el potencial creativo de esta vida, de este sistema viviente?''</blockquote>

 
{{#ev:youtube|_-BtfKHASsY}}


==Referencias==
*1Laloux, Frederic (2016): ''Reinventar las organizaciones'', ARPA EDITORES.
*[https://www.scrummanager.com/website/c/info/docs-media.php Scrum Manager web: Libro ''Scrum Level'' y ''Guía para evaluadores''].
*[https://www.youtube.com/watch?v=AYoh3SJjkQU&ab%20channel=ScrumManager '''Video-libro''' de Scrum Level disponible en Youtube].

[[Category:Glosario de términos]]

Scrum Master 3 - fe de erratas

2024-01-14T10:45:01Z

Smanager:

=Fe de erratas y actualizaciones de la guía de Scrum Master=

=En la versión 3.07=

==Errata (DoR)==
=====Localización=====
Página 20
'''Dice: y la definición de hecho (DoR)'''
'''Debe decir: y la definición de hecho (DoD)'''

==Enlace a vídeo explicativo del gráfico burn down==
=====Localización=====
Página 68
'''Dice: https://www.youtube.com/watch?v=alafvKVTICA'''
'''Debe decir: https://www.youtube.com/watch?v=hveuhx7rZgw'''

=En la versión 3.06 y corregidas en la 3.07=

==Revisión del sprint==
=====Localización=====
Página 52.

'''Dice:'''

''"Reunión realizada al final del sprint para comprobar el incremento. Lo habitual es que dure una o dos horas; en caso de incrementos de especial relevancia o complejidad, puede extenderse hasta 4 como máximo. Asiste todo el equipo scrum y todas las personas implicadas en el proyecto que lo deseen. Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto. Al ver y probar el incremento, el propietario del producto y el equipo en general obtienen feedback relevante para revisar la pila del producto. Se identifican las historias de usuario que se pueden considerar «hechas» («done») y las que no. Reunión realizada el final del sprint para enseñar el incremento y recoger sugerencias."''

Por la experiencia y sugerencias de la comunidad profesional Scrum Manager, no es necesario considerar "hechas" (done) las historias en esta reunión, y en muchas circunstancias puede resultar aconsejable no vincularlo a la revisión del sprint.

'''Nueva redacción :'''

''"Reunión realizada al final del sprint para enseñar el incremento y recoger sugerencias. Lo habitual es que dure una o dos horas; en caso de incrementos de especial relevancia o complejidad, puede extenderse hasta 4 como máximo. Asiste todo el equipo scrum y todas las personas implicadas en el proyecto que lo deseen. Esta reunión marca, a intervalos regulares, el ritmo de construcción y la trayectoria que va tomando la visión del producto permitiendo un espacio donde recibir sugerencias de los interesados que permitan seguir evolucionando el producto. El equipo presenta las historias de usuario que planificaron, las que han desarrollado, las que no y los impedimentos encontrados. Es importante situar las expectativas de los interesados en la realidad al principio de la reunión."''

'''Dice:'''

Protocolo recomendado:
#El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían y el incremento desarrollado.
#El equipo hace una introducción general del sprint y demuestra el funcionamiento de las partes construidas. Se abre un turno de preguntas y sugerencias. Esta parte genera información valiosa para que el propietario del producto y el equipo en general puedan mejorar la visión del producto.

'''Nueva redacción :'''

Protocolo recomendado:
#El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían y las que se han desarrollado.
#El equipo hace una introducción general del sprint y demuestra el funcionamiento de las partes construidas. Se abre un turno de preguntas y sugerencias. Esta parte genera información valiosa para que el propietario del producto y el equipo en general puedan mejorar la visión del producto.

==Resultados del scrum diario==
=====Localización=====
Página 50 -> Tabla de entradas y resultados del scrum diario.
En la columna "resultados" dice: "Información del avance de cada miembro del equipo". Debe decir "Identificación de posibles necesidades e impedimentos"
Capítulo: Aprendiendo las prácticas estándar -> Artefactos -> Otros artefactos

=En la versión 3.052 y corregidas en la 3.06=
==Desvinculación de la clasificación de implicados y comprometidos con los roles del marco scrum==
=====Localización=====
Página 29.

Nueva redacción:

Comprometidos e implicados
Durante el desarrollo del proyecto son muchas las personas que intervienen y aportan valor al desarrollo, si bien con diferentes niveles de compromiso y responsabilidad, en función de lo cual se suele diferenciar entre «comprometidos» e «implicados».
Comprometidos: intervienen directamente en la construcción del producto o el desarrollo del servicio.
Implicados: otras partes interesadas: dirección, gerencia, comerciales, marketing, operadores del sistema que se desarrolla, soporte a usuarios, etc.
En círculos de scrum es frecuente llamar a los primeros (sin ninguna connotación peyorativa) «cerdos» y a los segundos «gallinas». El origen de estos nombres está en la siguiente historia, que ilustra de forma gráfica la diferencia entre compromiso e implicación en el proyecto:
Una gallina y un cerdo paseaban por la calle. La gallina preguntó al cerdo:
-¿Quieres abrir un restaurante conmigo?
El cerdo consideró la propuesta y respondió:
-Sí, me gustaría. ¿Cómo lo llamaríamos?
-Huevos con Jamón.
El cerdo se detuvo, hizo una pausa y contestó:
-Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente comprometido… mientras que tu estarías sólo implicada.

==Revisión del texto del diagrama de árbol para retrospectiva==
=====Localización=====
Página 75.

==Sobre la participación del propietario del producto en la retrospectiva.==
=====Localización=====
Página 53.

Se eliminan las consideraciones acerca de la conveniencia de la participación en las retrospectivas del propietario del producto cuando no se trata de un miembro implicado, por encontrarnos más en una implementación más de ingeniería concurrente que de "Agilidad" con condiciones contractuales que pudieran desaconsejarlo.
Se elimina por ser una consideración que excede el ámbito de formación estándar del marco scrum.

==Actualización de contenido en el tema de estimación ágil: NoEstimates==
actualiza el tema de estimación ágil, reflejando algunas de las críticas y alternativas más frecuentes al uso de puntos de historia. Éstos siguen formando parte del temario que explica el marco estándar de scrum, y las alternativas se han incluido entre las «Prácticas para flexibilizar scrum», en dos apartados:

*Estimación sin puntos de historia.
*NoEstimates.

En ambos casos se destacan ventajas e inconvenientes, explicando en qué contextos pueden resultar más adecuados.

=En la versión 3.051 y corregidas en la 3.052=
==Mejora de la definición del gráfico de producto o burn up chart==
=====Localización=====
Capítulo: Aprendiendo las prácticas estándar -> Artefactos -> Otros artefactos
* Dice ... "si el gráfico de avance mide lo que falta, el de producto mide cuánto se ha construido o completado". Nueva redacción: "El gráfico de producto o gráfico “burn up” es una herramienta de planificación propia del propietario de producto, que presenta visualmente la evolución previsible del producto.

==Desvinculación de la validación de historias de usuario con la reunión de revisión del sprint ==
=====Localización=====
Descripción de la reunión "Revisión del sprint" (página 47 de la edición en PDF)
* Dice "Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto. Al ver y probar el incremento, el propietario del producto y el equipo en general obtienen feedback relevante para revisar la pila del producto. Se identifican las historias de usuario que se pueden considerar «hechas» («done») y las que no." Se cambia a: "Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto permitiendo un espacio donde recibir sugerencias por parte de los interesados que permitan seguir evolucionando el producto."

==Gazapo: falta cierre de interrogación ==
=====Localización=====
*Dice "¿Por qué es valioso este sprint". Debe decir "¿Por qué es valioso este sprint?" (Página 41 de la edición en pdf)

= En la versión 3.05 y corregidas en la 3.051=
==Actualización: ISO 15504 ha sido reemplazado por ISO 33000==
=====Localización=====
Capítulo: Introducción -> El Manifiesto Ágil
* Dice "...SPICE (proyecto inicial de ISO 15504)..." Debe decir "...SPICE (proyecto inicial de ISO 15504, a su vez precursor de ISO 15504)"

==Año en la nota bibliográfica de Extreme Programming Explained==
* Tiene como año de publicación 2000 y debe tener 1999

==Enlace a FAQ de scrummanager.com==
=====Localización=====
Apéndices.
* El enlace está desfasado.

==Supresión del término grooming==
* Para aludir a la preparación o refinado de la pila de producto se elimina como sinónimo "grooming" al quedar en desuso en la comunidad angloparlante por las connotaciones que le ha dado al término la acepción de abuso de menores.

==Actualización de la imagen del marco de scrum==
=====Localización=====
Pág. 27 (versión pdf)
* Actualización del nombre del rol del equipo de desarrollo por desarrollador.

==Uso homogéneo del término auto-gestión en relación al modo organizativo del equipo scrum==
* Se mantiene el término auto-organización al hacer referencia a las fuentes que se refieren a los equipos ágiles como "auto-organizados".
** Origen de scrum. Los autores de la definición de los equipos scrum (Nonaka y Takeuchi "The New New Product Development Game") usan la denominación "self-organizing project teams"
** Manifiesto ágil. El manifiesto ágil prefiere también el término "self-organizing" ("The best architectures, requirements, and designs emerge from self-organizing teams")
* En el resto se adopta la tendencia a preferir el término auto-gestionados. (Scrum Manager recomienda abordar el grado de autonomía de los equipos de forma coherente con la cultura de la orgnanización. V. Scrum Level)

= En la versión 3.04 y corregidas en las 3.05 =

== Fecha del Manifiesto Ágil ==
=====Localización=====
Capítulo: Introducción -> El Manifiesto Ágil
* Dice "En marzo de 2001" y debe decir "En febrero de 2001"

= En la versión 3.03 y corregidas en la 3.04=

== Imagen ejemplo pila del sprint ==
=====Localización=====
Capítulo: Artefactos -> Pila del sprint.
La imagen de ejemplo resulta confusa por indicar erróneamente en la cabecera de las columnas de tareas "Pila del producto"

= En la versión 3.02 y corregidas en la 3.03=

== Participación de Product Owner en la reunión retrospectiva ==
=====Localizaciones=====
* Figura "LAS REGLAS DE SCRUM"
* Capítulo Eventos -> Retrospectiva del sprint. Actualiza en su descripción la recomendación de la participación del product owner:
"En la retrospectiva del sprint participan: el equipo de desarrollo, el scrum master y el propietario de producto. Es importante que el propietario de producto se considere “equipo” más que “cliente”. Que la persona que desempeña el rol sea participativa y conocedora de los principios y valores de scrum. Si esto no fuera así, el scrum master debe actuar como facilitador para lograr su compromiso y participación o, si la situación lo requiere, no incluirlo en la retrospectiva."

== WIP ==

=====Localización=====
Capítulo: Prácticas para flexibilizar scrum - kanban- (página 71 de la edición impresa y 64 de la edición PDF)

En el cuarto párrafo dice "WIP (work in progress)" y debe decir "WIP (work in process)

==Rol interesados==

=====Localización=====
Capítulo: Prácticas para flexibilizar scrum - kanban- (página 31 de la edición impresa y 27 de la edición PDF)

En el esquema de componentes del ciclo estándar de scrum falta en el apartado de roles la mención de los "interesados".

= En la versión 3.01 y corregidas en la 3.02=

== DoD / DoR ==
=====Localización=====
Capítulo: Artefactos, "Otros artefactos"

Las definiciones de "Definition of Ready (DoR)" y "Definition of Done (DoD) están cruzadas.

Scrum Master 3 - fe de erratas

2023-09-01T17:13:23Z

Smanager:

=Fe de erratas y actualizaciones de la guía de Scrum Master=

=En la versión 3.07=
==Enlace a vídeo explicativo del gráfico burn down==
=====Localización=====
Página 68
'''Dice: https://www.youtube.com/watch?v=alafvKVTICA'''
'''Debe decir: https://www.youtube.com/watch?v=hveuhx7rZgw'''

=En la versión 3.06 y corregidas en la 3.07=

==Revisión del sprint==
=====Localización=====
Página 52.

'''Dice:'''

''"Reunión realizada al final del sprint para comprobar el incremento. Lo habitual es que dure una o dos horas; en caso de incrementos de especial relevancia o complejidad, puede extenderse hasta 4 como máximo. Asiste todo el equipo scrum y todas las personas implicadas en el proyecto que lo deseen. Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto. Al ver y probar el incremento, el propietario del producto y el equipo en general obtienen feedback relevante para revisar la pila del producto. Se identifican las historias de usuario que se pueden considerar «hechas» («done») y las que no. Reunión realizada el final del sprint para enseñar el incremento y recoger sugerencias."''

Por la experiencia y sugerencias de la comunidad profesional Scrum Manager, no es necesario considerar "hechas" (done) las historias en esta reunión, y en muchas circunstancias puede resultar aconsejable no vincularlo a la revisión del sprint.

'''Nueva redacción :'''

''"Reunión realizada al final del sprint para enseñar el incremento y recoger sugerencias. Lo habitual es que dure una o dos horas; en caso de incrementos de especial relevancia o complejidad, puede extenderse hasta 4 como máximo. Asiste todo el equipo scrum y todas las personas implicadas en el proyecto que lo deseen. Esta reunión marca, a intervalos regulares, el ritmo de construcción y la trayectoria que va tomando la visión del producto permitiendo un espacio donde recibir sugerencias de los interesados que permitan seguir evolucionando el producto. El equipo presenta las historias de usuario que planificaron, las que han desarrollado, las que no y los impedimentos encontrados. Es importante situar las expectativas de los interesados en la realidad al principio de la reunión."''

'''Dice:'''

Protocolo recomendado:
#El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían y el incremento desarrollado.
#El equipo hace una introducción general del sprint y demuestra el funcionamiento de las partes construidas. Se abre un turno de preguntas y sugerencias. Esta parte genera información valiosa para que el propietario del producto y el equipo en general puedan mejorar la visión del producto.

'''Nueva redacción :'''

Protocolo recomendado:
#El equipo expone el objetivo del sprint, la lista de funcionalidades que se incluían y las que se han desarrollado.
#El equipo hace una introducción general del sprint y demuestra el funcionamiento de las partes construidas. Se abre un turno de preguntas y sugerencias. Esta parte genera información valiosa para que el propietario del producto y el equipo en general puedan mejorar la visión del producto.

==Resultados del scrum diario==
=====Localización=====
Página 50 -> Tabla de entradas y resultados del scrum diario.
En la columna "resultados" dice: "Información del avance de cada miembro del equipo". Debe decir "Identificación de posibles necesidades e impedimentos"
Capítulo: Aprendiendo las prácticas estándar -> Artefactos -> Otros artefactos

=En la versión 3.052 y corregidas en la 3.06=
==Desvinculación de la clasificación de implicados y comprometidos con los roles del marco scrum==
=====Localización=====
Página 29.

Nueva redacción:

Comprometidos e implicados
Durante el desarrollo del proyecto son muchas las personas que intervienen y aportan valor al desarrollo, si bien con diferentes niveles de compromiso y responsabilidad, en función de lo cual se suele diferenciar entre «comprometidos» e «implicados».
Comprometidos: intervienen directamente en la construcción del producto o el desarrollo del servicio.
Implicados: otras partes interesadas: dirección, gerencia, comerciales, marketing, operadores del sistema que se desarrolla, soporte a usuarios, etc.
En círculos de scrum es frecuente llamar a los primeros (sin ninguna connotación peyorativa) «cerdos» y a los segundos «gallinas». El origen de estos nombres está en la siguiente historia, que ilustra de forma gráfica la diferencia entre compromiso e implicación en el proyecto:
Una gallina y un cerdo paseaban por la calle. La gallina preguntó al cerdo:
-¿Quieres abrir un restaurante conmigo?
El cerdo consideró la propuesta y respondió:
-Sí, me gustaría. ¿Cómo lo llamaríamos?
-Huevos con Jamón.
El cerdo se detuvo, hizo una pausa y contestó:
-Pensándolo mejor, creo que no voy a abrir un restaurante contigo. Yo estaría realmente comprometido… mientras que tu estarías sólo implicada.

==Revisión del texto del diagrama de árbol para retrospectiva==
=====Localización=====
Página 75.

==Sobre la participación del propietario del producto en la retrospectiva.==
=====Localización=====
Página 53.

Se eliminan las consideraciones acerca de la conveniencia de la participación en las retrospectivas del propietario del producto cuando no se trata de un miembro implicado, por encontrarnos más en una implementación más de ingeniería concurrente que de "Agilidad" con condiciones contractuales que pudieran desaconsejarlo.
Se elimina por ser una consideración que excede el ámbito de formación estándar del marco scrum.

==Actualización de contenido en el tema de estimación ágil: NoEstimates==
actualiza el tema de estimación ágil, reflejando algunas de las críticas y alternativas más frecuentes al uso de puntos de historia. Éstos siguen formando parte del temario que explica el marco estándar de scrum, y las alternativas se han incluido entre las «Prácticas para flexibilizar scrum», en dos apartados:

*Estimación sin puntos de historia.
*NoEstimates.

En ambos casos se destacan ventajas e inconvenientes, explicando en qué contextos pueden resultar más adecuados.

=En la versión 3.051 y corregidas en la 3.052=
==Mejora de la definición del gráfico de producto o burn up chart==
=====Localización=====
Capítulo: Aprendiendo las prácticas estándar -> Artefactos -> Otros artefactos
* Dice ... "si el gráfico de avance mide lo que falta, el de producto mide cuánto se ha construido o completado". Nueva redacción: "El gráfico de producto o gráfico “burn up” es una herramienta de planificación propia del propietario de producto, que presenta visualmente la evolución previsible del producto.

==Desvinculación de la validación de historias de usuario con la reunión de revisión del sprint ==
=====Localización=====
Descripción de la reunión "Revisión del sprint" (página 47 de la edición en PDF)
* Dice "Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto. Al ver y probar el incremento, el propietario del producto y el equipo en general obtienen feedback relevante para revisar la pila del producto. Se identifican las historias de usuario que se pueden considerar «hechas» («done») y las que no." Se cambia a: "Esta reunión marca, a intervalos regulares, el ritmo de construcción, y la trayectoria que va tomando la visión del producto permitiendo un espacio donde recibir sugerencias por parte de los interesados que permitan seguir evolucionando el producto."

==Gazapo: falta cierre de interrogación ==
=====Localización=====
*Dice "¿Por qué es valioso este sprint". Debe decir "¿Por qué es valioso este sprint?" (Página 41 de la edición en pdf)

= En la versión 3.05 y corregidas en la 3.051=
==Actualización: ISO 15504 ha sido reemplazado por ISO 33000==
=====Localización=====
Capítulo: Introducción -> El Manifiesto Ágil
* Dice "...SPICE (proyecto inicial de ISO 15504)..." Debe decir "...SPICE (proyecto inicial de ISO 15504, a su vez precursor de ISO 15504)"

==Año en la nota bibliográfica de Extreme Programming Explained==
* Tiene como año de publicación 2000 y debe tener 1999

==Enlace a FAQ de scrummanager.com==
=====Localización=====
Apéndices.
* El enlace está desfasado.

==Supresión del término grooming==
* Para aludir a la preparación o refinado de la pila de producto se elimina como sinónimo "grooming" al quedar en desuso en la comunidad angloparlante por las connotaciones que le ha dado al término la acepción de abuso de menores.

==Actualización de la imagen del marco de scrum==
=====Localización=====
Pág. 27 (versión pdf)
* Actualización del nombre del rol del equipo de desarrollo por desarrollador.

==Uso homogéneo del término auto-gestión en relación al modo organizativo del equipo scrum==
* Se mantiene el término auto-organización al hacer referencia a las fuentes que se refieren a los equipos ágiles como "auto-organizados".
** Origen de scrum. Los autores de la definición de los equipos scrum (Nonaka y Takeuchi "The New New Product Development Game") usan la denominación "self-organizing project teams"
** Manifiesto ágil. El manifiesto ágil prefiere también el término "self-organizing" ("The best architectures, requirements, and designs emerge from self-organizing teams")
* En el resto se adopta la tendencia a preferir el término auto-gestionados. (Scrum Manager recomienda abordar el grado de autonomía de los equipos de forma coherente con la cultura de la orgnanización. V. Scrum Level)

= En la versión 3.04 y corregidas en las 3.05 =

== Fecha del Manifiesto Ágil ==
=====Localización=====
Capítulo: Introducción -> El Manifiesto Ágil
* Dice "En marzo de 2001" y debe decir "En febrero de 2001"

= En la versión 3.03 y corregidas en la 3.04=

== Imagen ejemplo pila del sprint ==
=====Localización=====
Capítulo: Artefactos -> Pila del sprint.
La imagen de ejemplo resulta confusa por indicar erróneamente en la cabecera de las columnas de tareas "Pila del producto"

= En la versión 3.02 y corregidas en la 3.03=

== Participación de Product Owner en la reunión retrospectiva ==
=====Localizaciones=====
* Figura "LAS REGLAS DE SCRUM"
* Capítulo Eventos -> Retrospectiva del sprint. Actualiza en su descripción la recomendación de la participación del product owner:
"En la retrospectiva del sprint participan: el equipo de desarrollo, el scrum master y el propietario de producto. Es importante que el propietario de producto se considere “equipo” más que “cliente”. Que la persona que desempeña el rol sea participativa y conocedora de los principios y valores de scrum. Si esto no fuera así, el scrum master debe actuar como facilitador para lograr su compromiso y participación o, si la situación lo requiere, no incluirlo en la retrospectiva."

== WIP ==

=====Localización=====
Capítulo: Prácticas para flexibilizar scrum - kanban- (página 71 de la edición impresa y 64 de la edición PDF)

En el cuarto párrafo dice "WIP (work in progress)" y debe decir "WIP (work in process)

==Rol interesados==

=====Localización=====
Capítulo: Prácticas para flexibilizar scrum - kanban- (página 31 de la edición impresa y 27 de la edición PDF)

En el esquema de componentes del ciclo estándar de scrum falta en el apartado de roles la mención de los "interesados".

= En la versión 3.01 y corregidas en la 3.02=

== DoD / DoR ==
=====Localización=====
Capítulo: Artefactos, "Otros artefactos"

Las definiciones de "Definition of Ready (DoR)" y "Definition of Done (DoD) están cruzadas.

Interview snapshot

2023-08-01T08:41:48Z

Smanager:

Los interview snapshots son tarjetas que capturan en poco espacio la información destacada de una entrevista con un usuario. Es un artefacto recomendado para mantener hábitos de descubrimiento continuo. Crear estas tarjetas y guardarlas permite identificar patrones a largo plazo. No pretenden ser un registro exhaustivo, sino ayudar a refrescar la memoria.

== Plantilla según ''Continuous Discovery Habits'' ==
[[File:CDH InterviewSnapshot.png|thumb|right|Interview snapshot]]
Aunque la idea de resumir o visualizar las entrevistas con los clientes no es nueva, esta plantilla en concreto es la propuesta por Teresa Torres en ''Continuous Discovery Habits'' (2021), en el contexto de su metodología de descubrimiento continuo.
=== Foto u otra ayuda visual ===
Se recomienda que el ''snapshot'' sea lo más visual posible. Una foto de la persona entrevistada o el logo de la empresa para la que trabaja puede ayudar a contextualizar mejor que cualquier texto, y a identificar más adelante el ''snapshot'' entre los demás. La foto puede ser una captura de pantalla durante la vídeo llamada (solicitando permiso).
Si no es posible usar una foto o el logo de la empresa, cualquier otro apoyo visual que tenga sentido para el equipo de producto sirve.

=== Cita memorable ===
Se recomienda capturar alguna frase llamativa de la entrevista. Esto sirve de nuevo para refrescar la memoria, y para caracterizar al usuario, por lo que es importante usar las palabras exactas.

=== Datos personales ===
Datos rápidos que sean relevantes para el negocio e indiquen de qué tipo de usuario se trata. Por ejemplo, puede ser relevante en qué fecha se dio de alta y con qué frecuencia usa el servicio, o qué servicios en concreto usa.

Esta información ayuda no sólo a contextualizar la entrevista concreta que resume el ''snapshot'', si no también a identificar más adelante patrones entre usuarios.

=== Oportunidades ===
Al apuntar oportunidades es importante que éstas queden registradas como necesidades, no soluciones. Si el usuario solicita algo concreto, hay que preguntar por qué lo necesitan. No es necesario apuntar su explicación como una cita literal, pero en la medida de lo posible se recomienda usar su mismo lenguaje para no malinterpretar lo dicho más adelante.

=== ''Insights'' u observaciones ===
Puede que durante la entrevista surjan temas o comportamientos interesantes y que valga la pena apuntar, pero que no sean exactamente oportunidades; que no sean una necesidad, un problema o un deseo. Con el tiempo, estas observaciones pueden convertirse en oportunidades, sobre todo si se repiten. Es decir, en este apartado va información que suena valiosa pero con la que todavía no se sabe qué hacer.

=== Mapa de la experiencia de usuario ===
Dibujar la estructura de la experiencia del usuario, con nodos y enlaces, ayuda a recordarla y a ver cómo se alinea con el mapa de experiencia de usuario general.

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

Interview snapshot

2023-07-31T14:54:48Z

Smanager:

[[File:CDH InterviewSnapshot.png|thumb|right|Interview snapshot]]
Los interview snapshots son tarjetas que capturan en poco espacio la información destacada de una entrevista con un usuario. Es un artefacto recomendado para mantener hábitos de descubrimiento continuo. Crear estas tarjetas y guardarlas permite identificar patrones a largo plazo. No pretenden ser un registro exhaustivo, sino ayudar a refrescar la memoria.

Aunque la idea de resumir o visualizar las entrevistas con los clientes no es nueva, la forma específica que exploramos en este artículo es la propuesta por Teresa Torres en ''Continuous Discovery Habits'' (2021), en el contexto de su metodología de descubrimiento continuo.

== Información contenida en el ''snapshot'' ==

=== Foto u otra ayuda visual ===
Se recomienda que el ''snapshot'' sea lo más visual posible. Una foto de la persona entrevistada o el logo de la empresa para la que trabaja puede ayudar a contextualizar mejor que cualquier texto, y a identificar más adelante el ''snapshot'' entre los demás. La foto puede ser una captura de pantalla durante la vídeo llamada (solicitando permiso).
Si no es posible usar una foto o el logo de la empresa, cualquier otro apoyo visual que tenga sentido para el equipo de producto sirve.

=== Cita memorable ===
Se recomienda capturar alguna frase llamativa de la entrevista. Esto sirve de nuevo para refrescar la memoria, y para caracterizar al usuario, por lo que es importante usar las palabras exactas.

=== Datos personales ===
Datos rápidos que sean relevantes para el negocio e indiquen de qué tipo de usuario se trata. Por ejemplo, puede ser relevante en qué fecha se dio de alta y con qué frecuencia usa el servicio, o qué servicios en concreto usa.

Esta información ayuda no sólo a contextualizar la entrevista concreta que resume el ''snapshot'', si no también a identificar más adelante patrones entre usuarios.

=== Oportunidades ===
Al apuntar oportunidades es importante que éstas queden registradas como necesidades, no soluciones. Si el usuario solicita algo concreto, hay que preguntar por qué lo necesitan. No es necesario apuntar su explicación como una cita literal, pero en la medida de lo posible se recomienda usar su mismo lenguaje para no malinterpretar lo dicho más adelante.

=== ''Insights'' u observaciones ===
Puede que durante la entrevista surjan temas o comportamientos interesantes y que valga la pena apuntar, pero que no sean exactamente oportunidades; que no sean una necesidad, un problema o un deseo. Con el tiempo, estas observaciones pueden convertirse en oportunidades, sobre todo si se repiten. Es decir, en este apartado va información que suena valiosa pero con la que todavía no se sabe qué hacer.

=== Mapa de la experiencia de usuario ===
Dibujar la estructura de la experiencia del usuario, con nodos y enlaces, ayuda a recordarla y a ver cómo se alinea con el mapa de experiencia de usuario general.

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

Árbol de soluciones de oportunidades

2023-07-31T14:34:45Z

Smanager:

[[File:CDH ArbolDeSoluciones.png|thumb|right|Estructura de un árbol de soluciones de oportunidades]]
El árbol de soluciones de oportunidades (Opportunity Solutions Tree u OST en inglés) es una herramienta para ayudar a los equipos de productos a mantenerse centrados en los resultados mientras exploran diferentes soluciones para alcanzarlos. Ayuda a visualizar y priorizar resultados, oportunidades y las soluciones, y cómo se conectan.

Su estructura parte de un resultado que se desea obtener, y oportunidades que se espera ayuden a alcanzar este resultado. Cada oportunidad puede contener otras sub-oportunidades. En última instancia, cuando una oportunidad no se puede descomponer en otras menores, se buscan soluciones concretas para dar respuesta a esa oportunidad.
Se trata de un documento vivo, que se va actualizando y reordenando conforme se descubren nuevas oportunidades. Se recomienda combinar su uso con el de otros artefactos, como las [[interview snapshot|interview snapshots]], resúmenes de entrevistas con usuarios que ayudan a identificar problemas, necesidades, deseos, y patrones que se repiten.

Se trata de un concepto original desarrollado por Teresa Torres (''Continuous Discovery Habits'', 2021). Lo introdujo por primera vez en su blog Product Talk, y desde entonces ha sido adoptado y utilizado por muchos equipos de productos en todo el mundo. Teresa Torres ha escrito extensamente sobre el OST y ha dado numerosas charlas y talleres sobre el tema.

== Similitudes y diferencias con los Goal Maps ==

Tanto el árbol de soluciones (OST) como el Goal Map o Impact Map comienzan con un resultado o meta deseada y luego exploran diferentes formas de alcanzar ese resultado. La diferencia principal radica en cómo cada herramienta aborda este proceso.

El OST se centra en identificar oportunidades (problemas o necesidades del cliente que, si se resuelven, podrían conducir al resultado deseado) y luego en generar y probar posibles soluciones para esas oportunidades. Ayuda a los equipos a explorar una amplia gama de posibles soluciones, y a validarlas a través de la experimentación. Los experimentos para cada solución basan en probar o descartar supuestos necesarios para que la solución tenga éxito, antes de crear prototipos o empezar a construir la solución en sí.

Por otro lado, un Goal Map se centra en identificar a los actores (personas o grupos que pueden contribuir a alcanzar el resultado deseado), las acciones que estos actores podrían tomar para contribuir al resultado deseado, y los entregables (productos, características, etc.) que podrían ayudar a los actores a realizar esas acciones. Este enfoque ayuda a los equipos a entender y comunicar cómo planean alcanzar su meta.

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

Árbol de soluciones de oportunidades

2023-07-31T14:34:06Z

Smanager:

[[File:CDH ArbolDeSoluciones.png|thumb|right|Estructura de un árbol de soluciones de oportunidades]]
El árbol de soluciones de oportunidades (Opportunity Solutions Tree u OST en inglés) es una herramienta para ayudar a los equipos de productos a mantenerse centrados en los resultados mientras exploran diferentes soluciones para alcanzarlos. Ayuda a visualizar y priorizar resultados, oportunidades y las soluciones, y cómo se conectan.

Su estructura parte de un resultado que se desea obtener, y oportunidades que se espera ayuden a alcanzar este resultado. Cada oportunidad puede contener otras sub-oportunidades. En última instancia, cuando una oportunidad no se puede descomponer en otras menores, se buscan soluciones concretas para dar respuesta a esa oportunidad.
Se trata de un documento vivo, que se va actualizando y reordenando conforme se descubren nuevas oportunidades. Se recomienda combinar su uso con el de otros artefactos, como las [[interview snapshot|interview snapshots]], resúmenes de entrevistas con usuarios que ayudan a identificar problemas, necesidades, deseos, y patrones que se repiten.

Se trata de un concepto original desarrollado por Teresa Torres<ref>Torres, Teresa. ''Continuous Discovery Habits''. 2021.</ref>. Lo introdujo por primera vez en su blog Product Talk, y desde entonces ha sido adoptado y utilizado por muchos equipos de productos en todo el mundo. Teresa Torres ha escrito extensamente sobre el OST y ha dado numerosas charlas y talleres sobre el tema.

== Similitudes y diferencias con los Goal Maps ==

Tanto el árbol de soluciones (OST) como el Goal Map o Impact Map comienzan con un resultado o meta deseada y luego exploran diferentes formas de alcanzar ese resultado. La diferencia principal radica en cómo cada herramienta aborda este proceso.

El OST se centra en identificar oportunidades (problemas o necesidades del cliente que, si se resuelven, podrían conducir al resultado deseado) y luego en generar y probar posibles soluciones para esas oportunidades. Ayuda a los equipos a explorar una amplia gama de posibles soluciones, y a validarlas a través de la experimentación. Los experimentos para cada solución basan en probar o descartar supuestos necesarios para que la solución tenga éxito, antes de crear prototipos o empezar a construir la solución en sí.

Por otro lado, un Goal Map se centra en identificar a los actores (personas o grupos que pueden contribuir a alcanzar el resultado deseado), las acciones que estos actores podrían tomar para contribuir al resultado deseado, y los entregables (productos, características, etc.) que podrían ayudar a los actores a realizar esas acciones. Este enfoque ayuda a los equipos a entender y comunicar cómo planean alcanzar su meta.

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

Árbol de soluciones de oportunidades

2023-07-31T14:27:30Z

Smanager:

[[File:CDH ArbolDeSoluciones.png|thumb|right|Estructura de un árbol de soluciones de oportunidades]]
El árbol de soluciones de oportunidades (Opportunity Solutions Tree u OST en inglés) es una herramienta para ayudar a los equipos de productos a mantenerse centrados en los resultados mientras exploran diferentes soluciones para alcanzarlos. Ayuda a visualizar y priorizar resultados, oportunidades y las soluciones, y cómo se conectan.

Su estructura parte de un resultado que se desea obtener, y oportunidades que se espera ayuden a alcanzar este resultado. Cada oportunidad puede contener otras sub-oportunidades. En última instancia, cuando una oportunidad no se puede descomponer en otras menores, se buscan soluciones concretas para dar respuesta a esa oportunidad.
Se trata de un documento vivo, que se va actualizando y reordenando conforme se descubren nuevas oportunidades. Se recomienda combinar su uso con el de otros artefactos, como las [[interview snapshot|interview snapshots]], resúmenes de entrevistas con usuarios que ayudan a identificar problemas, necesidades, deseos, y patrones que se repiten.

Se trata de un concepto original desarrollado por Teresa Torres. Lo introdujo por primera vez en su blog Product Talk, y desde entonces ha sido adoptado y utilizado por muchos equipos de productos en todo el mundo. Teresa Torres ha escrito extensamente sobre el OST y ha dado numerosas charlas y talleres sobre el tema.

== Similitudes y diferencias con los Goal Maps ==

Tanto el árbol de soluciones (OST) como el Goal Map o Impact Map comienzan con un resultado o meta deseada y luego exploran diferentes formas de alcanzar ese resultado. La diferencia principal radica en cómo cada herramienta aborda este proceso.

El OST se centra en identificar oportunidades (problemas o necesidades del cliente que, si se resuelven, podrían conducir al resultado deseado) y luego en generar y probar posibles soluciones para esas oportunidades. Ayuda a los equipos a explorar una amplia gama de posibles soluciones, y a validarlas a través de la experimentación. Los experimentos para cada solución basan en probar o descartar supuestos necesarios para que la solución tenga éxito, antes de crear prototipos o empezar a construir la solución en sí.

Por otro lado, un Goal Map se centra en identificar a los actores (personas o grupos que pueden contribuir a alcanzar el resultado deseado), las acciones que estos actores podrían tomar para contribuir al resultado deseado, y los entregables (productos, características, etc.) que podrían ayudar a los actores a realizar esas acciones. Este enfoque ayuda a los equipos a entender y comunicar cómo planean alcanzar su meta.

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

Árbol de soluciones de oportunidades

2023-07-31T14:19:04Z

Smanager:

[[File:CDH ArbolDeSoluciones.png|thumb|right|Estructura de un árbol de soluciones de oportunidades]]
El árbol de soluciones de oportunidades (Opportunity Solutions Tree u OST en inglés) es un artefacto recomendado para mantener hábitos de descubrimiento continuo. Ayuda a visualizar y priorizar resultados, oportunidades y las soluciones, y cómo se conectan. Su estructura parte de un resultado que se desea obtener, y oportunidades que se espera ayuden a alcanzar este resultado. Cada oportunidad puede contener otras sub-oportunidades. En última instancia, cuando una oportunidad no se puede descomponer en otras menores, se buscan soluciones concretas para dar respuesta a esa oportunidad.
Se trata de un documento vivo, que se va actualizando y reordenando conforme se descubren nuevas oportunidades. Se recomienda combinar su uso con el de otros artefactos, como las [[interview snapshot|interview snapshots]], resúmenes de entrevistas con usuarios que ayudan a identificar problemas, necesidades, deseos, y patrones que se repiten.

== Similitudes y diferencias con los Goal Maps ==

Tanto el árbol de soluciones (OST) como el Goal Map o Impact Map comienzan con un resultado o meta deseada y luego exploran diferentes formas de alcanzar ese resultado. La diferencia principal radica en cómo cada herramienta aborda este proceso.

El OST se centra en identificar oportunidades (problemas o necesidades del cliente que, si se resuelven, podrían conducir al resultado deseado) y luego en generar y probar posibles soluciones para esas oportunidades. Ayuda a los equipos a explorar una amplia gama de posibles soluciones, y a validarlas a través de la experimentación. Los experimentos para cada solución basan en probar o descartar supuestos necesarios para que la solución tenga éxito, antes de crear prototipos o empezar a construir la solución en sí.

Por otro lado, un Goal Map se centra en identificar a los actores (personas o grupos que pueden contribuir a alcanzar el resultado deseado), las acciones que estos actores podrían tomar para contribuir al resultado deseado, y los entregables (productos, características, etc.) que podrían ayudar a los actores a realizar esas acciones. Este enfoque ayuda a los equipos a entender y comunicar cómo planean alcanzar su meta.

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

Interview snapshot

2023-07-31T14:08:42Z

Smanager: Created page with "Interview snapshot Los interview snapshots son tarjetas que capturan en poco espacio la información destacada de una entrevista con un usuario. Es un artefacto recomendado para mantener hábitos de descubrimiento continuo. Crear estas tarjetas y guardarlas permite identificar patrones a largo plazo. No pretenden ser un registro exhaustivo, sino ayudar a refrescar la memoria. Category:Glosario de términos Category:P..."

File:CDH InterviewSnapshot.png

2023-07-31T14:05:59Z

Smanager:

Interview snapshot

Árbol de soluciones de oportunidades

2023-07-31T14:05:07Z

Smanager:

[[File:CDH ArbolDeSoluciones.png|thumb|right|Estructura de un árbol de soluciones de oportunidades]]
El árbol de soluciones de oportunidades (Opportunity Solutions Tree u OST en inglés) es un artefacto recomendado para mantener hábitos de descubrimiento continuo. Ayuda a visualizar y priorizar resultados, oportunidades y las soluciones, y cómo se conectan. Su estructura parte de un resultado que se desea obtener, y oportunidades que se espera ayuden a alcanzar este resultado. Cada oportunidad puede contener otras sub-oportunidades. En última instancia, cuando una oportunidad no se puede descomponer en otras menores, se buscan soluciones concretas para dar respuesta a esa oportunidad.
Se trata de un documento vivo, que se va actualizando y reordenando conforme se descubren nuevas oportunidades. Se recomienda combinar su uso con el de otros artefactos, como las [[interview snapshot|interview snapshots]], resúmenes de entrevistas con usuarios que ayudan a identificar problemas, necesidades, deseos, y patrones que se repiten.

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

Árbol de soluciones de oportunidades

2023-07-31T14:01:47Z

Smanager:

[[File:CDH ArbolDeSoluciones.png|thumb|right|Estructura de un árbol de soluciones de oportunidades]]
El árbol de soluciones de oportunidades (Opportunity Solutions Tree u OST en inglés) es un artefacto para mantener hábitos de descubrimiento continuo. Ayuda a visualizar y priorizar resultados, oportunidades y las soluciones, y cómo se conectan. Su estructura parte de un resultado que se desea obtener, y oportunidades que se espera ayuden a alcanzar este resultado. Cada oportunidad puede contener otras sub-oportunidades. En última instancia, cuando una oportunidad no se puede descomponer en otras menores, se buscan soluciones concretas para dar respuesta a esa oportunidad.

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

Opportunity solutions tree

2023-07-31T14:01:21Z

Smanager: Redirected page to Árbol de soluciones de oportunidades

#REDIRECT [[Árbol de soluciones de oportunidades]]

[[Category:Glosario de términos]]" (and the only contributor was "[[Special:Contributions/Smanager|Smanager]]

Árbol de soluciones de oportunidades

2023-07-31T14:00:59Z

Smanager: Created page with "Estructura de un árbol de soluciones de oportunidades El árbol de soluciones de oportunidades es un artefacto para mantener hábitos de descubrimiento continuo. Ayuda a visualizar y priorizar resultados, oportunidades y las soluciones, y cómo se conectan. Su estructura parte de un resultado que se desea obtener, y oportunidades que se espera ayuden a alcanzar este resultado. Cada oportunidad puede contener otras sub-oport..."

[[File:CDH ArbolDeSoluciones.png|thumb|right|Estructura de un árbol de soluciones de oportunidades]]
El árbol de soluciones de oportunidades es un artefacto para mantener hábitos de descubrimiento continuo. Ayuda a visualizar y priorizar resultados, oportunidades y las soluciones, y cómo se conectan. Su estructura parte de un resultado que se desea obtener, y oportunidades que se espera ayuden a alcanzar este resultado. Cada oportunidad puede contener otras sub-oportunidades. En última instancia, cuando una oportunidad no se puede descomponer en otras menores, se buscan soluciones concretas para dar respuesta a esa oportunidad.

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

Opportunity solutions tree

2023-07-31T13:55:32Z

Smanager:

Opportunity solutions tree

2023-07-31T13:55:22Z

Smanager:

El árbol de soluciones de oportunidades es un artefacto para mantener hábitos de descubrimiento continuo. Ayuda a visualizar y priorizar resultados, oportunidades y las soluciones, y cómo se conectan. Su estructura parte de un resultado que se desea obtener, y oportunidades que se espera ayuden a alcanzar este resultado. Cada oportunidad puede contener otras sub-oportunidades. En última instancia, cuando una oportunidad no se puede descomponer en otras menores, se buscan soluciones concretas para dar respuesta a esa oportunidad.

[[File:CDH ArbolDeSoluciones.png|thumb|right|Estructura de un árbol de soluciones de oportunidades]]

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

Opportunity solutions tree

2023-07-31T13:55:09Z

Smanager: Created page with "El árbol de soluciones de oportunidades es un artefacto para mantener hábitos de descubrimiento continuo. Ayuda a visualizar y priorizar resultados, oportunidades y las soluciones, y cómo se conectan. Su estructura parte de un resultado que se desea obtener, y oportunidades que se espera ayuden a alcanzar este resultado. Cada oportunidad puede contener otras sub-oportunidades. En última instancia, cuando una oportunidad no se puede descomponer en otras menores, se bu..."

El árbol de soluciones de oportunidades es un artefacto para mantener hábitos de descubrimiento continuo. Ayuda a visualizar y priorizar resultados, oportunidades y las soluciones, y cómo se conectan. Su estructura parte de un resultado que se desea obtener, y oportunidades que se espera ayuden a alcanzar este resultado. Cada oportunidad puede contener otras sub-oportunidades. En última instancia, cuando una oportunidad no se puede descomponer en otras menores, se buscan soluciones concretas para dar respuesta a esa oportunidad.

[[File:CDH ArbolDeSoluciones.png|thumb|center|Estructura de un árbol de soluciones de oportunidades]]

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

File:CDH ArbolDeSoluciones.png

2023-07-31T13:54:35Z

Smanager:

Árbol de soluciones de oportunidades

Scrum Manager BoK

2023-05-22T14:16:59Z

Smanager:

__NOTOC__

<table style="text-align: left; width: 100%;" border="0"
cellpadding="2" cellspacing="3">
<tr>
<td style="text-align: center; width: 33%;">''Agilidad en el equipo''</td>
<td style="text-align: center; width: 33%;">''Agilidad en la empresa''</td>
<td style="text-align: center; width: 33%;">''Ampliación: Historias de usuario''</td>
</tr>
<tr>
<td style="text-align: center; width: 33%;">[[File:Portada scrum master.png|center|150px|link=]]</td>
<td style="text-align: center; width: 33%;">[[File:Portada scrumlevel 3 11b.jpg|center|150px|link=]]</td>
<td style="text-align: center; width: 33%;">[[File:Historias de usuario portada.jpg|center|150px|link=]]</td>
</tr>
<tr>
<td style="text-align: center; width: 33%;">[[File:Scrum master 22.png|50px|link=]]</td>
<td style="text-align: center; width: 33%;">[[File:Scrum level 22.png|50px|link=]]</td>
<td style="text-align: center; width: 33%;">[[File:Product-owner user-stories 22.png|50px|link=]]</td>
</tr>
<tr>
<td style="text-align: center; width: 33%;">[[File:Icon descargar pdf.png|100px|link=https://www.scrummanager.com/files/scrum_master.pdf|]] </td>
<td style="text-align: center; width: 33%;">[[File:Icon descargar pdf.png|100px|link=https://scrumlevel.com/files/scrumlevel.pdf|]] </td>
<td style="text-align: center; width: 33%;">[[File:Icon descargar pdf.png|100px|link=https://www.scrummanager.com/files/scrum_manager_historias_usuario.pdf|]] </td>
</tr>
<tr>
<td style="text-align: center; width: 33%;"> versión 3.07 </td>
<td style="text-align: center; width: 33%;"> versión 3.22 </td>
<td style="text-align: center; width: 33%;"> versión 3.01 </td>
</tr>
</table>

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;>[[Glosario de términos]] | [[:Special:Random|Mostrar una página aleatoria]]</div>

<hr>

<center>[https://scrummanager.com/website/c/search/list-centre.php Centros de formación y certificación Scrum Manager®] | [https://scrummanager.com/website/c/info/faqs.php?academic#academic_certification_framework Acerca del marco de formación y certificación]</center>


<center>Para solicitar más información o cursos para empresas o grupos: [[File:Mail info scrum manager.png]] </center>
<center>Puedes seguir a Scrum Manager en</center>

<center>
<table style="text-align: left; width: 100px;" border="0"
cellpadding="2" cellspacing="2">
<tr>
<td style="width: 54px;">[[File:Blog ico 50.jpg|25px|link=https://www.scrummanager.com/blog|]]</td>
<td style="width: 54px;">[[File:Linkedin ico 50.jpg|25px|link=https://www.linkedin.com/company/5013857|]]</td>
<td style="width: 54px;">[[File:Twitter ico 50.jpg|25px|link=https://twitter.com/scrummanager|]]</td>
<td style="width: 54px;">[[File:Facebook ico 50.jpg|25px|link=http://www.facebook.com/pages/Scrum-Manager/144889095527292|]]
<td style="width: 54px;">[[File:Youtube icon.png|25px|link=https://www.youtube.com/user/scrummanager|]]
</td>
</tr>
</table>
</center>

<center> [https://scrummanager.com/ Web e información] | [https://www.scrummanager.com/common_files/cookies_oks.html cookies] </center>

Criterios de aceptación

2023-03-02T15:25:25Z

Smanager: Created page with "Los criterios de aceptación definen qué requisitos mínimos debe cumplir una historia de usuario para determinar que ésta funciona adecuadamente. A diferencia de la definición de hecho, los criterios de aceptación se centran en cada elemento de la pila del producto por separado. Suelen presentarse en formato de lista o flujo, y pueden escribirse en lenguaje natural, tal y como el product owner o el miembro del equipo que sugiera cada criterio se ex..."

Los criterios de aceptación definen qué requisitos mínimos debe cumplir una [[historia de usuario]] para determinar que ésta funciona adecuadamente. A diferencia de la [[definición de hecho]], los criterios de aceptación se centran en cada elemento de la [[pila del producto]] por separado.

Suelen presentarse en formato de lista o flujo, y pueden escribirse en lenguaje natural, tal y como el [[product owner]] o el miembro del equipo que sugiera cada criterio se exprese. Lo importante es que ayuden a recordar de forma breve y clara la intención detrás de cada criterio.

Feature shoot-out

2023-02-21T17:59:42Z

Smanager:

'''''Feature shoot-out''''' ("tiroteo de características" en español) es un taller utilizado por autores como B. Gloger, R. Mittermayr, A. Opelt y P. Wolfgang para negociar contratos ágiles de precio fijo, pero que puede aplicarse a otros tipos de contratos.

Uno de los mayores desafíos durante un proceso de negociación de un contrato es la incertidumbre. Si el cliente no está familiarizado con las metodologías ágiles, la idea de un alcance variable, por ejemplo, puede generar desconfianza. Pero existen estrategias y herramientas diseñadas para informar al cliente, hacerle entender los beneficios que puede aportar a su negocio trabajar con metodologías ágiles.

Una de estas estrategias es '''''feature shoot-out'''''. Consiste en invitar a nuestros clientes a un concurso de características donde se comparen los beneficios de los diversos tipos de contratos. Permite al cliente ver los beneficios de un contrato ágil y también puede resultar útil para convencer a un círculo más amplio de empleados del cliente. De esta forma, es más fácil suavizar el rechazo u oposición a una metodología ágil y, por tanto, a un contrato ágil.

==Estructura==

Es un taller con sesiones de una duración aproximada de dos horas. Se estructura de la siguiente forma:
# Se muestran determinados tipos de contratos más apropiados para el proyecto, tanto ágiles como tradicionales.
# Se apuntan las ventajas y desventajas de cada uno.
# Comienza un debate sobre las ventajas y desventajas individuales de los diferentes tipos de contratos.
# Con el debate se irán descartando tipos de contratos hasta que solo quede uno.

==Materiales==

Pueden usarse apoyos visuales (''flip charts'' y colores) durante las sesiones. Además de ilustrar los resultados con una imagen clara en una ''flip chart'' al final de cada sesión. De este modo se tiene una visión global de cada tipo de contrato y se enseña que cada uno tiene su lugar.

==Referencias==
* Gloger, Boris; Mittermayr, Ralf; Opelt, Andreas & Pfarl, Wolfgang. (2013) ''Agile Contracts: Creating and Managing Successful Projects with Scrum.''

[[Category: Glosario de términos]]

SMART goals

2023-01-10T18:07:27Z

Smanager:

SMART goals es un acrónimo acuñado por George T. Doran. Significa "inteligente" en inglés, y las siglas se usan como medio nemotécnico para recordar una serie de criterios con los que definir objetivos en gestión de proyectos. Un objetivo SMART debe ser:
* Specific (específico): debe ser preciso, claro y comprensible.
* Measurable (medible): debe poder cuantificarse para saber si se está alcanzando.
* Assignable (asignable): debemos poder especificar quién se hará cargo. Éste era el significado original de la A, aunque ahora es más habitual usarla para recordar "attainable" (alcanzable) o "ambitious" (ambicioso).
* Realistic (realista): teniendo en cuenta todo lo demás que se desea conseguir, los recursos disponibles y la situación actual, hay que ajustar y ser realistas.
* Time-related (definido o marcado en el tiempo): se debe especificar para cuándo se espera alcanzar el objetivo, poner fechas límite.

==Significados alternativos para el acrónimo SMART==
El significado que se da a cada letra del acrónimo puede variar. Éstos son los significados y alternativas más comunes:
{| class="wikitable sortable"
! Letra
! Significado habitual
! Alternativas
|-
| S.
| Specific (específico)
| Strategic and specific (estratégico y específico)
|-
| M.
| Measurable (medible)
| Motivating (motivador)
|-
| A.
| Achievable / attainable (alcanzable)
| Assignable (asignable), Agreed (acordado), action-oriented (orientado a actuar), ambitious (ambicioso), aligned with corporate goals (alineado con los objetivos de la empresa)
|-
| R.
| Relevant (relevante)
| Realistic (realista)
|-
| T.
| Time-bound (limitado en el tiempo)
| Trackable (trazable), time-oriented (centrado en el tiempo), time/cost limited (limitado por el tiempo y el coste), timely (oportuno), time-sensitive o timeframe (en tiempo limitado), testable (testeable)
|}

==Recomendaciones de uso de S.M.A.R.T. goals==
Existen estudios que sugieren que el uso de metas específicas y ambiciosas como las que ayuda a elaborar este sistema pueden ser contraproducentes en algunos contextos.

===Contextos adecuados===
Son aconsejables cuando el resultado que se desea obtener está dentro de un ámbito en el que el equipo ya tiene experiencia, pues en ese caso serán capaces de imaginar soluciones para alcanzarlo. Una meta ambiciosa y medible en estos casos ayuda a concentrar esfuerzos y puede ser una fuente de motivación.

===Contextos contraindicados===
Cuando el resultado que se desea es más abstracto, complejo, o en un ámbito poco familiar para el equipo, en cambio, una meta así puede desmotivar. El equipo puede verse desbordado al no saber cómo abordar el problema. Según las encuestas, en estos casos funciona mejor proponer un objetivo más vago, como "hacer lo posible", para que haya menos presión y margen para maniobrar y experimentar.
Si el equipo está empezando a trabajar en un ámbito nuevo también se aconseja que los primeros objetivos se centren en investigación, en lugar de metas de rendimiento.

==Referencias==
* Latham, GP, Locke, Edwin A, & Latham, Gary P. (2002) ''Building a practically useful theory of goal setting and task motivation: A 35-year odyssey.'' ''American Psychologist,'' 57(9), 705-717.

[[Category: Glosario de términos]]
[[Category: Prácticas ágiles]]

Smart

2023-01-10T17:41:10Z

Smanager: Replaced content with "#REDIRECT SMART goals"

#REDIRECT [[SMART goals]]

Pila del producto

2022-12-22T07:54:42Z

Smanager:

En inglés product backlog
Lista ágil de los requisitos del cliente o requisitos del sistema:

*Simples: Expresados de forma breve, con una sentencia para cada uno, habitualmente con formato de historia de usuario o similar.
*Estimados: Está estimado el esfuerzo de construcción de cada requisito.
*Priorizados: Ordenados según la importancia para el cliente o responsable de la lista.

[[File:Requisitos agiles.png|650px|thumb|right]]

La pila del producto es la lista ordenada de todo aquello que el propietario de producto cree que necesita el producto.

Es el inventario de funcionalidades, mejoras, tecnología y corrección de errores que deben incorporarse al producto a través de los sucesivos sprints.
Representa todo aquello que esperan el cliente, los usuarios, y en general los interesados. Todo lo que suponga un trabajo que debe realizar el equipo debe estar reflejado en esta pila.

La pila del producto nunca se da por completada; está en continuo crecimiento y evolución. Al comenzar el proyecto incluye los requisitos inicialmente conocidos y mejor entendidos, y evoluciona conforme avanza el desarrollo.

Gracias a su carácter dinámico refleja aquello que el producto necesita incorporar para adecuarse a las circunstancias, en todo momento.
Antes de empezar a iterar el producto es necesario:
*Que el propietario de producto tenga la visión del objetivo de negocio que quiere conseguir, y la comparta con el equipo.
*Que la pila del producto tenga historias de usuario suficientes para realizar el primer sprint.

Habitualmente se empieza a elaborar la pila del producto con el resultado de una reunión de “tormenta de ideas”, o "fertilización cruzada", o un proceso de “Exploración” (eXtreme Programming) donde colabora todo el equipo, que comprende y comparte la visión del propietario del producto.

El propietario del producto mantiene la pila ordenada por la prioridad de los elementos, siendo los más prioritarios los que confieren mayor valor al producto, o por alguna razón resultan más necesarios, y determinan las actividades de desarrollo inmediatas.
El grado de concreción de las historias de usuario en la pila del producto debe ser proporcional a la prioridad: Las de mayor prioridad deben tener un nivel detalle suficiente para poder descomponerse en tareas y pasar al siguiente sprint.
Los elementos de la pila del producto que pueden ser incorporados a un sprint se denominan “preparados” o “accionables” y son los que pueden seleccionarse en la reunión de planificación del sprint.

===Formato de la pila del producto===
Scrum prefiere la comunicación verbal o de visualización directa, a la escrita.
La pila del producto no es un documento de requisitos, sino una herramienta de información para el equipo.

Si se emplea formato de lista, la información mínima que se suele incluir para cada historia de usuario es:

*Descripción de la funcionalidad/requisito, denominado “historia de usuario”.
*Prioridad.
*Preestimación del esfuerzo necesario.

Y a veces también un código o identificador único de la historia.

Por las características del proyecto o del equipo, se pueden incluir en la pila del producto información adicional como:

*Observaciones.
*Criterio de validación.
*Persona asignada.
*Nº de Sprint en el que se realiza.
*Módulo del sistema al que pertenece…

Un ejemplo del formato que podría tener una pila del producto:

[[File:Ejemplo pila producto.png|550px|center]]

Temas relacionados
*[[Mantenimiento de la pila del producto]]
*[[Artefactos]]

[[Category:Glosario de términos]]
[[Category:Standard scrum]]
[[Category:Prácticas ágiles]]

Scrum Manager BoK

2022-12-19T19:06:54Z

Smanager:

__NOTOC__

<table style="text-align: left; width: 100%;" border="0"
cellpadding="2" cellspacing="3">
<tr>
<td style="text-align: center; width: 33%;">''Agilidad en el equipo''</td>
<td style="text-align: center; width: 33%;">''Agilidad en la empresa''</td>
<td style="text-align: center; width: 33%;">''Ampliación: Historias de usuario''</td>
</tr>
<tr>
<td style="text-align: center; width: 33%;">[[File:Portada scrum master.png|center|150px|link=]]</td>
<td style="text-align: center; width: 33%;">[[File:Portada scrumlevel 3 11b.jpg|center|150px|link=]]</td>
<td style="text-align: center; width: 33%;">[[File:Historias de usuario portada.jpg|center|150px|link=]]</td>
</tr>
<tr>
<td style="text-align: center; width: 33%;">[[File:Scrum master 22.png|50px|link=]]</td>
<td style="text-align: center; width: 33%;">[[File:Scrum level 22.png|50px|link=]]</td>
<td style="text-align: center; width: 33%;">[[File:Product-owner user-stories 22.png|50px|link=]]</td>
</tr>
<tr>
<td style="text-align: center; width: 33%;">[[File:Icon descargar pdf.png|100px|link=https://www.scrummanager.com/files/scrum_master.pdf|]] </td>
<td style="text-align: center; width: 33%;">[[File:Icon descargar pdf.png|100px|link=https://scrumlevel.com/files/scrumlevel.pdf|]] </td>
<td style="text-align: center; width: 33%;">[[File:Icon descargar pdf.png|100px|link=https://www.scrummanager.com/files/scrum_manager_historias_usuario.pdf|]] </td>
</tr>
<tr>
<td style="text-align: center; width: 33%;"> versión 3.07 </td>
<td style="text-align: center; width: 33%;"> versión 3.2 </td>
<td style="text-align: center; width: 33%;"> versión 3.01 </td>
</tr>
</table>

<div class="center" style="width:auto; margin-left:auto; margin-right:auto;>[[Glosario de términos]] | [[:Special:Random|Mostrar una página aleatoria]]</div>

<hr>

<center>[https://scrummanager.com/website/c/search/list-centre.php Centros de formación y certificación Scrum Manager®] | [https://scrummanager.com/website/c/info/faqs.php?academic#academic_certification_framework Acerca del marco de formación y certificación]</center>


<center>Para solicitar más información o cursos para empresas o grupos: [[File:Mail info scrum manager.png]] </center>
<center>Puedes seguir a Scrum Manager en</center>

<center>
<table style="text-align: left; width: 100px;" border="0"
cellpadding="2" cellspacing="2">
<tr>
<td style="width: 54px;">[[File:Blog ico 50.jpg|25px|link=https://www.scrummanager.com/blog|]]</td>
<td style="width: 54px;">[[File:Linkedin ico 50.jpg|25px|link=https://www.linkedin.com/company/5013857|]]</td>
<td style="width: 54px;">[[File:Twitter ico 50.jpg|25px|link=https://twitter.com/scrummanager|]]</td>
<td style="width: 54px;">[[File:Facebook ico 50.jpg|25px|link=http://www.facebook.com/pages/Scrum-Manager/144889095527292|]]
<td style="width: 54px;">[[File:Youtube icon.png|25px|link=https://www.youtube.com/user/scrummanager|]]
</td>
</tr>
</table>
</center>

<center> [https://scrummanager.com/ Web e información] | [https://www.scrummanager.com/common_files/cookies_oks.html cookies] </center>

Learning matrix

2022-11-28T15:50:43Z

Smanager:

''Learning matrix'' (matriz de aprendizaje) es una práctica ágil para [[retrospectiva|reuniones retrospectivas]].

Se suele realizar durante la fase 3 de la reunión, en la que se busca generar ideas e identificar puntos de mejora. Suele durar entre 20 y 25 minutos.

==Cómo preparar la actividad ''Learning matrix''==
La actividad requiere haber recopilado información sobre la [[iteración]] de alguna forma antes, en la fase 2 de la retrospectiva.
El líder de la reunión dibuja una matriz delimitando cuatro secciones:
* Una con un icono sonriente donde apuntar datos positivos, cosas que el equipo quiere mantener en adelante.
* Una con un icono triste donde apuntar lo que el equipo quiere cambiar.
* Una con una bombilla donde apuntar las nuevas ideas que hayan surgido durante el ''[[sprint]]'' o la reunión.
* Una con un ramo de flores donde apuntar cosas por las que el equipo quiera dar gracias o que merezcan reconocimiento.

==Cómo moderar la actividad ''Learning matrix''==
El líder no apunta ni hace valoraciones durante la actividad, pero si la conversación no fluye es responsable de volver a centrar la atención de todos en la información de la fase 2 y preguntar si queda algo por apuntar.

# El primer paso es una tormenta de ideas. El equipo habla sobre la información recopilada en la fase 2 y decide qué apuntar en cada sector. El líder de la reunión puede encargarse de apuntar las ideas conforme van surgiendo, o repartir notas adhesivas para que el equipo las coloque.
# Una vez anotado todo, se prioriza cada una de las ideas. El líder entrega entre 6 y 10 pegatinas a cada miembro del equipo, que pueden colocar a su criterio en aquello que consideren más importante. A más prioridad, más pegatinas.
# Se extrae la lista en orden de prioridades para la siguiente fase de la retrospectiva.

[[Category: Glosario de términos]]
[[Category: Prácticas ágiles]]
[[Category: Prácticas para retrospectivas]]

Learning matrix

2022-11-28T15:50:32Z

Smanager: Created page with "''Learning matrix'' (matriz de aprendizaje) es una práctica ágil para reuniones retrospectivas. Se suele realizar durante la fase 3 de la reunión, en la..."

''Learning matrix'' (matriz de aprendizaje) es una práctica ágil para [[retrospectiva|reuniones retrospectivas]].

Se suele realizar durante la fase 3 de la reunión, en la que se busca generar ideas e identificar puntos de mejora. Suele durar entre 20 y 25 minutos.

==Cómo preparar la actividad ''Learning matrix''==
La actividad requiere haber recopilado información sobre la [[iteración]] de alguna forma antes, en la fase 2 de la retrospectiva.
El líder de la reunión dibuja una matriz delimitando cuatro secciones:
* Una con un icono sonriente donde apuntar datos positivos, cosas que el equipo quiere mantener en adelante.
* Una con un icono triste donde apuntar lo que el equipo quiere cambiar.
* Una con una bombilla donde apuntar las nuevas ideas que hayan surgido durante el ''[[sprint]]'' o la reunión.
* Una con un ramo de flores donde apuntar cosas por las que el equipo quiera dar gracias o que merezcan reconocimiento.

==Cómo moderar la actividad ''Learning matrix''==
El líder no apunta ni hace valoraciones durante la actividad, pero si la conversación no fluye es responsable de volver a centrar la atención de todos en la información de la fase 2 y preguntar si queda algo por apuntar.

# El primer paso es una tormenta de ideas. El equipo habla sobre la información recopilada en la fase 2 y decide qué apuntar en cada sector. El líder de la reunión puede encargarse de apuntar las ideas conforme van surgiendo, o repartir notas adhesivas para que el equipo las coloque.

# Una vez anotado todo, se prioriza cada una de las ideas. El líder entrega entre 6 y 10 pegatinas a cada miembro del equipo, que pueden colocar a su criterio en aquello que consideren más importante. A más prioridad, más pegatinas.

# Se extrae la lista en orden de prioridades para la siguiente fase de la retrospectiva.

[[Category: Glosario de términos]]
[[Category: Prácticas ágiles]]
[[Category: Prácticas para retrospectivas]]

Gráfico de producto

2022-11-23T13:10:12Z

Smanager:

El gráfico de producto o gráfico “burn up” es una herramienta de planificación propia del [[propietario de producto]], que presenta visualmente la evolución previsible del producto.

Proyecta en el tiempo la construcción del producto, en base a la [[velocidad]] del equipo.

La proyección se realiza sobre un diagrama cartesiano que representa en el eje de ordenadas el esfuerzo estimado para construir las diferentes historias de la pila del producto, y en el de las abscisas el tiempo medido en sprints.

[[File:Burn_up_1.png|550px|thumb|center|'''Ejes del gráfico de producto''']]

====Ejemplo====

Convenciones empleadas por el equipo:
*Unidad para medición del trabajo: [[Punto de función|puntos de scrum]].
*Está previsto trabajar con [[Sprint|sprints]] de duración fija mensual (20 días laborables).
*El equipo está formado por 4 personas y desarrolla una velocidad media de 400 puntos por sprint.

[[File:Burn-up5.png|550px|thumb|center|'''Equipo de 4 personas velocidad de 400 puntos por sprint''']]

Se traza en el gráfico la línea que representa el ritmo de avance previsto según la velocidad media del equipo (en este ejemplo 400 puntos por sprint).

Es recomendable trazar también los ritmos de avance con una previsión pesimista y otra optimista. Se dibujan basándose en información de los proyectos anteriores que han ido peor y mejor de lo previsto, o en su defecto estableciendo un margen según el criterio del equipo (ej. +- 20%).

[[File:Burn_up_2.png|550px|thumb|center|'''Ejes del gráfico de producto''']]

A continuación se toma la [[pila del producto]].

En este caso, el propietario del producto tiene previsto lanzar la versión 1.0 cuando disponga de las cuatro primeras [[Historia de usuario|historias]], que tienen un esfuerzo estimado de 950 puntos (150+250+250+300).

Además, según refleja la imagen siguiente, también tiene esbozadas las previsiones para las versiones posteriores 1.1 y 1.2.

[[File:Pila de producto y estimacion de versiones.jpg|550px|thumb|center|'''Pila de producto y versiones previstas''']]

Para trazar la previsión se sitúa cada versión en el eje vertical en la posición correspondiente al esfuerzo estimado para construir todas las historias que incluye.

Siguiendo con el ejemplo, la posición de la versión 1.0 se situaría sobre el valor 950 del eje de ordenadas:

[[File:Burn_up_4.png|550px|thumb|center|'''Se sitúan las versiones previstas sobre el eje de ordenadas.''']]

Los puntos de corte que marca esta posición con las líneas de velocidad del equipo (pesimista, realista y optimista) proyectan en el eje horizontal la fecha o sprint en el que se completará la versión.

[[File:Burn_up_3.png|550px|thumb|center|'''Pila de producto y versiones previstas''']]

Esta es una herramienta para desarrollo ágil.

Proyecta la previsión de la pila del producto, que es un documento vivo cuya evolución preestablece la del producto. Como herramienta ágil no debe considerarse para representar planes estables, sino las previsiones tras cada evolución de la pila del producto.

[[Category:Glosario de términos]]
[[Category:Prácticas ágiles]]

File:Burn up 4.png

2022-11-23T13:07:04Z

Smanager:

File:Burn up 3.png

2022-11-23T13:06:47Z

Smanager:

File:Burn up 2.png

2022-11-23T13:06:34Z

Smanager: