Justo después de publicar la entrada anterior se me ocurrió que en vez de pensar en irme a trabajar a aquella empresa en la que estaban introduciendo herramientas y políticas que facilitan el trabajo y aumentan la calidad del proceso de construcción de software, podría (e incluso debería) hacer algo al respecto en la empresa en la que trabajo actualmente.
Así que fui a hablar con la persona indicada y le propuse hacerle una presentación con todas las cosas que se podrían introducir y las mejoras que eso supondría. Hemos quedado para la próxima semana.
Espero convencerlos y quedar como responsable de todo el asunto.
Thursday, May 17, 2007
Evidencia sobre el estado de la informática en España
Ayer tuve una reunión con dos arquitectos de una de las mayores empresas de consultoría informática en España en la cual me explicaban las ventajas de trabajar para esa empresa.
Me comentaban que como parte de su nueva política estaban utilizando "best practices" (prácticas recomendadas) que importaban desde una de sus sucursales en el extranjero, en uno de esos países considerados (con razón diría yo) tecnológicamente más avanzados que España. Estas son algunas de esas prácticas recomendadas:
- Utilización de un sistema de gestión de incidencias (Issue Tracking System, Bug Tracking System)
- Utilización de control de versiones y control de código fuente (Source Control, Version Control)
- Utilización de un Wiki para la gestión del conocimiento (Wiki)
¡De verdad acaban de descubrir esto! Una vez más me sorprendo de lo poco serio que se toma el desarrollo de software.
En cualquier caso, debo decir que es el único lugar de los que conozco en el que estén implantando estas herramientas como parte de la política corporativa. ¿Quizás debería plantearme trabajar allí?
Me comentaban que como parte de su nueva política estaban utilizando "best practices" (prácticas recomendadas) que importaban desde una de sus sucursales en el extranjero, en uno de esos países considerados (con razón diría yo) tecnológicamente más avanzados que España. Estas son algunas de esas prácticas recomendadas:
- Utilización de un sistema de gestión de incidencias (Issue Tracking System, Bug Tracking System)
- Utilización de control de versiones y control de código fuente (Source Control, Version Control)
- Utilización de un Wiki para la gestión del conocimiento (Wiki)
¡De verdad acaban de descubrir esto! Una vez más me sorprendo de lo poco serio que se toma el desarrollo de software.
En cualquier caso, debo decir que es el único lugar de los que conozco en el que estén implantando estas herramientas como parte de la política corporativa. ¿Quizás debería plantearme trabajar allí?
Monday, May 7, 2007
Mi empresa actual
Tengo las manos muy libres en mi empresa actual. He logrado implementar muchas de las cosas que creo que se deben hacer en un equipo de desarrollo de software profesional, y que increíblemente son poco comunes!
Lo primero que quise hacer y logré fue eliminar el uso de Visual Source Safe. Como aspecto positivo debo decir que el uso del control de versiones de código estaba bien establecido aquí, pero la herramienta dejaba muchísimo que desear. VSS te deja sin control sobre lo que ocurre con tu código y además falla bastante, sobre todo si se utiliza la integración con VisualStudio.
La nueva herramienta para el control de versiones en mi equipo es Subversion, y estoy muy contento con ella, como también lo están los demás.
El segundo paso fue establecer un sistema de seguimiento de bugs... esto sí que ha sido una novedad por aquí. Increíble! Tengo un compañero que dirige otro equipo que no utilizaba ninguna herramienta y en estos momentos ya es un fan del BugTracker.NET, que es la herramienta que instalé: desarrollada con ASP.NET 2.0 y de código abierto, muy adaptable y que sigue la filosofía de FogBugz (http://www.fogcreek.com/FogBugz/, un poco de publicidad gratis para esta aplicación).
El éxito de esta aplicación depende de la disciplina pero los programadores con los que trabajo son buenos y han apreciado la idea, por lo que no me ha costado mucho que la utilicen... y claro, los otros dos miembros del equipo, el jefe de equipo y la analista, se han visto gentilmente forzados a utilizarla mediante sutilezas como pedirles que introdujeran una tarea en el BugTracker.NET en vez de enviarnos un correo o pedírmelo verbalmente: "es que se me olvidará" :-) En estos momentos creo que todos están muy contentos con la aplicación, a la que solo le falta controlar el tiempo dedicado a cada tarea automáticamente para generar los dichosos reportes de horas.
La tercera mejora fue precisamente en el tema de los reportes. Piden un reporte mensual, y además un reporte semanal de lo que haces. A mí me parece exagerado y demasiado molesto para un programador así que hice una aplicación (en .NET 3.0 por cierto) que ayuda bastante en la labor, y se la presenté a mis programadores. También están encantados porque además de generarles los reportes más o menos como deberían quedar nos ayuda a contar las 40 horas de trabajo semanal! Es genial! Se puede descargar desde SourceForge.NET: https://sourceforge.net/project/showfiles.php?group_id=190366, pero no se la recomiendo a nadie en su estado actual. Está demasiado orientada a mis necesidades particulares, pero planeo irla mejorando para que sea suficientemente configurable como para utilizarla en cualquier entorno.
También he instalado un Wiki que nos permite almacenar conocimiento sobre el desarrollo en proceso. De todas las aplicaciones esta es la que menos éxito ha tenido. Se sigue utilizando mucho la red para el intercambio de documentos. Creo que las causas fundamentales son:
- Falta de integración con el BugTracker.NET, el Subversion y el CC.NET
- Falta de soporte institucional: por un tema de ISO900x los documentos generados deben estar en ciertas ubicaciones en la red.
Aún hay más, aunque este post se extienda ya demasiado. Otro paso que completé hace solo unos días fue la implementación de un sistema de integración continua: CruiseControl.NET (http://ccnet.thoughtworks.com). Instalación sencilla en Windows, funcionamiento impecable, una comunidad muy activa y una documentación muy completa en forma de Wiki. Gratis y de código abierto. Ha significado una gran tranquilidad y una notable mejora en el proceso de creación de entregas (releases).
La integración continua no hubiera sido posible sin la utilización de NAnt, otra herramienta de las que ya se utilizaba con anterioridad en la empresa pero solo de forma esporádica.
Creo que esto es todo. Planeo seguir mejorando el proceso de creación de software aquí, al menos en el ámbito que controlo.
Lo primero que quise hacer y logré fue eliminar el uso de Visual Source Safe. Como aspecto positivo debo decir que el uso del control de versiones de código estaba bien establecido aquí, pero la herramienta dejaba muchísimo que desear. VSS te deja sin control sobre lo que ocurre con tu código y además falla bastante, sobre todo si se utiliza la integración con VisualStudio.
La nueva herramienta para el control de versiones en mi equipo es Subversion, y estoy muy contento con ella, como también lo están los demás.
El segundo paso fue establecer un sistema de seguimiento de bugs... esto sí que ha sido una novedad por aquí. Increíble! Tengo un compañero que dirige otro equipo que no utilizaba ninguna herramienta y en estos momentos ya es un fan del BugTracker.NET, que es la herramienta que instalé: desarrollada con ASP.NET 2.0 y de código abierto, muy adaptable y que sigue la filosofía de FogBugz (http://www.fogcreek.com/FogBugz/, un poco de publicidad gratis para esta aplicación).
El éxito de esta aplicación depende de la disciplina pero los programadores con los que trabajo son buenos y han apreciado la idea, por lo que no me ha costado mucho que la utilicen... y claro, los otros dos miembros del equipo, el jefe de equipo y la analista, se han visto gentilmente forzados a utilizarla mediante sutilezas como pedirles que introdujeran una tarea en el BugTracker.NET en vez de enviarnos un correo o pedírmelo verbalmente: "es que se me olvidará" :-) En estos momentos creo que todos están muy contentos con la aplicación, a la que solo le falta controlar el tiempo dedicado a cada tarea automáticamente para generar los dichosos reportes de horas.
La tercera mejora fue precisamente en el tema de los reportes. Piden un reporte mensual, y además un reporte semanal de lo que haces. A mí me parece exagerado y demasiado molesto para un programador así que hice una aplicación (en .NET 3.0 por cierto) que ayuda bastante en la labor, y se la presenté a mis programadores. También están encantados porque además de generarles los reportes más o menos como deberían quedar nos ayuda a contar las 40 horas de trabajo semanal! Es genial! Se puede descargar desde SourceForge.NET: https://sourceforge.net/project/showfiles.php?group_id=190366, pero no se la recomiendo a nadie en su estado actual. Está demasiado orientada a mis necesidades particulares, pero planeo irla mejorando para que sea suficientemente configurable como para utilizarla en cualquier entorno.
También he instalado un Wiki que nos permite almacenar conocimiento sobre el desarrollo en proceso. De todas las aplicaciones esta es la que menos éxito ha tenido. Se sigue utilizando mucho la red para el intercambio de documentos. Creo que las causas fundamentales son:
- Falta de integración con el BugTracker.NET, el Subversion y el CC.NET
- Falta de soporte institucional: por un tema de ISO900x los documentos generados deben estar en ciertas ubicaciones en la red.
Aún hay más, aunque este post se extienda ya demasiado. Otro paso que completé hace solo unos días fue la implementación de un sistema de integración continua: CruiseControl.NET (http://ccnet.thoughtworks.com). Instalación sencilla en Windows, funcionamiento impecable, una comunidad muy activa y una documentación muy completa en forma de Wiki. Gratis y de código abierto. Ha significado una gran tranquilidad y una notable mejora en el proceso de creación de entregas (releases).
La integración continua no hubiera sido posible sin la utilización de NAnt, otra herramienta de las que ya se utilizaba con anterioridad en la empresa pero solo de forma esporádica.
Creo que esto es todo. Planeo seguir mejorando el proceso de creación de software aquí, al menos en el ámbito que controlo.
Subscribe to:
Posts (Atom)