ITIL - Cómo aprobar el examen Foundations

Hola, hoy me apetece hablar del examen ITIL Foundations, y algunas recomendaciones para facilitar el superarlo y dar una guía y seguridad a los que se presentan a este reto.
Podéis leer en este mismo blog un post con una introducción sobre ITIL.

En primer lugar debo decir que escribo esto desde el punto de vista de mi experiencia personal. A mí me sirvió (superé con un 95% el examen oficial ITIL Foundations). Empecemos:

Y todo esto...¿para qué?

Al superar el examen ITIL Foundations, recibes una certificación que te acredita profesionalmente a tí, como conocedor del marco de servicios y buenas prácticas ITIL.
Profesionalmente, la acreditación ITIL Foundations está entre las más solicitadas. Este enlace, lo presenta en el 9º puesto, al mismo nivel que otras certificaciones mucho más costosas de conseguir desde mi punto de vista.

El examen.

El examen ITIL Foundations, para la edición 2011, está basado en 40 preguntas para las cuales se exige un 65% de acierto (es decir, acertar al menos 26 de esas 40 preguntas).
Para ello, los exámenes se realizan desde centros autorizados, y cualquier búsqueda en Google os dará centros para hacer cursos, normalmente acompañados de un examen final.
Para el examen, nos darán 60 minutos. Yo no fui el primero en entregar mis resultados, y me costó apenas 20 minutos responder a las preguntas. Mi consejo es que hay tiempo más que suficiente. Marcarse un ritmo, no más allá de un minuto por pregunta, de forma que nos quede margen para revisar las respuestas, preguntas que nos hayan quedado sin contestar, etc.
El examen se hace mediante ordenador, que conectado al centro evaluador, te permite hacer las preguntas, revisarlas, controla qué preguntas han sido contestadas, cuáles no...etc.
El idioma del examen: se puede elegir hacerlo en inglés o en castellano. Mi experiencia es que no notarás mucha diferencia. Cuidado con las traducciones de los exámenes que encontrarás por internet, porque muchos conceptos estamos acostumbrados a escucharlos en inglés, y la traducción se nos puede hacer extraña. Los de habla hispana encontrarán muy diferentes traducciones en función de la nacionalidad, así que cuidado. En mi caso, he llegado a dudar en preguntas solamente por leerlas en español (la traducción no era del todo afortunada).

Las preguntas.

Las preguntas son de tipo test, y son realmente sencillas si has estudiado. No tiene mucho misterio. Yo recomiendo hacer el curso de preparación que suele anteceder a los exámenes en los centros oficiales. Yo en mi grupo de estudio, detecté que simplemente atendiendo al curso y estudiando un poco en los 4 días de curso, era suficiente para superar todos los test de prueba que hicimos el último día.

El material de preparación.

Recomiendo hacerse con:

• Un buen libro o material de estudio, normalmente facilitado en el curso oficial. Sólo si no tienes el anterior, me plantearía comprarme un libro. Para el que ya tenga el material de presentación del curso, le será de rara utilidad comprar un libro aparte.
• Un buen paquete de test de exámenes. Intenta que no estén marcadas las respuestas. Normalmente los harás N veces antes de presentarte al examen final.

Dónde prepararse.

Buscando en google, encontrarás centros formativos. Yo estuve bastante contento de la formación que recibí durante 4 días, a unas 5 horas al día.
Si prefieres la autoformación, hay muy buenos libros en el mercado.
También, encontrarás en internet gran cantidad de exámenes en inglés y español. Luego os hablaré de ellos.
Yo lo digo por activa y por pasiva en este blog: yo no vendo, así que no esperéis que os venda un libro o una empresa certificadora. Yo tampoco me dedico a esto, no estoy en este blog para vender. Usad internet, basta poner ITIL en el buscador, Empresa Certificadora, etc.

Cómo prepararse.

Mi plan de trabajo fue el siguiente:

1. Asistir a un curso oficial
2. Hacer test de certificación
3. Recopilar las preguntas en que había fallado, y estudiarlas/razonarlas revisando de nuevo todo el material, de forma que me quedara claro la respuesta buena, y no la que yo erróneamente había escogido.
4. Repaso de teoría. Usar un resumen/esquema.
5. Volver al punto 3 hasta que la puntuación obtenida en los test mejorara sustancialmente hasta el 80% al menos.
6. El día antes del examen, hice un buen repaso de todas las preguntas en las que en algún momento había fallado (y que luego había razonado/estudiado la respuesta).

Que no se le ocurra a nadie ponerse a hacer tests sin haber estudiado a conciencia, o haber recibido un curso intensivo y completo. Ese es uno de los peores errores, porque aunque no hay preguntas trampa, sí lo pueden parecer al neófito.

Si el examen se hace al terminar un curso, mi consejo es estudiar todos los días al menos 2h aparte del tiempo dedicado al curso.

Si como me ocurrió a mí, pasa mucho tiempo desde el curso hasta el examen, tómate al menos una (o mejor dos) semana(s) dedicando entre 1 y 2 horas al día. Habrá quien le baste con menos...tú mismo.

Consejos.

Aquí van algunos consejos, obtenidos tanto de mi experiencia personal, como de otras personas que hicieron el examen y tuvieron a bien compartir esto conmigo:

• No es nada complicado. Es más importante calidad que cantidad al estudiar.
• Concentración. Es bastante teórico, por lo que merece la pena un ambiente silencioso y estar centrado. Los conceptos pueden parecer liosos a quien está fuera del ámbito de la prestación de Servicios IT.
• Una o dos tilas antes del examen, vienen bien ;)
• No te fies de los exámenes de test que verás por internet. Revisa toda las preguntas contrastando el material teórico que tengas (libros).
• Cuidado con la versión de los exámenes. Internet tiene mucha información (demasiada), y está mal clasificada, y mal presentada.
• Piensa que todo el material anterior a 2011 (y gran parte del de 2011), es anterior sí o sí a la última versión de ITIL. Además, por mi experiencia, mucho material presentado como de 2012 también está obsoleto. Los tests de versiones anteriores de ITIL no es que contradigan el ITIL 2011, sino que simplemente no están en el temario o pueden enfocarse de forma ligeramente distinta. Te harán perder tiempo.
• Mientras se estudia el temario, e incluso durante el mismo curso, hazte un esquema. Algo que parece imposible al principio (como identificar a qué área de procesos ITIL pertenece cada proceso individual), acaba siendo natural tras N repasos del esquema.
• No te agobies con descargar libros y libros de internet. Utiliza un solo material, preferiblemente en el mismo idioma en que te vayas a examinar (inglés o español). Es decir, que si ya te dieron material en el curso, céntrate en él y no pierdas tiempo en N libros que sólo te van a distraer.

Mucha suerte, si te animas a certificarte.

ITIL - Introducción

Tenía bastante abandonado el blog. Es lo que tiene estar en plena certificación CMMI nivel 3 y alguna cosa más. Es lo que tiene, que no te aburres.

Como tenía pocas cosas en marcha, me he certificado recientemente en ITIL Foundations, y ya tengo el certificado en mi poder.

Aprovecho un momento de no-descanso, y haré una breve introducción a ITIL. Me sorprende ver cómo hay mucha confusión en estos marcos de trabajo. Empecemos.

¿Qué es ITIL?

Es un conjunto de buenas prácticas para la gestión de los servicios que prestan las tecnologías de la información. Es decir, ITIL no es una metodología, como mucha gente tiende a llamar.

ITIL son las siglas de "Information Technology Infrastructure Library", una biblioteca de infraestructura para las tecnologías de la información.
Está pensada para ayudar a definir cómo trabajar en una empresa que preser servicios TI: software, hardware, consultoría...servicios IT en general.

ITIL se creó en los años 80, y a día de hoy es uno de los estándares más conocidos para la gestión de servicios IT.

