a subversive act of playful cleverness

El pasado 24 de junio a invitación del Chapter Lima del PMI ofrecí una charla respecto a los aspectos o practicas de gestión de proyectos que las organizaciones o empresas pueden rescatar del ecosistema de software libre e incorporarlos en sus proyectos, en específico los que tienen que ver con desarrollo de software.

La objetivo principal, más allá de dar a conocer el software libre como tal, era establecer y reconocer prácticas de gestión y procesos que se puedan rescatar e incorporarlos en el desarrollo de proyectos de software de las organizaciones.

La charla inicio ofreciendo un panorama general de los actores que participan en el desarrollo de proyectos de software libre, como podemos ver en el gráfico adjunto, a saber:

• Proyectos en sí,
• Usuarios finales: que incluye a personas, empresas, sector público, organizaciones sin ánimo de lucro,
• Asociados de los proyectos, que son las organizaciones que apoyan a dichos proyectos, caso gobiernos o empresas,
• Partners de los proyectos, que pueden ser empresas u otros proyectos que ofrecen infraestructura base a los mismos,
• Comercializadores de los proyectos, que son las empresas que se dedican a dar un soporte y canal comercial a los productos desarrollados bajo este modelo de licenciamiento.

Luego de esto explique el esquema de trabajo y gestión de los proyectos de software libre, la forma de organización, su estructura jerarquica, infraestructura de trabajo, interacción entre el grupo humano, etc.

A partir de esta información rescatamos algunos valores o prácticas que las organizaciones que realizan desarrollo de software pueden incorporar para mejorar su gestión y procesos de desarrollo.

Entre estos podemos mencionar a los siguientes:

Confía en tu equipo

Esto se refiere básicamente a que la información acerca del desarrollo, incidencias y progreso del proyecto se maneje de manera abierta, sin ocultar información a nigún integrante del equipo. Todos deben estar claros de lo que ocurre. Un esquema bastante similar al definido por Debian y lo que conocemos como el rol de «dictador benevolente».

Revisa todo, prueba todo

Que trata de resumir la necesidad de incorporar y establecer prácticas de testing en el proceso de desarrollo y aprovechar las herramientas de software, o construir las necesarias, para establecer un ciclo constante de auditoria general y automatización del proceso de pruebas de software. De esta manera a medida que se va desarrollando el proyecto también se tiene a la par un proceso que puede garantizar la validación de su funcionalidad.

Todos los desarrolladores son iguales

Algo que no se refiere a las características personales o de formación, sino a la equidad y valoración de las ideas o aportes de los desarrolladores, sean los más experimentados en el equipo o novatos que se acaban de incorporar. Cualquiera de ellos debe ser escuchandos y sus aportes o ideas respecto al desarrollo o diseño de los proyectos se debe tener en cuenta de la misma manera.

Y finalmente, la premisa que no debemos olvidar:

La mejor manera de finalizar un proyecto de forma exitosa es hacerlo de la forma correcta

Que básicamente nos recuerda que aunque tengamos los procesos definidos, las herramientas necesarias y la infraestructura de soporte para el desarrollo de nuestros proyectos; si los primeros se ignoran y no se siguen desde el inicio del proyecto, por razones de tiempo, urgencia, etc; es mucho más probable que a medida que se desarrolle el proyecto ocurran problemas que si se empieza de la forma correcta.

Esto es lo que cuenta al final del día y puede ser el factor crítico que conduce a pérdidas de tiempo, dinero y time-to-market para una organización. Para que un proyecto sea exitoso se requiere la participación de todos los actores involucrados, que va desde la gerencia hasta el desarrollador. No se trata simplemente de dar indicaciones al programador y encerrarlo un número de días esperando que entregue un resultado maravilloso.

Fue interesante el aprovechar que me antecedio una charla sobre  SCRUM, para vincular muchas de estas practicas que tambien son promovidas por frameworks de desarrollo ágil como éste, que fue expuesto por Tobias Mayer de AgileThinking.net.

