Compañías y Productos RAIS en el A2011 (conclusión)

Hace algún tiempo escribí sobre los productos que se iban a desarrollar en las asignaturas de Ingeniería de Software y Bases de Datos durante el semestre A2011 utilizando la estrategia RAIS. El A2011 terminó y los productos se desarrollaron (o casi). Me gustaría compartir los resultados, que en general, fueron bastante buenos.

MagicRoot

MagicRoot es un juego de cartas multi-jugador, y también, es el nombre de la compañía RAIS que lo desarrolló. El objetivo del juego es vencer al oponente utilizando cartas mágicas que representan los distintos elementos: Aire, Agua, Fuego y Tierra. La idea está basada en Triple Triad que es un mini-juego de Final Fantasy VIII (Espero que no nos demanden ;-).

El juego fue implementado en Java usando una arquitectura cliente-servidor. La interfaz de usuario está implementada en Swing. El servidor y el esquema de comunicación cliente-servidor implementan una arquitectura muy desacoplada y estructurada, que incluye el uso de varios patrones de diseño y que gestiona la lógica y los estados del juego utilizando una máquina de estados implementada de forma explícita. Sobre éste último punto tengo mucho que decir, e inclusive hay un trabajo de tesis en curso, pero eso es parte de otra historia. La capa de persistencia está implementada con Hibernate como ORM y MySQL como base de datos.

El código fuente de la aplicación se puede encontrar en:

http://code.google.com/p/magicroot

Sobre MagicRoot y su producto hay que decir dos cosas:

1.- La propuesta inicial del juego no me gustaba (debo admitirlo). Aquí, como Jefe Ejecutivo RAIS, es necesario tener fe en la gente con la que se trabaja. Lo que tenía en frente al principio del semestre eran cuatro “Ingenieros RAIS”, muy motivados con una idea clara entre manos. Esa motivación para mi fue suficiente para decidir que el producto era viable, aún cuando en lo personal no estaba completamente seguro.

2.- La propuesta inicial era técnicamente compleja. He desarrollado este tipo de aplicaciones, dado consultorías al respecto y conozco la complejidad del problema: Cliente gráfico, múltiples hilos del lado del cliente y del servidor, comunicación por sockets, protocolo de comunicación, lógica y reglas del juego complejas, máquinas de estado, Hibernate, etc. Esta complejidad añade algo de riesgo, y he visto más de un equipo de desarrollo empantanarse en tales condiciones. Esto me preocupaba mucho, tomando en cuenta que no conocía bien las capacidades técnicas o la madurez del grupo de programadores que tenía en frente.

A algunos desarrolladores de software experimentados el proyecto quizá les pueda parecer algo trivial, pero tomen en cuenta que el trabajo se debe hacer en 4 meses (o menos) a tiempo parcial y que estamos hablando de estudiantes del 7mo semestre que nunca han programado en Java y mucho menos conocen muchas de las tecnologías utilizadas.

Desde el punto de vista de RAIS, en el caso de los cursos de IS y BD, una estrategia que ha funcionado para manejar la complejidad de un producto es que al inicio del curso todos los integrantes de una compañía conozcan el nivel de dificultad y los riesgos presentes en el producto al que se enfrentan.

Me tomo muy en serio esto, explico los riesgos, el volumen de trabajo, los retos y capacidades técnicas necesarias, y me aseguro de que todos los integrantes de la compañía sepan en qué problema se están metiendo. Si hay algún aspecto del producto que desconozco (cosa que sucede con cierta frecuencia) lo digo directamente y sin rodeos, es decir, puedo estimar, hacer comentarios, tratar de adivinar, aconsejar, etcétera, pero soy muy claro de que se trata de un riesgo y no doy falsa confianza sobre algo que en el fondo no conozco y se sale de mi control.

Luego dejo que tomen la decisión por ellos mismos, y si desean cambiar de producto, no hay problema. Esto último también se deja bien claro, y es parte de mi visión particular con RAIS, yo como Jefe Ejecutivo puedo aconsejar y ayudar, pero las decisiones finalmente las toman las compañías de forma voluntaria.

Afortunadamente, los ingenieros de MagicRoot decidieron seguir adelante con el producto, aún después de conocer la complejidad y las dificultades a las que se enfrentaban. Debo decir que esa fue una verdadera demostración de coraje que siempre admiraré.

El resultado no sólo cumplió con las expectativas que tenía, sino que las superó. En verdad MagicRoot fue un producto espectacular, con una arquitectura muy sólida, muy fácil de mantener y manejar, que les permitía arreglar bugs y hacer cambios y ajustes en las reglas del juego muy fácilmente.

Como nota curiosa, los integrantes de MagicRoot cursaron Inteligencia Artificial el semestre siguiente e implementaron la inteligencia del juego, es decir, hicieron que fuese posible también jugar contra la computadora y no sólo contra la otra persona.

El equipo de MagicRoot está compuesto por:

Rafael Solórzano (Gerente), César Vielma, Andres Zamora y Jesus Daniel Garcia.

