Simulador para Examen PSPO I

La Retrospectiva del Sprint es una oportunidad para que el Equipo Scrum se inspeccione a si­ mismo y cree un plan para implementar mejoras durante el próximo Sprint.

Dado que los elementos en la parte inferior no son de alta prioridad debido a su menor valor de negocio, no se desarrollarí¡n pronto, por lo tanto, no hay necesidad de dedicar demasiado tiempo agregando o aclarando detalles; eso serí­a algún tipo de planificación por adelantado.

Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.

El rol de Product Owner no es un trabajo de tiempo completo, y la cantidad de tiempo que requiere depende del proyecto y su entorno; sin embargo, este rol debe dedicar tanto tiempo como sea necesario para cumplir con todas sus responsabilidades, que son entre otras, maximizar el valor, establecer prioridades en el Sprint Planning, responder preguntas durante el Sprint y refactorizando, ayudar a los desarrolladores a ajustar su trabajo.

El Product Owner gestiona la acumulación de productos asumiendo que se generará valor. Esta suposición queda invalidada cuando no se compara con los usuarios y el mercado.

Los usuarios de Scrum deben inspeccionar con frecuencia los artefactos Scrum y el progreso para detectar variaciones no deseadas. La herramienta principal para que el Product Owner mantenga la transparencia es el Product Backlog. El Product Backlog es un artefacto vivo que se mantiene y actualiza activamente para reflejar la realidad. En el Sprint Review, los asistentes colaboran en las siguientes cosas que se podrí­an hacer para optimizar el valor, las cuales se procesan en un Product Backlog actualizado.

Es probable que el valor varí­e entre productos y organizaciones.

Si la definición de “Done” es parte de las convenciones, estándares o lineamientos de la organización de desarrollo, todos los Equipos Scrum deben seguirla como mí­nimo. El Equipo de Desarrollo del Equipo Scrum puede complementarla con elementos especí­ficos para el producto o contexto.
Si “Done” o “Termindado” para un incremento no es una convención de la organización de desarrollo, el Equipo de Desarrollo del Equipo Scrum debe crear una definición de “Done” apropiada para el producto.

El Product Owner expresa claramente los elementos del Product Backlog, asegurándose de que el Equipo de Desarrollo los comprenda al nivel necesario para desarrollarlos y crear el valor que prevé el Product Owner. El alcance puede renegociarse si el esfuerzo crece mucho más de lo previsto.

El Product Owner no solo es responsable del desarrollo y lanzamiento de un producto, sino también del costo de mantenimiento y operación del producto. Si una persona es “owner” o dueí±a” del producto, se puede esperar que sea responsable del ciclo de vida completo de ese producto.

Un primer Sprint no requiere más que un Product Owner, un equipo y suficientes ideas para completar potencialmente un Sprint completo.

Las indicaciones de valor en el Product Backlog son útiles, pero son solo una predicción hasta que se validen con los usuarios y el mercado.

Un Product Owner se relaciona activa y regularmente con las partes interesadas. Sin embargo, para limitar la perturbación del progreso en el desarrollo y mantener un alto enfoque, las partes interesadas tienen un papel formal en el proceso solo en el Sprint Review.

El Product Owner gestiona la acumulación de productos asumiendo que se generará valor. Esta suposición queda invalidada cuando no se compara con los usuarios y el mercado. Cuando el horizonte de un Sprint es demasiado largo, aumenta el riesgo de que lo que se está desarrollando ya no sea deseable. Los sprints limitan el riesgo a un mes calendario o menos de trabajo.

Se han utilizado varias prácticas proyectivas sobre tendencias para pronosticar el progreso, como burn-downs, burn-ups, o flujos acumulativos. Estos han demostrado ser útiles, pero ninguno es obligatorio y se debe tener cuidado porque ninguno puede reemplazar la importancia del empirismo. Lo que sucederá es desconocido, no importa lo que haya sucedido.

El Product Backlog es dinámico; cambia constantemente para identificar lo que el producto necesita para ser apropiado, competitivo y útil. Los elementos del Product Backlog pueden ser actualizados en cualquier momento por el Product Owner o a discreción del mismo.

El Product Owner es responsable de maximizar el valor del producto y el trabajo del Equipo de Desarrollo. La herramienta principal para hacerlo es el Product Backlog.

Para que el Product Owner tenga éxito, toda la organización debe respetar sus decisiones. Nadie puede decirle al equipo de desarrollo que trabaje con un conjunto diferente de requisitos, y el equipo de desarrollo no puede actuar según lo que digan los demás.

Los usuarios de Scrum deben inspeccionar con frecuencia los artefactos y el progreso de Scrum para detectar variaciones no deseadas. La herramienta principal para que el Product Owner mantenga la transparencia es el Product Backlog.El Product Backlog es un artefacto vivo que se mantiene y actualiza activamente para reflejar la realidad. En el Sprint Review, los asistentes colaboran en las próximas cosas que se podrí­an hacer para optimizar el valor, que se procesa en un Product Backlog actualizado

Depende de los desarrolladores encontrar su camino y asegurarse de que sus resultados creen un Incremento integrado que sea potencialmente liberable.

La deuda técnica es la consecuencia de un diseí±o y arquitectura deficientes del sistema y/o de procesos inconsistentes relacionados. Esto se debe a que el equipo no refactoriza o tiene una mala definición de “Done” o “Terminado”. Si la deuda técnica sigue aumentando, el desarrollo será cada dí­a más difí­cil, por un lado relentizará el progreso , y por el otro, incluso creará problemas para los releases o lanzamientos.
El Equipo de Desarrollo debe aplicar refactorización continua, y/o todo el Equipo Scrum debe revisar los problemas con la definición de “Done” (estándares no incluidos a tiempo, criterios de aceptación incompletos, etc.)

El Sprint Planning sirve para planificar el trabajo a realizar en el Sprint. Este plan es creado por el trabajo colaborativo de todo el Equipo Scrum. El Sprint Planning está limitada en el tiempo a un máximo de ocho horas para un Sprint de un mes. Lo que se puede lograr en esta caja de tiempo puede verse influenciado por prácticas adicionales que, sin embargo, no están prescritas por Scrum.

Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de retroalimentación. Si no se lanza un producto, se pierde la oportunidad de captar la opinión de los usuarios y del mercado.

El Equipo de Desarrollo es responsable de todas las estimaciones. Las personas que realizarán el trabajo hacen la estimación final.

El Product Owner representa a las partes interesadas ante el equipo Scrum. Por lo general, esto requiere una interacción activa para poder representar a las partes interesadas y sus necesidades.
El refinamiento del Product Backlog es un proceso continuo en el que el Product Owner y el Equipo de Desarrollo colaboran en los detalles de los elementos del Product Backlog.

El propietario del producto es responsable de maximizar el valor del producto. Cómo se hace esto variará ampliamente.

El Product Owner es responsable de ordenar los elementos del Product Backlog para alcanzar mejor los objetivos y metas, optimizando así­ el valor del trabajo que realiza el Equipo de Desarrollo. La forma en que se hace esto y el significado de valor pueden variar ampliamente entre organizaciones.

El Product Owner gestiona el Product Backlog asumiendo que se generará valor. Las indicaciones de valor en el Product Backlog son útiles, pero son solo una estimación hasta que se validen con los usuarios y el mercado.

El propietario del producto representa a las partes interesadas ante el equipo Scrum, lo que incluye representar sus requisitos deseados en la cartera de productos. El propietario del producto tiene la decisión final sobre la cartera de productos.

Todos los miembros del Equipo Scrum deben tener una comprensión compartida de lo que significa que el trabajo esté completo, para garantizar la transparencia. Esta es la definición de “Done” o “Terminado” para el Equipo Scrum y se usa para evaluar cuándo se completó el trabajo en el Incremento del producto. El Incremento revisado en el Sprint Review debe ser utilizable, por lo que un Product Owner puede optar por liberarlo de inmediato.

Un gerente de proyecto tradicional es responsable de todos los aspectos de un proyecto; costos, recursos, ejecución, liberación, planificación, capacidad. Scrum es un marco para el desarrollo de productos complejos, independientemente de si el trabajo se organiza en proyectos. El Product Owner es responsable de maximizar el valor del producto y del trabajo realizado, responsabilidad que se complementa con las responsabilidades especí­ficas del Equipo de Desarrollo y el Scrum Master.

El Product Backlog es una lista ordenada de todo lo que podrí­a ser necesario en el producto y es la única fuente de requisitos para cualquier cambio que se realice en el mismo. El Product Backlog evoluciona a medida que evoluciona el producto y el entorno en el que se utilizará. Los elementos del Product Backlog de orden superior suelen ser más claros y detallados que los de orden inferior. Mientras exista un producto, también existe su Product Backlog.

