¿PHP, Ruby o Python?
Se ha establecido la discución internamente en mi empresa acerca de cual debería ser el lenguaje seleccionado para nuestros desarrollos, por lo menos para aquellos desarrollos donde al cliente no le interesa cual será la tecnología. Con la aparición de frameworks como Rails o DJango nace la necesidad de migrar del viejo y querido PHP hacia lenguajes mas ágiles, donde los cambios rápidos son más fáciles de implementar, son más fáciles de mantener y quien sabe que otra ventajas.
Por mi parte aunque reconozco la gran oportunidad que estos lenguajes ofrecen me tomo con calama la selección, ya que a mi juicio el factor lenguaje no es un argumento tan ponente como si lo es la perfecta coordinación del equipo de desarrollo, la generación de conocimiento al interior de las empresas y la utilización de las metodologías actuales como TDD, BDD, XP, etc. Este es mi juicio es el mayor valor que una empresa de software tiene o debierá tener. Así para mi siempre será mejor tener 10 tipos aromicamente coordinados trabajando en PHP que 10 expertos pero incomuicados programadores en Python.
En todo caso las cosas que he visto de Python ya me han abierto el apetito, mmhhhh... ya tengo mi elección.
Knowledge Management
Acabamos de instalar Sciret como medio para gestinar el conocimiento al interior de nuestro departamento. Aunque ya estabamos utilizando un wiki al interior de la empresa me parecio que un sistema como este podría fomentar de mejor manera el intercambio de conocimiento en nuestra área, principalmente por la facilidad y rapidez de publicación, además trae una opción para realizar pregunta a los usuarios registrados. Lo unico que estaría faltando es la posiblidad de la incorporación de keywords o la clasificación de contenidos en múltiples categorias.
Ójala y todos comprendan lo importante que es compartir el conocimiento y nuestra base se llene pronto de articulos!
Cultura
A poco andar en el camino de llegar a desarrollar bajo metodologías ágiles me encontrado con un número de técnicas de desarrollo que parecen realmente novedosas y atractivas, ofreciendo cada una solucionar alguno de los problemas de los enfoques tradicionales de desarrollo. Me he propuesto revisar algunas de estas y aplicarlas en mi trabajo diario, pero ahí es cuando choco con la realidad de nuestro mercado, al parecer dominado por un conjunto de fuerzas místicas arraigadas en nuestra cultura.
Implementaciones baratas de expertos asesores que malamente imitan las buenas prácticas existentes avalados por alguna certificación o por alguna visita a las ferias top en el extranjero sumergen a las empresa en procesos que estas no atienden, dando inicio a si a nuestros estándares a la “chilensis”. Muchos ven una oportunidad para agarrar una parte de la torta y surgen una serie de avezados en la industria, las bolsas laborales se llenan de expertos, el cuadro se completa cuando las empresas comienzan a exigir a sus proveedores el cumplimiento de estos estándares. “¿Usted tiene alguna certificación?”, “¿En que nivel esta usted?”, “¿Ha trabajado en la metodologías X e Y?”.
Al comienzo me sentía alegre y motivado a trabajar con empresas que me exigen un proceso o metodología de desarrollo. ¡Por fin!, la oportunidad de demostrar que intentas hacer las cosas bien, pero… de vuelta a la realidad de nuestro Chile me encuentro que son estas mismas empresas muchas veces incapaces de responder a los requisitos que estas metodologías les imponen, son las mismas que mal entienden el sentido de una metodología y son llevadas a prestan más atención en la forma y que en el fondo. Se verifica la existencia de los artefactos pero no se revisa su contenido, se verifica la existencia de un procedimiento pero no su seguimiento.
Pero no todo esta perdido y aunque suene reiterativo Internet ha permitido que sean cada día mas las personas que miran hacia fuera con un sentido crítico y constructivo. Aplican así lo mejor que nos ofrece el mercado y sólo faltará que las empresas estén atentas cuando se topen con uno de estos personajes y sepan realizar el cambio que nuestro mercado requiere. (Por cierto me considero afortunado de conocer a algunas de estas personas).
¿Cuándo comenzamos el proyecto?
¿Se han encontrado con clientes que quieren comenzar el proyecto el mismo día de aprobada la propuesta comercial?
¿Cuándo comenzamos el proyecto? No es primera vez que me hago esta pregunta, y pero aún no es primera vez que trato de discutirla con nuestros amigos del área comercial. Pensar en ella me hace reflexionar acerca de las cosas que deben suceder desde que obtenemos la aprobación de inicio del proyecto por parte del cliente, las siguientes son algunas de estas cosas:
Asignar las personas clave del proyecto ¿quien será el jefe de proyecto?, ¿que recursos necesita?, ¿están los recursos disponibles?
Comunicar el proyecto: el equipo es informado, el líder y/o el equipo cuenta con el tiempo para conocer los objetivos del proyecto y limitaciones del proyecto (tiempo, costo, etc.)
Un plan es realizado, se crea una estrategia que permitirá abordar con éxito el proyecto, los riesgos son evaluados, las actividades son asignadas; Aunque será una primera versión a depurar y conversar con el cliente, no debería iniciarse el proyecto sin esta planificación.
Todas estas actividades deberían estar respaldadas en alguna cláusula de nuestra oferta al cliente, así nos aseguramos que conozca de antemano que existirá por el bien del proyecto un periodo de retardo entre la aprobación y el inicio de las actividades.






