Por qué me gusta Scrum

Scrum es una metodología que me gusta mucho, los motivos principales son los siguientes:

Es simple: la simplicidad es un valor interesante para un metodología porque facilita su transmisión. Es facil contarsela a otros, que la entiendan y por tanto que la puedan poner en práctica. No necesita una fase de 'implantación' larga y es facil encontrar sporsor para realizar esta 'implantación' porque no requiere de grandes recursos humanos ni materiales. Solo necesitas un Scrum Master que entienda su papel y esté dispuesto a realizarlo con dedicación, contundencia y mano izquierda.

Hace incapié en la visibilidad y en el ROI: es un factor vital para Scrum que los progresos realizados sean visibles. Existe un momento claro en que esa visibilidad se lleva a su máxima expresión, durante el Sprint Review, en el que el equipo presenta los avances realizados durante el último sprint. Además este avance se demuestra mediante software ejecutable, no mediante es uso de otros artefactos que solo presentan un avance teorico. Un Gantt con barras en negro no es avance, software que puedes usar si. Además el cliente puede decidir poner en producción lo ya desarrollado, con lo que es el cliente quien decide cuando comienza a recuperar su inversión. A más corto plazo, durante un Sprint, se consigue visibilidad del avance mediante el gráfico de Burndown del Sprint y a más largo plazo se consigue tambien visibilidad mediante el gráfico de Burndown del Producto. Este último permite estimar a priori, y basandonos en la capacidad y velocidad del equipo con el que contamos, cuando podremos tener una determinada funcionalidad implementada. La estimación 'tradicional' tiende a obviar las diferencias radicales que hay entre el desempeño de diferentes equipos.

Tiene roles y normas claras: Es una metodología facil de llevar a cabo, porque todas las actividades y flujos de trabajo están definidas explicitamente usando normas claras. Existe un rol, el de Scrum Master, que entre sus reponsabilidades tiene el hacer posible y vigilar que se cumplan estas normas.

Protege al equipo de desarrollo: Con el fin de evitar las distorsiones derivadas de los 'cambios de contexto', el equipo de desarrollo se encuentra protegido de los cambios, de las interrupciones, de las variaciones estrategicas, de los cambios de visión durante un sprint, esto permite que el equipo se centre en lo que realmente es importante para el avance del proyecto, construir software ejecutable con calidad suficiente para ser desplegado. Una de las quejas más frecuentes en los equipos de desarrollo es que no les dejan hacer su trabajo con la dedicación necesaria, Scrum ataja este problema de manera explicita.

Se basa en el compromiso personal: El equipo se compromete a implementar una funcionalidad en un cierto tiempo (los 20 días de un Sprint), nadie le impone fechas absurdas o imposibles. Cuando se valora al equipo se le mide por cumplir sus compromisos, no por cumplir los compromisos de los demás. Además las personas ponen mucho más empeño en cumplir sus compromisos que en cumplir los compromisos de los demás. A menudo los equipos se quejan de situaciones en las que el departamente comercial impone compromisos imposibles. Esto además no significa que la gente de producto y el cliente no reciba lo que necesita, todo lo contrario. El equipo no tiene potestad sobre el 'que' solo sobre el 'cuanto' (cuanto podemos hacer en un Sprint) y el 'como' (solo el equipo es responsable de la solución técnica.

Soluciona los problemas día a día: El Daily Scrum Metting sirve para, de una manera efectiva (no puede durar más de 15 minutos), detectar pronto los problemas, realizar un seguimiento diario y planificar el corto plazo. Se atajan pronto las situaciones anomalas, dado que esta es una de las labores del Scrum Master

Tiene una implementación para Team System.

Es ágil y por tanto, sigue los principios del manifiesto ágil:

Individuos e interacciones sobre procesos y herramientas
Software que funciona sobre documentación exhaustiva
Colaboración con el cliente sobre negociación de contratos
Responder ante el cambio sobre seguimiento de un plan

¿Por qué os gusta o no Scrum?
¿Cúal es vuestra metodología favorita? ¿Por qué?

9 comentarios sobre “Por qué me gusta Scrum”

  1. Personalmente, me encanta Scrum como metodologia y es con la que hasta el momento me he sentido mas comodo trabajando (especialmente porque, como mencionas, bien aplicada elimina un monton de peso sobre el equipo de proyecto) Ademas, como ya sabes, tengo informacion de primare mano de que dos famosas y malvadas megacorporaciones (};P) la usan en muchos de sus equipos, lo cual siempre es interesante…

    El problema que tiene Scrum (pero que es practicamente extensible a cualquier otra metodologia agil) es que el esfuerzo de implantacion no esta en «la puesta en marcha»… esta en convencer a un monton de gente de que en realidad FUNCIONA. La «perdida de control» relativa que supone el dejar la estimacion a largo plazo y tener feedbacks solo por sprints tiende a «acongojar» un poco a los managers (especialmente a los mas «estilo Dilbert) aunque suele funcionar una vez se prueba que compensa con creces en cuanto se usen la demos de final de sprint un par de veces («tenemos algo funcionando cada dos semanas? de verdad?»)

    Pero como pluses: lo facil que es de manejar, las buenas practicas en comunicacion, integracion continua, el ser «time oriented» en vez de «goal oriented»,… en fin, que si alguien quiere pasarse a «la agilidad», yo definitivamente lo recomendaria!

  2. Aupa Phobeo!!!

    No sabía que andabas entre mis lectores!!!! Tengo idea de seguir escribiendo sobre Scrum y otras metodologías ágiles, se que tu has trabajado con Scrum, espero contar con tus valiosos comentarios por aquí.

    Volviendo al tema que nos ocupa, es cierto que un problema que sufren las metodología ágiles es que siempre nacen cuestionadas, sin el apoyo de un sponsor claro, y tienen que demostrar su valided. A otras metododologías más pesadas tipo RUP o CMMI la valided se las supone.

    Creo que tiene bastante que ver en que la idea de usar una metología tiene diferentes origen en cada caso. El interés por las metodologías ágiles tiene su origen, generalmente, en los equpos de desarrollo; mientras que el interés por las metologías basadas en planeamiento y control, suelen tener su origen en la gerencia de las empresas. Es natural teniendo en cuenta la diferente cultura que guia a desarrolladores y gerentes.

    De cualquier modo, a mi modo de ver, quienes desarrollan software son los desarrolladores y una metodología tiene que servir principalmente a estos y para ello la metodología tiene que sonarles natural. A menudo la principal escollo con el que se encuentran CMMI o RUP es precisamente ‘que vienen de gerencia’, se ven como burocracia y no como ayuda.

  3. hola Rodrigo!

    Estoy leyendo un poco más sobre metodologías ágiles, y tenía pregunta para ti, y era:
    ¿cuando usas una metología ágil, que usas para el modelado del sistema?. Por lo que he revisado, a vista rápida en tus post, no has hablado mucho del modelado en metologías ágiles.

    Estuve revisando por ahí, y llegue a: http://www.agilemodeling.com/. Tu lo estas aplicando?, o se entiende que si aplicas una metodología ágil como XP o Scrum, se entiende implícitamente que estas usando Agile Modeling?

    Saludos,

Responder a phobeo Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *