Parcial 1 - ISW

(ROSA) Una startup ha invertido en una plataforma de desarrollo de low-code esperando que sus desarrolladores junior puedan crear aplicaciones complejas sin experiencia técnica profunda. Como Líder de Proyecto, ¿qué afirmaciones serían coherentes con los planteamientos de Fred Brooks?. Las herramientas pueden mejorar la productividad, pero no eliminar las dificultades esenciales. Las dificultades esenciales, como la complejidad del dominio y la comunicación con el cliente seguiran presentes. La experiencia técnica se vuelve irrelevante con herramientas modernas. Las herramientas low-code pueden reducir dificultades accidentales como la codificación manual.

(ROSA) Un proyecto de desarrollo de software para una entidad bancaria debe entregarse antes de lo previsto por una exigencia regulatoria. El cliente no está dispuesto a reducir el alcance ni aumentar el presupuesto. ¿Qué afirmaciones son consistentes con el planteo de la triple restricción?. El tiempo es una variable independiente que no afecta las otras restricciones. Para cumplir con el nuevo plazo, se debería reducir el alcance o aumentar el presupuesto. Reducir el tiempo sin ajustar el alcance ni el costo, puede generar sobrecarga en el equipo. La calidad del producto podría verse afectada si se mantiene el alcance y el costo.

(ROSA) Una empresa trabaja con sprints de dos semanas. El cliente solicita que se reduzca la duración de los sprints para acelerar la entrega. ¿Qué afirmaciones son coherentes con la gestión del tiempo en proyectos ágiles?. Reducir la duración del sprint puede limitar la cantidad de trabajo entregable. El tiempo en ágil es flexible y no afecta la calidad del producto. El tiempo en proyectos ágiles es fijo por iteración, pero puede ajustarse entre sprints si el equipo así lo decide. Acelerar los sprints sin ajustar el alcance puede generar deuda técnica.

(ROSA) En un proyecto ágil, el equipo decide reducir la documentación formal de requerimientos. ¿Qué prácticas justifican esta decisión según los principios ágiles? Selecciona todas las opciones correctas: La documentación detallada es obligatoria para cada iteración. Los requerimientos se documentan exhaustivamente antes de iniciar el desarrollo. La documentación mínima viable permite mayor flexibilidad ante cambios. Se prioriza la comunicación directa y continua con el cliente. Se utiliza el Product Backlog como herramienta viva para gestionar requerimientos.

(ROSA) Utilizando el framework Scrum, ¿qué elementos pueden influir directamente en la planificación de un release?. La capacidad estimada del equipo durante el release. La cantidad de bugs reportados en versiones anteriores (sin contexto). La duración fija de cada sprint sin considerar el contenido. La “Definition of Done” del equipo. La velocidad del equipo en sprints anteriores.

(ROSA) En el contexto de estimaciones ágiles, ¿cuáles de las siguientes afirmaciones son verdaderas?. Las estimaciones en puntos de historia permiten comparar esfuerzos relativos entre historias de usuario sin necesidad de conocer su duración exacta. Las estimaciones deben ser precisas para garantizar el cumplimiento del sprint. Planning Poker fomenta la colaboración del equipo y reduce el sesgo individual en las estimaciones. El valor de una historia de usuario puede influir en su estimación si se utiliza el método WSJF. El uso de estimaciones temporales (horas/días) es preferido en metodologías ágiles por su precisión.

(ROSA) Durante una revisión de sprint, el equipo presenta los avances al Product Owner y stakeholders. Uno de los desarrolladores comenta que el Scrum Master debería haber intervenido más en la toma de decisiones técnicas. Por otro lado, el Product Owner propone reorganizar el equipo para acelerar la entrega de funcionalidades. ¿Cuáles de las siguientes afirmaciones reflejan correctamente los roles y responsabilidades en Scrum?. El Scrum Master facilita el proceso Scrum, pero no toma decisiones técnicas ni de negocio. El Product Owner puede reorganizar el equipo si considera que se mejora la entrega de valor. Los desarrolladores son los responsables de las decisiones técnicas y de cómo llevar a cabo el trabajo. El Scrum Master debe intervenir en las decisiones técnicas para asegurar la calidad del producto. El Product Owner define qué se construye, pero no cómo se construye.