La última versión de ITIL, no es la v3, aunque es la versión más popular. La última versión es la Edición 2011, que es una revisión de la v3 (no debía parecer interesante llamarla v3.1, ni v4).

¿Qué contiene ITIL?

ITIL no es una novela, y sin embargo consiste en 5 libros. Estos 5 libros definen la infraestructura de ITIL. Los títulos de esos 5 libros:

• Estrategia del Servicio.
• Diseño del Servicio.
• Transición del servicio.
• Operación del Servicio.
• Mejora continua del Servicio.

¿Qué es la certificación ITIL?

Hay una serie de certificaciones relacionadas con ITIL. Son certificaciones a nivel personal. Es decir, se supera un examen y se obtiene una acreditación. Pero no existe una acreditación ITIL para empresas. Para ello, existe un equivalente en la ISO 20000, que acredita empresas en un marco similar a ITIL (y que por contra, no tiene una acreditación para personas que pueda obtenerse con un examen).

Hay varios niveles. El nivel "Foundations" es el nivel más básico, y puede obtenerse mediante un examen de 40 preguntas tipo test en alguno de los centros oficiales acreditados. Existen niveles intermedios, y un nivel avanzado. Los distintos niveles, por encima del "Foundations", se logran aprobando exámenes que proporcionan créditos o puntos, distintos según el tipo de examen. Con suficientes puntos, se obtienen las distintas acreditaciones de forma incremental. En realidad, lograr las acreditaciones superiores es algo más complicado, pero no entraremos hoy en ello.

La certificación ITIL Foundations no es cara (de hecho, me parece uno de los certificados más baratos, para el nivel de demanda que tiene).

Para aprobar la certificación ITIL Foundations, es suficiente con estudiar por tu cuenta, aunque recomiendo los cursos de 3 o 4 días que suelen ir acompañados del derecho a realizar un examen. Si quieres trucos, recomendaciones, o un mayor detalle de ITIL, o cómo aplicarlo en tu empresa...lo dejaremos para un próximo post.

Otras entradas relacionadas en este Blog:

ITIL - Cómo aprobar el examen Foundations


--Update 19/02/2014: corregida una errata. Aclarar que ITIL NO certifica empresas sino personas. Para empresas está la ISO 20000. Disculpad el gazapo.

El mito de la usabilidad

Me tiene harto. Me ha hecho perder un buen rato. Y no sólo a mí. He hecho la prueba con varios compañeros, y a todos les ha pasado lo mismo. De hecho, el problema quizás no sea de usabilidad, sino de diseño erróneo de página.

Pero voy a introducir el problema. Me tenéis aquí, tratando de evaluar un producto de HP, el famoso Quality Center, para poder probar sus características, y pasar con el debido conocimiento de causa a la compra/alquiler/loquesea del mismo. Estupendo.

Pues en esas me veo cuando tras rellenar multitud de campos de información personal, utilísima para HP (quiero pensar)....no consigo superar el primer escollo. Cada vez que hago clic en "Enviar" la información, me da un error en uno de los campos obligatorios.
- Ok. Ya veo que está rojo...ya veo que es obligatorio....¡Pero ya está relleno!
- Bien, pues entonces como es el idioma ("Spanish"), voy a elegir otro...
- Pues no. Me harto de probar idiomas. Y lo hago en mi máquina. Y en una máquina virtual. Y con Internet Explorer y con Firefox....y aquí es cuando harto de probar, desisto.

Adjunto captura de pantalla de la maravillosa interfaz que me ha tenido entretenido a mí y a algún que otro amable compañero, y que agradezco en el alma a su equipo de desarrollo el inolvidable rato que me ha hecho pasar. Gracias. Pero que muchas gracias.

Y digo yo...¿no se podría pedir toda esta información más adelante? No podría rellenarlo por ejemplo...mientras instalo el producto? ¿No podría ser un poco más....AGIL?

[Editado] Gracias a un amable lector, al final no he hilado mi problema con el titular, y es que la usabilidad es un mito que aquí me ha golpeado amargamente. Supuestamente, este formulario web se desarrolló usando los últimos estándares de usabilidad y tecnologías novedosas (obsérvense los colores de fondo y texto, los distintos tipos de colores adicionales que proporcionan errores o enlaces, Ajax para facilitar el contenido dinámico, etc, etc.).
El caso es que la usabilidad, no puede lograrse únicamente con tecnologías novedosas. La usabilidad lleva pareja el ser amable con el usuario, no hacerle sentir estúpido, asumir su entorno (navegador, PC, etc.) y no imponer el nuestro, entender el objetivo final del usuario (darme de alta), en lugar del nuestro (obtener los datos a toda costa, aunque ello suponga perder usuarios). Usable también debe estar probado...¡resulta irónico que para la descarga de un prestigioso producto de testing, me encuentre fallos absurdos que me impidan su descarga!
Por otro lado, el lector tiene razón. Aunque están relacionados, un mito como el de la usabilidad se merece un post sólo para él, y no simplemente una mención de rebote. Por cierto, para los interesados en la usabilidad, leed algo de Alan Cooper. No os defraudará.

Pd.: al final, conseguí encontrar una persona que ya tenía cuenta HP y que por tanto, pudo entrar directamente desde la pestaña "Registro" (aunque también le tocó rellenar datos, y más datos, etc. etc.). Ahora, si consigo hacerlo funcionar, me gustaría poder comentar alguna bondad de este producto desde el lado de la experiencia.

[Editado] También comentar, que al final, pude probar la aplicación, comprobar las funcionalidades de este gran producto, y darme una idea de sus prestaciones y su adecuación al tipo y tamaño del proyecto...pero eso mejor lo dejaremos para otro post (o varios, porque hay mucho en esta familia de productos, que puede ser de utilidad si sabemos integrarlo en nuestros proyectos).

Beneficios de implantaciones CMMi

¡Ey, hoy es mi post nº 100! Pues nada, tras un auto-abrazo, paso al tema.

Recientemente he leído una presentación que mostraba, de la mano de Grupo Pragma Consultores, unos resultados de encuestas a empresas certificadas CMMi .

Las empresas estaban certificadas nivel 2 (80%) y nivel 3 (20%), y se trataba de empresas de España, Argentina y Chile.

Los resultados de la encuesta muestran, que en contra de los argumentos que esgrimen los detractores de estos marcos de trabajo, tras una implantación de CMMi se obtienen una serie de beneficios:

• Más del 90% observó mejoras en los tiempos/plazos.
• Alrededor del 70% observó mejoras en los costes. Esto se apreció, a pesar de considerar que una implantación CMMi tiene un alto coste inicial. Desde luego, el beneficio neto no se aprecia a corto plazo.
• El 100% observó mejoras más que apreciables en la calidad. Esto se apreció en una gestión más transparente, y un número de errores mucho menor.
• El 80% apreció una mejora sustancial de la satisfacción del cliente. Esto se aprecia principalmente debido a una mejor gestión del proyecto y de los requisitos, así como una planificación realista y adecuadamente comunicada a todos los involucrados.
• Más del 90% observó una mejor alineación de los objetivos del negocio con el desarrollo.

Los detractores de CMMi suelen alegar que éste modelo supone supone burocracia, exceso de documentación y sobrecarga de trabajo. Cuándo se les preguntó a los proyectos al respecto:

• Ante la pregunta de si se detectó sobrecarga de trabajo y en qué porcentaje, la respuesta está en todos los casos por debajo del 10%, siendo ese máximo de 10% la sobrecarga inicial en gestión. Por supuesto, una vez instaurados los procesos, la costumbre y la mejora continua producen una disminución progresiva en dicha sobrecarga de trabajo.
• Casi un 70% de los encuestados encuentra mucho aportado valor por la documentación que se generó
• Más de un 80% de los encuestados ve la documentación como algo provechoso (especialmente en los temas de estimaciones y métricas). 

Finalmente, comentar que los resultados de la encuesta muestran que a la empresa, le proporciona de forma global unos interesantes beneficios:

