Orientacion Hacia Los Proceso

Metodologías de Administración de Procesos Ágiles

• SCRUM

Scrum es una metodología de desarrollo ágil basado en procesos iterativos e incrementales. El desarrollo parte de una idea general de lo que se requiere construir, elaborando un listado de características ordenadas por prioridad (product backlog) que el propietario del producto desea obtener. El product backlog será un documento en constante actualización y al cual podrán acceder todos los interesados. A partir de aquí se efectuará una reunión para la planificación del primer sprint (la primera iteración), en la cual se generará una lista de tareas (sprint backlog) con asignaciones de personas y una estimación de tiempo y recursos. Adicionalmente se establecerá el objetivo del sprint (necesidad del negocio a cubrir).

Durante el sprint, se realizará una reunión diaria (15 minutos máximos) donde cada componente del equipo da respuesta a los siguientes aspectos:

 Trabajo realizado desde la reunión de seguimiento anterior.

 Trabajo a realizar hasta la próxima reunión.

 Limitaciones reales o potenciales que puedan impedir la ejecución del trabajo.

Al finalizar el sprint se realiza una revisión, donde se evalúa el mismo y se presentan los resultados obtenidos. De esta forma habrá concluido el primer sprint y se podrá dar lugar a una nueva iteración, volviendo a efectuar una reunión de planificación del nuevo sprint.

Responsabilidades

Tal y como hemos visto, aparte del equipo de trabajo, hay dos figuras bien diferenciadas:

Propietario del producto: representante del área de negocio (product manager o responsable de marketing para desarrollos internos) que tiene entre sus responsabilidades los siguientes objetivos:

 Obtener el máximo valor para usuarios y clientes.

 Financiación

 Decisión para efectuar el lanzamiento

Scrum Master: responsable de garantizar que se aplica correctamente la metodología.

Componentes básicos

Durante el desarrollo del proyecto se trabaja con tres elementos básicos:

Product backlog – proporciona los requisitos desde el punto de vista del negocio y cada uno de estos debe estar compuesto por:

 Identificador único de la funcionalidad

 Descripción

 Prioridad

 Estimación en tiempo

 Criterio de validación

Sprint backlog – determinas las tareas a realizar desde la perspectiva del desarrollo de software. En su elaboración debe participar todo el equipo y cubre todas las tareas necesarias (se recomienda actividades de tamaño entre 4 y 16 horas) para conseguir el objetivo del sprint. Todo el equipo debe tener acceso permanente a esta información vía digital (p.ej. hoja de cálculo, herramienta de gestión) o físicamente en el espacio de trabajo (p.ej. pizarra). El sprint backlog contiene por cada tarea:

 Identificador

 Descripción

 Responsable

 Estado

 Estimación del tiempo pendiente para su finalización

El incremento – parte del producto desarrollado en un sprint, el cual ya se encuentra preparado para ser entregado al cliente y por tanto, terminado y probado (no se trata de módulos no funcionales o similares). Cabe destacar que la primera iteración puede resultar difícil cumplir con la producción de un incremento entregable y por regla general, se suele ser considerar la única excepción.

Revisión del sprint

Reunión informativa que se efectúa una vez finalizado el sprint y a la que asiste el equipo de trabajo, el propietario del producto, el scrum master y todos aquellos interesados en el proyecto (p.ej. cliente).

El objetivo de la misma es presentar al cliente el incremento desarrollado (terminado, probado y operando en el entorno del cliente) y obtener feedback para mejorar e incorporar en sucesivos sprints.

La preparación de la reunión no debe llevar más de 1 hora al equipo de desarrollo (no se preparan presentaciones en PowerPoint o similares) y la reunión debe durar como máximo 4 horas:

 Se explica el objetivo del sprint finalizado y las tareas realizadas enfrente de las programadas.

 El equipo realiza una demostración.

 Preguntas y sugerencias.

Herramientas gráficas

Gráfico Burn-Up: utilizado por el propietario del producto para realizar la planificación y seguimiento de los diferentes Sprint:

Gráfico Burn-Down: utilizado por el equipo para mostrar el avance diario y detectar desviaciones.

Crystal Methodologies

Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equis.

• Dynamic Systems Development Method (DSDM)

Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción,

...