(ROSA) Durante la planificación de un proyecto bajo gestión tradicional, el gerente de proyecto solicita un cronograma detallado con fechas de inicio y fin para cada tarea. El equipo técnico propone incluir márgenes de contingencia y documentar los supuestos. Sin embargo, algunos stakeholders presionan para acortar los plazos y eliminar tareas que consideran innecesarias. ¿Qué acciones están alineadas con buenas prácticas de gestión tradicional de proyectos en este contexto?. Documentar los supuestos que afectan el cronograma para facilitar el análisis posterior. Definir fechas de inicio y fin basadas en estimaciones realistas y recursos disponibles. Ajustar el cronograma únicamente en función de las expectativas del cliente. Eliminar tareas del cronograma si los stakeholders consideran que no aportan valor directo. Incluir márgenes de contingencia para mitigar riesgos y posibles desviaciones.

(ROSA) Durante la ejecución de un proyecto tradicional, el equipo técnico solicita modificar el alcance para incluir una funcionalidad adicional que no estaba prevista originalmente. El Líder de proyecto evalúa el impacto en tiempo y costos, mientras que el cliente insiste en que se implemente sin alterar el cronograma. ¿Qué acciones están alineadas con buenas prácticas de gestión tradicional en este contexto?. Implementar el cambio directamente si el equipo técnico lo considera beneficioso. Evaluar el impacto del cambio en el alcance sobre el cronograma, costos y calidad. Aplicar el proceso de gestión de cambios antes de incorporar la nueva funcionalidad. Negociar con el cliente para ajustar el cronograma si el cambio es aceptado. Registrar el cambio en el plan de proyecto solo si el cliente lo aprueba formalmente.

(ROSA) Durante una auditoría de configuración funcional para un proyecto de desarrollo de software, el auditor detecta que varios ítems de configuración no tienen trazabilidad con los requisitos originales. El líder del proyecto argumenta que los cambios fueron menores y no requerían documentación formal. El equipo de calidad propone revisar el proceso de control de cambios. ¿Qué acciones están alineadas con buenas prácticas en auditorías de SCM?. Verificar que todos los ítems de configuración tengan trazabilidad con los requisitos aprobados. Documentar las decisiones tomadas durante el desarrollo, incluso si los cambios parecen triviales. Revisar el proceso de control de cambios para asegurar que todos los ítems modificados estén registrados. Aceptar cambios menores sin documentación si no afectan funcionalidades críticas. Validar únicamente los ítems que fueron entregados al cliente final.

(AZUL) En un proyecto con entregas parciales, el cliente solicita una modificación en una funcionalidad ya aprobada. El gerente de proyecto acepta el cambio verbalmente y el equipo lo implementa sin actualizar la documentación. En la siguiente revisión, el auditor solicita evidencia formal del cambio. ¿Qué prácticas deberían haberse aplicado para asegurar una correcta documentación del cambio?. Documentar el cambio solo si afecta el entregable final. Implementar el cambio directamente si el cliente lo solicita, sin necesidad de documentación. Incluir la justificación del cambio y su impacto en los registros del proyecto. Actualizar los documentos afectados por el cambio, incluyendo el plan de proyecto y el alcance. Registrar la solicitud de cambio en el sistema correspondiente y documentar su aprobación.

(AZUL) En un proyecto con múltiples entregas, el CCC recibe una solicitud de cambio que afecta la arquitectura del sistema. El impacto técnico es alto, pero el cliente considera que es necesario para cumplir con nuevos requisitos. El equipo propone realizar una evaluación rápida para no demorar el desarrollo. ¿Qué prácticas están alineadas con una correcta evaluación del cambio por parte del CCC?. Priorizar la opinión del cliente por sobre el análisis técnico para agilizar la aprobación. Realizar una evaluación técnica y de gestión completa antes de tomar una decisión. Consultar al equipo de arquitectura para evaluar la viabilidad técnica del cambio. Aprobar el cambio sin análisis si el equipo considera que puede implementarlo rápidamente. Documentar el análisis de impacto y la decisión del CCC en el registro de cambios.

