Algunos procedimientos para calcular la fecha de llegada a puerto:

1.- Comparar los días transcurridos con los planificados.  (Método del directivo)

Si el viaje tiene una duración prevista de 30 días y llevamos 20 de navegación, se puede responder que faltan 10 días.

2.- Comparar las horas de trabajo realizadas con las planificadas.  (Método del consultor)

No estaría de más comprobar que los motores no están parados, y trabajan al ritmo previsto usando una métrica del tipo: ¿Cuantos litros de combustible habíamos previsto gastar?, ¿Cuántos hemos gastado?.

Una de las alertas de búsqueda sobre metodologías que suelo revisar ha tropezado con este corto mudo en el que unos chicos portugueses describen la  metodología empleada por su empresa para el desarrollo de de soluciones a medida:

• Metodologia para o Desenvolvimento de Soluçoes à medida .

Allá por 1980, el profesor de programación (COBOL) siempre que nos veía en la sala de prácticas con los terminales de aquellos equipos "Altos Europa"   nos repetía la misma cantinela:
"Cuanto antes empiecen a codificar, más tarde terminarán. ¿Ya han hecho un análisis funcional completo?. ¿Tienen el análisis orgánico?. Tengan claros los requisitos y diséñenlo bien, que si no todo será probar y cambiar.

Le fascinaba la forma de trabajar de americanos, alemanes, ingleses... Decía: "los latinos ¡siempre igual!, casi sin tener claro lo que vamos a hacer, nos ponemos ya a trabajar.  ¡Hala! empezamos y luego todo es hacer y rehacer...."

Tenía muy claro que la cultura anglo-sajona seguía el planteamiento correcto:  la planificación detallada como método para consegur que la ejecución fuera tal y como se había previsto, y se pudieran hacer las cosas bien(?) y a la primera. Mientras que en la nuestra, con eso de empezar con una idea general de lo que queremos, e ir descubriendo más por el camino, ni se puede planificar ni "na".

Y ahora el hallazgo anglo-sajón es la agilidad : Empezar a trabajar pronto, con una visión general e ir construyendo de forma iterativa, revisando y cambiando... Curioso.

Las causas de fracasos en proyectos de software no está sólo en las empresas que los desarrollan. También hay que buscarlos en los clientes (v. Si nos han vendido una moto nos van a dar una moto ).

SEI acaba de publicar "A Guidebook for Acquirers": una guía para orientar a los clientes de empresas de software que trabajan con modelos de procesos CMMI, y ayudarles a comprender mejor los procesos de sus proveedores; cómo interpretarlos y dirigir la estrategia de compra.

Una guía para responsables de estrategia y planificación de la compra de sistemas de software, que explica:

Las críticas a la certificación ScrumMaster en el grupo Industrial XP son ahora un choteo: La creación de la nueva certificación Agile Software Specialist. Sin experiencia, sin examen, sin entrevistas, sólo pidiéndolo en "Agile Certification Now " puedes conseguir el título de Certified ASS Profesional

• Agile Certification Now
  

¿Como enseñarle a sobrevivir a un robot en una isla desierta?. Pues programándolo.

El vicepresidente ejecutivo de Microsoft Research, Rick Rashid, afirmó en TechFest 2007 que hay una creciente y cada vez más grave crisis en el área de formación de ciencias computacionales, que cada vez es menor el interés y peor la calidad en esta formación. "Nuestro objetivo es detener el problema mostrando a los niños la magia de la programación de software, que se interesen en la programación y que no se sientan incómodos frente a los retos de la ciencia computacional".

Para ello han desarrollado un juego de Xbox: Boku, robot virtual que los niños deben programar para garantizar su supervivencia en una isla desierta. Una manera divertida de enseñar a los niños habilidades de programación básicas.

• Vídeo en NechFest 07

El mes pasado José Manuel impartió en la Universidad Pontificia de Salamanca un curso de programación de videojuegos para móviles, que arrancó con una presentación de las metodologías ágiles Scrum y XP.
JM trabaja como ingeniero de software en unkasoft , empresa que emplea ambas metodologías, y tras el curso comenta en su blog :

Es divertido ver la cara de poker que pone alguien que acaba de estudiar "Ingeniería de Software II", cuando escuchan que las metodologías ágiles echan por tierra todas esas viejas ideas...

Pero recordad lo más importante: no os dejéis engañar, ni por los "clásicos", ni por los "ágiles". Cada proyecto debe buscar su propio equilibrio entre metodologías ágiles y clásicas (o formales). Habrá proyectos exitosos ágiles, y proyectos formales igual de exitosos, y eso no significa que unos sean unos inconscientes y otros unos carcas.