Es posible que existan otras prácticas que los proyectos de desarrollo de software en las empresas puedan incorporar, si has identificado o aplicado alguno ¡dejanos saber!.

Existe más información sobre el tema que he tomado como referencia para esta charla. A continuación pongo algunos enlaces de referencia:

• Sitio web del MIT que reune trabajos de post-grado sobre temas de software libre. http://opensource.mit.edu
• Articulo sobre el tema en OnLamp de O’reilly. http://www.onlamp.com/pub/a/onlamp/2006/02/27/what-corp-projects-learn-from-open-source.html
• Consultora Stellman Greene: http://www.stellman-greene.com
• Consultora Construx: http://www.construx.com

Hace unas semanas se ha publicado la actualización del Whitepaper «Software Development’s Classic Mistakes 2008» de la consultora Construx, que está disponible para descarga de manera gratuita.

Este trabajo de Steve McConnell, autor del libro «Rapid Development», recopila los errores más comunes en el proceso de desarrollo de software y tiene como objetivo el ofrecer un vistazo único a los factores de riesgo más comunes. Originalmente la lista se inició con 36 errores a partir de la publicación del libro en 1996, y a la fecha reune datos obtenidos del trabajo con más de 1000 clientes de Construx.

Entre las fuentes que han aportado para la elaboración de dicha actualización se encuentran Jefes o arquitectos de software (55%), gerentes (11%), Gerentes técnicos o con doble rol (6%), y técnicos (22%).

Entre los primeros 10 errores más frecuentes se identifico a los primeros 5 con el modo de «Casi siempre» y a los siguientes como «a menudo»:

1. Cronogramas demasiado optimistas
2. Expectativas irreales
3. Aseguramiento de calidad infimo
4. Oficinas ruidosas y hacinadas
5. Confusión de estimados con objetivos
6. Excesiva aplicación de multi-tarea
7. Pesadilla de características
8. Pensamiento iluso
9. Gestión de riesgo insuficiente
10. Omisión de tareas necesarias para estimados

Entre ellos se clasifico como de alto impacto con una criticidad de «Catastrófico» y «serio» en el siguiente orden.

1. Expectativas irreales (83%)
2. Personal inadecuado (78%)
3. Cronogramas demasiado optimistas (78%)
4. Pensamiento iluso (76%)
5. Aseguramiento de calidad infimo (72%)
6. Diseño inadecuado (72%)
7. Falta de auspicio del proyecto (71%)
8. Confusión de estimados con objetivos (71%)
9. Excesiva aplicación de multi-tarea (71%)
10. Falta de involucramiento del usuario (70%)

Es particularmente interesante observar que 35 de los 42 errores clásicos se clasificaron como de impacto catastrófico o serio por mas del 50% de participantes.

El paper ofrece además métrica de exposión al riesgo (RE) que mide la severidad y el impacto de forma aproximada, básicamente obtenida del producto de ambos criterios bajo la fórmula RE = severidad * impacto.

Una de las cosas que me llamo la atención fue el tema de «Whishful thinking» o pensamiento iluso, que ha sido calificado en la posición 4. A veces ocurre que en la gestión del proyecto se cierra totalmente en la idea de que va algo va a funcionar cuando no se tiene base concreta o razonable para pensar que así será. Costrux indica que esto puede llevar a grandes problemas si se da al inicio del proyecto, pero lo mas grave es que menoscaba el planeamiento adecuado y puede ser la raíz se otros problemas.

Como tantos de los temas en gestión de proyectos de diversa índole, este no deja de tener al factor humano como clave, fuera de buenas prácticas, métricas, procesos o metodologías, si el personal que lidera el proyecto se cierra bajo una visión irreal esta puede tener consecuencias serias para la organización.

El otro tema que me parece interesante es el multi-tarea excesivo. Generalmente se suele confundir al desarrollo de proyectos usando metodologías ágiles y etiquetarlos con cierta metodología, sin tomar en cuenta todos sus aspectos. El problema con el excesivo uso de multi-tarea es que, según los estudios, cada «switch» entre tareas puede tomar de 5 a 30 minutos de «para» de desarrollo mientras la persona cierra el flujo de trabajo de un proyecto y se inserta en otro.

