Dec 02 2008

Problemas en gestión de proyectos de software

Published by Rudy Godoy at 10:33 am under Computer Science, Free Software

Hace algunas horas Cristian comentaba acerca del post sobre las lecciones que se pueden tomar del software libre para la gestión de proyectos. Aquí su comentario:

Que tal Rudy te saluda Cristian Villalta acabo de leer el articulo y me parece de mucha utilidad pues justo ando trabajando en una tesis relacionada a la gestion de proyectos y software libre. Queria hacerte un par de preguntas:
Que problemas son los mas comunes, desde tu punto de vista, en la gestion de proyectos … y … cual es el impacto del Sw libre en la gestion de proyectos, desde ya agradecido.

Saludos.

Originally posted as a comment by Criso on a subversive act of playful cleverness using Disqus.

Los problemas que he observado en los proyectos de software tienen que ver generalmente con respecto a la gestión de equipo y recursos. Por otro lado, uno de los temas que presenta muchas situaciones complicadas es la definición del ámbito del proyecto y los requisitos del mismo. De hecho, hoy, existe una rama de software que se dedica específicamente a la ingeniería de requisitos.

Para el primer caso, el software libre tiene la ventaja de que los integrantes del equipo o proyecto trabajan en aspectos que son de su interés, de esta manera el proyecto en global se beneficia teniendo mejores resultados, personas comprometidas y apasionadas con su trabajo. Sin embargo, esto presenta el problema de que, generalmente, se pierde un poco el sentido de visualización integral del proyecto, cosa que se suele mejorar con la incorporación de roles de coordinación, por ejm. lo que hace Linus Torvalds o Andrew Morton en el kernel linux.

Además, gracias a las herramientas que ha adoptado la comunidad de software libre para soportar su desarrollo, los procesos generalmente tiene un soporte adecuado por lo que se hacen, hasta cierto punto, eficientes. A medida de que una organización tenga sus procesos mejor estructurados y estandarizados podrá obtener mejor provecho de las herramientas que tiene disponibles, y no al contrario. Esto último es algo que observo en muchas organizaciones, generalmente adquieren software que puede ofrecerles infinidad de posibilidades, razón por la cual otras empresas lo emplean, sin embargo al no tener la base definida es poco el provecho que obtienen pues no se busca optimizar el proceso a través del empleo herramientas.

Respecto al tema de definición de requisitos y ámbito del proyecto, podemos tomar, del software libre, como aspecto relevante la constante interacción con el usuario final a través de sus procesos de retroalimentación y la publicación de versiones en etapa temprana (beta). Esto permite que el desarrollo se realice a medida que se encuentre una necesidad del usuario. Sea un informe de fallo, solicitud de características nuevas, modificación de funcionalidad, etc. estas incidencias son las que usualmente activan los esfuerzos de desarrollo y mantienen una línea de vida constante en el proyecto de software. Si se pierde el interés en el software o no se obtiene esta retroalimentación, usualmente el desarrollo se estanca y suele quedar abandonado.

