En cuanto a trac está muy bien, es simple de usar, no parece difícil de tunear (aún no me he metido, pero he estado echando un vistazo al código). El wiki es muy útil sobretodo para pequeños report de cara a QA o para documentación. Soy partidario de tener la menos documentación posible (pero nunca insuficiente claro) y que el proceso de documentar sea lo menos tedioso y en eso el wiki va muy bien, con un click ya estás escribiendo y enlazando con facilidad.

Para trac hay varios módulos para scrumm, nosotros usamos uno y aunque no añade demasiadas cosas, va muy bien: saca los progresos en gráficas (el típico gráfico descendente de scrum), las horas que faltan, etc, etc. Es mucho mejor tener integrado todo lo necesario para scrum en el propio tracker para poder ir enlazando tareas del backlog con items del tracker.

En cuanto a lo de las ramas nos hemos encontrado con el mismo problema que tú, la dificultad de integrar unas ramas en otras. Actualmente el modelo que usamos es el siguiente: una rama por cada versión estable, en ella solo corregimos bugs que son mezclados a trunk mediante changesets. Por otro lado tenemos trunk en donde vamos a implementando nuevas features, algunas de ellas las implementamos en ramas si vemos que va a necesitar un proceso aparte para QA o si va a desestabilizar demasiado trunk. De esa forma siempre tenemos listas las versiones estables y las versión con nuevas features.

Nuestro mayor problema ahora es que subversion no tienen tracking de ramas y no tenemos un histórico de lo que vamos haciendo en el propio subversion, tenemos que hacerlo “a mano”. También probamos otros gestores de código como plastic, pero nos quedamos con SVN.

En a lo de TDD, sí, tratamos de usarlo, aunque muchas veces el tiempo apremia y te saltas un poco la filosofía. Aparte no es nada fácil saber hacer bien los test. En cualquier caso en mi opinión tener pruebas unitarias que mínimo te prueben el core y las funcionalidades más importantes es vital para saber si no has cascado algo en cada commit.

En cuanto a las pruebas gráficas no hemos hecho nada, plantemaos la posibilidad de hacer test unitarios para comprobar que las implementaciones de cada motor funcionan bien en los dispositivos. Programar para móvil es tedioso porque no sabes nisiquier si las funciones para pintar primitivas funcionan bien, así que plantemos esos test, aunque ahí está, esperando, como otros miles de cosas. Para probar entornos gráficos usamos abbot (es una herramienta para java) y anteriormente maraton (basado en python) con los que se pasa un plan de pruebas automático en cada release que pasa a QA.

por cierto, cuando hablo de nosotros me refiero a Unkasoft, puedes ver en el blog algunas entradas sobre scrum, tdd y control de versiones.

Gracias por los libros, los echaré un vistazo.

Yo tambien estoy usando trac para un proyecto personal que estamos haciendo un grupo muy pequeño de personas y la verdad es que está genial. Me gusta la integracion que hace de SVN, wiki y tareas.

Respecto a lo del RSS. Me gusta más que el correo como sistema de difusion de información al equipo. Queda todo mas centralizado que un sistema de correo. Aparte que si se incorpora un miembro nuevo al equipo recibe todo el RSS de un tiron. O por ejemplo, el servidor de RSS tiene todo el historico de la evolucion del proyecto. Quizá es una cuestión de gustos, con el correo se funciona bastante bien. Una cosa que hecho en falta en el TRAC es justamente el soporte de RSS.

En Pyro no usamos Scrumm. Yo lo he usado parcialmente en otras empresas usando el Project como gestor de tareas y un panel (fisico) para el backlog. Definitivamente, el Project no acabo funcionando muy bien. Para la gestion interna del equipo, usabamos Mantis, y no ha funcionado del todo mal.

De todas formas, todavía ando buscando una herramienta que se adopte mucho más a Scrumm. Posiblemente mi siguiente proyecto emplee Scrumm.

En el repositorio de código tenemos un sistema de ramas. Básicamente tenemos dos tipos de ramas: las ramas de versiones estables y las ramas que se crea un subequipo para trabajar en una feature durante un periodo de tiempo sin perturbar la rama principal. Lo ideal es reducir el numero de ramas porque suelen salir bastante caras con el tiempo (integraciones entre ellas. Y eso que empleamos Perforce que tiene un sistema de integracion increiblemente eficiente). El modelo de integración continua mantiene una rama current en la que esta todo el mundo.

Te recomiendo los siguiente papers con respecto a este tema:

• Codeline Management for Evolutionary Development
• Convergence vs. Divergence

Si, trabajamos con test unitarios. Gran parte de las clases tienen su correspondiente test. No usamos TDD en el sentido puro (tests antes que implementacion) pero es bastante normal el desarrollo de los tests en paralelo a la implementacion. Has usado TDD tu?

Para la parte gráfica los tests son bastante complicados y no tenemos muchos. Pero por ejemplo, si tenemos test que comprueban que una textura carga y que los colores que hay en memoria son los correctos. O que el optitmizador de mallas funciona, etc etc. Pero tests que comprueben los resultados en pantalla no tenemos. Parece muy complejo de implementar como test algo asi la verdad. Tienes alguna experiencia en esto?

Respecto al video, siento decirte que no puedo distribuirlo, es material de Pyro.

Un saludo.

El juego entiendo que es puramente en 2D no? Si tienes experiencia con DirectX, un juego 2D montado directamente sobre la capa 3D de DirectX no es muy costoso y tienes bastante libertad.

Encima de DirectX, Microsoft proporciona una capa (D3DX, incluida en el SDK) de más alto nivel que incluye 2 cosas que os pueden interesar: una libreria para soporte de sprites y una libreria para GUI que quiza os vale tb.

En caso de que esto os parezca todavía muy bajo nivel os recomiendo que echeis un vistazo a XNA. Es una capa sobre DirectX que viene a substituir al Managed DirectX (MDX). Para XNA teneis que usar (salvo que esto haya cambiado) el Visual Studio Express y esta algo limitado en cuanto a interaccion con otras librerias .NET (no podeis accedere a assemblies de fuera por ejemplo, no hay soporte de red, etc).

Si ninguna de estas opciones os convence, yo probaria la libreria SDL. Es una liberia multiplataforma montada sobre OpenGL y con una API 2D muy sencilla. Posiblemente para vuestro juego de cartas os venga bastante bien.

Y en cuanto a bibliografias para todo esto, la verdad es que no conozco ningun libro bueno (que no digo que no los haya) sobre estas API. Mi recomendacion es que tireis de la propia documentacion que incorporan (que en todos los casos que os he dicho es perfecta).

Ya me contaras por donde tirais.

Nosotros hasta ahora usamos skype como mensajería interna, trac para tracking de proyectos y como wiki y correo electrónico, lo que no entiendo es para qué y como usais el RSS y porqué es más efectivo que el correo.

Por otra parte, qué tal os funciona scrum con un número grande de personas? qué sistema de tracking usais para llevar scrum?

Luego por parte del servidor de compilación y el repositorio: usais algún tipo de modelo de ramas?. Si teneis integración continua imagino que subir cambios intermedios será peligroso si no usais un sistema de ramas o similar. Usais test unitarios? (y ya d epaso, usais TDD?) si es así, teneis algún tipo de test para los módulos de gráficos. La lógica es muy simple de probar, sin embargo el tema de la visualización es bastante más complejo…

Un saludo. Se puede ver el video que indicas al final de la presentación en alguna parte?

Te pediría que me recomendaras una bibliografía que consultar para crear la parte gráfica (el cliente) del juego de cartas online que te dije despues de la charla que estabamos haciendo un colega y yo como proyecto fin de carrera.

Saludos, Sickes.

Mi idea era dejar mucho tiempo para preguntas pero no fue posible.

Viendo vuestros blogs (muy interesantes por cierto) por lo menos he visto que habeis pillado muy bien los mensajes ensenciales que queria transmitir.

Un saludo, y cualquier cosa que me querais comentar aquí estoy (por aqui o por mail).

Un saludo.