lunes, 9 de mayo de 2011

SCRUM: Metodología Ágil a utilizar

Analizando unas cuantas metodologías ágiles creo haber encontrado con la que mejor se adapta a todos los proyectos en los que he participado y en donde las metodologías ágiles de desarrollo han brillado por su ausencia. Desde mi punto de vista y basándome en más de 15 años como profesional en el desarrollo de aplicaciones tanto en entornos empresariales como gubernamentales, la calidad de los desarrollos ha tenido que ver mucho con las metodologías utilizadas que, sinceramente, no han sido muchas.

Es por esto que durante el desarrollo de esas aplicaciones, aparecen factores negativos como la desmotivación del equipo, la falta de liderazgo, la falta de una visión global de la aplicación, etc. Todo esto influye notablemente en la calidad y en la duración de estos proyectos. No es de extrañar que ciertos proyectos atractivos desde la misma concepción de la idea se hayan tenido que abandonar por falta de liderazgo en el grupo, o por cambios producidos en el grupo de desarrollo o lo que considero más grave todavía, por desidia de la misma dirección del Departamento, empresa o Servicio.

En esta ocasión presento la metodología Scrum, una estrategia de gestión donde se aplican de manera regular un conjunto de prácticas para mejorar el trabajo colaborativo y obtener el mejor resultado posible en la gestión de un proyecto software. Esta metodología permite la trazabilidad de los requerimientos que se establezcan pemitiendo identificar y registrar cada uno de ellos de forma que se pueda seguir su ciclo de vida tanto desde su origen hacia adelante como desde su entrega hacia atrás.

Scrum identifica 3 tipos de roles:

1. Product Owner: Propietario del producto
2. ScrumMaster: Responsable del correcto funcionamiento de Scrum en el proyecto
3. ScrumTeam: Equipo de desarrollo

Scrum divide el desarrollo global en una serie de hitos o Sprint que son reuniones en las que están presentes todos los roles establecidos y donde se acuerdan los requerimientos generales para esa parte del proyecto. De esta forma se puede modularizar el proyecto teniendo ya desde el primer Sprint una versión operativa del producto para que sea visualizado por el cliente. Este dato es muy importante si nos fijamos en el ROI (Retorno de inversión) que puede existir en un determinado desarrollo, pudiendo anticiparse al "time to market" del producto.

Sobre el intervalo entre cada Sprint algunos autores apuestan por los 60 días, en mi opinión esta frecuencia debe estar acorde con los objetivos que se marquen y aquí es donde el ScrumMaster debe hacer bien su trabajo, no hacer estimaciones vagas basadas en ningún dato objetivo, una posible solución durante los Sprint de un proyecto pueda ser la utilización de mecanismos para el cálculo de estimaciones como pueden ser los gráficos PERT para después, basándose en los datos obtenidos por los gráficos BurnDown hacer estimaciones basadas en el esfuerzo y logros del ScrumTeam, de este modo conseguimos un menor riesgo en la estimación de realización de tareas.

La siguiente presentación no tiene más de 30 diapositivas y creo que es muy interesante visualizar para adentrarse en esta metodología o estrategia de gestión de proyectos software.

Bye.

Introducción a la Metodología SCRUM

Share

Twitter Delicious Facebook Digg Stumbleupon Favorites