jueves, marzo 29, 2007

Subversion: Colaboración en el Software

En este artículo vamos a ver el funcionamiento de Subversion, una herramienta libre que sirve como repositorio de código en los proyectos de desarollo software. La utilización de un repositorio de código, un sitio central donde se vayan juntando todas las partes desarrolladas por las diferentes personas involucradas, es obligado. Sin embargo, Subversion nos ofrece una serie de funcionalidades que la convierten en una de las herramientas colaborativas más utilizadas.

¿Qué es un repositorio?
Un repositorio de código es, en esencia, un programa que sirve para juntar las partes de código que los desarrolladores programan por separado. Las funcionalidades básicas (aunque no todos las cumplen) son las siguientes:
  • Mantener revisiones de código, es decir, si yo cambio algo en el repositorio, el gestor de código debe mantener puntos de restauración, de forma que cualquiera pueda descargarse el código con mis modificaciones o sin ellas.
  • Seguimiento de Cambios, debo poder realizar comentarios cuando actualice algo, indicando qué es lo que he cambiado, qué es lo que he arreglado, etc. de forma que el resto de desarrolladores puedan consultar mi comentario y saber qué es lo que he hecho antes de descargarselo.
  • Copias de seguridad de los códigos y las revisiones.
  • Etiquetas de versiones y revisiones, para poder localizar rápidamente la versión a descargar o la revisión específica.
¿Por qué utilizar un repositorio de código?
Cuando nos encontramos involucrados dentro de proyectos de desarrollo donde trabajan diversas personas cada una de ellas conocerá una parte del desarrollo y se centrará en ella. Sin embargo, aunque cada uno lleve su parte, necesita la de los demás para que funcione correctamente. Sin un repositorio, tendríamos que enviarnos constantemente todas las partes unos a otros con el consiguiente caos, o que una persona se dedicase a recibir todas las modificaciones y mandarlas al resto de desarrolladores. En el siguiente diagrama se muestra un poco esta situación:











En el caso que tengamos un repositorio de código, la situación sería diferente. Cada desarrollador estaría conectado con el repositorio y enviaría sus modificaciones al mismo. Este se encargaría de conjugar las diferentes partes y mostrar a los desarrolladores la versión completa.

Operaciones con los repositorios:
Existen dos operaciones básicas que se realizan en todos los respositorios y luego algunas funcionalidades avanzadas de algunos mejor preparados, caso de Subversion.

  • Confirmar: subir los cambios que hemos realizado al repositorio. Únicamente se enviarán los cambios realizados con respecto a la versión existente en el repositorio.
  • Actualizar: recibir la versión existente en el repositorio con los cambios que hayan realizado el resto de desarrolladores.












Las operaciones especiales que tenemos en los repositorios y que le dan un valor añadido son:

  • Creación de etiquetas y versiones: nos permite marcar con una etiqueta una confirmación de cambios o crear una versión, de forma que se pueden localizar rápidamente las revisiones o versiones.
  • Creación de ramas de desarrollo: esta opción permite crear líneas independiente de desarrollo. Esto se utiliza para el desarrollo de partes de las aplicaciones que no queremos que interfieran en la rama principal hasta que estén acabadas. Una vez terminadas, se fusiona la rama de desarrollo con la principal.
  • Bloqueo de ficheros: habrá veces que estemos modificando un fichero y no queramos que nadie lo toque mientras lo tengamos nosotros. En ese caso, bloquearemos el fichero y el repositorio no dejará que nadie lo utilice.
  • Fusión de ficheros: esta es una de las herramientas más potentes de Subversion ya que permite que varias personas trabajen simultáneamente sobre el mismo fichero, encargándose él de fusionar los cambios. En caso de surgir un conflicto porque varias personas han modificado la misma parte del fichero, tendrá que ser el usuario el que diga cual es la modificación que prevalece.











Utilización del repositorio:
Como en todas las fases de un proyecto, es necesario plantearse una estrategia para la utilización del repositorio. Subversion se basa en carpetas dentro de las cuales se organiza la información. Para acceder al repositorio se puede hacer vía un servidor Apache (utilizando http) o mediante el servidor subversion (protocolo svn). Dentro del servidor accederemos a una carpeta o subcarpeta para actualizar nuestra información. Se aconseja siempre que los ficheros que se mantengan controlados por el repositorio sean los de código fuente, excluyendo ficheros binarios, compilados, librerías, etc. La estructura de carpetas aconsejable es la siguiente:

  • Carpeta TRUNK: rama principal de desarrollo, aquí irá el desarrollo principal y se irán fusionando las diferentes ramas.
  • Carpeta TAGS: carpeta donde se almacenarán las diferentes versiones y revisiones con nombre del desarrollo. Cuando queramos descargarnos una versión la buscaremos en esta carpeta
  • Carpeta BRANCHES: carpeta donde se almacenan las ramas de desarrollo de nuestro sistema.
