Comments

    1. Kanban no define actores o roles obligatorios, los roles dependen de la organización. Generalmente participan el cliente, responsables del producto y el equipo encargado de ejecutar el trabajo.

  1. considera que Kanban sería más adecuado que Scrum para un equipo pequeño con pocos recursos y tareas que cambian constantemente?
    y por que?

    segun yo si, por motivos de que no se necesitan roles definidos y si hay tareas disponible se toma esas tareas cuando hay capacidad disponible, tambien se evita reuniones al ser un grupo pequeño para mi es mas adecuado usar kanban

  2. No terminé de entender del todo cómo funciona el límite WIP en Kanban, porque si una columna como “En Progreso” ya llegó al máximo de tareas permitidas y aparece una nueva tarea que es urgente o muy importante, entonces ¿el equipo necesariamente tiene que esperar hasta terminar alguna de las tareas actuales o existe alguna forma de hacer una excepción sin romper la lógica del sistema Kanban y sin generar nuevamente acumulación de trabajo?

  3. ¿Cómo debería determinar un equipo de desarrollo de software los límites WIP adecuados para cada etapa del proyecto sin que estos límites reduzcan la productividad o generen tiempos de espera innecesarios?

  4. ¿De qué manera influyen las métricas de Lead Time y Cycle Time en la identificación y resolución de cuellos de botella dentro de un tablero Kanban, y cómo puede el equipo utilizar ambas para diferenciar problemas de eficiencia interna frente a retrasos en la entrada de requerimientos?

  5. Tengo una duda sobre la diferencia entre el Lead Time y el Cycle Time, porque ambos parecen medir el tiempo que tarda una tarea en completarse, pero uno comienza desde que la tarea es solicitada y el otro desde que el equipo realmente empieza a trabajar en ella, entonces ¿para qué sirve medir los dos por separado y cuál de los dos sería más importante para saber si el equipo realmente está trabajando de manera eficiente?

  6. Creo que lo que más me convence de la metodología es que no exige reorganizar todo como Scrum: se aplica sobre el flujo que ya tenés y mejorás visualizando y limitando el WIP ¿en qué casos lo recomendaría por encima de Scrum?

  7. ¿si Kanban trabaja con un flujo continuo y no utiliza Sprints como Scrum, ¿cómo determina el equipo cuándo debe priorizar una tarea y cuándo debe detenerse para mejorar el flujo de trabajo?

  8. ¿cómo se supone que elija qué tarea agarrar del Backlog sin romper el flujo o saturar las columnas con límite de WIP?

  9. ¿Cómo maneja Kanban las tareas urgentes que llegan de improviso, si no existen Sprints que protejan el trabajo en curso?

  10. Kanban permite visualizar de forma clara el avance de las tareas desde el Backlog hasta Hecho, estableciendo límites de trabajo en progreso (WIP) para evitar que el equipo tenga demasiadas tareas abiertas al mismo tiempo. También es importante identificar los bloqueos y priorizar su solución para evitar retrasos y cuellos de botella.

    Además, comprendí que las métricas como Lead Time y Cycle Time ayudan a medir qué tan eficiente es el flujo de trabajo. Esto es importante porque permite al equipo detectar problemas, mejorar continuamente el proceso y tener una mejor idea de cuánto tiempo puede tomar completar y entregar una tarea.

Post a Comment