1. Instalar Dropbox y abrir cuenta si no se dispone ya de una.
2. Instalar TortoiseSVN.
3. Crear carpeta ‘svn’ dentro de la carpeta ‘Dropbox’ instalada en nuestro PC.
4. Hacer click derecho sobre la carpeta ‘svn’ y seleccionar TortoiseSVN > Create repository here.
5. Elegir la opción de ‘Create folder structure’ y después dar ‘OK’. Con esto hemos creado el repositorio.
6. Para sincronizar nuestros proyectos con el repositorio: sobre la carpeta en la que almacenemos nuestros proyectos hacemos click derecho y seleccionamos TortoiseSVN > Import.
7. Ponemos como URL del repositorio la dirección de la carpeta ‘svn’ creada en el paso 3. (Ejemplo: file:///D:/Dropbox/svn)
8. Aceptamos y comprobamos cómo se suben los ficheros del proyecto al repositorio.
9. Sobre la carpeta de nuestros proyectos, hacemos click derecho y elegimos ‘SVN Checkout…’
10. En ‘URL of repository’ ponemos la misma del paso 7 y en ‘Checkout directory’ la carpeta de nuestros proyectos, quitando el ‘/svn’ que añadirá por defecto al final de la URL y pulsamos ‘OK’.
11. Ya tenemos lista la carpeta de nuestros proyectos para hacer Commits y Updates haciendo click derecho sobre ella.

Si trabajamos con un IDE de desarrollo que incorpora plugins para Subversion no es necesario sincronizar manualmente la carpeta de nuestros proyecto (pasos 6 a 11), sino que sería suficiente con indicar en la configuración del plugin la dirección del repositorio (carpeta ‘svn’ de ‘Dropbox’).

Por cada uno de los PCs en los que vayamos a trabajar, habrá que repetir los pasos 1, 2, 9 y 10. Los demás pasos son sólo para el primer ordenador.

Sin embargo la especialización, siendo importante, no lo es todo. La tendencia actual en el desarrollo de software a la formación de equipos multidisciplinares para el soporte de las metodologías ágiles y la reducción de costes en las organizaciones obliga a que los Ingenieros en Informática, si quieren mantenerse competitivos, sean capaces de manejarse al menos de forma aceptable en los siguientes campos:

• Programación de aplicaciones de escritorio: conocer al menos .NET bajo Visual Studio y Java en Eclipse, siendo bastante competente en al menos uno de ellos.
• Programación web: HTML es obligatorio y por lo menos se deben tener unas nociones básicas de CSS y JavaScript. Además, tienes que ser capaz de hacer aplicaciones simples en ASP.NET, Java EE y PHP, siendo bastante competente en al menos una de ellas. Aquí cobra además especial importancia la seguridad.
• Ingeniería de Requisitos: Recogida y gestión de los requisitos. Normas básicas de elaboración de una buena especificación.
• Análisis y Diseño de sistemas de software: Hay varios lenguajes de modelado importantes, pero el dominio de UML es obligatorio, al menos en un grado avanzado. Hoy en día hay que tener nociones además de Desarrollo Dirigido por Modelos. Conocimientos de algoritmia y estructuras de datos son igualmente básicos tanto para el diseño como para la programación.
• Pruebas: unitarias, de integración, funcionales y de aceptación.
• Bases de Datos: el diseño de bases de datos es esencial, la normalización bastante deseable. El conocimiento de al menos un lenguaje de acceso a bases de datos (SQL principalmente) es obligatorio. No se pueden olvidar los servicios web para el encapsulamiento del acceso y modificación de los datos.
• Gestión de Proyectos:
• Definición, Descomposición y Planificación de Proyectos. Técnicas de estimación de tareas.
• Seguimiento de proyectos.
• Control de versiones.
• Gestión de riesgos, cambios e incidencias.
• Gestión de expectativas de los implicados y de la comunicación entre ellos.
• Nociones al menos básicas sobre presupuestos y contratos.
• Dominio de herramientas como Microsoft Project.
• Estándares, metodologías y modelos de calidad: CMMI, ISO 9001, RUP, 6 Sigma, Scrum, XP, etc. Algunos son metodologías de desarrollo, otros modelos de mejora de procesos, pero en cualquier caso haber oído hablar de ellos nunca está de más.

No creo que éstos que he mencionado tengan que ser campos que un junior deba conocer a fondo desde un principio para ejercer su profesión, pero sí creo que todo ingeniero debería trazar su propio plan de formación a corto y medio plazo de manera que se garantizase a sí mismo conocimientos en éstas y otras áreas de las que probablemente me haya olvidado y que resulten igualmente importantes. La Universidad pone las bases, pero el desarrollo formativo posterior es responsabilidad exclusiva de cada uno.

PD: Una primera crítica que se me ocurre a mi propia lista es que está posiblemente muy enfocada al desarrollo de software y deja de lado campos en los que ejercen gran número de ingenieros como son las Redes, la Optimización y el Control industrial o la electrónica de circuitos, entre otras.

En realidad no es que no existan buenas metodologías en el desarrollo de software, sino que cada metodología es aplicable a un contexto determinado. De hecho incluso dentro de una misma organización la metodología tomada como referencia debe ser evaluada y en su caso adaptada para cada proyecto concreto, en función de características diversas como son el número y la experiencia de los participantes, la relación con el cliente, los plazos, etcétera.

En resumen, hay que evitar ser un talibán de la metodología. La definición de los procesos de desarrollo en una organización debe ser configurable para cada proyecto, de forma que no se pierda el foco de lo realmente necesario para el éxito del mismo. Eso sí, los procesos resultantes de la adaptación no deben desviarse de los mínimos criterios de calidad impuestos por la organización. Se trata de modificar el cómo cumplir con los objetivos, no los objetivos en sí.

En él explicamos los principales desafíos que supuso la adaptación de las diversas áreas de proceso de CMMI al modelo de negocio del I+D+i, así como las pautas que a nosotros mejor nos funcionaron para implantar exitosamente las prácticas en la organización.

La ponencia surgió a raíz del interés de la organización del congreso en difundir el contenido del artículo -del mismo nombre que la ponencia- que se puede encontrar en este enlace.

Ante un imprevisto, un equipo de desarrollo cuenta con cuatro alternativas, que enumeraré en orden desde la más deseable hasta la que debe ser tomada como último recurso.

1. Elegir a una persona con la formación adecuada que pueda retrasar sus tareas sin impactar en la fecha de entrega. Esta opción es la más deseable porque las tareas que la persona está realizando se encuentran fuera del camino crítico, y por lo tanto su retraso, dentro de un límite -concretamente la holgura de sus tareas asignadas-, no impacta en el trabajo de los compañeros ni en las fechas de entrega.
2. Retrasar la fecha de entrega. Si no se dispone de recursos para afrontar las tareas que son desviadas por el marrón, y estas tareas ya se encontraban ajustadas de fechas, lo primero que se nos pasa por la cabeza es retrasar el hito. En este caso, por razones obvias, más nos vale disponer de un buen negociador en el equipo para interceder ante el cliente.
3. Disminuir el alcance del proyecto. Si bueno debe ser el negociador que retrase la fecha de entrega, mejor debe ser el negociador que recorte los objetivos del proyecto. Cuando las tareas asignadas no pueden resolverse en tiempo, es evidente que determinadas funcionalidades y características del producto han de verse recortadas. Una disminución del alcance reducirá con total probabilidad el valor percibido por el cliente y por lo tanto una rebaja en el precio final será prácticamente obligatoria.
4. Hacer horas extra. En el caso de que las horas extra estén bien pagadas y el equipo esté motivado, es muy posible que ésta no sea ni mucho menos la opción menos deseada para afrontar el imprevisto, pero también es cierto que este caso ideal no siempre se da y que por lo tanto el exigir un esfuerzo adicional del equipo para cumplir con el imprevisto y con el resto de tareas a tiempo y dentro de los objetivos marcados, va a exigir grandes dosis de mano izquierda y motivación por parte de los responsables de la organización.

En realidad el afrontar imprevistos es muy común en el mundo del desarrollo de software, y rara vez no se resuelven recurriendo al uso de horas extra. Que esos esfuerzos extraordinarios sean ocasionales entra dentro de lo perfectamente normal. El problema viene cuando se convierten en una práctica habitual.