Manteniendo esta simple jerarquía de carpetas será mucho más fácil gestionar nuestro repositorio de código y realizar las copias de seguridad.

Conclusión:
La utilización de un repositorio de código es obligado en proyectos que cuenten con más de dos o tres personas trabajando. No solo nos sirven como controlador de los cambios, sino también como copia de respaldo del código. Es muy aconsejable utilizarlos y sacarles el máximo de provecho.

domingo, marzo 18, 2007

Gestión de Proyectos de Cooperación al Desarrollo

1.Presentación

El objetivo de esta entrada es introducir una ya conocida herramienta en la gestión de proyectos de cooperación al desarrollo llamada "Enfoque del Marco Lógico" (EML).

2.Proyectos de desarrollo

¿Qué entendemos por desarrollo?
Un problema serio que nos encontramos a la hora de elaborar un proyecto de cooperación al desarrollo es que nos lanzamos a desarrollarlo sin habernos parado a pensar seriamente qué entendemos nosotros por desarrollo. ¿Qué es desarrollo? ¿desarrollo económico? ¿desarrollo humano? ¿mejora de las capacidades individuales? ¿mejora de las capacidades colectivas? ¿mejoras puntuales de las condiciones de vida? ¿mejora de las herramientas que generan las condiciones de vida? Es necesario que esto quede claro.
El desarrollo, entendido desde el punto de vista de un proyecto de cooperación al desarrollo siempre ha de ser el de la mejora de las condiciones de vida colectivas, que devendrá en la mejora de las condiciones individuales, desde la óptica del desarrollo humano siempre y salvaguardando los derechos humanos, la justicia social y los derechos colectivos de grupos étnicos y nacionalidades.

¿Qué es un proyecto de desarrollo?
Los proyectos de desarrollo tienen el objetivo de solucionar unos problemas o necesidades y mejorar la situación de los beneficiarios aplicando diversas técnicas y garantizando siempre la independencia de la población beneficiaria así como la dirección activa del proyecto por parte de éstos.
Una de las tareas principales del proyecto debe ser capacitar a sus beneficiarios para que sean más independientes de la ayuda y el apoyo exterior.. que sean capaces de resolver nuevos problemas por sí mismos.

Estructura de un proyecto de desarrollo
Un proyecto se estructura en 4 fases principales:
  • Identificación
En esta fase lo que hacemos es determinar los problemas que han de resolverse.. ¿qué sucede?, ¿por qué sucede?, ¿a quiénes y cómo afecta?... ¿cómo se puede solucionar?.
  • Diseño
En la etapa de diseño organizaremos la información obtenida en la fase anterior. Aquí hay que establecer las estrategias a seguir, los plazos, los costes, los recursos necesarios.. ¿qué queremos hacer?, y ¿cómo pretendemos realizarlo? ¿a quién se dirige la acción?, ¿por qué y para qué actuar?, ¿con quién, dónde, cuándo y con qué recursos?
En esta etapa construiremos el esqueleto del proyecto: la llamada Matriz de Planificación del Proyecto, que será nuestra guía a seguir para poder llevar a cabo la fase de Ejecución.
  • Ejecución
Éste es el punto es donde comenzamos a ejecutar el proyecto según lo planificado. Aquí es importante ser flexible y no seguir con rigidez el plan previsto, además de contemplar la identificación de nuevos problemas que pudieran no haberse captado durante las etapas previas.
  • Evaluación
Una vez ejecutado el proyecto, no vale simplemente con recoger los bártulos e irse a otra parte.. Es muy importante realizar un seguimiento posterior, ver si realmente se consiguen los objetivos iniciales de mejorar las condiciones de vida de los beneficiarios. Y aprender de los errores cometidos para mejorar en los próximos proyectos..

Pese a que se plantean como 4 fases diferenciadas, el formato de seguimiento de éstas no es estrictamente lineal sino que sería más bien circular teniendo en cuenta que cuando se detecta un nuevo problema en alguna fase podemos tener que repensar todas las fases anteriores.

3.Centrándonos

En ésta entrada nos vamos a centrar en la fase de Identificación y de Diseño, que son muy importantes pues serán la base de nuestro Proyecto. Si fallamos aquí… es bastante probable que nuestro proyecto se vaya al garete. Desgraciadamente el 30% de los proyectos de cooperación fracasan y el motivo suele ser que fallan en estas fases.

¿Qué es el Enfoque del Marco Lógico?
Para diseñar nuestro proyecto vamos a utilizar la principal herramienta de gestión de proyectos de Desarrollo: El Enfoque del Marco Lógico, convertido ya en método universal de la mayor parte de las agencias de cooperación internacional y que demuestra especial utilidad en las tareas de identificación y gestión de proyectos. De hecho, pese a que ha quedado ya institucionalizada como procedimiento indispensable para solicitar financiación de proyectos de cooperación al desarrollo a agencias y organismos donantes, la herramienta pudiera servir para la identificación y gestión de proyectos de cualquier tipo, no sólo de cooperación al desarrollo.

Características del EML
  • Nos permite tomar decisiones mejores y más razonadas.
  • Es un método participativo.. que no se puede llevar a cabo sin tener en cuenta a los beneficiarios. Hay que insistir en que los proyectos no se preparan en un despacho ni de manera individual. Los proyectos se identifican y diseñan en equipo y en el seno de esos equipos deben estar representados los beneficiarios, siempre que eso sea posible. Si olvidamos esa perspectiva, la mayoría de los pasos que vamos a comentar habrán perdido su sentido.
Un problema que presenta el EML es que luego no se lleve a la práctica, uno puede hacer un análisis teórico perfecto e impecable… pero luego en la práctica dejar de hacer muchas de las cosas planificadas y ésto es como un puente al que no se le puede andar quitando pilares así como así, pues se te viene abajo.

Por ejemplo, imaginad un proyecto en el que se mueven todos los medios para instalar unos equipos de radio que saquen de su aislamiento a unas comunidades. En ocasiones, por falta de tiempo los cooperantes instalan los equipos y luego apenas enseñan a los pobladores a utilizarlos. Si el EML se hace correctamente, esa capacitación forma parte del proyecto, es más, quizás la parte más vital para el funcionamiento correcto del mismo y para su perdurabilidad en el tiempo. Ya sabéis, si no cumples con una determinada etapa, sea cual sea, la estás cagando.

Estructura del EML
El EML consta de 5 pasos:
  • Análisis de la participación: Averiguar todos los actores, las relaciones entre ellos y determinar a quién va destinado el proyecto.
  • Análisis de los problemas: ¿qué problemas tienen los actores?
  • Análisis de los objetivos: ¿como se podrían solucionar cada uno de esos problemas?
  • Análisis de las alternativas: entre las soluciones anteriores, aquí elegiremos la que llevaremos a cabo.
  • Matriz de planificación del proyecto: tabla esquemática que resume la identificación del proyecto y facilita enormemente la gestión del mismo.

  • 4. Participación.

    Antes de nada, es necesario conocer la realidad social de la zona donde pretendemos actuar. Y para ello no hace falta ser sociólogo, basta con hablar con la gente y sobre todo.. escucharla. Así podremos descubrir qué inquietudes y problemas tienen y qué grupos están afectados por ellos.
    Con el análisis de la participación se pretenden básicamente dos cosas. En primer lugar, se trata de tener una visión, lo más precisa posible, de la realidad social sobre la que el futuro proyecto pretende incidir. Muchas intervenciones de desarrollo fracasan, precisamente, por haber efectuado un diagnóstico excesivamente superficial del contexto en el que deben insertarse.
    Un proyecto comienza siempre determinando quienes son los colectivos cuya situación se quiere mejorar.
    Es preciso mostrar qué problemas afectan a qué personas, cuáles son las relaciones entre los diferentes grupos que conforman una realidad, entre esos grupos y los problemas identificados y entre los propios problemas que se han detectado, para finalmente alcanzar los criterios que establecen las prioridades para elegir la alternativa considerada más deseable.

    5. Identificación de los actores y árbol de problemas

    Una vez recogidos todos los datos del terreno llega la hora de poner un poco de orden y de analizar la situación que nos hemos encontrado en clave de problemas. Al fin y al cabo el análisis del proyecto depende de varios factores clave:
  • La calidad de la información disponible.
  • La capacidad del equipo del proyecto.
  • El nivel de participación de la población beneficiaria y contrapartes locales en el análisis del problema.
  • La experiencia previa del equipo.

  • Salvo la experiencia previa, el resto de factores dependen de la etapa que acabamos de desarrollar y de cuánto impliquemos a las partes locales en el análisis y procesado de la información que hagamos ahora.

    Comencemos con la identificación de los actores, que van a poder ser de los siguientes tipos:
  • Gobierno (regional, local, nacional, extranjero, etc).
  • Población local (familias, poblaciones, comités, etc).
  • Sector privado (cooperativas, PYMEs, grandes empresas, etc).
  • Organizaciones no gubernamentales (asociaciones, colectivos, del lugar, del norte, etc).
  • Ecosistemas (fauna, flora, lugares protegidos, entornos de vital importancia para supervivencia de poblaciones, etc).

  • Si se han identificado correctamente los actores y extraído adecuadamente la información necesaria debiéramos ser capaces de construir la "tabla de análisis de actores", que debiera tener al menos la siguiente profundidad:

    Actores Características Problema Interés Potencial Inter-relación
    Actor 1




    Actor 2




    Actor 3




    Actor 4




    ...






    Una vez tenemos ya una buena tabla con todos los actores implicados en nuestro proyecto, sus relaciones, problemas y demás vicisitudes, llegó la hora de construir nuestro árbol de problemas que nos demuestre de forma causal cuáles son los más importantes que han de atajarse para producir un efecto dominó sobre sus derivados. El resultado ha de ser algo parecido a ésto:



    Hemos de tratar de ser claros a la hora de definir los problemas, no situarlos por orden de importancia, sino de causalidad y consecuencia, y tratar de situar problemas actuales, no futuros.

    Por último identificamos el que será el problema principal, que trataremos de atajar con el proyecto que estamos desarrollando.

    6.Árbol de soluciones (o árbol de objetivos)

    Bien. Analicemos nuestra situación actual. Ya tenemos los problemas analizados junto con los actores que intervienen y además clasificados según unos sean causas o efectos de otros e identificado el problema principal, foco de todos nuestros odios y rabias. Ha llegado la hora pues de transformar lo negativo en positivo, los problemas en soluciones, o más bien, en objetivos a cumplir. Le damos la vuelta a cada problema y lo convertimos en su objetivo/solución. Ejemplos:

    Problema -> La población tiene un problema serio de desnutrición.
    Objetivo/Solución -> La población está correctamente nutrida.

    Problema -> Existe una sequía que está devastando la agricultura.
    Objetivo/Solución -> No existe sequía alguna.

    Como vemos al hacer la transformación nos surgirán algunas soluciones válidas como la primera, que puede ser alcanzable por medios a nuestra disposición, pero otras irreales, o cuanto menos, que se quedan en buenos deseos, como el caso del segundo problema donde nosotros de ninguna manera podemos intervenir para una solución inmediata (si, ya sé que podemos influir en el calentamiento global y sus efectos, pero ya me entendéis lo que quiero decir).

    Además, cuando el objetivo/solución sea suficientemente genérico podremos concretarlo dividiéndolo en objetivo principal y objetivo específico, siendo el principal el objetivo último que mueve el proyecto y el específico lo que objetivamente vamos a conseguir si realizamos el proyecto. Un ejemplo:

    Problema -> La población tiene un problema serio de desnutrición.
    Objetivo/solución -> La población está correctamente nutrida.
    Objetivo principal -> La red de cultivos y distribución de alimentos está en buen estado.
    Objetivo específico -> La producción agrícola es dedicada al consumo interno.
    Objetivo específico -> La distribución de alimentos en mercados locales es proporcional a la población total a quien distribuye y su nivel de necesidad.
    Objetivo específico -> Las variedades de alimentos cultivadas/criadas son suficientes para una correcta nutrición.

    Una vez transformados los problemas en soluciones/objetivos, toca transformar el árbol de problemas en un árbol de soluciones/objetivos. Si el primero mostraba causa/efecto de los problemas, el segundo muestra medios/fines de las soluciones/objetivos. Un resultado pudiera ser éste algo como...




    Lo siguiente será hacer limpieza eliminando las soluciones no válidas que nos hubieran surgido, volviendo a formular las que no quedasen bien expresadas y añadiendo los objetivos específicos que hubiésemos visto necesarios.

    Ya tenemos los objetivos principales y específicos seleccionados y en nuestro árbol de objetivos ha quedado de tal manera que algunos objetivos quedan al mismo nivel determinando estrategias a seguir diferentes posibles. ¿Qué hacemos? seleccionar cuál será la nuestra en función de su viabilidad contando para ello con todas las variables que nos sean necesarias. Descartaremos el resto.


    Para esta selección nos podemos apoyar en una tabla como la que sigue:

    Alternativas\Criterios Coste Posibilidad de éxito Beneficio/coste Horizonte temporal Dependencia Riesgo social
    Alternativa 1





    Alternativa 2





    Alternativa 3





    ...






    Esta tabla se suele rellenar con valores como Baja/Media-baja/Media/Media-alta/Alta. Una fórmula para obtener la alternativa más deseable es luego dar valores numéricos a los anteriores (por ejemplo: Baja=0; Media-baja=1; Media=2; Media-alta=3; Alta=4) y luego sumar cada fila para obtener un resultado mayor en la alternativa ideal para nuestro proyecto. Es evidente que esto supondría tratar con el mismo peso cada una de las columnas, y puede que para nosotros el Coste tenga mayor o menor valor que Riesgo Social, por ejemplo, por lo que otra fórmula que se acostumbra a seguir es la de establecer unos pesos numéricos en el intervalo [0,1] para cada columna siendo el número mayor cuanto más peso tenga para nosotros dicha columna. Este peso será el coeficiente por el que multiplicaremos el valor numérico resultante de la substitución de los valores cualitativos que pusimos a cada columna.

    Como ejemplo más gráfico, imaginemos que una alternativa nos ha salido con los siguientes valores:
    Coste: Alto -> 0
    Posibilidad de éxito: Media -> 2
    Relación Beneficio/coste: Alta -> 4
    Horizonte temporal que cubrirá el proyecto: Medio -> 2
    Dependencia del proyecto de factores externos: Media -> 2
    Nivel de Riesgos Sociales que se puedan generar a partir del proyecto: Bajo -> 4


    TOTAL = 0.7*0 + 1*2 + 0.8*4 + 0.5*2 + 1*2 + 1*4 = 11.6
    Nótese que las columnas de coste, dependencia y riesgo social se sustituirán por sus valores numéricos de forma inversa a las demás puesto que pretendemos que lo más positivo para el proyecto obtenga una mayor puntuación y lo más negativo puntuación menor.
    Nótese también que los valores de los pesos que hemos establecido dan mayor importancia a los valores de "Posibilidad de éxito", "Riesgo Social" y "Dependencia" frente a "Coste", "Beneficio/Coste" y "Horizonte Temporal".

    Si ahora nos topásemos con otra alternativa con mayor puntuación sería ésta la que tendríamos que escoger, de lo contrario estaríamos teóricamente frente a la mejor de las alternativas para nuestro proyecto.

    7. Matriz de planificación del proyecto

    La matriz de planificación del proyecto constituye, por su parte, la estructura del diseño, el armazón sobre el que se construye el documento de formulación. Si bien la matriz es la base el diseño pero no es todo el diseño. Para que éste pueda considerarse completado es preciso realizar la programación de las actividades y los recursos (calendarios, presupuestos y organización del personal adscrito a la ejecución de todas esas actividades), completar los diseños técnicos siempre que éstos sean necesarios y efectuar una valoración de las posibilidades de viabilidad de la futura intervención.
    La matriz se rellena de la siguiente manera:


    Esta matriz puede interpretarse usando 2 lógicas distintas, la vertical y la horizontal.
  • Lógica vertical o lógica de intervención


  • Ver la matriz desde esta óptica vertical te revela una secuencia lógica que ha de ocurrir en el proyecto:
    1. Si los insumos están disponibles, las actividades se llevarán a cabo.
    2. Si las actividades se llevan a cabo, se obtendrán los resultados.
    3. Si se obtienen los resultados, se alcanzará el objetivo específico.
    4. A largo plazo ésto contribuirá a la consecución del objetivo global.
    IMPORTANTE: Sólo debe haber un objetivo específico en el proyecto.

    • Lógica horizontal


    Ver la matriz desde esta óptica horizontal revela también otra secuencia lógica del proyecto:
    1. Si los factores externos se cumplen podremos obtener datos de las fuentes de verificación.
    2. Con estos datos de las fuentes contrastaremos cada indicador.
    3. Si contrastamos positivamente cada indicador diremos que se ha cumplido cada uno de los objetivos, resultados o que se han realizado las actividades en cada nivel.

    Aclaración de la columna de "Factores Externos" (o hipótesis):
    Los factores externos han de ser problemas que puedan preveerse y que obstaculicen de manera decisiva cada uno de los objetivos. En definitiva, hipótesis.
    Se derivan del árbol de objetivos, deben enunciar en positivo, aplican a todos los elementos importantes del proyecto y se valoran y analizan de acuerdo a su importancia y probabilidad.

    Aclaración de la columna de "Indicadores Objetivamente Verificables":
    Los indicadores fijan el nivel de efectividad necesaria para el proyecto. Son aquéllos cuya medida da igual resultado independientemente de quien la realice. Son importantes en el apartado de evaluación del proyecto.
    Un indicador debe ser:
    • Específico: importante usar términos precisos.
    • Independiente: no deben depender entre sí indicadores de diferentes objetivos para que reflejen objetivamente la consecución de un objetivo.
    • Fáctico: no debe reflejar impresiones subjetivas sino hechos.
    • Reflejo de datos obtenibles: los datos deben de estar disponibles o de forma inmediata o mediante un esfuerzo extra razonable.
    • Medible.

    Aclaración de la columna de "Fuentes de Verificación":
    Para obtenerlas nos pueden ayudar las siguientes preguntas.
    ¿Cómo ha de ser la información que se requiere?: p.ej. Registros administrativos, estadísticas nacionales, grupos de trabajo, observación directa...
    ¿Cual es la fuente más apropiada para proveer la información?, ¿quién debe intervenir?, ¿es fiable la fuente?.
    ¿Quién recoge la información? (supervisores, equipos independientes...)
    ¿Cuándo y con qué frecuencia se debe recoger, analizar y sistematizar la información?
    ¿Cuáles son los formatos en los que se recoge la información?

    Construcción de la matriz

    Para construir la matriz de planificación del proyecto ya tenemos todas las herramientas, luego lo que tendremos que hacer será seguir un orden lógico para que no se nos escape nada. Un orden que nos puede ayudar podría ser éste:
    PASO I - OBJETIVOS - rellenamos la columna de objetivos excepto las actividades
    PASO II - ACTIVIDADES - rellenamos las actividades teniendo en cuenta los objetivos rellenados
    PASO III - INSUMOS, PRECONDICIONES E HIPÓTESIS - nos encargamos de los insumos necesarios para que se puedan realizar las tareas, las precondiciones para poder obtener los insumos y realizar las tareas y las hipótesis o factores externos que condicionan el proyecto
    PASO IV - INDICADORES Y FUENTES DE VERIFICACIÓN - rellenamos los huecos reservados para cada uno de los indicadores que nos objetivizan el éxito del proyecto y las fuentes de donde obtendremos los datos para compararlos con esos indicadores

    CONCLUSIONES Y DELIRIOS:
    Espero que el objetivo de esta entrada, que era dar a conocer la herramienta del EML de forma superficial a quien la lea se haya cumplido y quien encuentre ésto como recurso de información quede picado por el gusanillo del desarrollo de proyectos de cooperación, busque más información y termine participando en alguno.
    Toda la información procede del curso de "Introducción a la Gestión de Proyectos de Cooperación al Desarrollo de Base Tecnológica" que imparte maravillosamente la UOC, de la asignatura "Introducción a la Cooperación al Desarrollo" que se imparte en la Universidad Carlos III de Madrid y de otras muchas fuentes de información extraídas por internet.
    Además esta entrada es una adaptación de la sección teórica de una dinámica de gestión de proyectos de cooperación que desarrollamos entre mi compañero Juan José del Valle y yo durante las III y IV ediciones de las Jornadas Solidarias que las asociaciones Ingeniería Sin Fronteras y Asamblea Social Universitaria realizan en la Universidad Carlos III de Madrid, y por tanto somos coautores los dos.


    + info
    http://www.isf.es/menu_publicaciones/pub_libros.php?$sesion_idioma=1&$menu=3&identifica=libros&nombrexml=113
    http://bicho.uc3m.es/gta/introduccion_mas_links.htm
    http://www.preval.org/documentos/00423.pdf

    martes, marzo 13, 2007

    La comunicación en los Proyectos

    Últimamente he leído varios artículos sobre metodologías de trabajo en proyectos de desarrollo software o de ingeniería en general. Existen dos grandes familias de alternativas: las metodologías tradicionales y las metodologías ágiles. Unas se caracterizan por basarse en procesos de desarrollo (creación de documentación, ciclos de prueba, etc.) y las otras por el desarrollo rápido y de forma adaptable sin preocuparse en principio por aspectos como el costo o la mantenibilidad.

    ¿Por qué nec
    esitamos una metodología de trabajo?

    Usamos metodologías de trabajo porque tenemos miedo. Miedo a a desarrollar un mal producto de mala calidad, miedo a los retrasos...
    dice Robert Martin

    Normalmente, cada empresa tiene su propia metodología de trabajo basada en alguna más estandarizada, intentando adaptarla al funcionamiento interno. Por lo tanto, existen múltiples variantes y tipos de formas de trabajo. Sin embargo, existe una cosa común a todas que es la mayor causa de fracaso en los proyectos:
    la comunicación.

    Comunicación:
    ¿Por qué es común la comunicación en todas las metodologías de trabajo? Obviamente porque los proyectos
    se desarrollan por personas independientes, cada una con su perfil y sus cualidades. Independientemente de cómo trabajemos (tradicionales, XP, FDD,...) el equipo de trabajo estará compuesto por múltiples personas que trabajarán en partes del proyecto, tendremos uno o varios clientes, jefes de proyecto, entendidos de la materia, jefes técnicos, desarrolladores, testeadores, etc. y todos deben ir en la misma dirección.

    De todas formas, hablando se entiende la gente, dicen. Sí, pero siempre que hablen el mismo idioma. El problema reside en que lo que el cliente necesita debe ser implementado por el desarrollador, pero en medio de ellos existe mucha gente por la que el mensaje se cambia y al final el cliente no obtiene lo que necesita. Pero vamos a ir paso a paso en la cadena de comunicación:

    La cadena de comunicación:
    Lo normal que tengamos en un proyecto son los siguientes perfiles:
    • Cliente: es el destinatario final del producto, normalmente sabe lo que quiere, o tiene una idea aproximada, pero no suele saber comunicarlo en lenguaje técnico y hay que interpretarlo.
    • Jefe de Proyecto: es el encargado de hablar con el cliente, interpretar lo que quiere, evaluar lo que conviene hacer y lo que no (a su libre albedrío normalmente) y comunicarle lo que se va a hacer al Jefe Técnico.
    • Jefe Técnico: es el que debe traducir el lenguaje no técnico con el que le habla el Jefe de Proyecto de lo que le ha contado el Cliente al lenguaje técnico que entienden los desarrolladores o técnicos. En medio también mete una criba de lo que se debe hacer por "dificultades técnicas".
    • Desarrollador: hace lo que le ha dicho el Jefe Técnico y se lleva los marrones cuando el cliente ve que lo que le han hecho no es lo que él quería.
    Consecuencias de la mala comunicación:
    Aparte del posible fracaso de un proyecto, se deriva una consecuencia, si cabe peor: la desmotivación del equipo de trabajo. Un jefe sin el apoyo de los empleados no tiene poder para sacar ningún trabajo, por lo que un equipo de trabajo desmotivado que no trabajo con ilusión es la perdición de un responsable y su ruina. En cambio, un equipo de trabajo motivado, ilusionado con sus trabajo y partícipe del diseño y desarrollo de las soluciones podrá superar las expectativas del cliente y obtener un producto de calidad. Se mejorará la comunicación entre las diferentes partes (al haber mayor confianza) y se aportarán más ideas (enriqueciendo el producto final).

    Espero que os haya gustado este artículo y que se reflexione sobre él para intentar mejorar la comunicación y la confianza dentro de los proyectos.

    lunes, marzo 12, 2007

    Tiras de Dilbert


    Se ha incluido una nueva sección en el blog para poner cada semana una tira cómica de la serie Dilbert. Todos los lunes actualizaremos la tira, la cual creo que refleja de una forma muy sarcástica el trabajo dentro de una empresa (siendo algunas situaciones bastante reales...).

    Espero que os guste esta nueva sección.

    sábado, marzo 03, 2007

    La paradoja del software "libre"

    Este artículo se sale un poco de la temática de este blog puesto que no es técnico sino más bien una reflexión propia que me hago.

    Antes de nada, me gustaría aclarar que en este artículo me refiero a una parte del movimiento software libre y no a todo. Hay muchas personas que ponen su esfuerzo y trabajo a nuestro alcance de una forma altruista y desinteresada intentando que el resultado sea útil a toda la sociedad, independientemente de su nivel de conocimiento tecnológico y de su nivel salarial. A todas esas personas, gracias.

    Sin embargo, hay dos actitudes dentro del software libre que desvirtúan ese movimiento: aquellos que intentan que se convierta en propiedad o que esté bajo el mandato de una élite exclusiva de personas que discriminan cualquier iniciativa que no cumpla con sus reglas y aquellos que se aprovechan del movimiento para obtener beneficios económicos (no tengo nada en contra de aquellos que sin tapujos y con fines económicos distribuyen versiones de demo, prueba o sucedáneos). Sobre ellos va este artículo

    Empecemos

    Desde hace tiempo, vengo dándole vueltas a la expresión “software libre”, término asociado a múltiples programas, aplicaciones, sistemas operativos y demás que se distribuyen de manera libre y que son estandarte de un movimiento social a nivel tecnológico. Ejemplos de software libre serían, por ejemplo, Ubuntu como sistema operativo, Apache como servidor web, JBoss como servidor de aplicaciones, Java como lenguaje de programación (igual que .net de Microsoft), OpenOffice como entorno ofimático y múltiples aplicaciones más desarrolladas en Java o cualquier otra cosa que no sea Microsoft y sobre Linux (los que desarrollan en Java sobre Windows son menos “libres”).

    Sin embargo, después de probar Ubuntu y Kubuntu (de Fedora no comento), haber montado un par de servidores Apache, unos cuantos JBoss, viendo como un compañero sudaba tinta china para montar un servidor Nagios, me di cuenta que el software libre es libre sólo para unos cuantos, para aquellos que saben de informática y que tienen tiempo de enfrascarse en foros, chats, blogs y demás utilidades de Internet. El software libre no está orientado para el usuario real de a pie para el que el ordenador no es un fin sino una herramienta. Pero, vayamos paso a paso y explicando:

    Ubuntu (por poner un ejemplo)

    Una persona normal con los conocimientos básicos de informática, es decir, encender, apagar el ordenador, ver el correo y navegar por Internet, decide cambiarse a Ubuntu porque le han comentado que está muy bien y que es gratuito. Esta persona se descarga la distribución del sitio web de Ubuntu, la monta en un CD y lo arranca. Hasta aquí todo muy bien, la instalación es muy fácil con unas instrucciones muy bien puestas. Una vez finalizada la instalación, arranca el ordenador y lo primero que se encuentra (si sabe…) es que tiene que actualizar los repositorios y modificarlos para acceder a los que de verdad tienen las aplicaciones. Empieza a entrar en foros (si sabe…) y empieza a leer que tiene que entrar en no se qué directorio, utilizar algo llamado vi y teclear una serie de instrucciones en la pantalla desde algo que se llama “shell” (qué será eso). A medio camino se le queda colgado el OpenOffice (muy común) y el ordenador se queda tostado (no sé como no sabría entrar en el “shell” y hacer un “kill” del proceso del OpenOffice, hay que ver). Finalmente, nuestro usuario desesperado desinstala el Ubuntu y sigue con su Windows que por lo menos todo viene mascado y sale en ventanas.

    El Círculo Interno de los Ficheros

    Tengo la certeza de que para que un software sea “libre” debe de tener un montón de ficheros de configuración, de definición, de variables, en el path de un sitio, en el path de otro, y por supuesto, ninguna ventana de administración (y ninguna ayuda). Yo creo que es porque en inglés ventana se dice Windows y a los del software libre les da yuyu. Por otro lado, el mantener los ficheros y no hacer aplicaciones orientadas al usuario final es porque debe existir un Consejo de malvados o Circulo Interno de los Ficheros que otorgan el título de software libre (o software que mola) que realmente no quieren que el usuario normal (es decir, el usuario no gurú ni friky de la informática ni programador de algo) tenga el conocimiento total, siempre se guardan esa sabiduría de cómo configurar una aplicación (porque es software libre).

    La hipocresía del software social

    Como todo en esta vida, el software libre no deja de ser una tapadera de una serie de personas que tienen fines lucrativos. Esta serie de malvados no quieren que los mortales sepan utilizar al 100% sus herramientas porque ofrecen sus servicios (cobrando por supuesto) para enseñar a utilizarlas. Para conseguir esto se hace lo siguiente:

    1. Hágase una herramienta en Java. Por qué en Java? Porque funciona en Linux y en Windows (agggg he dicho la palabra prohibida) No mola lo mismo que sólo funcione en Linux que lo utilizan muy pocos y no tienen dinero, tiene que funcionar también en Windows (agggg, otra vez…)
    2. La herramienta debe de tener un montón de ficheros de configuración que solamente tú sabes manejar. Por supuesto el código no debe estar comentado para que nadie te pille por donde va el tema.
    3. Habla con un par de gurús de los foros para que digan que tu aplicación mola y que es muy libre y que tú vas contra sistema.
    4. Deja unos meses que la gente utilice tu herramienta gratis dándoles asesoramiento y respondiendo a sus dudas.
    5. Al pasar los meses, saca una versión Lite (que no vale un pimiento), saca una versión Professional (por la que cobras un dinerillo para sustentar la causa, siempre gusta) y empieza a cobrar por servicios y a cobrar por las respuestas.
    6. Ya tienes montado tu negocio de software libre.

    Fin del Discurso

    El software libre es libre hasta que se mete el dinero por medio y pienso que el dinero lleva metido mucho tiempo provocando que los intereses de unos pocos manejen a muchos. Pero en fin, viva Microsoft y abajo el monopolio…. digo…viva Linux y arriba el monopolio…. en fin, ya no se lo que me digo.