Por qué hablamos de marco y no de metodología en Scrum.

contenedor
Fuente: pixabay.com

Aunque no son pocas las veces que hemos abordado esta cuestión, y aún a riesgo de caer en la repetición, hoy hablaré de por qué hablamos de marco, y no de metodología en Scrum.

El método

Un método implica un procedimiento, que conlleva una entrada y una salida, o que espera obtener un resultado determinado, esto podría concluir de algún modo en un modelo predictivo. Veamos como ejemplo los 5 pasos del método científico:

  1. Observación.
  2. Hipótesis.
  3. Experimentación.
  4. Teoría.
  5. Ley.

Expuesto lo anterior, para que algo pueda llamarse método científico debe seguir esta serie de pasos y no otros. Pero no es solo esto, sino que el método por sí establece una secuencia y serie de pasos estrictos que deben seguirse.

Siguiendo la línea de los modelos predictivos podemos hablar de la restricción que estos producen sobre la creatividad y autonomía de las personas.

El marco Scrum

Scrum es un marco y esto se ve principalmente porque no te dice cómo tienes que hacerlo todo. Scrum te indica algunas de las formas en las que lograr algunos propósitos específicos, como ejemplo de ello, los eventos. Tan solo te indica unas pautas generales, ideas, pero nada específico. Algunos se refieren a esto como «los vacíos intencionales de Scrum«. Existen prescripciones en Scrum pero estas son mínimas.

En definitiva, en Scrum tienes un conjunto de «indicaciones» (framework, marco) con las que enfrentarte a un problema complejo, pero no se define ni la forma en la que se llevan a cabo (tan solo unas líneas generales), ni el resultado esperado.

Buena muestra de esto es que el marco eliminó del marco los gráficos Burndown, pero esto no quiere decir que no podamos seguir haciendo uso de ellos, de hecho siguen siendo una buena herramienta. El mismo caso podríamos verlo con los refinamientos.

Scrum se basa en un enfoque adaptativo de ahí que lo que busque sea que sean los propios equipos los que inspeccionen y adapten continuamente su proceso.

Es por esta apertura, entre otras cosas, por lo que Scrum se potencia aún más con el uso de técnicas como TDD, BDD, ATDD, Pair Programming, prácticas de XP… y un sin fin más.

Conclusión

Puede que no sea un tema de vital importancia o que sea «sencillamente» una cuestión de lenguaje, pero creo que la diferencia existente es importante.

¿Qué opináis?

Algunos artículos relacionados

Os dejo a continuación algunos artículos que dan más información sobre este tema:

Leave a reply:

Your email address will not be published.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.