• ROI (retorno de la inversión) se considera positivo en más del 70% de los casos
• Se generan nuevos negocios debido a la mejor percepción de los clientes, mejora en la comunicación con dichos clientes, y posibilidad de competir en mejores condiciones para conseguir concursos públicos, etc. Hay que recordar que para muchos clientes del sector público o privado, se exige CMMi nivel 2 ó 3 para optar a ganar un proyecto.

¿Significa esto que CMMi es bonito y maravilloso? ¿Todos los que se quejan de CMMi mienten?

Pues NO. A ver, CMMi es un modelo para la implantación de un marco de trabajo, que como ya he comentado otras veces, depende en su éxito de cómo se implanta. Las empresas no siguen CMMi. Lo que siguen son metodologías y procesos basados en CMMi. Unos procesos demasiado burocráticos pueden contentar a los gerentes, pero también enfadar y sobrecargar por ejemplo a los programadores. Por eso, la responsabilidad del fracaso sería en todo caso de los procesos implantados, no de CMMi.

¿Quién se preocupa de que todos en la empresa estén contentos con su forma de trabajo?

Pues la propia empresa, en su metodología y procesos, han de buscar ese equilibrio donde el control, el ligero aumento de documentación y la mejora continua, permitan lograr los objetivos marcados. Lo que no suelen tener en cuenta los detractores de CMMi es que la metodología que se usa, no se diseña para hacerles felices a ellos (que parece que todos queremos ser el ombligo del mundo!). La metodología resultante se enfoca a cumplir una serie de objetivos, que habrá definido previamente la empresa. Y es ahí donde el programador que tiene que hacer 2 o 3 documentos nuevos, lo puede interpretar como burocracia. De eso ya hablé en otro post (El Mito de la Burocracia).

La gestión de la deuda técnica

La deuda técnica es un concepto que se lleva manejando desde hace ya unos años. Muchos de vosotros habréis oido hablar de ello, y unos cuantos, como yo, lo habréis sufrido con dolor. Vamos a ver primero en qué consiste, y comentaré finalmente una iniciativa a nivel global para atender este grave problema que nos afecta en nuestra profesión.

¿Qué es la deuda técnica?

Qué curioso. Antes de explicar la deuda técnica, he querido contrastar mi definición con la de Wikipedia. Y qué decepción. Wikipedia explica, que la causa de la deuda técnica está en el ahorro de costes, que a su vez deriva en escasez de pruebas, y mala calidad de los productos implantados o incluso con errores conocidos.
Pues disiento. He visto proyectos bien sobrados de dinero, con abundancia de pruebas, y con resultados de calidad pésimos.
En mi opinión, la deuda técnica es la acumulación en el software de una o varias de las siguientes:

• Una o varias arquitecturas incongruentes entre sí o con las necesidades reales (o ausencia de arquitectura!).
• Inexistencia de estándares de programación, o existencia de varios estándares de desarrollo incongruentes entre sí.
• Falta de pruebas adecuadas a la solución requerida, de forma que posiblemente las pruebas se pasaron, pero el producto seguía adoleciendo de una baja calidad.
• Ineficacia en los programadores a la hora de realizar el código. Bien por usar soluciones inadecuadas o ineficades, no utilizar patrones cuando hubieran sido adecuados, o por el contrario, abusar de patronitis (ver mi entrada sobre esta enfermedad del software).
• En general, el uso y abuso de las distintas enfermedades del software que voy desgranando en este blog como son la ya comentada patronitis, cacheitis, etc.

Las consecuencias de todos estos problemas, se pueden ver tanto en proyectos faltos de presupuesto, como en complejos y grandes desarrollos bien dotados económicamente. Como ya he comentado en algún otro blog, los programadores tenemos la habilidad de echar siempre la culpa a los demás de todo, en lugar de hacer primero análisis, y después asumir la parte de culpa (mucha o poca) que podamos tener. Como decía las consecuencias son:

