Simulador para Examen PSM I

Todas estas opciones son criterios correctos para decidir la duración de un Sprint.

Solo tenemos tres roles en Scrum: Propietario del producto, Scrum Master y Equipo de desarrollo. No está permitido definir nuevas funciones y el equipo de desarrollo debe ser autoorganizado y multifuncional.

Cuando el elemento se completa según la Definición de Hecho, y por lo tanto, los usuarios reales y finales pueden usarlo, lo que también significa que se ha creado un Incremento de software trabajando que es potencialmente liberable.

El Scrum Master es responsable de ayudar a todos a comprender la teoría, las prácticas, las reglas y los valores de Scrum. Elimina impedimentos (resuelve problemas), facilita las reuniones según sea necesario. Todo el Equipo Scrum decide la duración del Sprint considerando cuatro semanas para la duración máxima. Las tareas son asignadas por los propios desarrolladores.

La Adaptabilidad, la Transparencia y la Inspección son los pilares de la teoría de Scrum. Scrum como marco ágil, se trata principalmente de Adaptabilidad (en lugar de predicción).

A pesar de que Scrum Master no gestiona personas, gestiona procesos. Por eso se considera una función de gestión. El equipo de desarrollo está autoorganizado; el Scrum Master puede entrenar y ayudar, pero los desarrolladores son los que manejan el progreso y el rendimiento de los Sprints. Es el Product Owner quien es dueño del Backlog del Producto.

El Equipo de Desarrollo es multifuncional y hace el trabajo de entregar un Incremento potencialmente liberable del producto “Hecho” o “Done” al final de cada Sprint. No usan ninguna ayuda externa. No se recomienda, ni es una buena práctica, que el Scrum Master o el Product Owner trabajen como desarrolladores.

La decisión sobre el orden de los ítems puede ser influenciada por un comité, el cliente o cualquier otra parte interesada, pero solo el Product Owner decide qué tiene más sentido para optimizar el valor del trabajo realizado por el Equipo de desarrollo.

Dado que las personas que realmente hacen el trabajo son las que mejor saben lo que se necesita para completar tareas específicas; Todas las estimaciones son hechas por el Equipo de Desarrollo.

El Product Owner es la única persona responsable de administrar el Product Backlog, pero siempre puede y debe tener en cuenta los comentarios y opiniones de otras partes interesadas, incluido el equipo de desarrollo, que pueden influir para agregar nuevos elementos en el Produt Backlog. Los buenos requisitos deben ser lo suficientemente breves, es por eso que las pruebas de aceptación se pueden utilizar para expresar muchos de los detalles que resultan de las conversaciones entre clientes, usuarios, propietarios de productos y desarrolladores, incluidos los requisitos no funcionales. Un producto solo tiene un Backlog de Producto.

Ser autoorganizado implica que el equipo sigue su propio proceso, en lugar de recibir órdenes. Cuando es así, los miembros del equipo tienden a comprometerse y aumentar su responsabilidad y creatividad.

No hay Sprint de análisis, Sprint de diseñoo, Sprint zero, Sprint de integración, Sprint de lanzamiento, etc. Solo hay un tipo de Sprint, y su objetivo es crear un Incremento de características valiosas potencialmente liberables.

Los Product Owner deben comunicarse efectivamente con los clientes, por lo tanto, también involucrarlos.

Esto no debería ser frecuente porque crea una reducción de tiempo breve en la productividad, pero si es necesario, trate de evitar cambios en los miembros del equipo durante el Sprint.

Cada equipo tiende a aprender más y madurar durante el proyecto, por lo que las técnicas, la experiencia, las habilidades y los métodos también mejoran. Esto debe afectar la definición de Hecho (o Done). Todos los roles, eventos y artefactos de Scrum son necesarios y no deben omitirse por ningún motivo.

Recuerde que el Equipo de Desarrollo es autoorganizado. Por lo tanto, es responsabilidad del equipo medir su propia productividad y rendimiento a lo largo del Sprint, determinar su propio proceso, planificar, estimar y optimizar el trabajo requerido para los artículos y el Objetivo del Sprint, así como resolver sus propios conflictos.

El único que puede cancelar un Sprint es el Product Owner. Esto puede suceder cuando se da cuenta de que el Sprint ya no tiene sentido, porque el Objetivo Sprint se ha vuelto obsoleto.

La definición acordada de “Hecho o Done” para el Equipo Scrum se utiliza para evaluar cuándo se completa el trabajo en el incremento del producto, con el fin de ofrecer un incremento de de funcionalidad potencialmente liberable.