Esta es la presentación a la que desde Navegapolis contribuimos con el material que pudimos facilitarle.

Al menos eso es lo que afirma Gegg Pollack , fundador del grupo de usuarios de Ruby de Orlando en la charla que dio el pasado día 15.

Afirma que él odia el desarrollo predictivo, con ciclo de vida secuencial y requisitos cerrados al comienzo del proyecto. Que Ruby On Rails es una plataforma pefecta para proyectos web con ciclos de construcción ágiles (desarrollo iterativo e incremental), que es libre y que resulta muy cómoda para los programadores.

• Vídeo de la charla: Why Ruby On Rails?

"Certified Scrum Master" suena bien. Suena muy bien. Tiene "Certified" y tiene "Master", y con estos términos tan pomposos, uno supone que se debe tratar de una certificación de conocimiento o  reconocimiento profesional; y este es un engaño que cada vez despista a más personas.

Decir que el emperador está desnudo quizá no es muy inteligente, porque uno no gana simpatías ni de los emperadores que han pagado un buen dinero por un traje inexistente, ni de los sastres que hacen tantos trajes y entregan tan poca tela; pero alabar el traje que no se termina de ver no es profesionalmente honesto.

En el área de descargas de Microsoft Research está disponible una revisión de Spec# para Visual Studio 2005. Según la página del proyecto, Spec# intenta ofrecer una forma de desarrollar y mantener software de alta calidad, con eficiencia de costes.

• Página de descarga .
• Página de información .

No sé (ni quiero saber ) si se trata de sitios con licencia para distribuir estos estándares, o de servidores que pagan canon a alguna gestora  SGAEEE o... pero en estas direcciones están disponibles algunos de los estándares de IEEE para Ingeniería del Software.

Sobre trac (herramienta open-source para gestión de proyectos) se han desarrollado en el último año una lista importante de plug-in's que se pueden ver en la home de tracHacks .
Actualizo en el artículo de Trac del año pasado la dirección de esta lista de ampliaciones que además de tener dos para Scrum, cuenta con un montón más que dan funcionalidades mejoradas de administración, gestión de tickets, cuentas de usuario, Wiki y le abren puertas de integración y compatibilidad con eclipse, excel, LDAP, Wiki - LaTeX, Wiki - PDF...

• Página del proyecto
• Home de tracHacks con la lista de ampliaciones disponibles
• Scrum iteration plannig plugin
  
• Plug-in Timing and Estimation (que incorpora Scrum Burndown)
• Artículo anterior de Trac en Navegapolis .

Que trata de las diferencias entre la gestión tradicional de proyectos (PMI, IPMA...)  y el desarrollo ágil (XP, Scrum...) desde el punto de vista del valor que obtiene el producto desarrollado con una y otra.

No sé si llamarlo screencast, pptcast, video...
Espero que resulte útil.

• Screencast: Desarrollo ágil y valor de producto .

Con SQL Designer se puede diseñar on-line la estructura de una base de datos y obtener el script para generar las tablas en PostgreSQL, MySQL, Oracle y MSSQL o para propel .

• SQL Designer

Es un gestor de proyectos y tareas, con control de tiempos, generador de informes, repositorio de ficheros, agenda, chat, notificaciones y RSS.

Desarrollado por afición y sin ánimo de lucro, según los autores, se puede usar gratuitamente y sin limitaciones como servicio hospedado, y posiblemente en un futuro esté también disponible como producto para descargar e instalar en un servidor propio.

• Clocking IT

El trabajo de consultoría diagnosticó, no sin dedicar muchas horas de trabajo, que la empresa de software no obtenía beneficios por la "falta de orientación a la rentabilidad de los trabajadores", especialmente de los programadores (?).

¡Claro! dijo el director general. Así como voy a dar resultados con los que poner contentos a los accionistas. ¡Los trabajadores pasan de la rentabilidad, y por su culpa lo tengo que pasar mal en los consejos de administración!

Siete de cada diez profesionales del sector tecnológico chino morirá de infarto o derrame cerebral por exceso de trabajo (karoshi); y hoy la media de vida de los intelectuales que trabajan en el parque de la ciencia de Zhongguancun es de 54 años. Según el artículo de Chinanews los profesionales más expuestos son los informáticos y los jóvenes ejecutivos (lógico que sean los jóvenes: parece ser que senior ya no les quedan). 

"Por no querer perder el tiempo
pierdes el tiempo y el alma.
Estás perdiendo la vida
de tanto querer ganarla."
José Bergamín

