sábado, 24 de diciembre de 2011

Metodologías Ágiles: Adaptando Scrum

Una cosa que encontré curiosa en el desarrollo de mi PFC es que no quisimos seguir una metodología tan encorsetada y 'obsoleta' como es el caso de métrica V3, en este caso nos apeteció añadir un poco de variedad a la amplia gama de proyectos que hay presentados en esta metodología (y que por ende cuando revisas las documentaciones terminan siendo todos iguales), por ello mi co-director (@brenes) decidió que podría ser bueno una especie de 'revisión' de una metodología ágil como puede ser Scrum. Vamos a ver a grandes rasgos que es lo que hicimos:


Icebox


Para comenzar con el análisis, lo primero que hicimos fue realizar una "lista a los reyes magos", que no dejan de ser los requisitos que queremos que vaya a cumplir (por descabellados que sean) el proyecto que se va a desarrollar.

Esta lista se hace definiendo una serie de roles (actores) al estilo:


  • Usuario: Usuario de la aplicación.
  • Desarrollador: Programador que realizará el código de la aplicación.
  • Cliente: Aplicación que puede conectarse a mi proyecto.



Una vez tenemos los actores definidos, pasamos a realizar la lista de requisitos de esta forma:



  •  Como usuario, quiero poder subir mis propias producciones.
  • Como desarrollador, quiero que mi aplicación pueda repartir la carga de trabajo como si fuera una botnet.
  • Como cliente, me gustaría poder tener una API para extender funcionalidad.


Como he dicho, esto son unos ejemplos de cómo podría ser una lista de requisitos Icebox. También se puede enfocar como una tormenta de ideas en la cual se vayan añadiendo lo que se ocurra que puede encajar (más adelante se hará una criba). 

Lo ideal de los requisitos que aparezcan aquí es que se puedan realizar en un Sprint, de tal forma que si los hay que sean más duraderos, habrá que desmenuzarlos en requisitos más pequeños para que encajen.


Sprint


Un Sprint es un ciclo de trabajo incremental (una especie de desarrollo por hitos), de tal forma que siempre se tiene una versión funcional para el cliente en caso de que solicite verla. Aquí viene una de las modificaciones que adaptamos, normalmente un Sprint debe ser de corta duración pero como se está realizando el proyecto a la vez que se realiza el tercer curso de la carrera, no hay más remedio que alargarlo a casi un mes por Sprint.


Backlog


Una vez realizada la Icebox con nuestras más alocadas ideas, toca el turno de hacer una especie de lista definitiva de requisitos a implementar (que se puede ajustar después de cada Sprint), aquí lo que se hace es cribar la lista anterior (llegar a un acuerdo con el cliente) para ver qué requisitos finalmente se implementan y además, se les dará una puntuación de 1-10 entre los expertos de la materia (lenguaje) a cada uno para valorar qué debe entrar en cada Sprint. De esta forma, a lo mejor es viable incluir 2 o más requisitos en un Sprint, dejar uno sólo por ser excesivamente denso, aprovechar para redesmenuzar los requisitos, etc. 

Aquí viene otra de nuestras adaptaciones. Para valorar estos requisitos, hace falta ser un experto en la materia y poder ponderarlos en función del tiempo que va a llevar desarrollarlos (también sería idóneo que los desarrolladores fueran expertos) puesto que una mala planificación hace que el proyecto comience de forma mal y ya se sabe: lo que mal comienza, mal acaba.

Una vez hecho el Backlog, ya solo queda organizar los requisitos en Sprints y realizar reuniones por cada uno de los Sprints para ver cómo evoluciona el trabajo y poder mostrar ese desarrollo incremental.

Hasta aquí este post navideño que espero sirva también para el "DevTech Project".

No hay comentarios:

Publicar un comentario