La Retrospectiva del Sprint ocurre siempre después de la Revisión del Sprint y antes de la próxima Planificación del Sprint.

Una de las principales responsabilidades del Product Owner es maximizar el valor del trabajo del equipo de desarrollo, y él es el único que puede agregar nuevos elementos al Product Backlog. Incluso cuando el Equipo de Desarrollo posee el Backlog del Sprint, los miembros no agregan elementos arbitrariamente, el Product Owner debe asegurarse de que cualquier elemento nuevo agregue valor y pueda trabajar con las partes interesadas adecuadas al respecto y luego agregarlo al Backlog del Producto para los próximos Sprints, además el propietario del producto puede rechazar la nueva función, en lugar del equipo de desarrollo.

El propósito de los Sprints es crear incrementos; en otras palabras, un producto de trabajo que sea potencialmente utilizable y se basado en la definición acordada de “Hecho” o “Done”, independientemente de las técnicas, documentos o métodos utilizados para lograrlo.

El Equipo de Desarrollo es propietario de las reuniones diarias de Scrum, se pueden llevar a cabo de diferentes maneras, pero siempre se enfoca en el progreso hacia el Objetivo del Sprint.

Los únicos que deben asistir son los miembros del Equipo Scrum. El Scrum Master se asegura de que el equipo de desarrollo tenga la reunión, pero no necesita estar presente en ella. Cualquier otra persona puede asistir, pero no “deben” participar, hay que notar que los invitados solo miran y escuchan sin participar.

Todos los Equipos de desarrolladores comparten la propiedad de los elementos del Backlog del Sprint y sus tareas; estas tareas son asignadas a los desarrolladores por sí mismos. Además, todos los miembros del Equipo de Desarrollo comparten la responsabilidad de sus propias tareas.

Cuando tenemos Sprints más cortos, hay más oportunidades para mostrar el progreso y recibir comentarios, validar nuestro conocimiento y, por lo tanto, adaptarnos. Por esta razón, se prefieren Sprints más cortos cuando tenemos mayores riesgos.

Es responsabilidad del Equipo de Desarrollo seleccionar la cantidad adecuada de elementos del Backlog de Producto, desglosar las tareas y crear estimaciones para cada Sprint.

El Product Owner es responsable de medir el rendimiento del proyecto. El Equipo de Desarrollo solo mide el rendimiento del Sprint actual.

El Product Owner establece el Objetivo que debe alcanzar el Sprint, aunque puede ser influenciado por el Equipo de Desarrollo. Sin embargo, solo los miembros del Equipo de Desarrollo crean el Incremento, es por eso que solo extraen los elementos del Backlog del Producto para lograr el Objetivo del Sprint.

El objetivo principal del Sprint es crear un incremento de producto “Listo” utilizable y potencialmente liberable.

El Scrum Master debe entrenar a todos los miembros del Equipo Scrum en entornos organizacionales en los que Scrum aún no se haya adoptado y entendido por completo con el fin de practicar la Agilidad. El Scrum Master debe ayudarlos a comunicarse eficazmente entre sí, pero ha que tener cuidado cuidado de no actuar como un “mediador” entre ellos.

Incluso si el equipo no entrega incrementos, el Product Owner debe estar informado al respecto y debe trabajar con el equipo de desarrollo y ajustar, agregar y/o eliminar los elementos del Sprint Backlog a lo largo de la iteración para lograr el Objetivo del Sprint. Pero, dado que esta sigue siendo la el Sprint Planning, también tenemos la oportunidad de modificar el Objetivo del Sprint, no podremos hacerlo después del Sprint Planning.
Siempre trabajamos a un ritmo regular y constante, no debemos trabajar horas extras.
No deberíamos cambiar el número de desarrolladores, agregar desarrolladores no aumentará la productividad a corto plazo.

La Definición de “Hecho o Done” define lo que se espera como resultado del Sprint actual. Esto incluye (pero no se limita) a criterios de aceptación y características no funcionales. El propósito es compartir la misma comprensión del trabajo completado para aumentar la transparencia.
El Objetivo del Sprint es lo que define el propósito del Sprint.
El equipo de desarrollo debe tener presente la definición de “Hecho o Done” para crear tareas, pero también la descripción de cada elemento extraído del Backlog del producto.

Necesitamos saber cuándo un elemento está realmente Hecho o Done, en otras palabras, compartimos una comprensión común de lo que significa un trabajo terminado. Con este propósito, podemos aumentar la Transparencia cuando hay pruebas incluidas en la Definición de “Hecho o Done” que verificarán qué tan cerca está el trabajo de estar “completo”, “potencialmente liberable” y convertirse en un Incremento real utilizable para los usuarios finales.
También escribir pruebas de aceptación ayuda a expresar muchos de los detalles que resultan de las conversaciones entre los clientes y los equipos Scrum, en lugar de escribir largas listas de “El sistema debe …”.