Códice Software quería combinar lo mejor de la tésis y de la antítesis, de los procesos y de la agilidad. Quería emplear Scrum en un marco de procesos "CMMI-evaluables", y como a estos chicos no se les pone nada por delante, son ya un referente: posiblemente la primera empresa española de pequeño tamaño que pasa una evaluación SCAMPI-A para un nivel 2 de CMMI, y sin duda la primera que lo hace combinándolo con las ventajas de agilidad e innovación de Scrum.

¡Enhorabuena!.

Hace ya algo más de un mes que recopilé las perlas de los dos últimos años de Navegápolis en el libro Mirando Alrededor. A los pocos días se puso entre los 10 libros en español más vendidos por Lulu. A la semana siguiente subió al 5º puesto, luego al 4º y veo ahora con asombro que esta semana ha sido el tercero.

Muchas gracias.  :-)

• Página de Mirando Alrededor en Lulu.

Algunas opiniones sobre el libro en otros webs (Mi agradecimiento a todas ellas, y disculpas por las omisiones que pueda cometer, porque incluyo aquellas de las que he tenido noticia).

• Miguel Matas: miguelmatas blog
• INTALBI SL
• Juanjo Navarro: Versión Cero
• Angel Agueda: Legnita Press
• Fernando Tricas: Reflexiones e irreflexiones
• Pedro Canut: blogespierre
  

Ahí van: un modelo de contrato, una plantilla para especificaciones de "requisitos del sistema" conforme al estándar IEEE 1362, y otra para "especificaciones de requisitos del software" con el modelo IEEE 830.

Puede resultar útil el "kit completo" una plantilla, o algún párrafo para "copia-pega" en otros contratos.

Afirmaciones de Alfonso Jiménez, socio director de PeopleMatters aparecida ayer en El País: 

"En los próximos años España se va a enfrentar a una escasez de profesionales tecnológicos cualificados, lo que va a obligar a reclutarlos a gran escala en el extranjero. "El número de ingenieros, ingenieros técnicos y programadores disponibles en el mercado laboral español va a ser inferior a la demanda de empleo, lo que acabará por crearnos un problema, puesto que hay países, como el Reino Unido o Israel, que ya disponen de programas ambiciosos de captación del talento en otras naciones, mientras que nosotros no tenemos experiencia en este terreno", explica.

En estos momentos ya hay pugna por los mejores talentos tecnológicos en todo el mundo desarrollado", alerta, añadiendo que España debe poner su foco en Latinoamérica para atraer profesionales de este sector que tengan alta capacitación, debido a la ventaja idiomática de la que disponen."

• Fuente en El País .

• Informe: European Innovation Scoreboard 2006
• Nota de prensa del informe  
• Resumen de la situación de los 27 estados europeos

Hay empresas con buena estrella que casi no tienen que gastar tiempo ni recursos para incorporar a nuevos programadores. Les basta con poner un anuncio y en un "plis-plas" ya han incorporado a la plantilla el nº de personas que necesitaban.

A otras, con peor suerte, les cuesta sudor dar con los técnicos que necesitan.

Se me ocurre proponer a consideración un indicador indirecto de la calidad técnica de una empresa de software: el coste de incorporación de personal.

Esta es la diferencia en la medición de tiempos entre la gestión de proyectos predictiva y la ágil. Justo ayer Richard, de Medellín, consultaba una duda frecuente al ver por primera vez la hoja de registro de un sprint: ¿Qué quieren decir las cifras de las horas trabajadas?. Hoy mismo Jeff Sutherland afirma en su blog que medir el tiempo trabajado es anti-scrum .

Estamos tan acostumbrados a medir las horas invertidas, que al ver la hoja de scrum creemos que es un registro de tiempo trabajado, cuando en realidad se trata de: tiempo que falta para terminar.

Los wikis son plataformas diseñadas para registrar y desarrollar conocimiento a partir de la colaboración asíncrona de los participantes. Interesante ¿verdad?. ¿Pueden servir también para gestionar la documentación,comunicación y participación de los personas de un proyecto?

Hace un año le dimos una vuelta a lo tentador de poner un wiki en un proyecto , y ahora en el número IEEE Software de este mes, el artículo "Wiki-Based Stakeholder Participation in Requirements Engineering " vuelve también la vista sobre los wikis, no para gestionar toda la documentación del proyecto, sino sólo la de los requisitos; y afirma que con algunas modificaciones un wiki puede cubrir las necesidades de dos áreas de la ingeniería de requisitos: especificación y gestión; y si nos ponemos, y según como sea el proyecto, también puede ser útil en la obtención (elicitación) y la validación y verificación.