Ing.

Cristian Garca Estrella

En febrero de 2001, tras una reunin celebrada en UtahEEUU, nace el trmino gil Aplicado al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software.

Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente Alternativa a los procesos de desarrollo de software tradicionales.

Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. Desarrollar software que funciona ms que conseguir una buena documentacin. La colaboracin con el cliente ms que la negociacin de un contrato. Responder a los cambios ms que seguir estrictamente un plan.

La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin dentro de un equipo de desarrollo.

El software que funciona es la medida principal de progreso. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberan ser capaces de mantener una paz constante. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad. La simplicidad es esencial. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s mismos. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y segn esto ajusta su comportamiento.

Metodologas giles Basadas en heursticas provenientes de prcticas de produccin de cdigo. Especialmente preparados para cambios durante el proyecto. Impuestas internamente (por el equipo). Proceso menos controlado, con pocos principios. No existe contrato tradicional o al menos es bastante flexible. El cliente es parte del equipo de desarrollo. Grupos pequeos (<10 integrantes) y trabajando en el mismo sitio. Pocos artefactos. Pocos roles Menos nfasis en la arquitectura del software

Metodologas Tradicionales Basadas en normas provenientes de estndares seguidos por el entorno de desarrollo Cierta resistencia a los cambios. Impuestas externamente. Proceso mucho ms controlado, con numerosas polticas/normas. Existe un contrato prefijado. El cliente interacta con el equipo de desarrollo mediante reuniones Grupos grandes y posiblemente distribuidos. Ms artefactos. Ms roles La arquitectura del software es esencial y se expresa mediante modelos

Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestin de proyectos, que se ha utilizado con xito durante los ltimos 10 aos. Caractersticas: El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duracin de 30 das. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. Reuniones a lo largo proyecto, entre ellas destaca la reunin diaria de 15 minutos del equipo de desarrollo para coordinacin e integracin.

Individuos e interacciones sobre procesos y herramientas. Software funcionando sobre documentacin extensiva. Colaboracin con el cliente sobre negociacin contractual. Respuesta ante el cambio sobre seguir un plan

Aunque valoramos los elementos de la derecha, valoramos ms los de la izquierda.

Algunos productos se desarrollan a medida, comenzando por el diseo, y ejecutando despus un plan de ejecucin; otros sin embargo son el resultado en serie de cadenas o procesos de produccin. Con los servicios ocurre algo similar .

Hay que tener en cuenta que los proyectos:

Los realizan personas. Se ejecutan con recursos limitados. Se llevan a cabo siguiendo una estrategia de actuacin

Las operaciones se ejecutan de forma repetitiva para obtener resultados de caractersticas similares. Un proyecto produce un resultado nico y se desarrollan en un marco temporal pre-establecido .

Inicio y fin definidos

Obra nica Realizado por personas, recursos limitados, ejecucin controlada

Conjunto nico de actividades necesarias para producir un resultado previamente definido, en un rango de fechas determinado y con una asignacin especfica de recursos

Algunos ejemplos: Diseo de un nuevo ordenador porttil. Construccin de un edificio. Desarrollo de un sistema de software. Implantacin de una nueva lnea de producto en una empresa. Diseo de una campaa de marketing

En los aos 50, el desarrollo de grandes proyectos militares evidenci la necesidad de coordinacin entre los equipos y disciplinas diferentes que trabajaban de forma simultnea en la construccin del mismo sistema. Los proyectos grandes y complejos requeran el trabajo concurrente y sincronizado de mltiples ingenieras, e hicieron evidente, en los 60, la necesidad de elaborar modelos de organizacin y gestin para evitar los problemas que aparecan con recurrencia en todos los proyectos:

Incumplimiento de agendas. Desbordamiento de costes. Funcionalidad deficiente.

Los proyectos han existido siempre. Todo trabajo para producir un resultado nico es un proyecto; pero la gestin de proyectos es una disciplina relativamente reciente que comenz a forjarse en los aos sesenta.