Después del Sprint Planning, los elementos incluidos en el Sprint Backlog no se pueden cambiar. Pero las tareas desglosadas y creadas por el Equipo de Desarrollo para completar el trabajo siempre cambian y se adaptan de acuerdo con sus prácticas, técnicas y conocimientos.

El Sprint actual continúa. El Product Owner y el equipo de desarrollo revisarán y ajustarán el trabajo de Sprint seleccionado, siempre siguiendo el objetivo de Sprint.

No hay unidades de estimación comparables entre los equipos de desarrollo, cada equipo es diferente. Si intenta normalizar, puede provocar malentendidos y problemas de relleno.
La definición de “Hecho o Done” es una práctica común, pero no forma parte de la Guía Scrum, y su objetivo no es normalizar las estimaciones ni la medición del rendimiento.

El Product Owner es responsable de maximizar el valor del producto resultante a partir del trabajo del Development Team, y en consecuencia, de priorizar los elementos del Producto Backlog .
No existe un rol Project Manager o equivalente en el marco de Scrum.
El Product Owner puede dedicarse a tiempo parcial a un proyecto.

Si un proyecto no incluye los roles Scrum Master o Product Owner, este proyecto no está utilizando Scrum. Ambos roles pueden ser a tiempo parcial, pero siempre existen en un proyecto Scrum. Una de las actividades más importantes del Scrum Master es eliminar los impedimentos, y no importa cuán maduro sea el Equipo de Desarrollo, sus miembros siempre se beneficiarán cuando alguien se ocupe de estos problemas.

Scrum no realiza una planificación de antemano, sólo se crean algunas tareas desglosadas desde los elementos tomados para el Sprint Planning.
El equipo de desarrollo se autoorganiza, sus miembros deciden quién qué hacer.
No hay línea de base para un proyecto Scrum.

No existe tal cosa como el Sprint zero. El primer Sprint es el primero, y no es diferente de otros Sprints, desde la perspectiva de que el Development Team debería crear un Incremento. La infraestructura, las herramientas y los requisitos se preparan gradualmente a lo largo del proyecto.

El Development Team no analiza, diseña ni describe la arquitectura e infraestructura completas de antemano para todo el proyecto. Los procesos ágiles se caracterizan por frecuentes ráfagas cortas de diseño, lo suficiente para alcanzar el objetivo de Sprint.

Sólo el Development Team puede modificar el Sprint Backlog a lo largo del mismo, aunque no puede modificar el objetivo del Sprint. Si hay tiempo y el Development Team ha completado todos los elementos, el equipo sacará el siguiente elemento de la parte superior del Product Backlog.

Scrum no es una metodología o cuerpo de conocimiento, es un marco de trabajo. Muchas organizaciones comienzan a implementar Agile en un contexto cultural que en su mayoría no es Agile. Esto crea tensiones y fricciones con las que tienen que lidiar los equipos que adoptan Agile.
Según la Guía Scrum, un Sprint es un período de tiempo de 4 semanas como máximo (puede ser menos).

Se pueden agregar muchas características no funcionales, como la seguridad, como criterios de aceptación y pruebas en la Definition of Done para aplicar a todos o algunos elementos del Product Backlog.
Podemos tener algunos problemas de seguridad específicos que pueden ser elementos en Product Backlog.
El equipo de desarrollo es multifuncional y autosuficiente, debe ser capaz de cuidar todos los aspectos del producto, incluida la seguridad.

Cuando se crea el Product Backlog, se le agregan elementos. Tienen diferentes tamaños y, finalmente, se ordenan según su valor de negocio. Los items más valorados estarán en la parte superior y, por lo general, estos elementos se desglosarán en otros más pequeños. No hacemos esto con aquellos elementos en la parte inferior. Es por eso que generalmente hay elementos más grandes y menos transparentes en la parte inferior del Product Backlog.

Los elementos del Product Backlog se ordenan en función de su valor de negocio. El Product Owner es responsable del Product Backlog, incluido su contenido, disponibilidad y priorización. El Product Owner puede considerar el tamaño y el riesgo de los items, pero entre otros, estos son solo criterios para establecer el valor final. Los elementos deben tratar de ser independientes entre sí, para facilitar su orden de priorización.

Cada incremento debería ser potencialmente liberable y completado basado en la Definición de Hecho o Done. Sinembargo, un incremento no tiene que ser forzoamente liberado. El Product Owner decide si hace sentido liberarlo o no.