• Código espaguetti, o incluso código estructurado de formas tan diferentes entre sí, que parece una lucha de voluntades por parte del programador de impregnar cada uno, su forma de trabajar. El exceso de estándares es tan malo como su carencia.
• Ausencia de control de errores, o un uso que imposibilite obtener cualquier beneficio de dicha implantación.
• La documentación representa al software como un huevo a una castaña.
• No se ha hecho refactoring: el código se queda como está...o lo que es peor: los cambios se limitan a añadir más y más elementos, hasta que el código o es espaguetti, o dan ganas de atentar contra la vida de los diversos autores.
• Errores no subsanados, errores desconocidos (pruebas mal diseñadas).
• Control de versiones inexistente, de forma que no es posible saber qué versiones de unos módulos son compatibles con qué versiones del resto de módulos, o con la base de datos.
• Wikipedia nombra que una consecuencia sea que el producto no sea escalable. A ver, aquí encontramos una falacia: la escalabilidad tiene un coste. No todos los productos tienen una arquitectura de 7 capas con servicios distribuidos, escalables multiplataforma y bla bla bla...
• Wikipedia nombra otra consecuencia, que aunque cierta, hay que analizar: "Problemas al incorporar nuevas funcionalidades". Y es que un producto que cuesta cambiar, no tiene porqué significar que está mal hecho y que supone una deuda técnica. Todo depende del cambio. Una aplicación de gestión de personas, que se quiera adaptar a la gestión de vehículos...pues quizás el cambio no es trivial. ¿Acaso le vamos a echar la culpa al equipo de desarrollo anterior? 
• Finalmente, wikipedia indica otra consecuencia con la que discrepo: "Dificultades a la hora de actualizar la tecnología, o migrar a una nueva plataforma". Que un software admita un cambio de tecnología o de plataforma, es un requisito muy complejo. No es un requisito habitual, por otra parte. Por desgracia, no existe el software, en ningún patrón, framework o metodología que admita "cualquier tipo de mejora tecnológica o cambio de plataforma". Si esto existiese, se habría acabado la profesión de informática y sólo trabajarían unos pocos haciendo los escasos cambios necesarios. 

En general, y por simplificar, la deuda técnica es la degradación en la calidad del software y la dificultad en los cambios posteriores, debido a decisiones a corto plazo ineficientes (seguro que se os ocurre o leéis por ahí alguna otra frase más elaborada, pero bueno).

El término deuda técnica, se lo debemos a Ward Cunningham (igual os suena como el pionero del software en temas como la primera wiki, los patrones de diseño, o la programación extrema).

Lo realmente importante no es cuánto sepamos de la deuda técnica. Seguro que muchos de vosotros daréis una visión y descripción académica mucho más acertada y exacta que la mía. Lo que es importante, es que empecemos a ser conscientes de una vez de que el software no se construye y ya está. Alguien lo debe mantener, alguien debe hacerlo funcionar como realmente quería el cliente. Por desgracia, cuando pasa la época de las medallas (qué bonito es todo cuando se entrega el software y no se ha probado del todo por el cliente), llega la realidad de que el cliente no puede hacer todo lo que quería en su negocio, con las funcionalidades que al final se le han dado. Además, por desgracia, los que sufren el esfuerzo de "pulir" el software y terminarlo de arrancar, suelen ser personas totalmente ajenas a los que recibieron las medallas, víctores y premios por la entrega.

Iniciativa del SEI

El SEI (Software Engineering Institute), ha llevado a cabo recientemente un Workshop en el que se trataba la gestión de la deuda técnica desde el punto de vista de arquitectura del software. El evento tuvo lugar el 13 de marzo de 2012, pero tenéis información disponible en este link.

Además, el SEI está haciendo un esfuerzo en la investigación y estudio de este problema, que cada día se hace más palpable en el mundo del desarrollo de software.


Más información en:
http://www.sei.cmu.edu/newsitems/tech-debt.cfm
http://es.wikipedia.org/wiki/Deuda_t%C3%A9cnica
http://en.wikipedia.org/wiki/Ward_Cunningham