Se considera que un proyecto se ha desarrollado con xito cuando se consigue la finalidad prevista, con el presupuesto y en las fechas que previamente se han estimado.

A tiempo

En Costes

xito

Lo previsto

Qu hacer?

Ejecucin y Control

Planificacin del Trabajo

La gestin de proyectos desarrollada a finales del siglo pasado se basa en la planificacin del trabajo, y en el posterior seguimiento y control de la ejecucin. Es una gestin predictiva, que pronostica, gracias al conocimiento detallado de lo que se va a hacer, y al plan del proyecto, las fechas, costes y recursos necesarios; as como la secuencia y coordinacin de las operaciones.

Su principal objetivo es conseguir que el desarrollo resulte segn lo previsto; y basa el xito del proyecto en los tres puntos sealados: agendas, costes y calidad.

Desde la perspectiva ortodoxa, un gestor de proyectos es un gestor formal, un planificador y controlador de las reas que intervienen en el desarrollo del proyecto.

Para PMI (por ejemplo) las reas de gestin que tiene a su cargo son (PMI, 2005):
Gestin de la integracin del proyecto. Gestin de costes. Gestin de la calidad. Gestin de tiempos y agendas. Gestin del alcance del proyecto. Gestin de la comunicacin en el proyecto. Gestin de los riesgos. Gestin de proveedores.

Las industrias militar y automovilstica fueron las primeras en adoptar las nuevas prcticas de gestin de proyectos, y por los buenos resultados que obtenan en la calidad y previsin de fechas y costes, su uso se ha ido extendiendo a prcticamente todos los sectores, y se ha ido formando un cuerpo de conocimiento comn y nico de gestin de proyectos.

La gestin de proyectos predictiva centra la atencin en la planificacin, ejecucin y control del trabajo. Diagramas de Gantt. Ruta crtica. Plan de comunicacin. Plan de riesgos. Plan de calidad. Plan de recursos. Matriz de responsabilidades. Actas de reuniones.

Pero esto son herramientas, y no el trabajo que deben realizar.

El trabajo del gestor de proyectos no es: hacer el Gantt, el presupuesto, el plan de comunicacin, el plan de riesgos, moderar las reuniones y redactar actas o registrar tiempos y gastos. Su misin es garantizar el seguimiento del plan previsto, y segn sea la organizacin de la empresa en la que trabaje tendr mayor o menor libertad para usar unas u otras herramientas.

El uso de las herramientas es el medio, no el fin. El trabajo del gestor de proyectos no es observar y cumplir los pasos establecidos para la gestin del proyecto. El trabajo consiste en la gestin del proyecto.

Considerar a los sub-productos del proyecto (requisitos, planificacin, informes, registros) como los deberes del colegio o los deberes del gestor, termina por darles el rango de su obligacin o, la obligacin de su trabajo; considerando por tanto que si hace la obligacin, hace su trabajo.

En la gestin de proyectos predictiva el gestor disea, traza el plan y es el responsable de su cumplimiento. Adems, a diferencia de la gestin gil, no tiene por qu ser un conocedor de la tecnologa empleada en el desarrollo.

La mezcla de estos factores tiende a dibujar puestos de controladores. No son miembros integrados del equipo con aportacin en las decisiones tcnicas; y por el sentimiento de propiedad del plan y la responsabilidad de su ejecucin es fcil que se limiten a adoptar posturas de control y orden jerrquico.

En proyectos de desarrollo de software, este modelo puede crear ambientes de trabajo inhibidores del talento personal.

La gestin que cae en el error de la cultura del cumplimiento, funciona como una fuente ms de propagacin en la organizacin, y la transmite al equipo. Las formas pasan a ser tambin ms importantes que los fines, y se da ms relevancia a las horas de dedicacin o al cumplimiento de las normas que a la eficiencia o calidad de los resultados.

Ing. Cristian Garca Estrella