(AZUL) En un proyecto con múltiples desarrolladores, se producen conflictos frecuentes al integrar cambios en el código. Algunos miembros trabajan directamente sobre la rama principal, mientras que otros no actualizan sus copias antes de hacer commits. El líder técnico propone revisar el flujo de trabajo de versiones. ¿Qué prácticas ayudarían a mejorar el control de versiones en este contexto?. Establecer revisiones de código antes de integrar cambios en ramas compartidas. Eliminar el uso de ramas para evitar conflictos de integración. Permitir commits directos en la rama principal para agilizar la entrega. Definir una estrategia de ramas que incluya desarrollo, integración y producción. Obligar a los desarrolladores a actualizar sus copias locales antes de realizar commits.

(AZUL) En un proyecto con entregas parciales, el equipo realiza auditorías de configuración solo al final del desarrollo. Durante una revisión externa, se detectan inconsistencias en versión de distintos artefactos, falta de trazabilidad y ausencia de información en los registros de control de cambios. ¿Qué prácticas están alineadas con una correcta planificación de auditorías en SCM?. Realizar una única auditoría final para validar el producto completo. Realizar auditorías previas a cada entrega para asegurar que los ítems estén completos y correctamente versionados. Planificar auditorías en puntos de control definidos en el cronograma del proyecto. Documentar los resultados de cada auditoría para facilitar el seguimiento y la trazabilidad. Evitar auditorías intermedias para no interrumpir el flujo de trabajo del equipo.

(AZUL) Durante una sesión de planificación, el equipo Scrum revisa las historias de usuario propuestas para el próximo sprint. Algunas tienen dependencias no resueltas, otras no están estimadas, y otras no tienen criterios de aceptación definidos. El Scrum Master recuerda que el equipo debe evitar este tipo de situaciones aplicando un Definition of Ready correcto. ¿Qué acciones están alineadas con una correcta aplicación del Definition of Ready en este contexto?. Incluir las historias de usuario en el sprint si el equipo cree que puede resolver los detalles durante la ejecución. Validar que cada historia tenga criterios de aceptación claros antes de incluirla en el Sprint Backlog. Estimar las historias durante el sprint para no demorar la planificación. Asegurar que las dependencias estén identificadas y gestionadas antes de comprometerse con la historia. Postergar las historias de usuario que no cumplen con el DoR hasta que estén completas y refinadas.

(AZUL) ¿Cuál de las siguientes afirmaciones refleja correctamente el uso del Definition of Done en un equipo Scrum?. El DoD puede variar entre miembros del equipo según su especialidad. El DoD debe ser compartido y comprendido por todo el equipo para asegurar calidad y consistencia. El DoD se define por el Product Owner y se comunica al equipo de desarrollo. El DoD se aplica únicamente a historias de usuario, no al incremento completo.

(AZUL) Durante la fase de ejecución, el Líder de proyecto detecta que varios miembros del equipo no están cumpliendo con los tiempos asignados. En las reuniones de seguimiento algunos justifican retrasos por falta de claridad en las tareas, mientras que otros mencionan problemas de comunicación con otras áreas. ¿Qué acciones podrían mejorar el desempeño del equipo en este contexto?. Implementar canales de comunicación formales entre áreas involucradas. Revisar la asignación de tareas y asegurar que estén claramente definidas. Realizar reuniones de seguimiento más frecuentes para detectar desvíos a tiempo. Reasignar tareas sin consultar al equipo para acelerar la ejecución. Evitar documentar los problemas para no generar conflictos internos.

