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.

martes, 12 de septiembre de 2006

Cómo afrontar un proyecto en comunidad (I)

donde se introduce el tema de cómo llevar un proyecto sin ánimo de lucro entre varios miembros dispersos por el globo a buen puerto.

Hace poco escribí una respuesta a una discusión en un foro en la que prevenía a un grupo de desarrolladores que estaban empezando a juntarse sobre los peligros que acechan a cualquier proyecto no profesional que se desarrolla en conjunto a través de internet. Planeaban la realización de un juego entre éllos y vi las similitudes con otros tantos proyectos que han empezado igual y cuyo destino ha sido el abandono.

Hice el ejercicio de pararme a pensar en todos los riesgos que tendrían que salvar y en cómo se podrían evitar, conociendolos de antemano. Está claro que sólo una parte de los problemas que pueden aparecer a lo largo de un proyecto son predecibles, pero no por éllo no se va a poder estar preparado en mayor o menor medida ante las eventualidades que seguro irán surgiendo.

A los problemas a los que podamos estar habituados hay que añadir problemas nuevos que surgen de las características especiales de este tipo de empresa: los miembros se encuentran dispersos a distancias muy dispares, en general bastante considerables, y ninguno de éllos va a cobrar por lo que haga, sino que se moverán únicamente por el interés que les suscite el desarrollo.

De esta forma he elaborado una pequeña lista de todos estos problemas, cómo prevenirlos, cómo detectarlos en caso de que hayan aparecido y cómo salvar la situación en caso de que estén ya minando la llegada a buen puerto del proyecto, todo en función de la experiencia que yo mismo he ido acumulando a lo largo del tiempo, bien en proyectos llevados a cabo en mis ratos libres junto a otras personas, bien mediante el seguimiento de proyectos en marcha llevados a cabo por otros, o bien extraídos de mi propia vida laboral (o dicho de otra manera, mis fuentes no son los libros, sino mis propias vivencias, por lo que lo que doy es mi visión subjetiva, no la de ningún autor).

En futuros posts iré detallando todos estos problemas con la esperanza de que puedan ayudar a más de un proyecto a llegar a buen término, y de que me sirvan a mi mismo de recordatorio para el futuro.

Un saludo.

sábado, 13 de mayo de 2006

Google Analytics

He decidido probar Google Analytics en el blog, sustituyendo a Webstats4u (antiguamente Nedstat). El cambio ha sido como la noche y el día.

Google Analytics ofrece una ingente cantidad de información y estadísticas sobre los visitantes del sitio, su procedencia, la tecnología que emplean, tendencias, etc., clasificado por perfiles (webmaster, marketing...) y áreas conceptuales.

Desde luego lo recomiendo, añadiendo que es completamente gratuito.

miércoles, 10 de mayo de 2006

Rubén laboral, de verdad

Bueno, por fin me puse a trabajar en serio. Desde mediados de Febrero ya dejé de ser becario y pasé a empleado de Amplía, empresa dedicada al mundo de la telemetría, telecontrol y M2M. Trabajo en el área de dispositivos móviles, donde desarrollamos el software para estos cacharros que comunique con nuestra plataforma de M2M. Me lo paso bien, la verdad: aplicaciones en tiempo real, comunicaciones, cada cacharro es un mundo nuevo, múltiples lenguajes... qué más puedo pedir :P

viernes, 14 de abril de 2006

Extraño problema en Netbeans 5

Quiero compartir un curioso problema que he tenido con Netbeans 5 sobre Windows XP, sobre todo por si a alguien le ocurriera lo mismo y así tal vez pueda encontrar aqui la solución.

Instalé Netbeans 5 para Windows para poder también probar y desarrollar en esta plataforma lo que desarrollo directamente sobre Linux. Cuál fue mi sorpresa al encontrarme con que al arrancar la aplicación y salir la ventana principal ésta aparecía vacía, sin ningún control gráfico, simplemente el fondo gris de cualquier ventana y la barra de título.

Probé a instalar todo tipo de versiones: el que viene incluido con el último JDK de la 1.5, suelto, usando la máquina virtual del J2EE 1.4 y nada. Ya empezaba a pensar que me debería limitar a usar Netbeans 5 sólo sobre Linux.

Tras una extensa búsqueda por los foros de Java hospedados por Sun, uniendo información de aqui y de allá, encontré lo que podría ser una solución: reducir en un grado la aceleración hardware en el cuadro de configuración avanzada de las propiedades de pantalla. Según la descripción que aparece ésto deshabilita la aceleración para el pintado de algunos cursores y bitmaps. Pues bien, el problema se solucionó. Netbeans apareció en todo su explendor.

No entiendo el porqué de ésto, pero supongo que será debido a alguna combinación no compatible de driver gráfico/máquina virtual. Al menos tiene solución sencilla, una vez que se ha conseguido dar con ella.

viernes, 6 de enero de 2006

Misterios de Google

Hace poco estuve depurando una aplicación relacionada con sockets utilizando Rational Purify (no sé qué costumbre tiene esta gente de dar a sus GUIs un aspecto tan de Win95). Me sorprendió encontrar en la pila de llamadas de mi aplicación que unas librerías de Google se habían introducido en lo más profundo, justo antes de la última llamada a Kernel32.dll.

Es normal que tenga instaladas librerías de Google, pues en la máquina conviven Google Desktop Search 2, Google Web Accelerator y Google Talk, pero no sé por qué motivo han de colocarse a esos niveles.

Como una imagen vale más que mil palabras aqui dejo la captura que saqué: