ICS Meles - Preguntero completo

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?. La inteligencia artificial puede eliminar las dificultades esenciales del desarrollo de software, por lo que la expectativa es realista. 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. Las dificultades del desarrollo de software son principalmente técnicas, por lo que cualquier avance tecnológico resolverá los problemas.

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: Aumentar el alcance sin ajustar tiempo ni costo puede comprometer la calidad del producto. 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. El equipo acuerda trabajar horas extra, puede absorber el cambio sin impacto.

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: En ágil, el costo no se considera una restricción relevante. El costo en ágil suele estar asociado al tiempo de trabajo del equipo, que es predecible por sprint. Mantener el presupuesto implica priorizar funcionalidades de alto valor. El costo puede mantenerse estable si se ajusta el alcance en cada iteración.

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: Priorizar los items del backlog según el valor de negocio. Traducir las necesidades del cliente en historias de usuario claras. Definir el alcance técnico de cada iteración. Asegurar que el equipo entienda los requerimientos antes de cada sprint. Aprobar el código antes de su integración.

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

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?. 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. 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. Evitar la documentación de supuestos para no generar confusión en el equipo.

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. Incluir la historia de usuario en el sprint sin modificarla, confiando en que el equipo podrá completarla. Priorizar la historia en función de su valor de negocio, pero asegurarse de que sea estimable y realizable. Convertir la historia en tareas técnicas para facilitar la estimación y planificación. Permitir que el Scrum Master decida si la historia entra en el sprint, para evitar conflictos.

¿Qué prácticas son adecuadas para el control del proyecto en un enfoque tradicional?. 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. Ajustar el alcance sin pasar por el proceso formal de gestión de cambios.

En la etapa de cierre de un proyecto tradicional, el equipo técnico considera que no es necesario realizar una revisión formal, 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?. Realizar una reunión de cierre para evaluar el cumplimiento de objetivos y entregables. Documentar las lecciones aprendidas para mejorar futuros proyectos. Omitir la revisión final si no hubo desviaciones significativas durante el proyecto. Archivar los documentos del proyecto y liberar los recursos asignados. Evitar compartir los resultados del proyecto con los stakeholders para no generar nuevas expectativas.

Un equipo ágil está revisando su Definition of Ready (DoR) 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. Eliminar el DoR si genera demoras en la planificación del sprint. Incluir criterios como estimación, criterios de aceptación y dependencias identificadas. Usar el DoR como una herramienta rígida que impida cualquier excepción. Asegurar que el DoR sea conocido y compartido por todo el equipo.

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?. Registrar la solicitud de cambio en el sistema correspondiente y documentar su aprobación. Implementar el cambio directamente si el cliente lo solicita, sin necesidad de documentación. Actualizar los documentos afectados por el cambio, incluyendo el plan de proyecto y el alcance. Documentar el cambio solo si afecta el entregable final. Incluir la justificación del cambio y su impacto en los registros del proyecto.

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?. Realizar una evaluación técnica y de gestión completa antes de tomar una decisión. Priorizar la opinión del cliente por sobre el análisis técnico para agilizar la aprobación. Documentar el análisis de impacto y la decisión del CCC en el registro de cambios. Aprobar el cambio sin análisis si el equipo considera que puede implementarlo rápidamente. Consultar al equipo de arquitectura para evaluar la viabilidad técnica del cambio.

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?. Definir una estrategia de ramas que incluya desarrollo, integración y producción. Permitir commits directos en la rama principal para agilizar la entrega. Establecer revisiones de código antes de integrar cambios en ramas compartidas. Obligar a los desarrolladores a actualizar sus copias locales antes de realizar commits. Eliminar el uso de ramas para evitar conflictos de integración.

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 versiones anteriores que nunca fueron auditadas. El auditor recomienda implementar auditorías en distintos momentos del ciclo de vida. ¿Qué prácticas están alineadas con una correcta planificación de auditorías en SCM?. Evitar auditorías intermedias para no interrumpir el flujo de trabajo del equipo. Planificar auditorías en puntos de control definidos en el cronograma del proyecto. Realizar una única auditoría final para validar el producto completo. Documentar los resultados de cada auditoría para facilitar el seguimiento y la trazabilidad. Realizar auditorías previas a cada entrega para asegurar que los ítems estén completos y correctamente versionados.

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 varias no tienen criterios de aceptación definidos. El Scrum Master recuerda que el equipo acordó un Definition of Ready (DoR) para evitar este tipo de situaciones. ¿Qué acciones están alineadas con una correcta aplicación del Definition of Ready en este contexto?. Postergar las historias de usuario que no cumplen con el DoR hasta que estén completas y refinadas. Incluir las historias de usuario en el sprint si el equipo cree que puede resolver los detalles durante la ejecución. Asegurar que las dependencias estén identificadas y gestionadas antes de comprometerse con una historia de usuario. Estimar las historias de usuario durante el sprint para no demorar la planificación. Validar que cada historia de usuario tenga criterios de aceptación claros antes de incluirla en el Sprint Backlog.