(AZUL) Un equipo Scrum con varios sprints completados presenta los siguientes problemas: ● El Product Backlog no se actualiza regularmente. ● El Sprint Backlog se define por el Scrum Master. ● El Incremento no siempre está en condiciones de ser entregado. El equipo considera que está cumpliendo con Scrum porque realiza reuniones periódicas. ¿Qué aspectos reflejan errores comunes en la aplicación de Scrum?. El Product Backlog debe ser gestionado activamente por el Product Owner para reflejar prioridades cambiantes. El Sprint Backlog debe ser definido por el equipo de desarrollo, no por el Scrum Master. Realizar reuniones periódicas es suficiente para cumplir con Scrum, aunque los artefactos no se utilicen correctamente. El Incremento debe ser potencialmente entregable al final de cada sprint. El Product Owner puede delegar la gestión del Product Backlog al Scrum Master si está sobrecargado.

(AZUL) Un equipo de desarrollo está planificando un proyecto bajo un enfoque tradicional. El gerente de proyecto solicita estimaciones detalladas para cada fase, y propone usar datos históricos y descomposición del trabajo como base. Durante la reunión surgen opiniones sobre cómo estimar. ¿Cuáles prácticas están alineadas con una correcta aplicación de estimaciones tradicionales?. Evitar considerar riesgos en las estimaciones. Descomponer el proyecto en tareas específicas y asignar duración en horas o días. Realizar estimaciones solo sobre entregables finales. Documentar los supuestos que afectan las estimaciones. Ajustar las estimaciones en función de disponibilidad de recursos y restricciones del calendario.

(AZUL) Durante el diseño de un sistema para una empresa financiera, el equipo se enfrenta a constantes cambios del cliente. Un desarrollador sugiere usar Slack para resolverlo. ¿Qué reflexión basada en No Silver Bullet podrías ofrecer?. Los cambios en los requisitos son una dificultad esencial del software, no solucionable por herramientas. El problema se debe a mala elección de lenguaje. La dificultad accidental puede resolverse con más documentación. Slack resolverá los problemas de comunicación.

(VERDE) Durante el diseño de un sistema financiero, el equipo enfrenta constantes cambios en los requisitos del cliente. Un desarrollador sugiere que el problema se resolvería adoptando un framework como Jira. ¿Qué afirmaciones son coherentes con el enfoque de Brooks? Selecciona todas las opciones correctas: El problema se debe exclusivamente a una mala elección de tecnología. El uso de frameworks como Jira puede facilitar la implementación, pero no resolverá problemas de comunicación o comprensión del dominio. Los cambios en los requisitos reflejan una dificultad esencial del software. Las herramientas pueden ayudar, pero no reemplazan el análisis profundo del problema.

(VERDE) Una empresa decide reducir el presupuesto de un proyecto en curso para reasignar fondos a otro proyecto. El alcance y el cronograma deben mantenerse. ¿Qué afirmaciones reflejan correctamente el impacto según la triple restricción? Selecciona todas las opciones correctas: El equipo puede mantener el rendimiento sin cambios si se motiva adecuadamente. El costo está directamente relacionado con los recursos disponibles para cumplir con el alcance y el tiempo. Reducir el presupuesto sin ajustar el alcance ni el tiempo puede afectar la calidad del producto. Para mantener el alcance y el tiempo, se podrían reducir recursos o buscar soluciones más económicas.

(VERDE) Durante un sprint, el Product Owner solicita agregar una nueva funcionalidad que no estaba en el sprint backlog. El equipo expresa preocupación por el impacto en la entrega. ¿Qué afirmaciones reflejan correctamente cómo se gestiona el alcance en proyectos ágiles? Selecciona todas las opciones correctas: En Scrum, el alcance es fijo durante el sprint, pero negociable entre iteraciones. Cambiar el alcance del sprint puede impactar en el compromiso asumido. El equipo debe aceptar todos los cambios para mantener la satisfacción del cliente. El alcance puede ajustarse entre sprints, pero no durante un sprint en curso.

(VERDE) Durante el desarrollo de un producto, el cliente solicita cambios frecuentes en los requerimientos. ¿Qué características del enfoque ágil permiten gestionar esta situación de forma efectiva? Selecciona todas las opciones correctas: Los cambios se incorporan únicamente al final del proyecto. Los cambios deben ser aprobados por un comité de control de cambios. El product backlog se actualiza constantemente según nuevas prioridades. Las iteraciones permiten revisar y ajustar el alcance regularmente. La colaboración continua con el cliente facilita la adaptación.