Eliminar los impedimentos y facilitar los eventos Scrum según es solicitado o necesitado son el tipo de cosas que se esperan del Scrum Master. El Development Team está auto-organizado, el Scrum Master no les da órdenes. El Scrum Master debe asegurarse de que el Product Owner sepa cómo priorizar el Producto Backlog para maximizar su valor, pero el Scrum Master no es responsable de hacerlo.

Solo los miembros del Development Team crean el Incremento y son los miembros del Equipo Scrum más adecuados para hacer estimaciones. El Product Owner y el Scrum Master pueden sugerir y usar técnicas para ayudar al Development Team a medir su esfuerzo, sin embargo, solo el Development Team realiza la estimación por sí mismo.

La infraestructura y las herramientas se preparan gradualmente a lo largo del proyecto, y el Objetivo del Sprint y la Definition of Done deben ser realistas y crearse en consecuencia.

Scrum es un marco de trabajo que es adaptativo y empírico en lugar de teórico, por lo que se puede utilizar para el desarrollo de productos complejos en entornos de alta complejidad. Scrum tiene más que ver con la entrega de proyectos que con la gestión de proyectos, por lo tanto, no es una metodología ni un cuerpo de conocimientos.

– Solo hay una Product Backlog y un Product Owner para un producto. Sin embargo, cada equipo debe tener un Sprint Backlog separado.
– El Development Team es responsable de seleccionar los elementos del Product Backlog , sin embargo, pueden seleccionar representantes para hacerlo. Pero, comparten la propiedad de estos.
– Los miembros del equipo pueden cambiar la composición de los equipos (turno) entre Sprints.
– Aunque los elementos del Product Backlog y deberían independientes entre sí, las dependencias entre los equipos son inevitables en escalamiento Scrum y deben ser manejadas.

Scrum no describe ningún paso detallado, y más que una metodología es un marco de trabajo.

Los desarrolladores deben ser auto-organizados y son responsables de la formación y composición de los equipos.

Los valores de Scrum nombrados en la Guía Scrum son Compromiso, Coraje, Enfoque, Apertura, Respeto. Los pilares de la teoría Scrum son Transparencia, Inspección, Adaptabilidad.

Los pilares de la teoría de Scrum nombrados en la Guía Scrum son Transparencia, Inspección, Adaptabilidad. Los Valores de Scrum son Compromiso, Valor, Enfoque, Apertura y Respeto.

Multifuncional significa que los profesionales en el Equipo de Desarrollo deben tener toda la experiencia para hacer el trabajo necesario a fin de entregar un Incremento potencialmente liberable del producto “Hecho o Done” al final de cada Sprint.

El Development Team está auto-organizado, por lo tanto, esta es una decisión y responsabilidad de sus miembros. Por supuesto, el Scrum Master debe abordar y apoyar esta decisión, ya que también es un impedimento.

El Development Team es auto-organizado, por lo tanto, sus miembros deciden sobre su forma de trabajo y el enfoque técnico del proyecto.

La infraestructura y las herramientas no están preparadas por adelantado, ya que se requiere de una comprensión completa de todo el proyecto y el producto, que generalmente no es el caso, por lo que debemos aferrarnos al pilar de adaptación. La infraestructura y las herramientas necesarias se prepararán gradualmente a través del proyecto porque dependen del producto que vamos a crear, que a su vez se define a través del proyecto.

No podemos cambiar el Objetivo del Sprint, sin embargo, el equipo puede hablar y negociar con el Product Owner para agregar nuevos elementos del Sprint Backlog según sea necesario.

Los eventos de duración fija (timeboxed) Scrum no se extienden, puede tomar el tiempo disponible para algunos de estos eventos como duración máxima, por lo que pueden terminarse antes si se hace completado, pero la duración del Sprint tienen una duración fija, esto significa que no pueden reducirse. Si todo está terminado antes del final del Sprint, el Equipo de Desarrollo elegirá el siguiente elemento del Product Backlog y comenzará a trabajar en eso.

Las Historias de Usuario, Casos de Uso, Pruebas, Tareas e incluso otros elementos que ayudan a definir y aclarar el trabajo pueden ser parte del Sprint Backlog.

La línea de tendencia nos da visibilidad sobre el pronóstico para la fecha de finalización, considerando un constante Capacidad del Equipo de Desarrollo para el Backlog del Sprint.

El Development Team es responsable de sus miembros porque es auto-organizado, esto significa que sus miembros deciden eliminar a cualquier miembro del equipo. Dado que esta situación es realmente un impedimento, el Scrum Master puede ayudar al equipo.

