
El recurso más importante para respaldar el examen PSM I es La Guía de Scrum. Asegúrate de haber leído La Guía de Scrum muchas veces. Además, consulta el Glosario de Scrum y observa si te has familiarizado con todos los términos de Scrum. Muchos de los términos de Scrum que se encuentran en el Glosario de Scrum, aparecerán en el examen.
En esta lección presentamos una empresa imaginaria que vende productos orgánicos, y al equipo designado para diseñar una nueva solución para comercio electrónico usando el marco de trabajo Scrum.
Scrum es un marco para abordar trabajos complejos, como el desarrollo de nuevos productos.
Lo que Scrum hace es tomar un poco de todos los pasos necesarios para desarrollar un producto (como los requisitos, análisis, diseño, desarrollo, pruebas) y ponerlos en una iteración de duración fija llamada sprint. De esa manera, un sprint combina todos los aspectos del trabajo.
Scrum define tres roles: Dueño de Producto, Equipo de Desarrollo, Scrum Master, y todos forman parte del Equipo Scrum.
El Dueño de Producto creará una lista de características, denominada Lista del Producto, y las organizará por importancia.
Durante la Planificación del Sprint, el Equipo de Desarrollo seleccionará una lista de elementos del comienzo de la lista del producto e intentará convertirlos en un incremento de producto potencialmente transportable.
El equipo tiene un marco de tiempo fijo para completar el trabajo y se reúnen en un scrum diario para sincronizar, identificar problemas y mantener el trabajo andando.
En el proceso, el Scrum Master mantiene al equipo enfocado en el Objetivo del Sprint.
Los artefactos en Scrum representan trabajo o valor. Proveen transparencia y oportunidades para la inspección y la adaptación.
La Guía de Scrum define tres artefactos de Scrum:
Lista de Producto (Product Backlog)
Lista de Pendientes del Sprint (Sprint Backlog)
Incremento
Scrum está basado en la transparencia, la inspección, y la adaptación.
El trabajo del Scrum Master trabajar con todos los que están dentro y fuera del Equipo Scrum para garantizar que los artefactos son transparentes.
En Scrum, la Lista de Producto, o Product Backlog, es un artefacto diseñado para brindar transparencia y oportunidades para la inspección y para la adaptación.
El Product Backlog está constituido por una lista ordenada de todo lo que el producto necesita. Es una lista de requisitos que pueden ser nuevas características o mejoras, correcciones, o cualquier otro cambio que se necesite realizar al Producto. En tanto exista el Producto, va a existir su Product Backlog.
Cómo es descripto un Elemento del Product Backlog es una facultad del Equipo Scrum. La Guía de Scrum no ofrece diseños previos ni brinda recomendaciones al respecto de su formato. En la práctica, es muy común que el Equipo Scrum utilice Historias de Usuario. De hecho es tan frecuente, que los elementos del Product Backlog son referidos simplemente como historias.
La Guía de Scrum no impone una forma específica de administrar la Lista de Producto, en términos de cómo se deben escribir los Elementos de la Lista de Producto.
La Guía de Scrum no hace sugerencias al respecto. Los Equipos Scrum generalmente son libres de decidir qué prefieren usar. Y esto puede ser a través de simples notas adhesivas, ubicadas en un tablero para que sean transparentes para todos y para facilitar la planificación y las discusiones, o directamente a través de una herramienta de software.
En organizaciones que ya practican metodologías ágiles, tales herramientas de software ya están disponibles. El uso de una herramienta de software para esta tarea también puede facilitar la adaptación del contenido.
Es común que las organizaciones de hoy en día utilicen un Product Backlog digital y un Tablero Scrum digital. Si bien existen muchas herramientas, muchas empresas utilizan Jira, creada por Atlassian para administrar sus proyectos Agile, incluidos Scrum y Kanban.
Este video muestra cómo crear una Lista de Producto en Jira.
Ahora las Historias (Elementos de la Lista de Producto) tienen una descripción, una descripción de prueba y un pedido. Como puedes notar, la Historia aún no está completa. El siguiente paso sería tomar este Elemento de la Lista de Producto escrito como una Historia de Usuario y discutirlo con el Equipo para aclarar los detalles, agregar orden y obtener una estimación.
Esta colaboración entre el Dueño de producto y el Equipo de Desarrollo se produce durante la reunión de Refinamiento del Product Backlog.
Después de que el Equipo de Desarrollo haya estimado una Historia, el Dueño del Producto puede ingresar esa estimación en la herramienta de software utilizada para administrar la Lista de Producto, en nuestro caso Jira.
El Dueño del Producto también puede definir una escala y usar Puntos de Valor. De esta manera, cada Historia de Usuario también tendrá una cantidad de puntos de valor asignados.
El Sprint Backlog transparenta todo el trabajo que el Equipo de Desarrollo considera necesario para alcanzar el Objetivo del Sprint.
El Sprint Backlog puede verse como un artefacto temporal que existe solo durante el Sprint. El Sprint Backlog es responsabilidad del Equipo de Desarrollo.
El Equipo de Desarrollo modificará el Sprint Backlog a lo largo de todo el Sprint. Es una descomposición de cada elemento del Product Backlog en unidades de trabajo más pequeñas que permiten al Equipo construir el incremento.
El Sprint Backlog se crea durante la Reunión de Planificación de Sprint. El Equipo de Desarrollo extraerá los elementos del Product Baclog y los colocará en el Sprint Backlog
Este video muestra cómo crear un Sprint Backlog en Jira.
El Incremento (o Incremento de Producto) está representado por todos los Product Backlog Items completados durante un Sprint más el valor de todos los Incrementos de todos los Sprints anteriores.
Es decisión exclusiva del Dueño de Producto si se debe liberar el Incremento y cuándo, pero éste debe estar en condiciones de usabilidad.
Cuando un Product Backlog Item se considera terminado o "Done", todos deben entender lo que esto significa.
Para que sea más fácil para todos entender esto, el Equipo Scrum debería crear una Definición de Terminado que se pueda usar para evaluar si el trabajo realizado está de acuerdo con la definición.
Por lo tanto, cada Sprint creará un Incremento de producto que debe cumplir con la Definición de Terminado.
A medida que el Equipo Scrum gane más experiencia, se espera que la Definición de Terminado contenga criterios más estrictos que garanticen una mayor calidad.
Al final de cada Sprint, el Incremento debe "hacerse", de acuerdo con la Definición de Terminado.
Este es un ejemplo de la "Definición de Terminado". Cada Equipo de Desarrollo u organización de desarrollo puede formular la Definición de Terminado de un modo diferente.
Algunos Equipos Scrum también prefieren tener una definición de "Ready" (Listo).
Al igual que la Definición de Terminado, la Definición de Listo se refiere a los Product Backlog Items (Elementos de la Lista de Producto), pero en este caso, a los que aun se encuentran en el Product Backlog y que están por ser seleccionados para el Sprint Backlog por el Equipo de Desarrollo.
Scrum utiliza eventos prescritos (o reuniones de Scrum, o ceremonias de Scrum) para crear una rutina y reducir la necesidad de otras reuniones que no están definidas en Scrum.
En el corazón de Scrum está el Sprint, que actúa como un contenedor para todos los eventos. Todos los eventos dentro de Scrum tienen un timebox.
Scrum definió los siguientes eventos:
Planificación de Sprint (donde se planifica el trabajo a realizar en el Sprint)
Scrum Diario (que se realiza todos los días del Sprint)
Revisión del Sprint (que se realiza al final del Sprint para revisar el Incremento)
Retrospectiva de Sprint (que es una oportunidad para mejorar el proceso)
Todos los eventos son una oportunidad formal para inspeccionar y adaptar.
Un Sprint tiene un plazo de un mes o menos en el que se crea un Incremento de Producto potencialmente entregable. Un Sprint contendrá todos los eventos Scrum prescritos, un plan flexible sobre cómo construir el Incremento de Producto y, por supuesto, el trabajo de desarrollo necesario.
Un nuevo Sprint comienza inmediatamente después de que el Sprint anterior haya finalizado. No hay brecha entre Sprints y nada debe suceder entre los Sprints.
La reunión de Planificación de Sprint tiene un límite de tiempo de hasta ocho horas para un Sprint de un mes.
Durante este evento, el Dueño de Producto y el Equipo de Desarrollo acordarán un objetivo de Sprint y analizarán qué elementos del Product Backlog se agregarán al Sprint Backlog.
Una vez que se ha definido el Objetivo de Sprint y se seleccionaron los Product Baclog Items para el Sprint, el Equipo de Desarrollo analiza cómo se integrará la funcionalidad en un Incremento de Producto.
Al final de esta reunión, el trabajo planeado se descompone para los primeros días del Sprint, a menudo en unidades de un día o menos. Debido a que el trabajo surge durante el Sprint, esta reunión no puede identificar todo el trabajo que debe hacerse por adelantado. Es solo un plan con suficiente detalle para que el trabajo de desarrollo pueda comenzar.
El Equipo de Desarrollo debería poder explicar al Dueño de Producto y al Scrum Master cómo planean lograr el Objetivo de Sprint y crear el incremento de producto previsto.
El Scrum Diario (Daily Scrum) es un evento que se sucede dentro de un timebox, y que se celebra a la misma hora y lugar cada día para reducir la complejidad. El Daily Scrum se celebra todos los días durante el Sprint y es un evento destinado al Equipo de Desarrollo.
El Daily Scrum ayuda al Equipo de Desarrollo a inspeccionar el progreso destinado a completar el trabajo en el Sprint Backlog y alcanzar el Objetivo de Sprint.
Independientemente del tamaño del Equipo, el Daily Scrum es un evento de 15 minutos.
Durante el Daily Scrum, el Dueño de Producto, el Scrum Master u otras partes no están presentes. Esta es una reunión interna del Equipo de Desarrollo.
Un Tablero Scrum es una herramienta que ayuda al Equipo de Desarrollo a hacer transparentes los elementos de Sprint Backlog.
El tablero puede ser una simple pizarra con post-it para cada tarea o una pizarra digital. Ten en cuenta que la Guía de Scrum no menciona el término "Tablero Scrum".
El Tablero Scrum se actualizará constantemente por el Equipo de Desarrollo, mostrando todo el trabajo en tres columnas: Por Hacer, En Curso, Listo.
Al final del Sprint, el Equipo de Desarrollo debería haber entregado un Incremento de Producto potencialmente enviable.
La Revisión de Sprint (Sprint Review) se lleva a cabo al final del Sprint para inspeccionar el Incremento del Producto y adaptar el Product Backlog si es necesario.
El Dueño del Producto es el dueño de esta reunión e invitará a las Partes Interesadas relacionadas a este evento. También participan el Equipo de Desarrollo y el Scrum Master. El rol de Scrum Master es facilitar esta reunión y asegurarse de que se lleve a cabo dentro del timebox.
La Revisión de Sprint es una reunión informal. Se realiza la demostración del Incremento para obtener comentarios y alentar la colaboración sobre lo que se debe hacer a continuación.
¿Qué sucede con los elementos incompletos del Product Backlog?
Los elementos del Product Backlog que aún no se han hecho o que no se han hecho por completo (por ejemplo, se ha creado alguna funcionalidad pero se necesita más o las pruebas aún no se han completado), en primer lugar, no se demostrarán durante esta reunión y no deberían formar parte del Incremento del Producto. Se volverán a colocar en el Product Backlog.
La Retrospectiva de Sprint es el último evento en Sprint, justo después de la Revisión de Sprint pero antes de la próxima Planificación de Sprint. El objetivo de la Retrospectiva de Sprint es inspeccionar y adaptar el proceso de desarrollo.
La Retrospectiva de Sprint es un evento interno del Equipo Scrum en el que no participan partes externas.
La Retrospectiva de Sprint es, como está implícito, un evento en un timebox. Para un sprint de un mes, la duración máxima es de 3 horas.
La Guía Scrum no entra en muchos detalles respecto de la Retrospectiva de Sprint y solo explica las reglas, el propósito y el resultado deseado. Si bien la Guía de Scrum no lo hace explícito, el Scrum Master es normalmente quien planifica y organiza esta reunión.
Normalmente, en las Retrospectivas se usan notas adhesivas y bolígrafos, por lo que debería haber muchos de estos disponibles.
La reunión generalmente comenzará con un ejercicio para romper el hielo o haciendo ejercicios de calentamiento. Este paso no solo da inicio a la reunión, sino que ayuda con la formación de equipos y a comenzar con la interacción grupal.
Luego, la reunión puede proceder sin problemas con un simple check-in para ver cómo se sienten todos. Un ejercicio es dibujar una cara sonriente en un post-it y ponerlo en algún lugar de la pizarra. Esto puede expresar, por ejemplo, cómo fue el último Sprint para ese miembro en particular.
Luego viene la parte central del evento. La idea detrás de la próxima actividad es recopilar datos sobre el Sprint. Por lo general, se establece un timebox en el que cada miembro del Equipo Scrum reflexiona sobre el Sprint y escribe ideas.
A continuación, el equipo intentará discutir los temas más importantes dentro de un timebox. El objetivo de la reunión es identificar mejoras. Entonces, el equipo discutirá los problemas que encontraron durante el Sprint y pensará en posibles soluciones.
La Retrospectiva puede incluir una actividad final en la que se aclaran las mejoras, la decisiones o cualquier punto de acción identificados.
Cancelar un Sprint antes de que caduque el timebox es algo muy infrecuente. De hecho es algo que a mí no me ha sucedido hasta el momento. Pero debe ser consciente de que esta es una posibilidad.
El equipo Scrum consta de un Dueño de Producto… el Equipo de Desarrollo… y un Scrum Master.
Lo importante es recordar que los Equipos Scrum son auto-organizados y multi-funcionales.
Auto-organizados: eligen la mejor manera de realizar su trabajo, en lugar de ser dirigidos por otros desde fuera del equipo. Significa que toman las decisiones respecto de cómo se debe construir el producto, pero también sobre otros aspectos de su trabajo.
Multi-funcionales: tienen todas las habilidades necesarias para realizar el trabajo, sin depender de otros que no forman parte del equipo (especialmente cuando se trata, por ejemplo, de la experiencia técnica necesaria para crear el producto).
La responsabilidad principal del Dueño de Producto es maximizar el valor del producto resultante del trabajo del Equipo de Desarrollo.
El Dueño de Producto es una persona, no un comité, ni un grupo de personas o cualquier cosa por el estilo. El hecho de que el Dueño de Producto sea una persona no se ha decidido al azar, sino que se tomó una decisión intencionalmente en Scrum. Y esto tiene que ver con la responsabilidad. El Dueño de Producto es, en última instancia, el único responsable del resultado, por lo que nadie debe pasarlo por alto en lo que respecta a las decisiones (como el orden interno del Product Backlog).
El Dueño de Producto es la única persona responsable de administrar el Product Backlog. Por lo tanto, el Dueño de Producto debe asegurarse de que el Equipo de Desarrollo exprese y comprenda claramente los elementos del Product Backlog.
¿El Dueño de Producto es un Gerente Proyecto?
Para ser claros, no existe un rol de Gerente de Proyecto, o Project Manager, en Scrum y, en general, el rol de Dueño de Producto no debe confundirse con un Project Manager. En Scrum, las responsabilidades de un gerente de proyecto tradicional se distribuyen entre el Dueño de Producto, el Scrum Master y el resto del equipo.
El Equipo de Desarrollo está formado por especialistas que tienen todas las habilidades para hacer el trabajo necesario. Su objetivo es crear un Incremento de producto potencialmente entregable al final de cada Sprint. Vale la pena mencionar que solo los miembros del Equipo de Desarrollo pueden trabajar en el Incremento del producto. El equipo es auto-organizado y multi-funcional.
El equipo de desarrollo está estructurado y capacitado por la organización para organizar y administrar su propio trabajo. De esta forma, se optimiza la eficiencia y efectividad del Equipo de Desarrollo.
Scrum no reconoce ningún título oficial para el equipo de desarrollo, independientemente del trabajo que realizan (desarrollo de software, arquitectura, pruebas, diseño, etc).
¿Qué tan grande debe ser el Equipo de Desarrollo?
Si el Equipo de Desarrollo es demasiado pequeño, puede encontrar limitaciones de habilidad durante el Sprint, lo que hace que el Equipo de Desarrollo no pueda alcanzar un Incremento de producto potencialmente entregable.
Tener demasiados miembros en el equipo tampoco es una buena idea. Tener más de nueve miembros requiere demasiada coordinación entre ellos, por lo que todo el proceso se vuelve demasiado complejo.
El tamaño óptimo del Equipo de Desarrollo es de entre 3 y 9 miembros.
El Scrum Master asiste al Equipo de Desarrollo y al Dueño de Producto y es responsable de promover y apoyar a Scrum dentro de la organización. Podemos ver al Scrum Master como un "entrenador de Scrum". El Scrum Master está haciendo esto al ayudar a todos a comprender la teoría, las prácticas, las reglas y los valores de Scrum.
El Scrum Master ayuda a aquellos que están fuera del Equipo Scrum (por ejemplo, las Partes Interesadas) a comprender cuáles de sus interacciones con el Equipo Scrum son útiles y cuáles no.
Respecto del Equipo Scrum en sí mismo, el Scrum Master es un servicio líder experto. El Scrum Master no es un administrador o alguien con autoridad formal. El Scrum Master es un facilitador y un entrenador y el objetivo es servir al Equipo Scrum para maximizar el valor creado.
¿Cómo sirve el Scrum Master al Equipo de Desarrollo?
El Scrum Master tiene que defender el empoderamiento que tiene el Equipo de Desarrollo y capacitarlo con respecto a la auto-organización y la funcionalidad cruzada.
Un servicio importante es el de ayudar al Equipo de Desarrollo a crear productos de alto valor. El Scrum Master tiene éxito si el equipo tiene éxito.
El Scrum Master ayuda a eliminar esos impedimentos independientemente de su naturaleza. A veces, el Scrum Master necesitará trabajar con personas dentro de la organización para abordar esos problemas. Cualquier problema no resuelto pone en peligro el resultado de Sprint y, por lo tanto, el Scrum Master debe actuar con prontitud.
El Scrum Master también facilita los eventos Scrum según sea solicitado o necesario, Ponemos énfasis en la palabra facilitador. No hoy que malinterpretar que "facilitar reuniones" significa organizarlas, reservar y organizar salas o cualquier otra cosa. El Scrum Master no es el secretario del equipo.
¿Cómo sirve el Scrum Master al Dueño de Producto?
El Scrum Master entrena al Dueño de Producto para comprender las prácticas ágiles en Scrum. Esto significa que el Scrum Master debe capacitar al Dueño de Producto para comprender y aplicar los beneficios y las buenas prácticas de Agile y Scrum.
También es extremadamente importante que el Equipo de Desarrollo y el Dueño de Producto comprendan la necesidad de Product Backlog Items claros y concisos y que el Scrum Master esté allí para ayudar con esto también.
Con el fin de maximizar el valor, el Scrum Master asesorará al Dueño de Producto sobre cómo administrar el Product Backlog, para asegurarse de que esté ordenado y en un estado saludable.
El Scrum Master también puede facilitar la planificación y los eventos de refinamiento del Product Backlog según sea necesario o solicitado por el Dueño de Producto.
Cómo Sirve el Scrum Master a la Organización
El Scrum Master lidera y entrena a la organización en su adopción de Scrum y planea las implementaciones de Scum. Por ejemplo, el Scrum Master puede interactuar y colaborar con diferentes departamentos que deben hacer modificaciones para tener éxito con Scrum. El Scrum Master tiene que explicar por qué es necesario un cambio y guiar a la organización en esa dirección. El Scrum Master puede trabajar en colaboración con otros Scrum Masters dentro de la organización para lograr estos objetivos.
El Scrum Master también puede causar cambios que aumenten la productividad del Equipo Scrum. Por ejemplo, mejorando los procesos internos que afectan al Equipo y que causan demoras.
A veces, las Partes Interesadas u otras personas dentro de la organización no entienden Scrum y el desarrollo empírico de productos, y el Scrum Master está allí para capacitarlos en estos temas.
¿Qué es Agile y de dónde viene?
Generalmente en el desarrollo de software, Agile describe una forma en la que surgen los requisitos comerciales y las posibles soluciones a través del esfuerzo conjunto de equipos auto-organizados y multi-funcionales, y sus clientes o usuarios finales.
El término Agile, utilizado en este contexto, proviene del Manifiesto para el Desarrollo de Software Agile.
Scrum es un marco de trabajo utilizado para gestionar el trabajo en productos complejos, no solo en el desarrollo de software.
El uso de este marco ayuda a abordar problemas de adaptación complejos, al tiempo que ofrece productiva y creativamente productos del mayor valor posible.
Para comprender mejor de dónde viene Scrum, es importante comprender lo que sucedió antes de que Scrum se introdujera. En el pasado, se ha realizado un gran desarrollo de software y todavía se realiza utilizando el modelo Waterfall.
Scrum es ampliamente adoptado en la industria del desarrollo de software, pero Scrum no solo se usa para desarrollar software.
Scrum se basa en el empirismo (la teoría de control del proceso empírico). Esto significa que el conocimiento proviene de la experiencia pasada y las decisiones se toman en función de lo que se conoce. Scrum nunca se trata de saber o planificar todo por adelantado.
Los valores de Scrum son compromiso, coraje, foco, apertura y respeto. Scrum se basa en tres pilares: transparencia, inspección y adaptación.
Scrum.org proporciona otro marco de trabajo para resolver cómo escalar el marco de Scrum. Este marco adicional se llama Marco Nexus y se describe en la Guía Nexus.
Recuerda que el contenido de la Guía Nexus no forma parte del examen Scrum.org PSM I. La Guía Nexus presenta muchos otros términos que pueden confundirte, por lo que, por esa razón, no lo recomiendo necesariamente.
En esta sección, repasaremos los aspectos más importantes que son relevantes para el examen y te explicaré todas las reglas que necesitas saber.
La regla más importante que debe recordar cuando varios equipos trabajan en el mismo Producto.
1 Producto = 1 Product Backlog = 1 Dueño de producto
Entonces, para múltiples Equipos Scrum, habrá un nuevo Equipo de Desarrollo y un Scrum Master. El Dueño de Producto será la misma persona.
Es importante recordar que solo hay un Product Backlog. No habrá Backlogs separados para cada equipo.
Durante la reunión de Planificación de Sprint, los Equipos de Desarrollo aún extraerán elementos del Product Backlog de acuerdo con el Dueño de Producto. Por lo tanto, el Dueño de Producto y los Equipos de Desarrollo colaborarán para encontrar soluciones que tengan sentido para ellos.
Cuando varios Equipos Scrum comienzan a trabajar en el mismo producto, surgen diferentes desafíos.
La preocupación clave, en este caso, es reducir tanto como sea posible las dependencias entre los equipos.
1 Producto = 1 Product Backlog = 1 Dueño de Producto
Multiples Equipos trabajando en el mismo producto = 1 Dueño de Producto
Es importante tener una sola persona responsable de los resultados finales. Tener un comité / varias personas puede complicar la toma de decisiones (ya que todos deben estar de acuerdo o se debe llegar a una negociación). Cuando se hacen negociaciones, la decisión puede no ser la mejor. Esto también deja en claro quién es responsable de qué, ya que la propiedad compartida puede conducir a la no propiedad (es un problema del otro, no mío).
Si una sola persona está involucrada, está claro qué persona es responsable de los resultados. Cuando hay varias personas involucradas y las cosas no funcionan bien, puede ser un proceso complejo descubrir qué es lo que no funcionó.
Tener múltiples Dueños de Producto puede conducir a problemas de microgestión y coordinación.
No hay Dueños de Producto Principales ni Dueños de Producto Jefe en Scrum.
Scrum no tiene un requisito que establezca que los Sprints estén alineados. El único requisito es que el trabajo se integre al final del Sprint. Si todos los equipos tienen la misma duración de Sprint y las mismas fechas de inicio / finalización, esto será un poco más fácil de administrar.
Si los Equipos Scrum tienen diferentes duraciones de Sprint (por lo que los Sprints no están alineados), este proceso será más difícil pero aún está contemplado dentro de las reglas de Scrum.
Recuerda que no hay Sprints de Integración en Scrum.
Una distinción importante es que una persona puede jugar diferentes roles en Scrum. Si bien esto no es relevante para el examen, en la práctica puede ser confuso. Entonces el rol no necesariamente define a una persona.
Una persona puede jugar múltiples roles. La Guía de Scrum establece condiciones en los roles, no en personas individuales.
Un gráfico Burndown es una representación gráfica del trabajo que queda por hacer (generalmente representado en puntos de tiempo o de historia) a lo largo del tiempo. El trabajo se ubica generalmente en el eje vertical, y el tiempo a lo largo del eje horizontal.
Este cuadro se usa para estimar cuándo se completará todo el trabajo en un Sprint. Si bien los gráficos burndown se pueden usar en proyectos Agile, también se pueden aplicar a cualquier proyecto que contenga un progreso medible a lo largo del tiempo.
El Gráfico Burnup proporciona una representación visual del trabajo completado de un Sprint relacionado con su alcance total, que se representa por el número de Elementos (o Historias) del Product Backlog seleccionado.
Es bastante similar al gráfico Burndown con la diferencia de que cualquier trabajo agregado será visible en un cambio del alcance.
Una o dos preguntas en el examen real podrían contener una referencia al término deuda técnica. Si bien la deuda técnica es un término que no aparece en La Guía de Scrum, se menciona en el Glosario.
En términos generales, la deuda técnica es algo que debe tratarse constantemente y no posponerse. Es parte del proceso de desarrollo y es un proceso continuo (similar a la arquitectura del producto que se trabaja y mejora constantemente).
Está estrechamente relacionado con la calidad del producto y el Equipo de Desarrollo debe trabajar constantemente junto con el Dueño de Producto para mantener la deuda técnica manejable.
El término Cono de Incertidumbre es usado en el desarrollo de software en el cual el entorno técnico y comercial está constantemente evolucionando.
La Velocidad del Equipo de Desarrollo (o simplemente la Velocidad) es una medida de la cantidad de trabajo que un Equipo de Desarrollo puede manejar durante un Sprint normal.
Esto se calcula promediando la cantidad de trabajo realizado en los Sprints anteriores y puede usarse para tener una idea de lo que es posible lograr en un Sprint.
Recuerde que esta es una métrica opcional y está destinada solo para el Equipo Scrum. Además, no hay compromisos en Scrum (por ejemplo, para los Product Backlog Items seleccionados) y nadie es castigado si la estimación resulta ser inexacta.
Los estándares de ingeniería se refieren a un conjunto de reglas y convenciones dentro de la organización de desarrollo que se aplica a todo el Producto que se está desarrollando.
El examen de Scrum PSM I puede incluir preguntas que hablan sobre equipos de Funciones y equipos de Componentes. Al igual que con muchos otros términos, el examen intenta comprobar algunos conocimientos prácticos, pero La Guía de Scrum no los menciona.
Equipo de Funciones: trabaja a través de todas las capas de la aplicación para satisfacer las necesidades de un cliente o usuario. Un equipo de Funciones es multi-funcional y de multi-componentes, porque tiene todas las habilidades necesarias para completar una función y lo hace trabajando a través de todas las capas o componentes de la aplicación.
Equipo de Componentes (o un equipo de capa): se centra en un solo componente del sistema. Varios equipos de componentes deberían trabajar juntos para ofrecer una función.
Algunas preguntas del examen de Scrum PSM I pueden hacer referencia al término ritmo sostenible. Cuando se realiza un trabajo de desarrollo, es importante poder tener resultados constantes.
Un requisito funcional es un requisito que el Dueño de Producto, las pPartes Interesadas y los usuarios del Producto pueden comprender fácilmente. Un requisito funcional describe una función del Producto.
Los requisitos no funcionales describen cualidades, comportamientos, atributos y restricciones del Producto y pueden clasificarse en múltiples categorías: rendimiento, seguridad, disponibilidad y usabilidad, por nombrar solo algunos ejemplos.
Los Sprints de Endurecimiento o de Integración, normalmente son Sprints separados en los que no se desarrollan nuevas características. Algunas organizaciones han adoptado Sprints de Endurecimiento para integrar (fusionar) el trabajo de múltiples Equipos de Desarrollo y probar el Incremento antes de que entre en producción.
¿Quién crea la Definición de Terminado?
Existen dos opciones posibles:
La organización de desarrollo
El Equipo de Desarrollo
En primer lugar, para aprobar con éxito la certificación PSM 1, debes invertir algo de tiempo en estudiar la Guía de Scrum. Y, confía en mí, no hay forma de evitarlo. Yo sé que la Guía Scrum es bastante seca y a veces puede ser confusa.
Por eso lo he dividido en pequeñas secciones para que sea más fácil de leer y digerir. Solo quería señalar que necesitas leer y comprender los detalles de la guía Scrum; porque con solo mirar las clases de video puede que no sea suficiente para tener la comprensión necesaria.
Por lo general, debes revisar el curso completo una vez para tener una visión general de Scrum y luego regresar y ver algunas partes del curso nuevamente.
Imprime la guía de Scrum y subraya las partes que consideres relevantes. Además, recomendaría que crees tu propio resumen de la Guía de Scrum, para que puedas revisar fácilmente los aspectos más importantes cuando sea necesario.
No hay pre-requisitos para intentar tomar el examen PSM 1 (Professional Scrum Master I).
Este curso y los exámenes de práctica no están respaldados, asociados, ni afiliados a Scrum. org.
Las declaraciones y opiniones expresadas en este documento pertenecen exclusivamente al creador de este curso y no son compartidas ni representan el punto de vista de Scrum .org. Esta capacitación no constituye una aprobación de ningún producto, servicio o punto de vista. Scrum .org no hace representaciones, seguros o garantías de ningún tipo, expresas o implícitas, en cuanto a la integridad, precisión, fiabilidad, idoneidad, disponibilidad o vigencia del contenido contenido en esta presentación o cualquier material relacionado con esta presentación. En ningún caso Scrum .org, sus agentes, funcionarios, empleados, licenciatarios o afiliados serán responsables de ningún daño (incluidos, entre otros, daños por pérdida de ganancias, información comercial, pérdida de información) que surjan de la información o declaraciones contenidas en el entrenamiento. Cualquier confianza que deposite en dicho contenido es estrictamente bajo su propio riesgo.
Este curso contiene material promocional.
Este curso brindara todo lo que necesitas para aplicar el marco de trabajo Scrum en tu trabajo, y si lo deseas, para prepararte para el examen PSM I ®.
Este es el curso mejor calificado por los estudiantes (4.7 estrellas sobre 5) respecto de todos los cursos de Scrum en español. Puedes comprobarlo. Esto es porque nuestros estudiantes aprueban el examen de certificación PSM I®
Este curso te llevará desde cero hasta avanzado, y además te preparará para la certificación en PSM ® I. No se necesitas experiencia previa en Scrum.
En este curso podrás:
Aprender sobre el marco Scrum y Agile
Comprender los contenidos de La Guía de Scrum
Practicar con cuestionarios todo lo aprendido
Obtener consejos imprescindibles para el examen
Hacer una simulación del examen con la ayuda de más de 240 preguntas
¿Qué es Scrum y quién es el Scrum Master?
Scrum es un marco de trabajo en el que las personas pueden lidiar con problemas complejos al desarrollar productos de valor. Scrum es sencillo de entender pero muy difícil de dominar. Scrum se ha utilizado para gestionar el trabajo en productos complejos desde principios de la década de 1990. Scrum no es un método ni una técnica: es un marco de trabajo.
Se considera que el Scrum Master es un líder de servicio para el Scrum Team. También se menciona en La Guía de Scrum, que el Scrum Master ayuda a todos a comprender los valores, las reglas y la teoría de Scrum. Scrum se ha utilizado en casi todo lo que usamos en nuestra vida diaria para desarrollar software, hardware, pero también en marketing u otras áreas.
El rol de Scrum Master
Si alguna vez conociste a un Scrum Master en tu vida, puedes haber sentido que quieres tener ese trabajo. Puede que hayas deseado convertirte en Scrum Master tras haber conocido a alguno. Su trabajo es inspirador debido al tipo de tareas que requiere.
Te permite tanto ganar como impactar en otros. Este trabajo enseña cómo puedes ayudar a un equipo a trabajar de manera correcta y eficiente, e incluso mucho más.
Los Scrum Masters deben tener una mentalidad ágil y estar dispuestos a compartir sus conocimientos para hacer el trabajo de una manera mejor. Si has decidido convertirte en Scrum Master Profesional, debes aprender muchas técnicas útiles. Los problemas típicos incluyen la eliminación de obstáculos o restricciones que detienen el trabajo en equipo y capacitar a los grupos lo suficiente como para que se conviertan en un equipo auto-organizado y auto-empoderado.
Te recomendamos encarecidamente obtener la capacitación suficiente previamente a tomar los exámenes PSM ®. El programa de estudios de PSM I ® incluye un vasto conocimiento sobre Scrum, que está disponible en La Guía de Scrum. Necesitarás tiempo para capacitarte seriamente en las evaluaciones abiertas de Scrum.
Aprender de Scrum es aprender acerca de cómo se origina Scrum, sobre cómo evolucionó, y sobre su desarrollo progresivo. El proceso de aprendizaje para ser Scrum Master también te beneficiará con un conjunto de competencias profesionales de Scrum, cada una ellas sobre sus distintas áreas de enfoque.
Una vez que hayas completado este curso de Scrum, puedes intentar obtener el certificado. Pero este entrenamiento no es obligatorio: es completamente opcional. Sin embargo, lo que sí es obligatorio son los exámenes para obtener la certificación. Los Scrum Masters Profesionales son todo-terreno, ayudantes, solucionadores de problemas, habilitadores, y sus características principales influyen en las mentes de su equipo de trabajadores.
Acerca del examen PSM I ®
Una vez que hayas terminado tu preparación, puedes registrarse para tomar el examen. Respecto de la tarifa del examen, es de u$d 200 por cada intento, y si asistes a un centro de entrenamiento de Scrum. org, entonces tu primer intento sería gratis. Obtienes una contraseña personal sin fecha de vencimiento a través de la cual puedes conectarte a su página y realizar el examen.
Un consejo: realiza la evaluación abierta de Scrum para aprobar el examen PSM ® en tu primer intento. Una vez que comiences a obtener el 100% en cada intento, considérate listo para la prueba.
¿Necesito ser un Scrum Master para tomar el examen PSM I ®?
La pregunta es, ¿para quién es esta certificación? Este curso y certificación son para aquellos que estén interesados en trabajar dentro de un equipo Agile.
Puedes ser un aspirante a Analista de Negocios, Gerente de Proyecto, Dueño de Producto o Desarrollador. No necesitas ser un Scrum Master o tener el deseo de convertirte en uno. Esta prueba simplemente certificará que sabes cómo serlo.
Scrum es para aquellos miembros de equipos Agile que desean ampliar su conocimiento sobre el proceso Agile o que desean adquirir ese conocimiento.
Preguntas frecuentes
¿Puedo obtener PDU (Unidades de Desarrollo Profesional) de PMI tomando este curso?
No, al realizar este curso no podrá obtener PDU.
¿Puedo reclamar las PDU (Unidades de Desarrollo Profesional) de PMI tomando el examen PSM 1?
Lamentablemente no. Las PDU de PMI se obtienen asistiendo a un curso y NO aprobando un examen PSM.
El Examen de Certificación de PSM I es en inglés ¿En qué idioma son las preguntas de práctica de este curso?
Nuestras 340 preguntas de práctica están en ingles para que puedas hacer la práctica en el mismo idioma que utilizarás cuando realices el examen real.