Agile Project Management

6 Oct

El AGP parte de la premisa de que los proyectos de software son impredecibles y que la incertidumbre del mercado nos conduce a tener que cambiar. Esta incertidumbre implica que los requerimientos necesitaran cambiar durante la vida del proyecto y cuando mayor es la incertidumbre, mas la organización tiene que preparase para adaptarse. Partiendo de este esquema, considerar el scope del proyecto meramente es un inadecuado punto de partida para comenzar a evaluar la performance de un proyecto.

Asi, los proyectos agiles consideran el tiempo y el costo como las restricciones primarias, las cuales son establecidas muchas veces antes que el scope. Mas que comenzar a planificar el desarrollo con una evaluación del alcance, los stakeholders de los proyectos miran el tiempo y el dinero que están gastando invirtiendo en entregar un producto al mercado.  Los requerimientos de proyectos agiles son escritos como “ladrillos” finos de un sistema competo y son contruidos en una forma tal que la mayoria de estos ladrillos son independientes entre si, lo cual les permite ser priorizados e implementados en cualquier orden.

Escribir los requerimientos en un forma minima e incremental es critico para variar el scope con un minimo impacto para el equipo. El equipo comienza a meditar que tan rápido ellos son capaces de completar trozos de funcionalidad y asi entender cuantos de los requerimientos pueden ser entregados dentro de las restricciones de tiempo y costo impuestas.

Agile Project Scheduling

Los project managers agiles se preocupan por dos indicadores primarios de performance en un proyecto agil:

  • El tamaño del backlog del proyecto
  • La velocidad.

El Product backlog es la lista de requerimientos de un proyecto agil. Representa una coleccion priorizada de features listas para ser construidas por el equipo. Los items del backlog se estiman en horas ideales, dias ideales o en unidades mas abstractas como los puntos de historia (story points).

La suma total de esas estimaciones es el tamaño total del backlog. La velocidad mide cuantos items del backlog el equipo es capaz de entregar en una iteracion dada. Esta velocidad representa el rendimiento del equipo o la tasa con la cual el backlog puede ser completado.

Intervalos para completar el proyecto = Tamaño del Backlog / Estimacion por intervalo

La velocidad ideal describe la tasa en la cual el equipo debe completar las features para entregar el proyecto dentro de las restriccioens de tiempo y costo definidas por los interesados del proyecto. La velocidad real es el rendimiento verdadero del equipo durante cada iteracion. La diferencia entre ambos es el principal indicador de que tan bien el proyecto está progresando en relacion a las expectativas de negocio.

Cuanto mas cerca se encuentre la velocidad real de la ideal, mas probabilidad que el backlog del proyecto se entegue dentro del tiempo permitido.
 
Los equipos con una velocidad relativamente razonable pueden calcular el tiempo que pueden completamente finalizar el backlog. Si el tiempo y el costo son restricciones fijas, ellos pueden determinar que funcionalidades pueden entregar dentro de dichas restricciones.

Los equipos con velocidades inestables no son predecibles y tipicamente generan resultados no esperados. Medir la velocidad en el tiempo permite al PM entender con que probabilidad pueden ocurrir los destinos de un proyecto.

Fuente: The Agile Project Manager – Mike Cottmeyer

Saludos Gastón

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: