• No se han encontrado resultados

El reto de los proyectos de software para la dirección de proyectos

N/A
N/A
Protected

Academic year: 2021

Share "El reto de los proyectos de software para la dirección de proyectos"

Copied!
6
0
0

Texto completo

(1)

El reto de los proyectos de software para la dirección de

proyectos

 

Los proyectos de desarrollo de software, presentan un desafío extraordinario para el enfoque tradicional de dirección de proyectos (PMBoK Guide). Primero, el software es intangible y difícil de explicar bien; raramente el mismo sistema es construido dos veces, lo que complica hacer una analogía con alguna funcionalidad existente. Esto puede llevar a "dificultades en la evaluación", dándose incompatibilidades en la interpretación de los objetivos y requisitos originales del cliente.

 

En segundo lugar, los proyectos de desarrollo de software son complejos y representan actividades de alto riesgo. A diferencia de muchos proyectos basados en construcción, desarrollar software en lenguajes que evolucionan rápidamente complica tener un proceso definido y repetible. El desarrollo del software es a menudo un proceso de investigación y desarrollo tecnológico sin precedentes.Tratar de crear planes con tareas detalladas para los desarrolladores de software es probable que nos lleve a desarrollar planes frágiles que pronto serán abandonados, o a los que se les tendrá que dedicar demasiado tiempo para

actualizarlos.

 

Un enfoque que ha surgido como una técnica para vencer las dificultades arriba mencionadas es el desarrollo iterativo, el cual agrega puntos de evaluación y revisión de productos tangibles (prototipos) a lo largo del proyecto; promueve la colaboración cercana entre los equipos de desarrollo y usuarios; y permite que  se hagan ajustes posteriores a los productos entregables, logrando que el sistema evolucione hacia los requisitos reales del negocio.

 

(2)

Cuando a los usuarios se les da la oportunidad de refinar sus requerimientos basándose en los prototipos proporcionados por el equipo de desarrollo, se logra reducir las diferencias entre lo originalmente establecido y las necesidades reales de la empresa, lo que se traduce en valor real para la organización.

 

El enfoque ágil permite que se hagan ciertos cambios aún en etapas avanzadas del proyecto, dándole una “variabilidadextrema”, es decir, permiten agregar al proyecto nuevos

requerimientos o que estos evolucionen, entregando así el máximo valor posible a la empresa, ya que se reconocen sus necesidades cambiantes.

 

¿Por qué los métodos ágiles funcionan en los proyectos de desarrollo de software?

 

1.- Reconocen que es importante hacer una validación de requerimientos  en el proyecto, desde el inicio y a lo largo de todo su ciclo de vida; apoyándose de un prototipo que va evolucionando.

2.- Emplean esquemas de priorización de requerimientos, que favorecen las modificaciones e intercambios contra los requerimientos originales, permitiendo la entrega de aplicaciones y sistemas que proporcionen ventajas competitivas al negocio.

3.- No intentan hacer una micro-gestión de los desarrolladores, a través de planes con tareas  específicas, en lugar de eso,  usa un enfoque orientado al logro del objetivo, utilizando las

(3)

habilidades del equipo para resolver las complicaciones que se presenten en el proyecto.

 

Procesos de ejecución y control

 

1.- Lista priorizada de requerimientos o características que serán construidas

El patrocinador o el usuario representante del proyecto prioriza todos los requerimientos del proyecto de acuerdo a su importancia o valor estratégico.

2.- Lista de requerimientos para construir el primer prototipo

 

A partir de esta lista inicial, se hace una segunda selección de requerimientos para ser desarrollados, tomando a los de mayor prioridad.

 

3.- Ciclo de desarrollo del prototipo

(4)

 

Los requerimientos y características elegidas pasan a través de un proceso de análisis, desarrollo, pruebas y evaluación durante un período de tiempo corto que comúnmente puede tomar de 2 a 4 semanas (es decir, pasan por una iteración).

En cada iteración, se van agregando más características y mayor funcionalidad al prototipo, desde su construcción inicial hasta que se tiene el producto entregable final.

 

4.- Ciclo de evaluación de riesgos y comunicación

 

Dentro de las 2 a 4 semanas que dura la iteración,  se realiza una breve reunión diaria en la que los integrantes del equipo se responden lo siguiente:

·       En qué han estado trabajando desde la reunión anterior

·       En qué estarán trabajando hoy

·       Si tienen algún problema, tema o impedimento para lograr avances

(5)

A través de esta breve reunión diaria, los involucrados del proyecto (stakeholders) conocen los avances, los miembros del equipo aprenden de en lo que los demás están trabajando. Incluso las  barreras y riesgos son rápidamente derrumbados y mitigados por el Director del Proyecto.   5.- Lecciones aprendidas  

Los métodos ágiles al igual que los tradicionales también realizan retrospectivas. En

proyectos que usan métodos ágiles, en cada iteración los integrantes del equipo se preguntan ¿"qué se hizo bien"?, ¿"qué no se hizo bien"?, y se hacen

"Recomendaciones para el futuro"  las cuales son tomadas en cuenta para la planeación de la siguiente iteración.

 

Mucha gente cree que estas técnicas parecen moderadamente útiles, pero no reemplazan los rigores del enfoque tradicional de gestión de proyectos. Sin embargo, la adopción del enfoque ágil en realidad representa elementos clave de un cambio a un conjunto actual de teorías de dirección.

 

En resumen, el enfoque de los métodos ágiles en proyectos de desarrollo de software es que el equipo se encarga de crear valor a la empresa a través de la transformación de los

(6)

requerimientos en un sistema funcional; y el rol del Director de Proyectos es asegurar la entrega de ese valor removiendo las barreras o impedimentos al equipo del proyecto.

Fuente: Project Management Institute

 

Espera nuestra tercera y última parte de esta entrega en Dirección Ágil de Proyectos...

 

Fuente: Project Management Institute

Publicado: 19 de Diciembre 2011

Regresar a nuestros Artículos de Interés

Referencias

Documento similar

Where possible, the EU IG and more specifically the data fields and associated business rules present in Chapter 2 –Data elements for the electronic submission of information

The 'On-boarding of users to Substance, Product, Organisation and Referentials (SPOR) data services' document must be considered the reference guidance, as this document includes the

In medicinal products containing more than one manufactured item (e.g., contraceptive having different strengths and fixed dose combination as part of the same medicinal

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in

This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)

Package Item (Container) Type : Vial (100000073563) Quantity Operator: equal to (100000000049) Package Item (Container) Quantity : 1 Material : Glass type I (200000003204)

b) El Tribunal Constitucional se encuadra dentro de una organiza- ción jurídico constitucional que asume la supremacía de los dere- chos fundamentales y que reconoce la separación