Mentes en Guerra

Mentes en Guerra, desarrollado por CodeSolids, es un juego de batalla multi-jugador en el que los jugadores pueden crear personajes, combatir con otros personajes de otros jugadores, ganar puntos, aumentar de nivel y comprar equipamiento para mejorar a su personaje.

El juego es una aplicación WEB desarrollada en Java, utilizando Echo3 para la interfaz de usuario, Hibernate como ORM y MySQL como base de datos.

Esta compañía llevó el uso de Echo3 al extremo, y hay cosas que, desde el punto de vista visual si bien imagino como están hechas, en el fondo no tengo una idea clara de como las implementaron. En especial resulta interesante ver la parte de la batalla, en la que los personajes efectivamente tienen animaciones, se mueven y atacan a los otros personajes.

El código fuente de la aplicación se puede encontrar en:

http://code.google.com/p/codesolids-project

Es interesante mencionar que Mentes en Guerra fue uno de los últimos productos que se desarrollaron bajo el concepto de aplicación WEB implementada con Echo3, ya que, pareciera que después de MagicRoot, todas las compañías de los cursos siguientes han querido desarrollar únicamente aplicaciones en Swing.

En general, CodeSolids fue un grupo bueno, la compañía no tuvo ningún problema serio a lo largo del semestre y avanzó bastante bien. Quizá cerca del final sentí cierta preocupación y cierto retraso en el desarrollo del producto, pero finalmente todo salió bien, entregaron un buen producto, que funciona y satisface (mucho) las expectativas.

El equipo de CodeSolids está compuesto por:

José Luis Pérez (Gerente), Antonio Lopez, Karla Moreno, Fernando Osuna y Hector Prada.

Greed Treasure

No todo salió completamente bien en el A2011, de las tres compañías, una de ellas, Thinking & Looking, fracasó rotunda y estrepitosamente.

El fracaso de Thinking & Looking fue doloroso. ¿La razón? El producto que decidieron desarrollar me importaba mucho, era una idea original que realmente quería ver funcionando, al menos a nivel de prototipo o prueba de concepto.

¿Por qué fracasó la compañía? Tengo una teoría (bueno, quizá varias teorías a decir verdad), pero aún así es difícil estar completamente seguro. En mi opinión los factores más importantes fueron:

1.- Falta de liderazgo: El fracaso está asegurado sin un liderazgo fuerte, que logre darle coherencia y sentido a la compañía (y al producto), y sobre todo, que logre dar buenos ejemplos de trabajo al resto del grupo. En este caso, en mi opinión, el gerente no supo aprovechar el equipo de trabajo del cual formaba parte, no supo motivar al equipo y lograr que trabajaran de forma conjunta.

2.- Falta de compromiso de los ingenieros con la compañía y el producto: Esta es la otra cara de la moneda del punto anterior. Creo que hubo mucha, pero muchísima, falta de compromiso. Un buen liderazgo debería crear ese compromiso, pero no toda la responsabilidad debe pesar sobre el gerente de la compañía.

Si el gerente no puede sacar a flote a su grupo, alguien dentro de la compañía debería asumir esa responsabilidad y lograr que el equipo salga adelante, esto ha ocurrido en otros casos y en otras compañías. Sin embargo esto no sucedió en Thinking & Looking. Todos los ingenieros simplemente se limitaron a hacer lo mínimo que se les pedía y no pudieron salir adelante, no hubo un liderazgo emergente, y de hecho, fue bastante triste verlos al final del semestre buscando la forma de culparse mutuamente.

3.- Problemas de comunicación, coordinación, colaboración y trabajo en equipo: Thinking & Looking tenían el balance adecuado de destrezas y capacidades técnicas, pero en mi opinión simplemente no supieron aprovechar esta fortaleza. Es decir, reunieron un conjunto interesante de talentos individuales, pero nunca lograr en verdad “formar” una compañía. El punto anterior también forma parte de esto último.

4.- No se puede culpar del fracaso al producto: El producto tenía requisitos muy claros y bien definidos, no era excesivamente complejo y no tenía riesgos técnicos serios. El riesgo técnico más fuerte, que era dibujar e interactuar con un mapa estaba ya controlado, a nivel de prototipo y de trabajos hechos en el semestre anterior.

No voy a mencionar los nombres de los integrantes de Thinking & Looking, en mi opinión ya bastante problemas tuvieron tratando de sobrevivir al A2011, de modo que les voy a dejar en el anonimato.

De los tres productos del A2011, dos fueron en mi opinión un éxito rotundo. Aún con el doloroso fracaso de Thinking & Looking creo que fue un buen semestre en el que se obtuvieron excelentes resultados. Inclusive puedo decir que aprendí mucho del fracaso de Thinking & Looking, y que espero ahora poder detectar e intervenir esas “compañías patológicas” con el tiempo suficiente como para poder resolver el problema, e inclusive, desarrollar políticas de organización de compañías que eviten que este tipo de desastres vuelvan a ocurrir.

¡Hasta la próxima experiencia RAIS! :-)