Barrapunto

• Si quiero tener separadas las pruebas del código normal en diferentes DLLs, solo puedo probar métodos públicos.
  
• A veces estoy explorando y no sé qué devolverá un método hasta que lo ejecuto.
  
• Cuando decido cambiar la API de un módulo (cambio parámetros o resultados), tengo que revisar un montón de pruebas que usan esa API.

Bueno:

Yo no veo un problema en el tamaño del proyecto para aplicar XP ni en la reutilización, lo que sí que veo es que todo proceso hay que adaptarlo a las necesidades de cada uno. Adelanto que no tengo conocimiento práctico de XP pues no he trabajado bajo dicha metodología, pero si que he leido mucho sobre el tema (si le digo a mi jefe que implantemos esto igual se muere el pobrecito :) ).

Supongamos que tenemos un proyecto de 50 personas. Está claro que XP como tal no va a aceptar bien un proyecto tan grande, y que el código no es reutilizable.

Yo lo que he pensado es dividir el equipo en 5 grupos de 9 personas (45 personas) más 5 personas de soporte. Estos grupos trabajarán como equipos independientes de extreme programming.

Por otro lado, creo que la definición de producto es un tanto escueta. Un producto es algo más que lo que tienes que entregar al cliente. Yo considero producto todos los componentes que se emplean para hacer un programa, y considero a mis compañeros como clientes de lo que hago (esto no lo he inventado yo, es parte integrante de toda empresa con un plan de calidad integral).

A uno de los equipos de trabajo se le asignaría el desarrollo del sistema completo. Este grupo se encargaría del esqueleto de la aplicación así como de su arquitectura. Trabajaría como un equipo XP normal pero además sería el cliente de los otros grupos y les iría solicitando los componentes que necesita para completar su aplicación. Así si el equipo A es el encargado de la realización del producto y puede pedirle al equipo B un componente (por ejemplo, un componente para loguear el funcionamiento de las aplicaciones).

¿Llega el día de la entrega?. Pues se traspasa el componente al equipo 1 mediante insourcing. Para ello se irán sustituyendo programadores del equipo B por programadores del A (esto no lo he inventado yo... ¿eh?...). Y cuando ya la mitad de los programadores del B hallan sido sustituidos, los programadores vuelven a su equipo y se emparejan con los que allí estan para mantenerlo.

Por otro lado, nos quedan 5 programadores sin asignar los cuales se encargarán de llevar un repositorio común de componentes, una publicación diaria que mantenga cohesionados a los 5 equipos de desarrollo(anunciando nuevos componentes desarrollados, cambios en los que ya hay, que tal compañero ha tenido un hijo, etc).

Algo en lo que difiere el tema de los componentes aquí es que no debe tenerse miedo a refactorizar los componentes porque tenemos los casos de prueba para asegurar su correcto funcionamiento (no nos olvidemos de "diseño simple" y "coraje"). Así si nuestro componente de logeo es utilizado en un proyecto como una librería sin capacidad multihilo y en otro proyecto se nos solicita dicha capacidad, el componente mantiene su interfaz antígua pero la implementación se puede simplificar (incluso puede que no sea necesaria otra interfaz).

Para aumentar la comunicación, intercambiaría programadores entre equipos cada cierto tiempo. 2 programadores cada 4 meses o así. Por otro lado haría que la sala de trabajo fuera la misma para los 5 equipos con una mesa para cada uno, así como una sala de descanso común.

Bueno. Yo creo que funcionaría. Ya me direis.

  Yo lo conocia (ahora no lo conozco ;) )como Keep It Silly and Simple (matenlo sencillo y 'tonto').

  Gusi