Hasta ahora, y en diversas entradas de este apartado GENERAL de nuestro blog hemos dado unos consejos sobre la gestión de proyectos TI en nuestras empresas. La metodología que ha sido el hilo conductor a lo largo de todas esas entradas ha sido la Metodología Sure Step recomendada por Microsoft. Desde Gregal seguimos esta metodología por considerarla la más adecuada para la mayoría de proyectos en los que nos embarcamos, tanto a nivel interno (nuevos desarrollos) como proyectos en clientes (implantación de nuestros ERP’s). Las características de nuestros proyectos así nos lo aconsejan: necesidad de documentar el diseño, intentar evitar la dependencia de las personas, necesidad de reusabilidad…. No obstante siempre hay un porcentaje de proyectos que no se adaptan a esta metodología y merecen otro tratamiento. Muchos de ellos merecen estudiarse desde lo que se llama en terminología de proyectos métodos rápidos o ágiles de implantación.
Empecemos por aclarar el término de “método rápido/ágil”; en realidad, la mejor manera es poniéndolo en contraposición a los “métodos predictivos” como sería el caso de Sure Step y otros como PMBOK o PRINCE2. La característica principal de estos últimos es que se parte del detalle del producto que se quiere elaborar, a partir de ahí se definen fases que se planifican en el tiempo y a las que se les asignan los recursos oportunos; el objetivo, en este tipo de métodos, consiste en que se cumplan las previsiones de costes, calendario y calidad final. No obstante estos métodos se quedan atrás cuando en un desarrollo se pide rapidez, reducción de costes y al mismo tiempo se valora muy positivamente la agilidad y flexibilidad en la toma de decisiones, estas son las características que definen a las metodologías ágiles. Estas metodologías, aunque se les haya bautizado recientemente, seguro que forman parte del día a día de muchos desarrolladores puesto que es el método de trabajo seguido en desarrollos muy cortos en los que se tiene relación muy directa con el cliente (mejoras puntuales en funcionalidades…).
Metologías ágiles también hay muchas, pero por la facilidad de implantación y la agilidad en cuanto a los cambios vamos a utilizar como referencia a la metodología SCRUM, esta nos servirá para explicar mejor en qué consisten este tipo de métodos.
El método SCRUM:
- Evita la documentación excesiva y superficial.
- Permite empezar a trabajar inmediatamente, aún sin haber documentado; la finalidad es que se vean pronto los resultados.
- En SCRUM se diferencian los ACTORES y las ACCIONES:
- ACTORES: el PRODUCT OWNER (quien marca las prioridades del proyecto); el SCRUM MASTER (quien asegura el seguimiento de la metodología); el SCRUM TEAM (responsables de implementar la funcionalidad) y los USUARIOS o CLIENTES (destinatarios de los desarrollos).
- ACCIONES: las acciones en SCRUM se enmarcan en ciclos iterativos repetitivos. Las acciones fundamentales son: PRODUCT BACKLOG (la totalidad de las tareas a realizar) que sería responsabilidad del PRODUCT OWNER; SPRINT BACKLOG (son una o más tareas del Product Backlog que deben acometerse en pocos días); DAILY SCRUM MEETING (tarea iterativa de todos los días, se trata de una reunión operativa, informal y ágil).
- La forma de trabajar ya se deduce del detalle que figura en el punto anterior, simplificando, podemos decir que:
- El Product Owner define la lista de tareas a realizar.
- De esta lista se definen tareas concretas que se asignan al equipo.
- En las reuniones se informa de la situación de cada tarea, de las dificultades encontradas y la ayuda que se necesita.
- Cuando una tarea se finaliza se realiza una SPRINT REVIEW entre los diferentes ACTORES para analizar los avances realizados y entregarlos.
Como se indicaba anteriormente este tipo de metodologías son muy recomendables en determinado tipo de proyectos. Lógicamente no todas las metodologías sirven para el mismo tipo de proyectos TI, por lo tanto, no hay metodología mejor que otra ni válida al 100 % para todos los proyectos. La elección entre unos u otros dependerá de lo que se busque en cada proyecto en concreto.
Por último quiero resaltar una verdad que, si no fuera porque suena pretencioso, me atrevería a calificar de ABSOLUTA: SIEMPRE Y EN TODOS LOS CASOS, PARA QUE UN PROYECTO TI TENGA ÉXITO EL CLIENTE DEBE INVOLUCRARSE SÍ O SÍ.