Finalmente el tema del ambiente laboral resulta vital, ya que un entorno ruidoso o demasiado hacinado evita la concentración y el estado necesario que se requiere para trabajar y obtener altos niveles de productividad. Se ha determinado que los trabajadores que tienen oficinas silenciosas y privadas tienden a deempeñarse sinificativamente mejor que aquellos que ocupan cubículos o bahías ruidosas y demasiado hacinadas.

Recomiendo leer este trabajo si trabajas o te interesa el tema de desarrollo de software, en especial si estas a cargo de proyectos o su gestión.

La Universidad San Agustin de Arequipa acaba de anunciar la apertura del primer programa de doctorado en Ciencia de la Computación de nuestro país. Este programa, además de ser el primero en el país bajo estándares internacionales, es el único y el primero que cuenta con financiamiento para los estudiantes (por ahora los primeros puestos) y cuyo formato es de dedicación exclusiva, lo cual lo convierte en único  en nuestro país.

Es por esto, que este anuncio representa un importante momento para el desarrollo del área de computación en nuestro país, pues coloca nuestros programas en niveles y bajo reglas internacionales de estudios académicos.

Las felicitaciones a los amigos de Arequipa, entre ellos César Beltran, actual presidente de la SPC, y nuestro amigo Ernesto Cuadros que ha sostenido una persistente labor por empujar el tema, cuyos frutos ya se están manifestando.

Transcribo el anuncio del presidente de la SPC y profesor de la cátedra.

BECAS PARA DOCTORADO EN CIENCIA DE LA COMPUTACIÓN – UNSA
La Universidad Nacional de San Agustín - Arequipa (UNSA) convoca al proceso de admisión 2008 para el programa de Doctorado en Ciencia de la Computación.
Este programa se constituye en el único del país que otorga becas para alumnos con dedicación integral a los estudios. Las becas serán proporcionadas por el CONCYTEC a los primeros puestos del proceso de admisión. La beca asciende a S/.48 000.00 (Cuarenta y ocho mil Nuevos Soles)
durante tres años, tiempo en el que el estudiante del programa debe presentar su tesis doctoral. Cabe destacar que la UNSA participó en el Concurso Nacional de Cátedra CONCYTEC 2007, habiéndose adjudicado la Cátedra en Tecnologías de la Información y Comunicación. Gracias a ello nuestro
programa se constituye en el primer doctorado con las siguientes características:

a) Contará con alumnos becados dedicados integralmente al desarrollo de su proyecto de investigación doctoral,

b) Otorga tutoría para el desarrollo del trabajo doctoral con el apoyo de docentes de planta y docentes invitados por el programa, con el fin que el alumno esté apto para sustentar la tesis doctoral, al culminar los tres años de estudio,

c) Otorga la posibilidad de pasantias internacionales, para desarrollar parte de los estudios en alguna universidad del extranjero (prioritariamente Francia).

d) Estimula la participación de los alumnos mediante la presentación de trabajos en eventos arbitrados y revistas indexadas.

Las líneas de investigación que comprende el programa son:

1. Ingeniería de Software
2. Sistemas Inteligentes.
3. Optimización y Computación Aplicada.
4. Bioinformática
5. Intermedia
6. Redes y Sistemas Distribuidos.
7. Computación Gráfica y Procesamiento de Imágenes.

Para la convocatoria 2008 se tienen previstas dos líneas de investigación:

- Sistemas Inteligentes: Sistemas Conexionistas, Reconocimiento de Patrones, Computación Bioinspirada (evolutiva), Inteligencia Artificial.

- Ingeniería de Software: Proceso de Ingeniería de Software, Calidad de Software, Ambientes de Desarrollo de Software, Métodos Formales.

Cronograma:

· Informes e Inscripciones : Hasta el 27 de Mayo
· Entrevista Personal: 28, 29 y 30 de Mayo
· Examen Escrito: 31 de Mayo
· Matrícula: 2 Junio
· Inicio de Clases: 2 de Junio