La razón por la que surgen los proyectos, viene dada por la necesidad o problemática de una persona u organización. En ciertos casos, la solución tiene un enfoque sencillo y claro, pero en otras requiere de aportación valor diferencial e I+D.

Es en estos casos, es donde tienen una mayor aceptación los nuevos modelos ágiles, tanto aplicables en todo el ámbito del proyecto, como los especializados en la dirección de los mismos.

Estos modelos se basan en los cuatro pilares del manifiesto ágil, donde se valoran:

1. A los individuos y su interacción por encima de los procesos y las herramientas
2. El software que funciona, por encima de la documentación exhaustiva.
3. La colaboración con el cliente, por encima de la negociación contractual.
4. La respuesta al cambio, por encima del seguimiento de un plan.

Como podemos observar, existen ciertas divergencias en comparación con los modelos clásicos o dirigidos, pero debemos tener en cuenta, al igual que con el resto de metodologías y modelos, que para resolver un mismo problema tenemos que tener en cuenta los siguientes factores:

1. Capacitación y capacidad del equipo, ya que son las personas las que idean y crean cada elemento, creando un entorno de gestión del conocimiento compartido, coherente, directo y no sobrecargado.
2. Disponer de forma temprana de parte del producto final. Esto permitirá recibir feed-back por parte del cliente, y recabar nuevas necesidades, además de disponer de un entorno de pruebas mucho más potente e integral.
3. El proveedor de soluciones IT debe ser más un aliado tecnológico que hace las veces de consultor, que un mero suministrador de tecnología.
4. Si el entorno en el que se mueve el cliente cambia, su necesidad o problemática mutará, por lo tanto debemos disponer de los medios que nos permitan adaptarnos a dichos cambios lo antes posible.

En este punto podréis pensar que soy un gran soñador, y que no he tenido en cuenta grandes problemas organizativos, pero antes de plantearnos siquiera el trabajar con metodologías ágiles, debemos de cumplir ciertos prerrequisitos y tener claras ciertas cuestiones:

• El equipo debe de estar formado por un conjunto de personas que muestren una actitud colaborativa y dispongan de aptitudes y conocimientos destacables en diferentes áreas de conocimiento, ya que si no es así, ¿que innovación y contribución diferencial existirá?
• El no disponer de documentación exhaustiva no quiere decir que no haya documentación. Debemos saber qué es crítico en el ciclo de vida del producto y dónde se encuentra su complejidad.
• La comunicación interpersonal es la base de la gestión del cambio continuo. Esto puede parecer que choca con las políticas de calidad de las organizaciones, pero no es así, ya que como hemos indicado en el punto anterior, debemos tener muy claro, qué debe quedar por escrito.
• Para conocer el nivel de cumplimiento de un contrato, necesitamos conocer  alcance, plazo y coste, ¿pero qué pasaría si no conocemos el primero de los factores? ¿No podríamos crear un contrato marco y para cada uno de los entregables realizar un anexo?

Una persona encargada de la venta o de gestionar un presupuesto, puede resaltar de la dificultad de gestionar la ocupación y rentabilidad de un departamento, y la complejidad añadida de tener que negociar de forma continuada. Este enfoque nos obliga a trabajar estrechamente y colaborar con el cliente, centrarnos en sus necesidades y hacer un trabajo de alto valor añadido en cada entrega.

Al igual que existen muchas metodologías tradicionales, atendiendo a la importancia y relevancia sobre la que se quiere hacer énfasis, existen muchas otras denominadas ágiles, como son:

• Agile Database Techniques
• Agile Modeling
• Agile Unified Process
• Crystal
• Feature Driven Development
• Dynamic Systems Development Method
• Lean Software Development
• Scrum
• Test-Driven Design
• XBreed
• eXtreme Programming

Muchas de ellas tratan tanto el ciclo de vida de desarrollo de software como el de gestión, mientras que algunas de ellas se centran única y exclusivamente en el modelo de gestión. Dada la extensión del análisis de las mismas, podrá ser objeto de otra futura aportación a este blog.

Aun así, me gustaría comentar algunas de las características de una de ellas, SCRUM. Es un término acuñado del rubgy, y haciendo una semejanza, describe cómo:

• El equipo debe organizarse haciendo una piña, y donde cada persona aporta tanto individualmente como colectivamente.
• El objetivo de cada iteración es la aportación de valor, es decir, conseguir un ensayo.
• El objetivo es ganar el partido y que el cliente (interno y externo) esté satisfecho del resultado final.

Personalmente, esto me lleva a un dilema, si el objetivo de todo proyecto de desarrollo de software, es crear el producto necesario con el nivel de calidad requerido, y debe estar disponible con la premura que requiere el negocio al que dará soporte, el fin justifica los medios ¿no?

Alberto Salgado

Consultor IT, Consultoría y Formación

Tags: Modelos Ágiles, Proyectos, SCRUM

Esta entrada fue publicada el 14 de Octubre de 2008 a las 14:18 y está clasificada bajo: Dirección de proyectos. Puede hacer un seguimiento de los comentarios de esta entrada gracias al feed RSS 2.0. Puede dejar un comentario, o enviar un trackback desde su sitio.