El roduct Owner gestiona la cartera de productos asumiendo que se generará valor. Esta suposición queda invalidada cuando no se compara con los usuarios y el mercado.

Durante el Sprint, el alcance puede aclararse y renegociarse entre el Product Owner y el Equipo de Desarrollo a medida que se aprende más.

El marco Scrum consta de equipos Scrum y sus roles, eventos, artefactos y reglas asociadas. Cada componente dentro del marco tiene un propósito especí­fico y es esencial para el éxito y el uso de Scrum. El Equipo Scrum está formado por un Product Owner, el Equipo de Desarrollo y un Scrum Master. El Product Owner es responsable de maximizar el valor del producto y el trabajo del Equipo de Desarrollo. En ausencia de un Product Owner, esta última responsabilidad no se realiza.

Es responsabilidad del Equipo de Desarrollo estimar la cantidad de trabajo de los elementos del Product Backlog y seleccionar el número apropiado de ellos para cada Sprint. También dividen los elementos en tareas durante el Sprint.
Medir el rendimiento del proyecto es responsabilidad del Product Owner, mientras que medir el rendimiento del Sprint lo realiza el Equipo de Desarrollo.
Crear nuevos elementos del Product Backlog, ordenarlos (priorización) y asegurarse de que todos los entiendan claramente es responsabilidad del Product Owner.

Se desea una mayor velocidad, también es bueno tener visibilidad de nuestra capacidad actual, pero estas métricas no están directamente conectadas con el valor y pueden ser engaí±osas. WIP es una medida de cuánto trabajo está haciendo el equipo al mismo tiempo, no se usa para medir el valor.
La satisfacción del usuario/cliente es importante. No es una medida abstracta como las lí­neas de código o la velocidad.
Existen varios métodos y algunos KPI para medir el valor de los lanzamientos y, cuando se mejoren, mostrarán nuestro éxito.

El equipo que tiene muchas funcionalidades por completar no garantiza que se incluyan las más importantes.
Aún más, tener más funciones en el momento equivocado puede aumentar el costo de mantenimiento y otros esfuerzos, lo que disminuye el valor general.

El propósito principal del Product Owner es la responsabilidad de maximizar el valor del producto resultante a partir del trabajo del Equipo Scrum. La forma en que se hace esto puede variar entre organizaciones, equipos Scrum e individuos.

El responsable de la Definición de “Done” es el Equipo de Desarrollo y no el Product Owner.

La estimación es responsabilidad total del Equipo de Desarrollo por defecto. El Product Owner no elige delegarlo porque, en primer lugar, no tiene esa autoridad.

No es necesario tener todos los elementos identificados antes de comenzar el primer Sprint, ya que Product Backlog es un documento dinámico y vivo. Sin embargo, los elementos elegidos como parte del objetivo Sprint actual deben estar claros para el desarrollo.

Cuando se cancela el Sprint, el Product Owner revisa los elementos completados y, por lo general, acepta los que están en “Done”. Esto se debe a que no hay valor agregado en devolverlos a la Product Backlog y luego a otro Sprint Backlog cuando no hay nada más que hacer por ellos.
Cada vez que un elemento no se completa durante el Sprint (por cancelación o por llegar al final de la caja de tiempo), se moverá de nuevo a la Product Backlog, en lugar de al siguiente Sprint Backlog. Esto es así­, porque el Product Owner podrí­a volver a pedirlos y ya no estarán en la parte superior del Backlog.

Solo el Product Owner puede ordenar el Product Backlog. Esto puede verse influenciado por otras partes interesadas, pero el Product Owner siempre tiene la última palabra.

Para proporcionar valor, el Incremento debe ser utilizable, es por eso que un incremento puede liberarse solo si tiene sentido.

Un Burndown Chart es una representación gráfica del trabajo que queda por hacer durante un perí­odo de tiempo determinado. Cuando los equipos Scrum utilizan esta herramienta, se utiliza para realizar un seguimiento del esfuerzo de desarrollo de productos restante en un Sprint.

Todos los equipos deben ser multifuncionales, con 10 o menos miembros.

Está bien si algunos de los elementos no se completan hasta el final del Sprint. Lo que tenemos en el Sprint Backlog es nuestra mejor estimación de lo que podemos ofrecer. Si hay presión sobre los desarrolladores para terminar todo, comenzarán a agregar márgenes a sus estimaciones, lo que se traduce en una menor productividad debido a la ley de Parkinson.
Cuando el equipo de desarrollo se da cuenta de que no puede terminar todo, recibe ayuda del Product Owner para ajustar su trabajo (tareas) y garantizar que entregará el máximo valor al final del Sprint.
Los elementos del Product Backlog en el Sprint Backlog no se agregan ni eliminan durante el Sprint.

Scrum no usa planificación y diseño por adelantado, y lo que se describe en esta pregunta es una forma de planeación por adelantado.

El Product Backlog es un concepto dinámico, que no está completamente compuesto al comienzo del proyecto (o en cualquier otro momento), y nunca se vuelve estático al establecer la lí­nea de base.
El Product Backlog siempre cambia para reflejar los Retroalimentacións del cliente, de los usuarios finales, del mercado y su entorno.
Es justo decir que todo el marco está diseñado de una manera que permite una Product Backlog muy receptivo.

El Product Owner es responsable de la gestión eficaz del Product Backlog y de maximizar el valor del trabajo del Equipo Scrum, sabiendo y comprendiendo cuáles son las necesidades del negocio.

El Product Owner es responsable de pasar suficiente tiempo con los desarrolladores para asegurarse de que los elementos sean claros y comprensibles.
Los Daily Scrums son solo para los desarrolladores. Otros pueden asistir, pero no participarán.

Cuando un elemento del Product Backlog o un Incremento se describe como “Done”, todos deben entender lo que significa “Done”. Los miembros del Equipo Scrum deben tener una comprensión compartida de lo que significa que el trabajo esté completo, para garantizar la transparencia y utilizar esta referencia para evaluar cuándo se completa el trabajo en el Incremento del producto. Esta definición de “Done” brinda orientación al equipo sobre lo que se necesita para que el incremento se pueda liberar.

“Lí­nea base” es un término que se usa en entornos tradicionales para referirse a un plan inicial finalizado que se seguirí­a en el futuro y se usarí­a para evaluar el desempeño real. No hay planificación inicial ni lí­neas de base en Scrum.

El Product Owner es responsable de medir el progreso del proyecto y realizar un seguimiento del trabajo restante en el Product Backlog.
El Equipo de Desarrollo es responsable de medir el progreso del Sprint y hacer un seguimiento del trabajo restante en el Sprint Backlog.

El Product Owner puede delegar sus responsabilidades al equipo de desarrollo, pero sigue siendo responsable.

Todos los equipos pueden usar la misma definición de “Done” pero, si eso tiene sentido, pueden tener diferentes definiciones siempre que sean compatibles y capaces de crear Incrementos integrados. Por lo tanto, los equipos no “deben”, pero “pueden” tener diferentes definiciones de “Done”.

Una misma persona puede desempeñar más de un papel; por ejemplo Product Owner y desarrollador. Sin embargo esto no es recomendable.

Los elementos del Product Backlog en el Sprint Backlog no cambian, pero otro elemento en el Sprint Backlog son las tareas, y siempre están cambiando.
Esta es la responsabilidad del Equipo de Desarrollo para hacer cambios en las tareas del Sprint Backlog; mientras que también pueden “consultar” al Product Owner para esto.

El Product Owner no es un trabajo de tiempo completo y la cantidad de tiempo requerida depende del proyecto y su entorno. Necesitan dedicar tanto tiempo como sea necesario para cumplir con todas sus responsabilidades, lo que resulta en maximizar el valor.
Tenga en cuenta que la única razón por la que el Product Owner pasa tiempo con los desarrolladores no es el refinamiento, sino también el Sprint Planning, responder preguntas durante el Sprint, ayudar a los desarrolladores a ajustar su trabajo, etc.

No hay Sprints de endurecimiento en Scrum. Todos los Sprints son iguales y crean Incrementos. Actividades dedicadas a estabilizar la base de código
o “Endurecimiento” se realiza durante todos los Sprints.

Los conflictos gestionados pueden ser útiles para el proyecto. A través de una gestión adecuada de conflictos, los miembros del equipo aprenden más sobre los objetivos del proyecto, los detalles del proyecto, crean o mejoran ideas e interactúan entre sí­ de manera productiva.

