sábado, 30 de septiembre de 2006

Cómo afrontar un proyecto en comunidad (II)

donde se tratan los peligros a afrontar en el inicio de un proyecto, entre los que se encuentran los riesgos asociados a no definir bien el ámbito de un proyecto, o bien a definir un objetivo inalcanzable.

En esta primera entrega de la serie de artículos sobre el desarrollo de proyectos en grupo por Internet voy a centrarme en los riesgos a los que hay que hay que hacer frente cuando se está comenzando un proyecto de estas características.

Primeramente situemonos en contexto: Es habitual que una o dos personas sean los que han tenido la idea original, que puede que no esté muy bien definida, además de que tal vez no tengan mucha experiencia como analistas. A ésto muchas veces se suele sumar el hecho de que piden muchos colaboradores para el arranque del proyecto, incluído el diseño inicial, y que todos quieran empezar a escribir el núcleo de la aplicación software a desarrollar en el más breve plazo de tiempo posible.

¿Qué origina esta situación? En primer lugar todos aportan su granito de arena al diseño que, por lo general, suele ser algo bueno, pero en estas situaciones tienden a ser verdaderas montañas. Es fácil que la idea inicial crezca hasta convertirse en un gran sistema inatacable por cualquier equipo de desarrollo de pequeño tamaño en límites de tiempo razonables. El ejemplo típico es el del equipo que pretende desarrollar un juego del estilo RPG y acaba evolucionando hasta un gran MMORPG. Ésto inevitablemente acabará dando lugar al abandono del proyecto por parte de la mayor parte de los colaboradores y, finalmente, por parte de los creadores iniciales.

La mejor manera de evitar ésto es definir un objetivo que sea realmente alcanzable. Hacer el ejercicio de detallar por escrito lo que se quiere hacer y la estimación del tiempo requerido para llevarlo a cabo, así como su complejidad y áreas de conocimiento implicadas ponderando de alguna manera los resultados es una buena manera de poder hacerse una idea, en el caso de que no se tenga la experiencia necesaria para intuirlo. A modo de ejemplo se podrían escribir las características del sistema implicado, y asociar un nivel de complejidad de 1 a 5, que se multiplicaría por el número de áreas de conocimineto necesarias para su desarrollo. Por ejemplo, en el caso de un pequeño juego:

  • Gráficos isométricos
    • Dificultad: 2
    • Conocimientos: Gráficos 2D, Optimización
  • Juego en red
    • Dificultad: 4
    • Conocimientos: Redes, Tiempo real
  • Efectos de sonido
    • Dificultad: 2
    • Conocimientos: Sonido
Ésto es sólo un pequeño ejemplo, que daría una complejidad de 14 según el método que improvisé anteriormente. Para profundizar más en el tema de la estimación del esfuerzo de desarrollo de un proyecto recomiendo consultar la técnica de los Puntos-Función y Cocomo II.

Una vez hayamos definido algo que se encuentre dentro de nuestras posibilidades, o no muy lejos de éllas, conviene organizar bien cómo se va a implementar el sistema que queremos desarrollar. Es fácil que todos los desarrolladores implicados comiencen a escribir código, y quieran innovar y destacar con grandes subsistemas muy complejos. ¿Alguien descubre la necesidad de leer un archivo varias veces? No dudará en desarrollar todo un recubrimiento al sistema de archivos que permita todo tipo de acciones, como proyección a memoria o cacheo basado en estadísticas de uso. ¿Es necesario que cierto objeto notifique en un par de ocasiones un evento? A la orden del día está el desarrollar un gran framework que automatice la gestión de eventos, su propagación a través de jerarquías o redes de objetos, validaciones condicionales en los nodos, etc. ¿Es criticable la creación de estos tipos de códigos? Claro que no, pero hay que estudiar su necesidad real. Si lo que queremos desarrollar es un Tetris en poco tiempo (en ratos libres, digamos un mes) desde luego éste no es el camino a seguir.

Está claro que esta situación dará lugar a un código enorme, de gran complejidad, difícil depuración, difícil integración (hay que tener en cuenta que los equipos estarán distribuídos y con poca comunicación) y que habrá de avanzar bastante para comenzar a ofrecer una funcionalidad mínima. Para evitar ésto se ha de realizar un diseño previo, aunque no en excesivo detalle. Descubrir qué subsistemas se requieren, refinando el modelo global, y describir por encima cómo se implementarán. Ésto ayudará a conocer de antemano la necesidad real de subsistemas complejos y el ámbito de cada uno, que permitirá decidir si se han de implementar más o menos funcionalidades en éstos.

Si al definir el objetivo inicial se definieron también objetivos futuros se pueden tener en cuenta en el diseño de los subsistemas, para que su futura implementación sea menos traumática para la base de código, pero hay que evitar a toda costa guiar el desarrolla con la premisa del "Por si acaso...". Por ejemplo...
Quiero hacer una aplicación que gestione los iconos no usados de mi escritorio Windows, pero por si acaso en el futuro Windows soporta múltiples escritorios o la porto a Linux voy a añadirle esta complejidad. Y qué decir si por casualidad quiero que algún día soporte gadgets y sea ampliable por plugins...

Está bien adelantarse a posibles condiciones del futuro o nuevos campos de desarrollo, pero hay que ser realistas: ¿De verdad algún día se hará? ¿No sería mejor hacer lo que se quería hacer y cerrar el proyecto pronto para poder empezar otro? Es muy común extender excesivamente la complejidad de la base de código de un proyecto sin ninguna razón, excepto la premisa del "Por si acaso". Lo mejor: no diseñar una pieza software excesivamente acoplada o específica, sobre todo si está a alto nivel, en previsión de futuras ampliaciones, pero manteniendo siempre un límite: no hay que tender a hacer el API global (public Object accion(Object args), o bien void *accion(void *args)).

En esta primera entrega he descrito un poco los problemas que se pueden encontrar en los arranques. Obviamente no todos los proyectos indie por internet han de acotarse bastante, siempre depende de la experiencia de los desarrolladores (véase como ejemplo Linux, KDE, o cualquiera de los grandes proyectos hospedados en SourceForge.net). Pero por regla general el perfil de los desarrolladores suele ser el que he descrito (estimo que para el 80% de los proyectos en sf.net).

En las próximas entregas trataré el tema de la organización del equipo, del seguimiento del proyecto y cómo poder convivir con la desaparición de los miembros de éste, de manera bastante relacionada a lo hoy expuesto (se verá la razón de ser de algunas de las afirmaciones aqui realizadas).

Un saludo.

No hay comentarios: