Este año lo empecé pasándome a utilizar otra metodología de desarrollo de software SCRUM, muy diferente a la pseudo-Cascada que utilizaba anteriormente. Pues bien se establecieron las reglas del juego y quiero compartirlas con ustedes.
¿Qué es SCRUM?
SCRUM es un metodología de desarrollo Ágil, la que consiste en que el cliente siempre va a poder ver parte del producto terminado y no debe de esperarse hasta el final, como en cascada. Esto nos da una serie de ventajas como lo son:
- Mejora la calidad del desarrollo y hace que el proceso siempre sea una mejora continua ya que se retroalimenta a sí misma.
- Los programadores se sienten más a gusto, pues ellos son los que eligen que hacer de las tareas del product backlog. Esto hace que el equipo sea cada vez más productivo
- Los clientes están contentos, pues cada vez que un sprint termina se les entrega una parte funcional del sistema, la cual puede si se quiere estar en producción. Siempre se hace una integración continua y el sistema crece con cada entregable
- A la hora de realizar cambios en lo solicitado por los usuarios se tiene más flexibilidad, permitiendo a los usuarios poder revisar detalladamente la aplicación mientras se continúa con el proceso.
¿Cómo se lleva el proceso a la práctica?
SCRUM no es una metodología sin metodología como dicen por ahí, es una metodología que permite ajustarse a las necesidades del proceso de los equipos, para que estos tengan una mejora continua y sean cada día más productivos.
Como trabajar con SCRUM
Lo primero que se hace es conocer las necesidades del usuario, esas historias que deben de terminar en un caso de uso donde se especifica como el usuario y el sistema interactúa. El caso de uso debe de ser lo más consistente posible ya que como un history debe de indicar las necesidades del cliente y como el sistema deberá de responder a estas. Hemos visto en nuestro proceso de día a día que los casos de uso son la mejor herramienta para hacer un análisis de que es lo que el usuario necesita y como los ingenieros que están a cargo de este proceso creen que el sistema debe de interactuar. Pero primero es escuchar las necesidades que el cliente priorice estas necesidades y según las prioridades empezar a obtener los casos de uso. Una vez que tenemos los casos de uso se deben de priorizar para saber que se debe de hacer en cada una de las iteraciones de desarrollo.
Una vez que tenemos los casos de uso priorizados, y tenemos las demás historias esperando por ser analizadas, el cliente determina que quiere que se desarrolle en cada iteración, el equipo define el tamaño de cada iteración por lo común son 4 semanas de desarrollo y 1 de pruebas, para continuar con otra iteración, se define cada cuanto se van a entregar el producto al cliente; puede ser cada 2 iteraciones o cada iteración y esto es entregado al finalizar la iteración. Una vez que se establecieron estas reglas simples inicia el primer sprint.
SPRINT o iteración
El equipo ya tiene priorizado por el cliente que desea que se desarrolle así que se determina el peso para cada una de las tareas que se van a desarrollar en el SPRINT, para esto se leen los casos de uso y el equipo debe de votar por un peso, puede usarse una serie para determinar el peso (0,1/2,1,3,5,8,13,20,?) En esta página pueden ver como se realiza el proceso (http://www.crisp.se/planningpoker) esta parte es muy divertida ya que todo el equipo interactúa. Pero hay un problema, cuando se inicia en la metodología porque como todo en esta metodología consiste en una mejora continua y aprender del proceso, por eso al inicio debemos de medir la velocidad del equipo y estar revisando si exactamente los pesos que establecimos al inicio se ajustan al final, para así poder en un futuro determinar fácilmente cual es el peso para una tarea y no estar como comúnmente decimos bateando.
Mi equipo estableció las reglas para el SPRINT y para poder ir determinando la velocidad del equipo y de cada uno de los integrantes. Estas son las reglas que determinamos:
2.La pizarra se divide en partes según se avanza en el SPRINT, esto es lo que se ajusta según las necesidades del equipo y acá como lo implementamos nosotros:
- Producto Backlog, todo lo que se desarrollara en el SPRINT
- Selected by Dev, cuanto un ingeniero selecciona una tarea a desarrollar le coloca su nombre a la ficha y se adueña de la tarea.
- TO DO, al ingeniero seleccionar una tarea y hace una serie de papelitos donde despedaza por así decirlo la tarea general en subtareas (Divide y vencerás) para cada una de las tareas estima el tiempo que durará realizando la tarea. Esto lo hace el ingeniero una vez que ha leído el caso de uso y entiende a que se refiere lo que debe de hacer.
- IN PROGRESS, cuando el ingeniero va a empezar a programar entonces el toma uno de los papelitos del TODO y lo pasa al IN PROGRESS al hacer esto coloca en el papelito a qué horas inicio la tarea y que día inicio la tarea, al final esta información nos servirá para determinar de cierta forma la velocidad del equipo y como poder estimar mejor las tareas.
- Test and DOC, Cuando el ingeniero termina una tarea en el IN PROGRESS, coloca en el papelito la hora en que termino la tarea y la fecha, así de una vez calcula cuanto duro en la construcción de esa tarea y coloca en el papelito el tiempo real que duro en terminar la tarea. Una vez que hace esto mueve dicho papelito a Test and DOC. Una vez que todos los papelitos del TODO están en test and DOC el ingeniero procede a realizar pruebas unitarias de lo que construyo, finalizadas las pruebas unitarias el ingeniero realiza la documentación necesaria para el usuario. El tiempo que dura realizando esta tarea queda implícito en las tareas del TODO pues cada uno de los papelitos debe determinar el tiempo que se dura probándose y documentándose.
- DONE, una vez que se tiene todo documentado y probado se pasa la ficha del Selected by Dev a Done, en la ficha se coloca el tiempo estimado, sumando el tiempo estimado de todos los papelitos del TODO y también se coloca el tiempo real, sumando el tiempo real de todos los papelitos que se crearon en el TODO .
- Una vez que el ingeniero termino con una tarea debe de volver al producto Backlog y seleccionar una nueva tarea. A esto se le conoce como una iteración dentro del SPRINT.
3. Al finalizar la programación cada uno de los miembros del equipo debe de seguir una guía para revisar punto a punto cada una de las tareas que realizo y hacer pruebas unitarias, finalizadas estas pruebas se inicia un nuevo proceso de pruebas donde en ingeniero X revisa las tareas realizadas por el ingeniero Y, una vez que se terminan las revisiones el ingeniero Y le entrega un documento de pruebas al ingeniero X para que este proceda con los cambios pertinentes.
4. El último paso es hacer un historial de los casos de uso resueltos, colocando el tiempo estimado y el tiempo real para cada una de las tareas, así como la cantidad de peso asignada a la ficha. Se debe de estimar un nuevo peso si es el caso para que en el futuro el ingeniero se refiera a estos casos para que sepa cuando dura resolviendo una tarea específica. Afinando cada vez este proceso se puede determinar con más facilidad la velocidad del equipo y la velocidad de cada uno de los ingenieros involucrados.
5. Realizados todos estos pasos, se debe de hacer la presentación del producto y entregar una versión para pruebas del usuario. El equipo hace una reunión de retrospectiva donde discute si debe de hacer cambios en el proceso de SCRUM o si debe dejar la metodología igual. Es discutir que les pareció el proceso a todos y que se debe de mejorar. Recordemos que la metodología busca tener siempre un equipo productivo y contento con su trabajo y su forma de trabajo.
Si quieres saber más sobre SCRUM te invito a buscar en la web información referente al tema, esta forma en cómo yo explique las reglas de mi equipo tal vez solo se puedan utilizar en mi equipo y en mi proyecto, pero con algunas variantes puede funcionar correctamente en tu equipo de trabajo. Te invito también a revisar el manifestó de Ágil (http://agilemanifesto.org/iso/es/principles.html) y si estas utilizando una metodología Ágil firma el manifestó (http://agilemanifesto.org/sign/display.cgi?ms=000000201)