La deuda técnica es las deficiencias en el código que lo hacen menos que “suficientemente bueno” y, por lo tanto, crea riesgos en el futuro. Por lo general, disminuye la velocidad en el futuro (porque el equipo tiene que corregir las deficiencias), y parte de la deuda puede permanecer en el producto final, el costo de mantenimiento también aumentará.
El “costo total de propiedad” o “total cost of ownership” es una combinación del costo del proyecto y el costo de mantenimiento.

El Sprint Planning tiene un lí­mite de tiempo de máximo de 8 horas para un Sprint de un mes. Para Sprints más cortos, el evento suele ser más corto.

Un equipo autoorganizado es un equipo que es capaz de gestionarse a sí­ mismo y de decidir la mejor manera de realizar su trabajo.

Esta es una pregunta facil. Pero ojo, tiene múltiples respuestas, una pregunta puede parecer fácil pero puedes elegir mal o de forma incompleta, solo porque no la leí­ste con atención.

El diseño del software es parte del desarrollo y debe ser realizado por los desarrolladores. Son autoorganizados y toman decisiones técnicas, y se ofrecen como voluntarios para tareas (las asignan a sí­ mismos). La estimación también es responsabilidad de los desarrolladores, porque son las personas que desarrollarán el elemento. El resto lo hace el Product Owner.

Al final de cada Sprint, debe estar disponible un incremento de trabajo “Done” para inspeccionar y adaptar correctamente.
Scrum se basa en el control de procesos empí­ricos y afirma que el conocimiento proviene de la experiencia previa y de tomar decisiones basadas en lo que ya se sabe. Scrum emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar el riesgo

El Product Backlog está a cargo de establecer la visión general del producto y garantizar que se alinee con los objetivos de negocio. Sin embargo, el “Sprint Goal” se prepara durante el Sprint Planning, por todo el Equipo Scrum.

A veces, las organizaciones pueden usar una definición de “Done” para todos sus proyectos. De lo contrario, el Equipo de Desarrollo serí­a responsable de crear uno.
Incluso cuando hay una definición de “Done” en la organización, se puede usar como mí­nimo y el desarrollador puede agregarle elementos adicionales.

La Retrospectiva del Sprint es el último evento del Sprint. Tiene un lí­mite de tiempo máximo de tres horas para un Sprint de un mes, y todos los miembros del Equipo Scrum asisten.
Su propósito es buscar mejoras en los individuos, interacciones, procesos, herramientas y su Definición de “Done” (la forma en que está trabajando el Equipo Scrum), problemas enfrentados, etc.

El Product Owner puede delegar sus responsabilidades al equipo de desarrollo, pero sigue siendo responsable.

La velocidad y el valor no están relacionados directamente. El valor es la relación beneficio-costo. Dado que comenzamos con los elementos más importantes primero, de aquellos que quedan para el sexto Sprint se espera que tengan menos valor comparados con los entregados en el cuarto Sprint.

Durante el Sprint, elementos del Product Backlog en el Sprint Backlog no se agregarí­an ni eliminarí­an, pero a medida que se aprende más, el alcance puede ser más claro y renegociarse entre el Product Owner y el Equipo de Desarrollo. Este se centra principalmente en la interpretación de los elementos del Product Backlog y las tareas creadas al descomponerlos.

En dominios complejos, solo puede conocer los resultados en retrospectiva. El empirismo, a partir del cual se fundó Scrum, afirma que el conocimiento proviene de la experiencia y de la toma de decisiones en base a lo que se sabe. Surgirán nuevos conocimientos a medida que se realice el trabajo.

Todos los eventos Scrum son necesarios; nunca deben ser removidos.

El “Cono de Incertidumbre” se trata del hecho de que la incertidumbre es más alta al comienzo del proyecto y se reduce a medida que avanzamos. Esta incertidumbre puede ser sobre la duración, requerimientos, etc.
El “Cono de Incertidumbre” no forma parte del marco de Scrum, pero es otra herramienta/técnica que se puede utilizar.

El Product Owner puede delegar sus responsabilidades al equipo de desarrollo, pero sigue siendo responsable.

El refinamiento del Product Backlog lo realizan el Product Owner y el Development Team. La práctica más común (no una regla) es que no deberí­a tomar más del 10% del tiempo de los desarrolladores. El Product Owner dedica todo el tiempo necesario al refinamiento.

Los gráficos de evolución son muy comunes para rastrear y representar el progreso, pero no son obligatorios, y el Product Owner también puede usar otras herramientas/técnicas.