2/10/2011

Políticas para el desarrollo de software ágil

Una organización que requiera agilidad en la ejecución de sus proyectos de software necesita del establecimiento de políticas que garanticen entrega temprana y continua de artefactos y servicios de software de valor y utilidad.

A continuación describo un conjunto de políticas que he utilizado en consultorias, que permitirán a la organización alejarse del modelo de desarrollo de software tradicional donde se realizaba un levantamiento de información durante 3 meses, y luego 2 meses para el desarrollo. Este tipo de desarrollo no permitía la entrega temprana de valor y no consideraba las siguientes realidades:
  1. Es imposible reunir a todos los requisitos al principio de un proyecto.
  2. La actividad de análisis y diseño no garantiza que no habrá cambios.
  3. Siempre existirán desviaciones en tiempo y recursos.
Lineamientos Generales
  1. El proyecto deberá ser ejecutado en iteraciones incrementales con una demostración del producto al finalizar cada iteración: con esta política, se conocerá el estado del proyecto, evaluando si los requisitos cumplen con las expectativas del cliente, si la calidad es la esperada, o si hay retrasos; agilizando la toma de decisiones correctivas.
  2. El proyecto se ejecutará en iteraciones incrementales con una duración fija de 3 semanas.
  3. Los requisitos se desarrollarán priorizados por el valor aportado al cliente: Esta política permitirá que los objetivos más importantes del proyecto sean atendidos.
  4. El control y seguimiento del proyecto se basará en los requisitos completados en cada iteración. Se entiende como un requisito, los entregables asociados a: análisis, desarrollo, pruebas, documentación, etc. e integrados con los entregables de las iteraciones anteriores.
  5. Cada requisito debe ser independiente del resto de los requisitos, en la medida de lo posible.
  6. Cada requisito debe ser demostrable, permitiendo cómo comprobar con el cliente que el requisito está completado y que se cumplen sus expectativas.
  7. El requisito debe ser de un grado de esfuerzo para ser completado semejante al del resto de requisitos: de manera que la organización y el cliente, puedan realizar una extrapolación del progreso del proyecto.
Desarrollo
  1. Los componente de software, deberán ser desarrollados y liberados por partes, y no entregados al final del proyecto.
  2. El desarrollo de los componente de software que conformaran la solución, deberán ser liberados en varias iteraciones.
  3. Cada iteración deberá producir software con calidad de producción, probado, integrado, y documentado (funcional, técnica).
  4. Cada iteración deberá cumplir con un subconjunto de requerimientos.
  5. Cada iteración deberá contemplar (análisis, diseño, implementación, documentación, etc.).
Pruebas
  1. Cada proyecto debe incorporar las practicas de TDD (Test Driven Development).
  2. Cada uno de los entregables, deberá contener scripts de pruebas unitarias, integrales, funcionales, etc; mediante la utilización de frameworks como junit, dbunit, mockObjtects, etc.
Documentación
  1. La documentación del proyectos, específicamente:  manual de usuario, manual de operaciones, arquitectura de la solución, especificaciones, etc; deberán ser entregables parciales para cada una de las iteraciones, es decir, la documentación no se liberara al final del proyecto, sino en entregables parciales.
Control de Calidad
  1. Cada uno de los entregables, serán sometidos a un script de calidad, que ejecutara la organización,  y no serán admitidos como productos del proyecto hasta alcanzar un nivel aceptable.
Control de Riesgos
  1. Los riesgos serán identificados en la primera iteración, llevándose a cabo también una valoración inicial de la exposición al riesgo y planes de contingencia. En cada iteración se revisará y actualizará el documento “Lista de Riesgos”, añadiendo además la lista de riesgos más importantes actualizada por cada iteración.
Control de Artefactos
  1. Cada uno de los artefactos del proyecto, deberán ser mantenidos bajo un sistema de control de versiones.
  2. La organizacion disponibilizara un sistema de control de versiones, que deberá ser actualizado por el cliente de forma remota.
"Es increíble el cambio que puede producir en una organización la incorporación y aplicación de políticas de desarrollo de software ágil".

No hay comentarios.: