Javier Garzás

INTECO (Instituto Nacional de Tecnologías de la Comunicación) ha publicado dos guías sobre la serie ISO/IEC 20000. La serie ISO/IEC 20000 son normas cuyo ámbito es la gestión del servicio (si, como lógico y fácil, alguien se lía con tanta ISO y tanto número recomiendo leer antes ¿ISO/IEC 9000, 15504, 12207, 27001 o 20000?) que ofrecen las tecnologías de la información y que por tanto aplica principalmente a las áreas de explotación – producción. Concretamente las guías son:

- Guía de gestión de servicios en ISO 20000, donde se presenta la preparación e implantación de la ISO 20000 en el escenario de una certificación, su obtención, validez y renovación. También trata la relación entre ISO/IEC 20000 e ITILv2 (me llamó la atención que el estudio tratase la relación de ISO 20000 frente a ITIL v2, versión antigua, y no frente a ITIL v3, versión actual) y, brevemente, la relación entre ITIL y CMMI (se echa de menos, y hubiese sido muy útil, incluir igualmente la relación con ISO 15504).

- Guía de aproximación incremental a ISO 20000, que trata el ámbito de aplicación, planificación e implementación de un Sistema de Gestión de Servicios de TI (SGSTI) y de los procesos de gestión de servicios.

Felicitar INTECO por la iniciativa.

Twitter: http://twitter.com/jgarzas

Tenía pendiente comentar que hace unas semanas estuve en Santiago de Chile, en un encuentro tecnológico entre empresas Chilenas y Españolas organizado por PROMOMADRID y CEIM, a los que desde aquí queremos dar las gracias por invitar a Kybele Consulting. El encuentro fue muy interesante, productivo y muy bien organizado.

En mi caso además fue agradable volver a Chile. En una etapa profesional anterior trabajé una temporada en dicho país, por mediación de Telefónica Móviles Corporación y dedicado a la parte de desarrollo e ingeniería software, etc., de una fábrica software que implantaron en Santiago.

En estos años Chile se ha convertido en un país lleno de oportunidades en el sector tecnológico, cada vez más emergente en un país que ha apostado por jugar un papel muy estratégico en el offshoring, en estar entre las primeras opciones a la hora de externalizar el desarrollo software a otro país.

Lo dicho, muy interesante y espero que nos volvamos a ver por allí.

P.D: Me he apresurado a poner este post antes de las 20:30, para que, independientemente de lo que pase, no se vea afectada mi objetividad ; -)

Twitter: http://twitter.com/jgarzas

Hace un par de semanas estuve en la conferencia Agile Spain 2010, para impartir una breve charla sobre normas de aplicación al desarrollo software y métodos ágiles. Os dejo abajo la presentación, aunque es corta y bastante esquemática, la idea principal fue que modelos – normas de desarrollo software y métodos ágiles no son contrarios, si no complementarios, y que en muchas ocasiones se necesitan unos a los otros; otra cosa es saber integrarlos, que se interpreten o evalúen erróneamente, o que, como comentábamos en el debate, se confunda certificación con competitividad, certificación con total seguridad en la calidad de los productos, etc.

Aprovecho también para dar la enhorabuena a los organizadores por el evento, por el éxito de participación y la organización del mismo.

Twitter: http://twitter.com/jgarzas

Muchas veces, en alguna conversación referente a algún proyecto software, cuando alguien nos pide una opinión, en alguna charla o cuando estudiamos los riesgos de algún proyecto, suele salir la lista de “errores clásicos” de McConnell. Debido al uso y utilidad de la misma, me ha parecido interesante dejarla resumirda en este post.

En 1996 Steve McConnell publicó el libro “Rapid Development”, en mi opinión uno de los mejores libros que se han escrito en lo que refiere a la gestión de proyectos software, en el que introducía el concepto “error clásico del desarrollo” software. McConnell definió a los “errores clásicos” como aquellos que se han repetido tantas veces, y por tanta gente, que debieran ser previsibles y siempre se deberían gestionar. El libro describía 36 errores clásicos, que en 2007 se ampliaron a 42, sobre los que se realizó una encuesta sobre aproximadamente 500 profesionales con el objetivo de determinar su frecuencia y gravedad. A continuación os resumo los errores que ocurren con mayor frecuencia, los  que ocurren con menor frecuencia y los que de ocurrir tienen más impacto:

Errores que ocurren con mayor frecuencia

1.    Planificaciones demasiado optimistas
2.    Expectativas no realistas (o pedirle a un proyecto algo imposible)
3.    Excesivas tareas (cuando, por ejemplo, los desarrolladores están en muchos proyectos a la vez)
4.    Insuficiente aseguramiento de la calidad
5.    Oficinas ruidosas
6.    Incorporación de características (por ejemplo, introducir nuevos requisitos a mitad de proyecto)
7.    Hacerse ilusiones (por ejemplo, cerrar los ojos a lo que se nos viene encima)
8.    Gestión del riesgo insuficiente
9.    Confundir estimaciones con objetivos (cuando por ejemplo el objetivo es tener el software en 3 meses, y de ahí se fija que el desarrollo serán 3 meses)
10.    Omitir tareas relacionadas con la estimación (no guardar históricos para realizar mejores estimaciones, al estimar obviar tareas como son las reuniones, etc.)

Errores que ocurren con menor frecuencia

1.    Cambio de herramientas en mitad del proyecto
2.    Falta de control automatizado del código fuente
3.    Desarrollo dirigido por la investigación
4.    Convergencia prematura o muy frecuente (forzar el cierre de una versión antes de que sea posible)
5.    Estimar obviando el uso de nuevas herramientas o métodos (obviando, por ejemplo, el coste de aprendizaje)
6.    Negociaciones y el “tira y afloja” (entre, por ejemplo, desarrollo y comerciales)
7.    El síndrome de la bala de plata
8.    Errores en la subcontratación
9.    Llevar al equipo en la oscuridad (cuando, por ejemplo, los jefes de proyecto ocultan al equipo el avance y plan de proyecto)
10.    Problemas con el equipo

Errores que provocan problemas de mayor impacto

1.    Expectativas no realistas (o pedirle a un proyecto algo imposible)
2.    Equipo poco preparado
3.    Planificaciones demasiado optimistas
4.    Hacerse ilusiones (por ejemplo, cerrar los ojos a lo que se nos viene encima)
5.    Insuficiente aseguramiento de la calidad
6.    Diseño inadecuado
7.    Falta de apoyo al proyecto
8.    Confundir estimaciones con objetivos (cuando por ejemplo el objetivo es tener el software en 3 meses, y de ahí se fija que el desarrollo serán 3 meses)
9.    Excesivas tareas (cuando, por ejemplo, los desarrolladores están en muchos proyectos a la vez)
10.    Falta de involucración del usuario

Twitter: http://twitter.com/jgarzas

Esta es una de esas noticias que a uno no le gusta poner el blog, pero las cosas son así, así pintan y mejor contarlo.

Aunque los estudios de AETIC y ASIMELEC (dos de las asociaciones de empresas TIC más importantes) sobre la facturación en 2009 del sector TIC (e informática) en España no muestran los mismos datos, ambos coinciden en que el sector ha disminuido considerablemente su facturación: un 9% según AETIC y un 7% según ASIMELEC. Desde 2003 el sector TIC siempre había crecido año tras año… hasta que llegó el 2009. Sin duda no son buenas noticias, que se juntan a todo lo que ya “está cayendo” en torno a la crisis.

Además, los resultados de 2009 son peores en España que en el resto de países de nuestro entorno. En el sector ya no se crea empleo, ahora se destruye y bajan los sueldos.

Dentro del macro sector TIC (e informática), los subgrupos que más cayeron fueron el de servicios audiovisuales y la electrónica de consumo. Los relacionados con software, cayeron, pero por debajo de la media.

Y para 2010 se esperan datos similares.