Skip to main content

Seleccionar el mejor flujo de trabajo

Después de completar esta unidad, podrá:

  • Explicar en qué casos usaría Scrum para gestionar el trabajo y en cuáles otros usaría Kanban.
  • Definir el trabajo con prioridad en interrupciones.
  • Explicar por qué algunos equipos usan Scrumban.

En Salesforce, el 70% de los equipos usa Scrum y el 20% prefiere Kanban. El resto de los equipos usan una combinación de ambas, ya que son herramientas compatibles entre sí.

Entonces, ¿cómo decidir cuál es el mejor flujo de trabajo para impulsar el éxito de su equipo? ¿Scrum, Kanban o ambos? En realidad, todo depende del tipo de trabajo que realice su equipo y de lo imprevisible que sea o de las interrupciones que surjan. Podemos ayudarlo a decidir.  

En primer lugar, a continuación se exponen las principales preguntas que debe plantearse a la hora de decidir qué flujo de trabajo usar:

  • ¿Su equipo se centra en la previsibilidad y la productividad de grandes proyectos?
  • ¿Con cuánto tiempo de antelación cuenta su equipo para planificar?
  • ¿El trabajo nuevo de verdad representa una emergencia?
  • ¿Con qué velocidad debe entregarse un nuevo trabajo?

¿Su equipo se centra en la previsibilidad y la productividad de grandes proyectos?

Examine estos dos diferentes tipos de proyecto de trabajo.

Caso de estudio de Scrum

Imagine que su equipo debe crear un nuevo sitio web. El equipo puede dividir el trabajo en proyectos más pequeños. A medida que se completen los elementos de trabajo más pequeños, el equipo podrá revisar su progreso en cada sprint y realizar modificaciones para garantizar que todo el proyecto se lleve a cabo correctamente. Si el proyecto necesita un cronograma de entrega predecible, Scrum es el flujo de trabajo preferible. 

Caso de estudio de Kanban

¿Su equipo tiene que lidiar con cortes de servicio? Ese es un ejemplo de trabajo con prioridad en interrupciones. No siempre se puede prever o planificar los cortes de suministro con 2 semanas de antelación. Los equipos que trabajan en soporte de arquitectura, servicios o plataformas tienden a trabajar con problemas que aparecen y cambian las prioridades. 

En este caso, Kanban es la mejor opción, ya que su flujo de trabajo flexible permite la gestión de estos tipos de cortes imprevistos.

¿Con cuánto tiempo de antelación cuenta el equipo para planificar?

Hay que decidir el grado de planificación con el que el equipo puede ejecutar y concluir un proyecto. Los equipos usan Scrum cuando su hoja de trabajos pendientes está llena de pequeños fragmentos de proyectos más grandes que son fáciles de planificar con antelación.

¿Las prioridades de su equipo cambian con frecuencia? ¿Comprometerse con el alcance del trabajo durante 2 semanas seguidas supone un desafío? ¿Al menos el 25% de su trabajo cambia a mitad del sprint? Si su equipo debe responder a la aparición de nuevos elementos de trabajo con muy poca antelación, quizá Kanban sea la opción más adecuada. Esto es lo que denominamos trabajo con prioridad en interrupciones.

¿El trabajo nuevo de verdad representa una emergencia?

¿Pero en qué consiste el trabajo con prioridad en interrupciones?

Lo ideal sería limitar los cambios que sufre el equipo. Hay una serie de cuestiones que los equipos deben tener en cuenta antes de clasificar los nuevos elementos de trabajo como urgentes o prioritarios.  

  1. ¿Este proyecto puede causar alteraciones que requieran mucho tiempo y desmotiven al equipo?
  2. ¿Las interrupciones impiden que el equipo termine trabajos más importantes?
  3. ¿Las interrupciones impiden que el equipo termine lo más importante primero?

Kanban no será de ayuda para el equipo si la prioridad del trabajo no son realmente las interrupciones. Aquí tiene algunas maneras para determinar si su trabajo prioriza o no las interrupciones (y, en consecuencia, si Scrum es la mejor opción).

  • Pregúntese lo siguiente: ¿El trabajo necesario es una interrupción que impide la actividad comercial o podría generar la pérdida del negocio si no se resuelve cuanto antes? Muchas veces, puede descubrir que no es su caso y que estos elementos de trabajo son urgentes debido a una mala planificación.
  • ¿Cuál es la verdadera causa de la necesidad de este trabajo y por qué no se identificó en la etapa de planificación?  
    • ¿Se debió a que no planificamos con antelación?  
    • ¿Se trataba de una nueva solicitud de una parte interesada o de un cliente?
    • ¿El producto no funciona?

Si el trabajo urgente es el mero resultado de una mala planificación, no es una interrupción tan importante que justifique el cambio a Kanban. 

¿Con qué velocidad deben entregarse los nuevos elementos de trabajo prioritarios?

Las interrupciones de alta prioridad ocurren en cualquier compañía competente y exitosa. Lo importante es cómo se gestionan esas interrupciones. 

Así que, cuando se presente una solicitud urgente, pregúntese: "¿Cuánto tiempo usted o la parte interesada pueden esperar a que se concluya un elemento de trabajo urgente?". Es importante plantearse esta pregunta porque Scrum y Kanban procesan los proyectos en función de plazos diferentes. Si el trabajo debe realizarse lo antes posible, Kanban es el flujo de trabajo menos disruptivo que puede emplear.

Recuerde: Scrum limita la capacidad de trabajo mediante la focalización en una sección de 2 semanas de su hoja de trabajos pendientes. Kanban restringe la capacidad con límites de trabajo en curso para no realizar varias tareas al mismo tiempo. 

A continuación, encontrará una tabla en la que se describen algunas de las diferencias clave entre el flujo de trabajo Scrum y Kanban. Imaginemos que un cliente solicita una nueva función para la aplicación que estamos desarrollando.

Scrum

Kanban

¿Quién establece las prioridades?

El propietario del producto establece prioridades en la hoja de trabajos pendientes del producto.

El propietario del producto establece prioridades en la hoja de trabajos pendientes del producto.

¿A dónde va?

La hoja de trabajos pendientes del producto se reordena para el próximo sprint.

La hoja de trabajos pendientes del producto se reordena de forma continua para encontrar a la próxima persona con capacidad disponible.

¿Cuándo comienza el trabajo?

Durante la planificación del sprint, el equipo se compromete a trabajar en el próximo sprint.

En cuanto haya capacidad disponible para comenzar el trabajo.

¿Por qué podrían producirse retrasos?

Scrum hace que el equipo se enfoque en cumplir sus compromisos del sprint y no se favorecen las interrupciones a mitad del trabajo.

Kanban se enfoca en el flujo de trabajo eficiente, por lo que los primeros trabajos de la lista de pendientes siempre son los próximos que se atenderán.

¿Cuánto tiempo demora la entrega?

Puede demorarse 2 semanas o más, según el estado del sprint.

En cuanto el trabajo se haya completado.

Use Kanban si es necesario cambiar de dirección con frecuencia, minimizar las interrupciones del plan o empezar con el trabajo urgente cuanto antes.

Use Scrum si gestiona un proyecto planificado de gran volumen, si su equipo puede comprometerse a plazos de 2 semanas de trabajo o si las partes interesadas pueden esperar hasta el final del sprint para que el equipo comience con el trabajo.

Puede usar ambos: Scrumban

Muchos equipos de Salesforce aprovechan las ventajas de usar elementos tanto de Scrum como de Kanban para gestionar su carga de trabajo. Muchas veces, a los equipos les gusta la estructura de la cadencia regular de planificación y revisión de Scrum, porque les permite gestionar el progreso con mayor facilidad. Al mismo tiempo, usan los límites del trabajo en curso de Kanban para hacer frente al trabajo urgente mientras minimizan las interrupciones que proporciona este modelo.

A lo largo de este recorrido, gracias a un espíritu de inspección y adaptación, destacamos las formas de trabajar y los temas comunes para ofrecer el máximo beneficio a nuestros clientes.

Comparta sus comentarios de Trailhead en la Ayuda de Salesforce.

Nos encantaría saber más sobre su experiencia con Trailhead. Ahora puede acceder al nuevo formulario de comentarios en cualquier momento en el sitio de Ayuda de Salesforce.

Más información Continuar a Compartir comentarios