NEW
Font size
WorksheetsDetección y Resolución de Probelmas
Total questions: 12
Worksheet time: 6mins
Como Scrum Master, usted espera que los miembros del equipo:
Acudan a usted cada vez que se encuentren con un problema
Informen de todos sus problemas en la reunión diaria de pie
Resuelvan la mayoría de los problemas colectivamente a medida que avanza el trabajo
Encuentren la mejor solución por su cuenta
Idealmente, ¿quién detectará y corregirá un error de codificación?
El cliente lo verá en la demostración
Los desarrolladores lo encontrarán durante las pruebas unitarias.
El revisor lo detectará durante la programación en pares
Los testers lo encontrarán en las pruebas
Dos miembros del equipo están teniendo una diferencia de opinión sobre cómo construir la siguiente historia de usuario. ¿Qué se debe hacer?
El Scrum Master debe evaluar el nivel de conflicto e intervenir adecuadamente.
El Scrum Máster debe decidir el tema, ya que se está convirtiendo en un impedimento para el progreso
Se debe consultar al Product Owner
El equipo debe reunirse para discutir el tema y proponer una solución colectiva.
Idealmente, ¿qué es lo que su equipo quiere ver en la línea superior de su risk burndown graph?
Una tendencia al alza constante y consistente
Una fuerte tendencia al alza tan pronto como sea posible en el proyecto
Una tendencia a la baja constante y consistente
Una fuerte tendencia a la baja tan pronto como sea posible en el proyecto
Como líder de tester en un equipo de XP, usted descubre un problema. ¿Qué debe hacer usted?
Discuta el tema con el desarrollador
Intenta arreglar el problema ti mismo.
Dile al cliente.
Alerta a los otros codificadores sobre el problema.
Un equipo ágil está refactorizando su código. ¿Por qué están haciendo esto?
Para comprobar si hay errores en las pruebas unitarias
Para asegurarse de que las pruebas estén listas antes de que se escriba el código
Para facilitar la actualización y el mantenimiento del código
Obtener un nivel consistente de deuda técnica que facilite la predicción de la velocidad.
Ponemos actividades de mitigación de riesgos en el Product Backlog para :
Evitar tener que mantener una lista separada de amenazas y problemas
Mantener al equipo enfocado en los riesgos.
Asegurar que los esfuerzos de reducción de riesgos se realicen en las primeras iteraciones
Asegúrese de que el equipo no se olvide de hacer algo con respecto a los riesgos.
Como líder del equipo, se le ha pedido que explique lo que el equipo del proyecto ha logrado durante la Iteración 0. ¿Cuáles de las siguientes herramientas utilizaría para esta presentación?
Gráfico de trabajo pendiente de deuda técnica
Risk burndown graph
Risk-adjusted backlog
Promedio de defectos por liberación
Como entrenador ágil del equipo, usted mide pequeñas cantidades de variación en la duración de las tareas. ¿Qué debe hacer usted
Llevar a cabo un análisis de causa raíz para eliminarlo.
Involucre al equipo en el diagnóstico del problema.
Diagnosticar el tema como parte de su rol de liderazgo.
Aceptar alguna variación como inevitable.
¿Cuál es el enfoque ágil para la resolución de problemas?
Arreglar el problema después de que surja, en el último momento responsable
Para mantener la velocidad consistente, sólo arregle los problemas que plantean impedimentos para el progreso.
Cuando surja un problema, arregle el problema de forma puntual o añádalo al trabajo pendiente
Capture los impedimentos, problemas y lecciones aprendidas diariamente en las reuniones de pie.
Como miembro del equipo, si encuentra un problema delicado durante el desarrollo de una iteración:
Deje de hacer lo que está haciendo hasta que encuentre una solución, utilizando su experiencia e ingenio individual.
Dígale al Scrum Máster sobre el problema y deje que ellos decidan qué hacer al respecto, ya que su trabajo es eliminar los impedimentos para el progreso.
Sólo siga avanzando para que su velocidad no se vea afectada, ya que la mayoría de los problemas eventualmente se resuelven por sí solos.
Lleve rápidamente el problema a los miembros de su equipo y pida su ayuda para resolverlo, ya que muchas cabezas son mejores que una.
¿Cuál es la razón menos probable por la cual los cambios que se encuentran más adelante en el proyecto son más costosos de arreglar?
Es posible que se necesite más retrabajo para solucionar el problema
Más partes interesadas podrían verse afectadas por el problema
Puede que haya que refactorizar más códigos.
Puede que haya que implementar más funcionalidades.