¿Cuál de las siguientes afirmaciones refleja correctamente el uso del Definition of Done (DoD) en un equipo Scrum?. El DoD puede variar entre miembros del equipo según su especialidad. El DoD se aplica únicamente a historias de usuario, no al incremento completo. 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.

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?. Revisar la asignación de tareas y asegurar que estén claramente definidas. Implementar canales de comunicación formales entre áreas involucradas. Reasignar tareas sin consultar al equipo para acelerar la ejecución. Realizar reuniones de seguimiento más frecuentes para detectar desvíos a tiempo. Evitar documentar los problemas para no generar conflictos internos.

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, y 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. El Incremento debe estar potencialmente entregable al final de cada sprint. Realizar reuniones periódicas es suficiente para cumplir con Scrum, aunque los artefactos no se utilicen correctamente. El Product Owner puede delegar la gestión del Product Backlog al Scrum Master si está sobrecargado.

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 distintas opiniones sobre cómo abordar las estimaciones y qué factores considerar. ¿Cuáles de las siguientes prácticas están alineadas con una correcta aplicación de estimaciones tradicionales?. Descomponer el proyecto en tareas específicas y asignar duración en horas o días a cada una. Documentar los supuestos que afectan las estimaciones para facilitar el análisis posterior. Ajustar las estimaciones en función de la disponibilidad de recursos y restricciones del calendario. Evitar considerar riesgos en las estimaciones para mantener el enfoque en el plan ideal. Realizar estimaciones únicamente sobre entregables finales, sin incluir tareas intermedias.

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

Una startup ha invertido en una plataforma de desarrollo 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? Selecciona todas las opciones correctas: Las herramientas low-code pueden reducir dificultades accidentales como la codificación manual. Las dificultades esenciales, como la complejidad del dominio y la comunicación con el cliente, seguirán presentes. La experiencia técnica se vuelve irrelevante con herramientas modernas. Las herramientas pueden mejorar la productividad, pero no eliminar las dificultades esenciales.

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? Selecciona todas las opciones correctas: Reducir el tiempo sin ajustar el alcance ni el costo, puede generar sobrecarga en el equipo. Para cumplir con el nuevo plazo, se debería reducir el alcance o aumentar el presupuesto. La calidad del producto podría verse afectada si se mantiene el alcance y el costo. El tiempo es una variable independiente que no afecta las otras restricciones.

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? Selecciona todas las opciones correctas: 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.

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. Se prioriza la comunicación directa y continua con el cliente. Los requerimientos se documentan exhaustivamente antes de iniciar el desarrollo. Se utiliza el product backlog como herramienta viva para gestionar requerimientos. La documentación mínima viable permite mayor flexibilidad ante cambios.

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

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. El uso de estimaciones temporales (horas/días) es preferido en metodologías ágiles por su precisión. Planning Poker fomenta la colaboración del equipo y reduce el sesgo individual en las estimaciones. Las estimaciones ágiles deben ser precisas para garantizar el cumplimiento del sprint. El valor de una historia de usuario puede influir en su estimación si se utiliza el método WSJF (Weighted Shortest Job First).

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 eso 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.

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?. Incluir márgenes de contingencia para mitigar riesgos y posibles desviaciones. Documentar los supuestos que afectan el cronograma para facilitar el análisis posterior. Eliminar tareas del cronograma si los stakeholders consideran que no aportan valor directo. 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.

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?. Evaluar el impacto del cambio en el alcance sobre el cronograma, costos y calidad. Registrar el cambio en el plan de proyecto solo si el cliente lo aprueba formalmente. Aplicar el proceso de gestión de cambios antes de incorporar la nueva funcionalidad. Implementar el cambio directamente si el equipo técnico lo considera beneficioso. Negociar con el cliente para ajustar el cronograma si el cambio es aceptado.

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?. Aceptar cambios menores sin documentación si no afectan funcionalidades críticas. Revisar el proceso de control de cambios para asegurar que todos los ítems modificados estén registrados. Validar únicamente los ítems que fueron entregados al cliente final. Documentar las decisiones tomadas durante el desarrollo, incluso si los cambios parecen triviales. Verificar que todos los ítems de configuración tengan trazabilidad con los requisitos aprobados.

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: Los cambios en los requisitos reflejan una dificultad esencial del software. El uso de frameworks como Jira puede facilitar la implementación, pero no resolverá problemas de comunicación o comprensión del dominio. El problema se debe exclusivamente a una mala elección de tecnología. Las herramientas pueden ayudar, pero no reemplazan el análisis profundo del problema.

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: 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. 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.

