Saltar al contenido
Be Agile My Friend

Push o Pull en Scrum

Push vs Pull Scrum

Una buena practica es dar lo que luego quieras recibir. Seguro que hay algún proverbio chino al respecto, aunque con un poco de empatía a cualquiera de nosotros se nos podría haber ocurrido.

En Scrum podemos trabajar de varias formas, empujando nuestro trabajo (PUSH) o tirando de él (PULL).

Por definición, cuando planificamos el trabajo de un Sprint en el Sprint Planning, estamos haciendo PUSH puesto que estamos empujando todo el trabajo que queremos desarrollar. Cada desarrollador coge una tarea y se pone a trabajar en ella.

En principio, toda tarea que se coge del TO DO, se pone en WIP, pasa el TEST y finalmente si cumple las condiciones se pone en la columna de DONE (ver estructura de un tablero Scrum). Pero suele suceder que las figuras del desarrollador y del tester son diferentes, y en función de como se gestione el paso de una tarea de WIP a TEST podemos estar haciendo PUSH o PULL.

  • Si el desarrollador pasa la tarea a pruebas, se desentiende y se pone a trabajar en otra tarea entonces estamos haciendo PUSH. El desarrollador empuja todo el trabajo que es capaz de desarrollar.
  • Si por el contrario el desarrollador se sienta con la persona que ejecuta los casos de pruebas, y lo acompaña, resolviendo los posibles problemas que pudieran surgir de la validación, hasta que la tarea pasa a DONE, entonces estamos haciendo PULL, ya que vamos al ritmo marcado por la capacidad del tester de validar los desarrollos.

Con PUSH tenemos la ventaja de que el desarrollador aprovecha al máximo su tiempo, desarrollando a su máxima capacidad. Por el contrario, si surgen incidencias en la validación, debe dejar a medio el trabajo actual, para resolver estas, y permitir que la tarea pueda pasar a DONE. Además, podemos generar un cuello de botella en la parte de pruebas, ya que las tareas que van a la parte de validación, no tienen en cuenta la capacidad de estos usuarios de poder ejecutarlas, pudiendo encolar un volumen grande de tareas.

Con PULL tenemos la ventaja que ponemos en DONE cada tarea que cogemos. Como desventaja, el desarrollador no aprovecha todo el tiempo para desarrollar, al acompañar al tester en la validación.

Las ventajas de usar uno u otro método va en función de la composición de los equipos y de la calidad de los desarrollos.

En equipos donde hay capacidad holgada para las pruebas, tal vez el método PUSH sea mas eficiente, ya que permite al desarrollador aprovechar al máximo su tiempo. Hay que tener mucho cuidado con las entregas del ultimo día. En equipos donde el método PUSH puede funcionar teóricamente, encuentran que no han podido entregar todo el trabajo, porque no han podido validarlo, debido a que aunque el desarrollador ha terminado el desarrollo, se han entregado la mayor parte de las tareas para validar el último día del Sprint, no dando tiempo a los testers a ejecutar los casos de prueba de las mismas.

En equipos con problemas de entregas por validaciones, o con una capacidad de testers limitada, el método PULL te permite un mejor desempeño, puesto que garantizas una entrega de producto, a riesgo de disminuir el rendimiento máximo del desarrollador.

Ambas formas de trabajar son posibles, así que adapta una u otra en función de tu equipo y su desempeño.

¿Te ha gustado el post?

Valóranos!

Puntuación media / 5. Recuento:

¿Nos ayudas a compartir?

Elige la red social que prefieras!