Comments

  • Hola Rudy
    El articulo esta muy interesante, y creo que la experiencia de Edgar es muy valiosa, al respecto, cuando hablamos de proyectos de software, tal vez no habria mucha diferecia entre software propietario y software libre, ambos terminan siendo productos terminables, personalmente no veo la diferencia.
    Amtes de entrar mas en detalle, tal vez haria una diferencia si me refiero a trabajar usando herramientas libres o si el producto es software libre, ya que podemos desarrollar software propietario con herramientas libres y software libre con herramientas propietarias.
    Sin embargo, centrandome en la gestion del proyecto, yo tomaria como factor de desicion sobre que herramientas usar, a la forma en como se encuentran distribuidos los miembros del equipo de desarrollo., puesto que no seran las mismas harramientas que se utilizen para la gestion.
    Personalmente yo apuesto por el mismo framework que usas, SCRUM, y como herramientas de gestion uso papelotes y plumones, por una sencilla razon, evitar la flojera de pasar todo a una herramienta computacional, ademas lo tenemos todo el dia al frente de nosotros y siempre esta al alcance de las manos, insisteiendo en la distribuición del equipo, no podria hacer esto con un equipo distribuido.
    Por que SCRUM, una metodologia, o mejor dicho, un framework agil adaptable a XP, por que me permite cierta flexibilidad, y mas importante que la flexibilidad, el hecho de tener extregables funcionales cortos, permite mostrar al cliente que si se esta avanzando, ya que el cliente siempre quiere ver algo y ya, sabiendo ademas, que mas de una vez se ha comentado, que los clientes no saben realmente lo que quieren hasta que lo pueden mirar, para luego desechar :D, entonces si este trabajo es corto, es facil retocarlo y readaptarlo, algo que no podria permitirse facilmente en una metodologia predictiva, que al ser un proceso tan largo, como dices , se pierde el interes y puede quedar abandonado, o si no es del parecer del cliente, lo usa por el dolor de pagarlo, pero no siempre queda totalmente satisfecho, si es que antes no espero a que se retire el equipo, para despues desecharlo, vi alguna vez hacer eso.
  • Realmente muy buenos aportes, que hay acerca de la documentación? como es que los metodos agiles o SCRUM en este caso ayuda a esta parte importante en la gestion de proyectos?.

    Por otro lado, leia unos articulos en los que algunos de los principales problemas al desarrollar proyectos de Software Libre y Open Source eran entre otros:

    - Procesos sin documentar.
    - Codigo modificado por distintos voluntarios y que en muchos casos quedan inconclusos.
    - Que los usuarios finales no saben como reportar errores o fallas del producto final.

    Que hay de cierto en estas afirmaciones?

    Nuevamente gracias por responder.
  • Vaya que interesante! un post de gestión de proyectos :D !!!

    Te comento que yo veo gestión de proyectos en una empresa que desarrolla con software libre y pienso que antes de incursionar en algún proyecto de desarrollo de software se debe de tener previamente definidos procesos establecidos, estandares y metodologías entendidas por el equipo de desarrolladores conjuntamente con el área de gestión del proyecto. Esto es vital para que el proyecto avance de una manera ordenada el primero saber como es que se debe de trabajar.

    Además, es cierto que una solución debe de ser a la medida y esta debe de acomodarse a la necesidad del cliente y no al reves. Desarrollar en software libre se ajusta perfectamente a este escenario.

    Sin embargo, mi opinión personal con respecto a la definición de requisitos es que ya sea en proyecto de software libre o cualquier otro tipo de proyecto, los problemas justamente se originan en la excesiva flexibilidad de algunas empresas desarrolladoras al momento de ofrecer al cliente soluciones que se van tranformado con el tiempo haciendo que estos proyectos no sean eficientemente controlados, ya que no se llega a determinar el alcance del mismo y por lo tanto afecta en los tiempos de entrega, calidad, costo, etc.

    No niego el dinamismo que se siente al hacer versiones tempranas de las soluciones por parte de los programadores pero pienso que esa filosofía de "voy desarrollando y va quedando como quiere el cliente ya que somos recontra flexibles", no es la mejor ya que, de acuerdo a mi experiencia, genera mas problemas que soluciones (refactoring, retrasos, perdida de persepción del alcance, etc, etc.)

    Con respecto a la consulta de Criso sobre la estimación de tiempos de un proyecto, podría comentar que el grado alto de flexibilidad dificulta terriblemente una estimación confiable, ya que el cliente puede cambiar tantas cosas que tu proyecto puede crecer y crecer. En todo caso lo que se hace es controlar componentes más pequeños del proyecto, planificar el trabajo sobre estos, el tiempo y los recursos que intervendran y posteriormente a este componente, los que sigan.
  • Gracias por tu aporte Edgar.

    El tema la definición de alcance del proyecto es muy importante para su buena y eficaz conclusión. En este sentido, las metodologías y frameworks de desarrollo son herramientas que nos permiten soportar y estructurar el proyecto de una manera concisa. Aquí, es importante aplicarlas y usarlas de forma adecuada. Sea como empresa de consultoría o desarrollo interno los objetivos del proyecto se deben definir desde el inicio, esto no implica, necesariamente, que no sea extensible. sino que delimita un rango de cosas que abarca.

    Por otro lado, los proyectos de desarrollo a medida no necesariamente cumplen con un balance adecuado de oferta vs. demanda y beneficios para proveedor y cliente, algo que generalmente se pasa por alto. El desarrollo a medida tiene un costo bastante alto, contemplando tiempo y dinero, para una empresa como para un proveedor. En primer lugar, a la empresa le interesa que el proyecto se ponga en operación en el menor tiempo posible, para que esto beneficie a sus operaciones y por ende a reducir sus costos operativos. En segundo lugar, a la empresa que ofrece el servicio le interesa que el proyecto cumpla con lo requerido por el cliente y se obtenga utilidad. Obtener resultados beneficiosos para ambos es el reto a enfrentar, y para ello se debe hacer uso de las herramientas idóneas.

    En mi opinión, para proyectos de desarollo a medida creo que es más eficiente un desarrollo incremental que entregue beneficios tangibles al cliente en corto plazo. Frameworks como SCRUM trabajan bajo este enfoque, descartando funcionalidad que no ofrece beneficios concretos y realizando entregables concretos en tiempos eficientes. En este caso, el proveedor cotiza sobre entregables y el ámbito del proyecto se define bajo ese marco. Esto permite tener un balance adecuado de beneficios para el cliente y el proveedor. En HTU trabajamos de esa forma.
  • Gracias por la respuesta.
    Bien, coincido con tus ideas y a eso agregarle otro problema como estimacion de tiempo para cumplir el proyecto verdad? ... como asegurarnos que el tiempo estimado para cumplir las fases de un proyecto es el correcto? tendrá que ver el uso de metodologías ágiles o clásicas?.
    Sin duda estos 2 post me han servido de mucho, nuevamente gracias.
blog comments powered by Disqus