QuŽ es scrum?

Dentro de la pr‡ctica de desarrollo de sistemas administrado bajo el paradigma ‡gil scrum es una de las metodolog’as de mayor aceptaci—n y uso dentro de la comunidad de desarrolladores de las empresas m‡s influyentes de software como Microsoft y Google por mencionar algunas (scrum gathering 2005). Scrum es una de las metodolog’as ‡giles que est‡n mejor estructuradas y a la vez no rompen con los principios del manifiesto ‡gil publicados en 2001 (http://www.agilemanifesto.org/iso/es/), sino al contrario toma los principios como suyos. En scrum se valora:

á       A los individuos y las interacciones entre ellos sobre los procesos y las herramientas

á       Funcionalidad completada sobre documentaci—n comprensiva

á       Colaboraci—n con el cliente sobre negociaci—n de contratos

á       Responder al cambio sobre seguir un plan

 

Siguiendo estos lineamientos, Scrum es un paradigma para desarrollo de sistema iterativo e incremental. En scrum cada iteraci—n se denomina sprint. Scrum define de manera general l los siguientes pasos:

1.     Crear una lista priorizada de requerimientos llamada backlog

La lista priorizada de requerimientos empieza por ser una lista de requerimientos indicada directamente por el usuario o solicitante que en scrum se conocer como due–o del producto. El due–o del producto expone sus requerimientos al equipo de trabajo y los mismo se registran como cuentos del usuario (del inglŽs user stories). Los cuentos del usuario son referencias, indicaciones, notas para ser usadas m‡s adelante durante el desarrollo del sistema. La diferencia m‡s importante entre un cuento de usuario y un requerimiento es que los cuentos de usuario no son documentos finales e inamovibles, sino que son referencias a ideas que pueden ser negociables, que de hecho se desarrollar‡n a detalle cuando el equipo de trabajo desglose las tareas requeridas para implementar el cuento. Esta tŽcnica es m‡s aceptada por los solicitantes pues es mucho m‡s flexible y menos estricta, por lo que se sienten en mayor libertad para expresas sus ideas y para comunicar sus peticiones. El registro de los cuentos de usuario se realiza en una sesi—n de trabajo en d—nde participa el equipo completo que estar‡ trabajando durante el desarrollo del sistema y el due–o del producto. Se pueden utilizar varias tŽcnicas para su recopilaci—n. Una de las tŽcnicas m‡s usadas cualquiera que sea el formato es hacerse las preguntas: ŔquiŽn?, ŔquŽ?, y Ŕpara quŽ? QuiŽn responde a la interrogante sobre quiŽn ser‡ en usuario de la caracter’stica a pedir. Es decir, quiŽn usar‡ el m—dulo, componente, funcionalidad que se solicitar‡. El quŽ es la parte de la caracter’stica en s’. Es lo similar al requerimiento, lo que se espera que el sistema realice. La śltima pregunta Ŕpara quŽ? sirve para dar un mayor detalle a la solicitud y establecer las bases de lo que se espera que produzca el quŽ. Un cuento de usuario debe contener una descripci—n de quŽ es lo que se espera que el sistema (o m—dulo del sistema) entre como salida. Esto ser‡ la base para establecer los criterios de aceptaci—n del cuento y esclarece para todos los participantes la meta al construir ese cuento. Un cuento de usuario debe cumplir con ciertas caracter’sticas para cumplir con su funci—n. Un cuento debe ser independiente de los dem‡s cuentos en la medida de lo posible. Esto facilitar‡ el establecer prioridades y evitar‡ problemas de planeaci—n. Los cuentos deben representar algo de valor para el due–o del producto. Es por ese motivo que el responsable de escribir (en el sentido de dictar) los cuentos es el mismo due–o del producto. Los cuentos deben ser cuentos y no historias Žpicas, es decir, los cuentos deben ser cortos y no demasiado grandes. Una medida para conocer si el tama–o es demasiado grande es que el equipo de trabajo, los desarrolladores, son incapaces de estimar el esfuerzo requerido para su implementaci—n. Si esto sucede es cuento o historia Žpica debe desglosarse en cuentos m‡s peque–os. Finalmente un cuento debe ser algo que se puede probar una vez completado su trabajo de construcci—n. Si al definir un cuento, no se pueden establecer los criterios de aceptaci—n o los par‡metros con se probar‡ su funcionalidad o Žxito, entonces el cuento es demasiado vago, abstracto o todav’a no est‡ lo suficientemente claro en la mente del due–o del producto y por consecuencia del equipo de trabajo.

Cuando los cuentos se usuario han sido expuestos y documentados el due–o del producto establece las prioridades indicando que cuentos a su criterio ofrecen m‡s valor para Žl o el negocio que este representa.

 

2.     Planear el trabajo tomando un peque–o conjunto de requerimientos, pero los de m‡s alta prioridad

Con esta lista priorizada de cuentos de usuario, el equipo de trabajo est‡ listo para estimar identificar las tareas requeridas para implementar cada cuento y para estimar el esfuerzo requerido para implementar cada uno de las tareas. Se reśne el equipo de trabajo y usando alguna tŽcnica de estimaci—n y alguna mŽtrica acordada estiman esfuerzos para cada cuento. Una de las tŽcnicas de estimaci—n mejor adoptada por la comunidad de scrum y en general por la comunidad que sigue sus pr‡cticas con paradigmas de desarrollo ‡gil es  la estimaci—n de p—quer. En la estimaci—n de p—quer cada miembro del equipo tiene una baraja de cartas que tiene un nśmero que puede seguir una serie de Fibonacci o una serie exponencial (mŽtricas). Durante la sesi—n de estimaci—n el equipo escoge un cuento de usuario, lo analiza y cuando todas las dudas sobre el cuento y las tareas relacionadas est‡n aclaradas y el equipo est‡ listo para estimar. Al mismo tiempo cada uno de los miembros del equipo muestra una tarjeta con un nśmero que significa la complejidad de la tarea. Para obtener la complejidad final que tendr‡ la implementaci—n de esa tarea se obtiene el promedio de las votaciones de todos los miembros del equipo y ese es el valor que tendr‡ la tarea. Si hay votaciones con nśmeros muy disparados, se discuten las razones de esos resultados, se despejan dudas, se revisan premisas, etc., y se realiza un nuevo ejercicio de votaci—n. Esto se repite hasta que exista consenso y se concluye cuando todos los cuentos y las tareas han sido ponderados.

 

3.     Trabajar las tareas en un lapso de tiempo generalmente entre dos y cuatro semanas

 

 

4.     Durante el periodo de trabajo reunirse diariamente para verificar el progreso

5.     Finalmente se realiza una sesi—n de revisi—n del trabajo realizado y de la forma en que se realiz—. El nombre es una sesi—n de retrospectiva

Los roles de los miembros del equipo de Scrum son:

Aunque no a todos los practicantes o seguidores del desarrollo guiado por un paradigma ‡gil les agrada, scrum cuenta con una certificaci—n de scrum master avalada por el scrum Alliance (http://www.scrumalliance.org/)