Los principios ágiles apoyan procesos que promueven el desarrollo sostenible, esto significa que cada persona relacionada directamente con un proyecto debe poder mantener un ritmo constante indefinidamente.

El Sprint Planning tiene un límite de tiempo de hasta ocho horas para un Sprint de cuatro semanas o un mes. Para Sprints más cortos, el evento suele ser más corto.

El Scrum Master sirve a la organización de varias maneras, incluido el liderazgo y el entrenamiento de la organización en su adopción de Scrum, la planificación de la implementación de Scrum dentro de la organización, también el Scrum Master sirve al Equipo de Desarrollo de varias maneras, incluida la eliminación de impedimentos para el progreso del Equipo de Desarrollo.

Ciertamente, el Product Backlog contiene los elementos seleccionados del Product Backlog, pero también contiene las tareas para el Sprint actual.

La prioridad del Sprint Planning es responder dos preguntas:
¿Qué se puede entregar en el Incremento resultante del próximo Sprint?
¿Cómo se logrará el trabajo necesario para lograr el Incremento?
El equipo no necesita obtener todos los detalles sobre cada tarea siempre que se respondan estas preguntas y las definiciones pendientes se puedan completar lo antes posible en las actividades de refinamiento.

El Objetivo del Sprint y el Sprint Backlog se crean durante la reunión de Sprint Planning.

El evento del Sprint Review. se lleva a cabo al final del Sprint para inspeccionar el Incremento y adaptar el Product Backlog si es necesario. Los asistentes también colaboran en las siguientes cosas que podrían hacerse para optimizar el valor.

Todos en el Equipo Scrum deben entender lo que significa “Done o Hecho”. Aunque esto puede variar significativamente según el Equipo Scrum, los miembros deben tener una comprensión compartida de lo que significa que el trabajo se complete, para garantizar la transparencia. Esta es la definición de “Done o Hecho” para el Equipo Scrum y se utiliza para evaluar cuándo se completa el trabajo en el Incremento del producto.

El Sprint Zero no existe en el marco de trabajo Scrum y todos los Sprints deberían poder crear un Incremento de software que trabaje. Los conceptos de Inspeccion y Adaptabilidad tratan de realizar ajustes gradualmente a través del proyecto, esto incluye infraestructura y herramientas.

El Product Owner posee la Product Backlog y es la única persona responsable de la misma. El Product Owner gestiona el Product Backlog, esto incluye:
• Expresar claramente los elementos del Product Backlog.
• Ordenar los items en el Product Backlog para lograr las mejores metas y objetivos.
• Optimizar el valor del trabajo que realiza el Development Team.
• Asegurarse de que el Product Backlog sea visible, transparente, claro para todos, y que muestre en qué trabajará el Equipo Scrum a continuación.
• Asegurar que el equipo de desarrollo comprenda los elementos del Product Backlog al nivel necesario.

El Sprint Review es como máximo una reunión de cuatro horas para Sprints de un mes o cuatro semandas. Para Sprints más cortos, el evento suele ser más corto. Durante este evento, el Equipo Scrum y las partes interesadas colaboran sobre lo que se hizo en el Sprint, por lo que es una oportunidad de inspección y adaptación.

No hay tal cosa como Hardening Sprint. Tenemos un Sprint 1, Sprint 2 y seguimos, un Sprint sorpresa adicional o un Sprint de colchón planificado no está alineado con los principios de desarrollo Agile con límite de tiempo (Timeboxed) para crear un producto potencialmente empaquetable. Si las historias se priorizan correctamente, la Definition of Done no es ambigua, y el trabajo atrasado del producto se refina regularmente en función de las prioridades comerciales, los equipos deben poder completar las tareas de desarrollo.

El Product Owner es responsable de obtener la aceptación y comprender las preocupaciones y objetivos de los interesados. El Product Owner se comunica y representa los deseos del cliente.

El Scrum Master sirve al equipo de desarrollo de varias maneras, como:
• Coaching al Development Team en autoorganización y funcionalidad cruzada.
• Ayudar al Development Team a crear productos de alto valor.
• Eliminar los impedimentos para el progreso del Development Team.
• Facilitar eventos Scrum según lo solicitado o necesario.
• Entrenar al Development Team en entornos organizacionales en los que Scrum aún no se ha adoptado y entendido completamente.

El propósito de todos los Sprints es crear un Incremento del trabajo “Done o Hecho”, una pieza de software funcional, utilizable y potencialmente liberable, sin embargo, el equipo no necesita lanzar o liberar algo cada Sprint, pero eventualmente, el equipo debe liberar su trabajo.