Metodología Scrum

Scrum es un marco de referencia para desarrollo ágil de productos. Esta metodología se puede aplicar a procesos de producción de distintos sectores, yo me centraré en el de Desarrollo de Software.

Desarrollo tradicional vs Desarrollo Ágil

Especialización vs Equipo Multidisciplinar

Fases vs Solapamiento

Requisitos detallados vs Visión del producto

Seguimiento del plan vs Adaptación a los cambios

Las metodologías tradicionales se ven como una carrera de relevos, en el que cada miembro es responsable de una fase, y hasta que no se termina una fase, es imposible comenzar las siguientes.

En cambio, las metodologías ágiles son más como un partido de Rugby, en el que el empuje conjunto del equipo es importantísimo para el éxito. De hecho, Scrum significa melé.

Ya comparé en un post anterior estos dos tipos de metodologías.

¿Por qué Scrum?

• El cliente puede ver resultados desde el primer momento.

• Se ahorra el tiempo que en las metodologías tradicionales se dedica en conseguir especificaciones y documentaciones exhaustivamente documentadas.

• Se hace equipo: comunicación contínua, se reparten éxitos.

• El cliente interviene en todas las fases del proyecto.

• Se reducen los riesgos por retrasos acumulados, entregas que difieren de lo que el cliente esperaba, y por tanto influye de manera decisiva en el éxito del proyecto.

• Es una metodología sencilla y nada rígida. Se puede complementar con otras. Por ejemplo, nosotros la combinamos con eXtreme Programming.

¿Qué se necesita para aplicar Scrum?

• Actores: usuarios con distintos tipos de roles.

Product Owner: Representa la voz del cliente. Escribe historias de usuario, las prioriza, y las coloca en el Product Backlog.

Scrum Master: Protege al equipo de distracciones y de otros elementos externos (presiones no razonables,...). Elimina obstáculos que alejen al grupo de la consecución de objetivos del sprint. No es el líder del grupo, ya que el grupo se autogestiona.

Equipo: Tiene la responsabilidad de entregar el producto.

Product Owner, Scrum Master, y Equipo, son roles llamados "Cerdo". También hay roles "Gallina", que no forman parte de Scrum (Cliente, Usuario, Manager).

• Product Backlog o Pila de Producto:

Traducción poco afortunada, por cierto, ya que no sería una estructura "pila", es más bien una lista ordenada y priorizada de Historias de Usuario. Es confeccionada por el Product Owner o el Cliente.

Las Historias de Usuario son requisitos a muy alto nivel de lo que debe hacer la aplicación. Por ejemplo: Como administrador quiero dar de alta un usuario en el sistema.

• Estimación:

El Scrum Master y el Equipo estiman cada una de las Historias de Usuario del Product Backlog. Para ello, cada miembro del Equipo, dispone de una baraja Scrum, que contiene los valores: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinito, ?. Estos valores son llamados Puntos de Historia y sirven para valorar el "esfuerzo" necesario para desarrollar cada "Historia de Usuario". Los valores de la baraja sigue una sucesión de Fibonacci aproximada, y redondeada. No nos interesa afinar demasiado, sobretodo en los valores más altos, ya que son los más susceptibles de desviarse. Los Puntos de Historia nos sirven para comparar Historias. Es decir, si dos Historias están estimadas en "5", nos costará el mismo esfuerzo (aproximadamente) llevarlas a cabo, y seguramente se tarde lo mismo en ser concluidas, pero de "tiempos" hablaremos más adelante.

Si una Historia está estimada con valores altos, 100 o infinito, seguramente deberá ser dividida en varias Historias "más pequeñas". El infinito se suele usar cuando una Historia no está suficientemente definida, y normalmente conlleva una

...