Durante un sprint, el Product Owner solicita agregar una nueva funcionalidad que no estaba en el sprint backlog. El equipo de desarrollo 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: El alcance puede ajustarse entre sprints, pero no durante un sprint en curso. Cambiar el alcance durante el sprint puede impactar en el compromiso asumido. En Scrum, el alcance es fijo durante el sprint, pero negociable entre iteraciones. El equipo debe aceptar todos los cambios para mantener la satisfacción del cliente.

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: El product backlog se actualiza constantemente según nuevas prioridades. Los cambios se incorporan únicamente al final del proyecto. Las iteraciones permiten revisar y ajustar el alcance regularmente. La colaboración continua con el cliente facilita la adaptación. Los cambios deben ser aprobados por un comité de control de cambios.

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 proponen reestimar tareas durante el sprint, mientras que otros sugieren dejar de estimar por completo, ya que el equipo tiene una velocidad estable. El Product Owner también quiere participar en la estimación para asegurar que se consideren 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. 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. Estimar tareas técnicas en lugar de historias de usuario para mayor control. Evitar estimaciones en equipos maduros que ya tienen una velocidad estable.

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 de refinamiento del backlog y mejorar la comunicación. Algunos miembros sugieren cambiar el rol del Product Owner por alguien más técnico. ¿Qué acciones están alineadas con el marco de trabajo Scrum para abordar esta situación?. Mejorar las sesiones de refinamiento del product backlog para asegurar que las historias estén claras antes del sprint. Reemplazar al Product Owner por un desarrollador con mayor conocimiento técnico. Fomentar la colaboración continua entre el equipo de desarrollo y el Product Owner durante el sprint. Solicitar al Scrum Master que asuma el rol de Product Owner temporalmente. Establecer acuerdos de disponibilidad y comunicación con el Product Owner como parte de la mejora continua.

En un proyecto tradicional, el equipo debe estimar el esfuerzo de desarrollo de un módulo crítico. El gerente de proyecto solicita estimaciones detalladas y confiables, ya que el cliente 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?. Descomponer el módulo en tareas específicas y asignar duración en horas a cada una. Incorporar márgenes de contingencia para cubrir posibles desviaciones por riesgos. Basar las estimaciones únicamente en la opinión del gerente de proyecto para mantener consistencia. Utilizar datos históricos de proyectos similares como referencia para estimar esfuerzo. Evitar documentar los supuestos para no generar expectativas poco realistas.

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 de proyecto considera modificar el cronograma y reasignar recursos. Algunos miembros del equipo sugieren 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. Reasignar recursos si eso permite mitigar el impacto del retraso en el proyecto. Esperar a la reunión formal de seguimiento para tomar decisiones, aunque el retraso afecte el proyecto. Actualizar el plan de proyecto solo si el cliente lo aprueba, independientemente del impacto técnico.

En un proyecto tradicional, el Líder de proyecto 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?. Realizar controles de calidad periódicos para verificar que los entregables cumplen con los requisitos. Priorizar el cumplimiento del cronograma por sobre los estándares de calidad si hay presión de tiempo. Documentar los criterios de calidad en el plan de gestión de calidad. Delegar la responsabilidad de calidad exclusivamente al cliente que recibe el producto. Aplicar aseguramiento de calidad desde las primeras fases del proyecto.

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 (DoR) 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?. Asegurar que las historias de usuario cumplan con los criterios definidos en el DoR antes de ser seleccionadas para ser incluidas en el sprint. Incluir las historias de usuario en el sprint si el Product Owner considera que son urgentes, aunque no cumplan con el DoR. Utilizar el DoR como guía para evaluar si una historia de usuario está suficientemente preparada para ser trabajada. Estimar las historias de usuario durante el sprint para ganar tiempo en la planificación. Postergar las historias de usuario que no cumplen con el DoR hasta que estén refinadas adecuadamente.