PRIS

Una de las filosofías que alimenta la Agilidad es Lean Software Development. ¿Cuál de las siguientes acciones sería considerada la eliminación de “desperdicio” más importante en un proyecto de desarrollo ágil?. Eliminar la documentación formal del proyecto y utilizar solo diagramas de flujo simples. Utilizar únicamente la Programación en Parejas (XP) para reducir los defectos del código. Reducir el número de reuniones diarias del equipo a solo dos por semana. Evitar construir funcionalidades que el cliente nunca ha solicitado explícitamente ni necesita actualmente (“funcionalidad extra”).

El principio ágil de “Aceptar que los requisitos cambien, incluso en etapas tardías del desarrollo” se relaciona más estrechamente con el concepto económico de: Coste de oportunidad. La Ley de Moore. Economía de escala. La Ley de Parkinson.

¿Cuál de los siguientes aspectos es el que el Manifiesto Ágil prioriza sobre “Seguir un plan”?. La respuesta al cambio. Los procesos y herramientas. La documentación exhaustiva. La negociación contractual.

El Manifiesto Ágil establece: “Individuos e Interacciones sobre Procesos y Herramientas”. ¿Qué implicación tiene este valor en la gestión de riesgos del proyecto?. Se debe priorizar el uso de un software de gestión de riesgos estandarizado sobre las reuniones de comunicación. La identificación y mitigación de riesgos es más efectiva a través de la comunicación directa y abierta que por medio de reportes burocráticos. El Scrum Master es el único individuo con permiso para interactuar con los stakeholders externos. Los procesos formales de gestión de riesgos, una vez definidos, no pueden ser modificados por el equipo.

Según el CHAOS Report (mencionado en el T1), el modelo tradicional de gestión en cascada fallaba porque los proyectos tendían a ser demasiado grandes y largos. ¿Cuál de los 12 Principios Ágiles ataca este problema estructural de la forma más directa y práctica?. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. El desarrollo ágil promueve procesos sostenibles: los promotores, desarrolladores y usuarios deberían poder mantener un ritmo constante de forma indefinida. Los mejores arquitectos, requisitos y diseños emergen de equipos autoorganizados. Entregar frecuentemente software que funcione, en periodos de dos semanas a dos meses, con preferencia a los periodos más cortos.

Respecto a la reunión diaria (Daily Scrum), la afirmación "El Scrum Master es el único que puede asistir a la reunión diaria" es: Verdadera, siempre y cuando el Product Owner no tenga tareas técnicas asignadas en el Sprint Backlog y se limite solamente a observar el proceso. Verdadera, ya que el Scrum Master es el único responsable de eliminar los impedimentos reportados y debe proteger la estructura de la reunión de interferencias. Falsa, pues todos los roles (SM, PO, y el público general) tienen permitido asistir, aunque solo el Equipo de Desarrollo participa activamente para inspeccionar el progreso. Falsa, pues la reunión es exclusiva para el Equipo de Desarrollo, y tanto el PO como el SM deben consultar el progreso en el Tablero Kanban.

¿Cuál es la diferencia de foco esencial entre el Product Backlog y el Sprint Backlog en la gestión de la información?. El Product Backlog se enfoca en el valor de negocio (QUÉ) y es priorizado por el PO, mientras que el Sprint Backlog se enfoca en el plan de ejecución (CÓMO) y es propiedad del Equipo. El Product Backlog es propiedad del Scrum Master, quien lo prioriza, y el Sprint Backlog es propiedad del Product Owner, quien lo supervisa y aprueba. El Product Backlog es la lista de tareas técnicas detalladas con estimación en horas, mientras que el Sprint Backlog es la lista de pruebas de integración continua a realizar. El Product Backlog se enfoca en la velocidad (Velocity) del equipo, mientras que el Sprint Backlog se enfoca en la Visión del Producto a largo plazo del negocio.

La estimación en Puntos de Historia es una práctica más ágil que la estimación en horas porque: La estimación en Puntos de Historia es la métrica más importante para calcular la eficiencia del Product Owner al hacer el Product Backlog Refinement. Mide la complejidad, el esfuerzo relativo y la incertidumbre de la tarea, que son características estables, a diferencia del tiempo, que es inestable y está sujeto a presión. Los Puntos de Historia permiten una conversión más sencilla a costo monetario fijo para la negociación contractual con el cliente al final del proyecto. Mide la complejidad y el esfuerzo absoluto del trabajo, lo cual es mucho más exacto que las horas, que suelen ser infladas por los desarrolladores.

Si un Equipo de Desarrollo tiene dificultades para completar consistentemente el trabajo comprometido en el Sprint Backlog, ¿qué evento de Scrum se utiliza para inspeccionar y adaptar el proceso de trabajo del equipo?. La Retrospectiva del Sprint (Sprint Retrospective), pues su objetivo es inspeccionar el PROCESO del equipo (cómo trabajamos), identificar las causas raíz de la dificultad y proponer mejoras. La Planificación del Sprint (Sprint Planning), pues es donde el equipo debe ser más honesto en la estimación de su Velocity para el próximo ciclo. La Revisión del Sprint (Sprint Review), pues es el momento de mostrar al cliente el incremento incompleto para que este decida si se lanza a producción o no. El Scrum Diario (Daily Scrum), ya que permite al Equipo de Desarrollo reportar el problema diariamente al Scrum Master para que este lo elimine en menos de 24 horas.

¿Qué rol tiene la autoridad final para cancelar un Sprint si el Objetivo del Sprint se vuelve obsoleto o si el trabajo pierde su valor de negocio inicial?. El Equipo de Desarrollo (Team), pues son los profesionales que realizan la ejecución del trabajo y quienes definen la Definition of Done. D. El Stakeholder Principal, ya que es el único que proporciona la financiación y quien aprueba el presupuesto de cada uno de los Sprints. El Scrum Master (SM), pues su rol principal es el de eliminar cualquier tipo de impedimento y proteger la estructura interna del equipo. El Product Owner (PO), pues es el único responsable directo de maximizar el valor del producto y el retorno de la inversión para la empresa. El Stakeholder Principal, ya que es el único que proporciona la financiación y quien aprueba el presupuesto de cada uno de los Sprints.

En la Sprint Retrospective, la fase de 'Generar Ideas' es considerada la más crítica para el Scrum Master. ¿Por qué?. Porque es la única fase donde el Product Owner está obligado a participar para aprobar los cambios propuestos. Porque aquí es donde el Scrum Master mide oficialmente el 'Burn-down Chart' para determinar si el equipo cumplió el Objetivo del Sprint. Debido a la posible 'Ley de la Monotonía', donde el equipo tiende a repetir las mismas ideas superficiales sin generar soluciones profundas o creativas a sus problemas de proceso. Porque es la fase donde el equipo define los nuevos Criterios de Aceptación para las Historias de Usuario futuras.

Un equipo de desarrollo omite deliberadamente la ejecución de pruebas de integración para cumplir con la fecha límite del Sprint. Esta omisión, causada por un DoD débil en las pruebas, genera directamente: Una violación del Time-Box del Sprint Retrospective, lo que requiere que el Scrum Master cancele el evento. Una necesidad de re-estimación de los Criterios de Aceptación en el siguiente Sprint Planning. Un Incremento Potencialmente Entregable que aún puede ser aceptado si el Product Owner lo autoriza. Una acumulación inmediata de Deuda Técnica que compromete la estabilidad futura del sistema y reduce la Velocity de Sprints posteriores.

El Product Owner desea utilizar la Velocidad (Velocity) del equipo. ¿Cuál es la aplicación correcta de esta métrica en la gestión del riesgo?. Se usa para determinar la cantidad de Deuda Técnica acumulada al dividir los Puntos de Historia terminados por los Puntos de Historia que no cumplieron el DoD. Se usa para forzar al Equipo de Desarrollo a aumentar el número de Puntos de Historia comprometidos en el siguiente Sprint Planning. Se usa para crear un Pronóstico de Liberación (Release Plan), estimando cuántos Sprints se requieren para completar una porción grande del Product Backlog o un objetivo específico del producto. Se usa para identificar a los miembros del Equipo de Desarrollo con bajo rendimiento individual en la Daily Scrum.

¿Cuál es la principal razón por la que la Definición de Terminado (DoD) se considera un compromiso del Equipo de Desarrollo y no del Product Owner (PO)?. Si una Historia de Usuario no cumple el DoD, el PO debe reescribirla y volver a priorizarla. El PO solo es responsable del 'Qué' (valor), mientras que el Equipo de Desarrollo es responsable del 'Cómo' (calidad técnica). El Equipo de Desarrollo utiliza el DoD para gestionar el riesgo del Product Backlog, que es su principal artefacto. El PO no puede participar en el DoD porque es un documento técnico y legal.

Durante la Sprint Review, ¿cuál de las siguientes acciones refleja correctamente el pilar de Adaptación de Scrum, basándose en la inspección del Incremento y el feedback de los Stakeholders?. El Product Owner modifica las prioridades y estima el Product Backlog basándose en la retroalimentación, el mercado y el Incremento demostrado. El Equipo de Desarrollo desglosa la Historia de Usuario que no cumplió el DoD en tareas más pequeñas para el siguiente Sprint. Los Stakeholders firman el acta de entrega del Incremento, asegurando que el equipo puede iniciar el siguiente Sprint. El Scrum Master actualiza la Velocity del equipo en función de los Puntos de Historia terminados.