(VERDE) Durante una sesión de planificación de sprint, el equipo Scrum se encuentra debatiendo cómo abordar las estimaciones de las nuevas historias de usuario. El Scrum Master nota que algunos miembros prefieren reestimar tareas durante el sprint si descubren nueva información, mientras que otros sugieren dejar el trabajo para más adelante, ya que el equipo tiene una velocidad estable. El Product Owner también insiste en que las estimaciones estén alineadas con las prioridades del negocio. ¿Cuáles de las siguientes acciones están alineadas con buenas prácticas de estimación ágil en este contexto?. Permitir que el Product Owner participe en las sesiones de estimación para aportar contexto de negocio. Estimar tareas técnicas por separado durante la ejecución para mayor control. Estimar en equipos maduros ya que tienen una velocidad estable. Reestimar historias de usuario durante el sprint si se descubre nueva información. Utilizar la velocidad del equipo como referencia para proyectar la capacidad en futuros sprints.

(VERDE) Durante una retrospectiva, el equipo Scrum identifica que el Product Owner no ha estado disponible para aclarar dudas sobre las historias de usuario, lo que ha generado bloqueos durante el sprint. El Scrum Master propone revisar el proceso, pero el equipo sugiere involucrar más al Product Owner. ¿Qué acciones están alineadas con el marco de trabajo Scrum para abordar esta situación?. Fomentar la colaboración continua entre el equipo de desarrollo y el Product Owner durante el sprint. Reemplazar al Product Owner por un desarrollador con mayor conocimiento técnico. Establecer acuerdos de disponibilidad y comunicación con el Product Owner como parte de la mejora continua. Solicitar al Scrum Master que asuma el rol de Product Owner temporalmente. Mejorar las sesiones de refinamiento del product backlog para asegurar que las historias estén claras antes del sprint.

(VERDE) En un proyecto tradicional, el equipo debe estimar el esfuerzo de desarrollo de un módulo crítico. El gerente solicita estimaciones detalladas y confiables, y exige un cronograma cerrado. Durante la reunión, se discute cómo abordar la estimación considerando la complejidad técnica, la experiencia del equipo y los riesgos asociados. ¿Qué prácticas contribuirían a generar estimaciones más confiables en este contexto?. Incorporar márgenes de contingencia para cubrir posibles desviaciones por riesgos. Evitar documentar los supuestos del proyecto para no generar expectativas poco realistas. Utilizar datos históricos de proyectos similares como referencia para estimar esfuerzo. Basar las estimaciones únicamente en la opinión del gerente de proyecto para mantener consistencia. Descomponer el módulo en tareas específicas y asignar duración en horas a cada una.

(VERDE) En la ejecución de un proyecto tradicional, el equipo detecta que una tarea crítica está demorando más de lo previsto. El Líder del proyecto considera modificar el cronograma y reasignar recursos. Algunos miembros del equipo proponen esperar a la próxima reunión formal para tomar decisiones, mientras que otros proponen registrar el cambio sin actualizar el plan base. ¿Qué prácticas están alineadas con una correcta gestión de cambios en proyectos tradicionales?. Evaluar el impacto del retraso en el camino crítico y actualizar el cronograma si es necesario. Registrar el cambio en el cronograma sin modificar el plan de proyecto para mantener la trazabilidad. Actualizar el plan de proyecto solo si el cliente lo aprueba, independientemente del impacto tecnico. Esperar a la reunión formal de seguimiento para tomar decisiones, aunque el retraso afecte al proyecto. Reasignar recursos si permite mitigar el impacto del retraso en el proyecto.

(VERDE) En un proyecto tradicional, el Líder observa que el equipo está cumpliendo con las tareas planificadas, pero los entregables no cumplen con los estándares de calidad definidos. Algunos miembros argumentan que cumplir con el cronograma es más importante que revisar la calidad. ¿Qué prácticas deberían aplicarse para asegurar la calidad en este contexto?. Delegar la responsabilidad de calidad exclusivamente al cliente que recibe el producto. Documentar los criterios de calidad en el plan de gestión de calidad. Aplicar aseguramiento de calidad desde las primeras fases del proyecto. Priorizar el cumplimiento del cronograma por sobre los estándares de calidad si hay presion de tiempo. Realizar controles de calidad periódicos para verificar que los entregables cumplen con los requisitos.

(VERDE) Durante una sesión de refinamiento del Product Backlog, el equipo detecta que varias historias de usuario no tienen criterios de aceptación ni estimaciones. El Product Owner insiste en incluirlas en el próximo sprint por su urgencia, mientras que el Scrum Master recuerda que el equipo acordó un Definition of Ready para evitar este tipo de situaciones. ¿Qué acciones están alineadas con una correcta aplicación del criterio de listo (Definition of Ready) en este contexto?. Incluir las historias de usuario en el sprint si el Product Owner considera que son urgentes, aunque no cumplan con el DoR. Estimar las historias de usuario durante el sprint para ganar tiempo en la planificación. Asegurar que las historias de usuario cumplan con los criterios definidos en el DoR antes de ser seleccionadas para ser incluidas en el sprint. Utilizar el DoR como guía para evaluar si una historia de usuario está suficientemente preparada para ser trabajada. Postergar las historias de usuario que no cumplen con el DoR hasta que estén refinadas adecuadamente.

(AMARILLO) Una empresa de desarrollo de software ha decidido implementar una nueva tecnología de inteligencia artificial para asistir en la generación automática de código. El equipo directivo espera que esta herramienta duplique la productividad y reduzca significativamente los errores. Como líder técnico, debes evaluar esta expectativa. Según los planteamientos de Fred Brooks en “No Silver Bullet”, ¿cuál sería la respuesta más adecuada?. Aunque la inteligencia artificial puede mejorar aspectos accidentales del desarrollo, no eliminará las dificultades esenciales, por lo que la expectativa debe moderarse. La productividad del software depende exclusivamente de la tecnología utilizada, por lo que la herramienta garantizará el éxito. La inteligencia artificial puede eliminar las dificultades esenciales del desarrollo de software, por lo que la expectativa es realista. Las dificultades del desarrollo de software son principalmente técnicas, por lo que cualquier avance tecnológico resolverá los problemas.

(AMARILLO) Durante el desarrollo de un sistema de gestión para una universidad, el cliente solicita agregar nuevas funcionalidades no contempladas en el alcance original, sin modificar el presupuesto ni el cronograma. Como líder de proyecto, ¿qué afirmaciones reflejan correctamente el impacto según lo que plantea la triple restricción? Selecciona todas las opciones correctas: Para mantener la calidad, se debería extender el tiempo y aumentar el presupuesto. Cambiar el alcance afecta directamente las otras dos restricciones: tiempo y costo. Aumentar el alcance sin ajustar tiempo ni costo puede comprometer la calidad del producto. El equipo acuerda trabajar horas extra, puede absorber el cambio sin impacto.

(AMARILLO) Una organización quiere implementar el framework Scrum para gestionar sus proyectos. ¿Qué afirmaciones reflejan correctamente cómo se gestiona el costo en proyectos ágiles? Selecciona todas las opciones correctas: Mantener el presupuesto implica priorizar funcionalidades de alto valor. En ágil, el costo no se considera una restricción relevante. El costo puede mantenerse estable si se ajusta el alcance en cada iteración. El costo en ágil suele estar asociado al tiempo de trabajo del equipo, que es predecible por sprint.

(AMARILLO) En Scrum, el Product Owner tiene un rol clave en la gestión de requerimientos. ¿Cuáles son sus responsabilidades principales en este aspecto? Selecciona todas las opciones correctas: Traducir las necesidades del cliente en historias de usuario claras. Definir el alcance técnico de cada iteración. Priorizar los ítems del backlog según el valor de negocio. Aprobar el código antes de su integración. Asegurar que el equipo entienda los requerimientos antes de cada sprint.

(AMARILLO) ¿Cuáles de las siguientes prácticas son recomendadas para la planificación de releases en un entorno ágil?. Congelar el product backlog al inicio del release para evitar cambios. Estimar todas las funcionalidades con precisión antes de iniciar el desarrollo. Involucrar stakeholders en la definición de objetivos del release. Hacer un Roadmap evolutivo que se ajuste a cambios de prioridad. Priorizar entregables según valor de negocio y feedback del cliente.

(AMARILLO) Durante la planificación de un proyecto gestionado con un enfoque tradicional, el equipo debe estimar el esfuerzo de cada tarea del cronograma. El gerente de proyecto solicita estimaciones detalladas en horas y propone usar técnicas cuantitativas para mejorar la precisión. Algunos miembros del equipo sugieren usar datos históricos, mientras que otros proponen agregar márgenes de contingencia. ¿Cuáles de las siguientes prácticas están alineadas con enfoques tradicionales de estimación?. Basarse en datos históricos de proyectos similares para mejorar la precisión de las estimaciones. Estimar únicamente las tareas que tienen asignado un recurso específico. Incorporar márgenes de contingencia para mitigar riesgos en el cronograma. Descomponer el trabajo en tareas detalladas y asignar duración en horas a cada una. Evitar la documentación de supuestos para no generar confusión en el equipo.

(AMARILLO) Durante una reunión de planificación de sprint, el equipo Scrum discute cómo abordar una historia de usuario compleja que involucra múltiples áreas técnicas. Algunos miembros proponen dividirla en tareas técnicas, mientras que otros sugieren dejarla para el próximo sprint. El Product Owner insiste en incluirla por su valor de negocio, y el Scrum Master interviene para facilitar el consenso. ¿Cuáles de las siguientes acciones están alineadas con buenas prácticas Scrum en este contexto?. Dividir la historia de usuario en historias más pequeñas que puedan completarse dentro del sprint. Priorizar la historia en función de su valor de negocio, pero asegurarse de que sea estimable y realizable. Permitir que el Scrum Master decida si la historia entra o no en el sprint, para evitar conflictos. Convertir la historia en tareas técnicas para facilitar la estimación y planificación. Incluir la historia de usuario en el sprint sin modificarla, confiando en que el equipo podrá completarla.

(AMARILLO) ¿Qué prácticas son adecuadas para el control del proyecto en un enfoque tradicional?. Ajustar el alcance sin pasar por el proceso formal de gestión de cambios. Comparar el avance real con el plan de proyecto para detectar desviaciones. Actualizar el cronograma sin registrar los cambios para evitar burocracia. Realizar reuniones de seguimiento periódicas con el equipo.

(AMARILLO) En la etapa de cierre de un proyecto tradicional, el equipo técnico considera que no es necesario realizar una revisión final, ya que todos los entregables fueron completados. El Líder de proyecto insiste en realizar una evaluación final y documentar las lecciones aprendidas. ¿Qué prácticas están alineadas con una correcta gestión del cierre de proyectos?. Omitir la revisión final si no hubo desviaciones significativas durante el proyecto. Evitar compartir los resultados del proyecto con los stakeholders para no generar nuevas expectativas. Realizar una reunión de cierre para evaluar el cumplimiento de objetivos y entregables. Documentar las lecciones aprendidas para mejorar futuros proyectos. Archivar los documentos del proyecto y liberar los recursos asignados.

(AMARILLO) Un equipo ágil está revisando su Definition of Ready porque detectaron que muchas historias de usuario ingresan al sprint sin estar claras, lo que genera bloqueos. Algunos miembros proponen agregar requisitos técnicos mínimos, mientras que otros sugieren eliminar el DoR para ganar flexibilidad. ¿Qué prácticas están alineadas con un uso adecuado del Definition of Ready?. Revisar y ajustar el DoR de forma colaborativa para que refleje las necesidades reales del equipo. Incluir criterios como estimación, criterios de aceptación y dependencias identificadas. Asegurar que el DoR sea conocido y compartido por todo el equipo. Usar el DoR como una herramienta rígida que impida cualquier excepción. Eliminar el DoR si genera demoras en la planificación del sprint.