Deloitte presenta resultados encuesta sobre uso del móvil

Estamos en una era digital. Eso está claro. Sin embargo, no podemos dejar de lado que cada día los usuarios estamos más y más enganchados a los dispositivos móviles.

Como desarrolladores de software, esto nos afecta por una doble vía: por un lado los hemos de tener en cuenta a la hora de crear aplicaciones y productos que realmente son del agrado del público y satisfacen sus requisitos (que los "enganchen", vamos). Por otro lado, y por desgracia, también nos vemos afectados por esa misma "fiebre" de los dispositivos móviles. Eso nos puede hacer imparciales, y es un factor a tener en cuenta.

Recientemente, se han presentado los siguientes resultados, discretos diría yo, que muestran el número de veces al día que se consultan los móviles, entre otros interesantes datos.

Aquí se muestra cómo los jóvenes entre 18 y 24 años llegan a consultar su móvil hasta 53 veces al día (de media). Evidentemente, hay casos en que estas cifras se superan ampliamente, pero estamos hablando de valores medios.

En la figura siguiente, vemos los tiempos medios que los usuarios tardan en consultar su móvil desde que se despiertan por la mañana:

Los datos provienen del estudio que ha presentado la consultora Deloitte.

Fuente: http://www.deloitte.co.uk/mobileuk/smartphones-wake-up-and-plug-in/

El trabajo autónomo: ¿solución o problema?

Es el sueño de muchos: el trabajar como autónomos. Y sin embargo, pocos se atreven. A la dificultad se une el desconocimiento, el temor de emprender por cuenta propia una senda que por otro lado es radicalmente opuesta a la seguridad que nos proporciona el trabajar por cuenta ajena, recibiendo órdenes concretas en un horario concreto.

Estaba leyendo un artículo en prensa relacionado, y me ha precido retomar este interesante tema. Sin embargo, me voy a centrar el agunas afirmaciones que se hacen, y que para la desgracia de nuestro sector profesional, no me parecen del todo acertadas si las contemplamos desde el punto de vista de la industria del software. Como excusa, diremos que por el contenido y el tono generalista del artículo, no se han centrado ni mucho menos en el mundo del desarrollo/mantenimiento de aplicaciones.

• Crece el número de profesionales autónomos. Por supuesto, ante el creciente desempleo, no queda otro remedio que buscar trabajo mediante el auto-empleo.
• Los nuevos emprendedores surgen principalmente en el sector servicios. Pues claro, como que es el sector que aunque ha sufrido la crisis, lo ha sufrido en menor medida. Si te quedas en paro, y te planteas ser autónomo...¿no lo harás en un sector que es menos castigado por la crisis? Aquí estamos mezclando causa y efecto.
• Responden a una demanda del mercado de personas con experiencia. El mercado siempre quiere personas con experiencia. La diferencia es que antes de la crisis, estas personas con experiencia eran caras, y ahora no lo son.

Al final, no me queda claro si el trabajar como autónomo es una solución o un problema. Lo que sí es cierto es que el mercado en general, pero también en nuestro sector en particular, es cada vez más precario y estacional. Trabajar por proyectos, por encargos, por picos de trabajo, está siendo cada vez más habitual. Pocas empresas son capaces de asegurar a sus empleados crecimiento, y al mismo tiempo, aseguramiento de la empleabilidad.

Metodología XP - Los 15 principios

Hace tiempo que quería escribir algo sobre XP (eXtreme Programming). Y es que todo el mundo está emocionado con las metodologías ágiles, principalmente Scrum. Pero para entender los problemas de Scrum y sus ventajas en función del tipo de proyecto (ya he comentado esto otras veces), hay que entender la historia de las metodologías ágiles.

Y qué mejor forma de empezar, que recordando los principios básicos de XP (hablo de eXtreme Programming, la metodología ágil antecesora de las actuales).

La metodología XP comenzó oficialmente con el libro de Kent Beck de 1999, aunque ya llevaba al menos uno o dos años oyéndose por la red. Ya existía un brote ágil que terminaría de catalizar a partir del año 2000.

El propio Martin Fowler, en su blog nos habla en un artículo de los 15 principios de XP. Vamos a revisarlos.

Tenemos los 5 principios fundamentales:

• Rapid Feedback
• Assume Simplicity
• Incremental Change
• Embracing Change
• Quality Work

Aunque existen otros 10 principios adicionales, hasta conformar los 15 principios ágiles:

• Teach Learning
• Small Initial Investment
• Play to Win
• Concrete Experiments
• Open, honest Communication
• Work with people's instincts - not against them
• Accepted Responsibility
• Local Adaptation
• Travel Light
• Honest Measurement

Si os fijáis, estos principios serían anteriores incluso al manifiesto ágil, surgido a raíz de la reunión que convocó Kent Beck y que dio origen a dicho manifiesto. Kent Beck fue el autor, 2 años antes del manifiesto ágil del libro "Extreme Programming Explained".

El resto, como se suele decir, es historia.

Estimación basada en tallas de ropa

Hoy voy a hablar de una forma de estimar el tamaño del software, que en realidad no es más que una variante de un viejo conocido: el uso de las cartas en el planning poker. Estas cartas, suelen estar numeradas utilizando la conocida serie de Fibonacci:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100...

Sin embargo, hay más. Y aunque quizás no se usen tanto, la estimación basada en tallas de ropa (o "t-shirt estimation"), también existe. En concreto, es popular por ejemplo entre grupos de trabajo de Microsoft, entre otros.

Ventajas

Por supuesto, esta forma de estimación presenta varias ventajas:

• Más fácil de imaginar incrementos de forma cualitativa.
• Más fácil de comunicar las estimaciones al product owner. Los usuarios finales pueden más fácilmente asimilar que las estimaciones y por tanto los desarrollos, son de magnitud diferente.
• Facilita la estimación ágil en grupos menos experimentados.

Inconvenientes

Y ahora, pasemos a ver los inconvenientes:

• Más difícil de mapear los incrementos de forma cuantitativa. El paso entre tallas pequeñas parece ser similar al paso entre tallas grandes. Sin embargo, la estimación ágil basada en la serie de Fibonacci se parece más a la realidad, ya que las diferencias entre estimaciones pequeñas son mucho menores que el salto entre las estimaciones más grandes. Es decir, la estimación en tallas de ropa sugiere erróneamente que los escalones son iguales, cuando no es así.
• Conforme los grupos de trabajo son más experimentados, es mejor pasar a otros tipos de estimación ágil.
• Es complejo intercambiar estimaciones con otros grupos ágiles, ya que su uso no está tan extendido.

Mi consejo es usar las tallas de ropa como una referencia de trabajo, y mapear, como indican varios autores, cada talla con un número de la tradicional serie de cartas de póker (o Fibonacci). De esta forma, se pueden aprovechar las ventajas y evitar los inconvenientes antes mencionados. Con el tiempo, de todas formas, lo ideal es que los equipos de trabajo acaben estimando directamente con los números y acaben abandonando las tallas de ropa.

Fuentes:
http://qeworks.com/t-shirt-estimation-in-agile/
http://tech.mindcandy.com/2011/06/t-shirt-sizes-in-story-estimation/
http://www.mountaingoatsoftware.com/blog/estimating-with-tee-shirt-sizes

Cortana ya habla Español

Bueno, como he comentado recientemente, he cambiado mi móvil por un Windows Phone y no puedo estar más contento. Se acabaron los problemas que llevaba arrastrando en mis diversos dispositivos, y que mi mujer (que aún tiene Android), todavía sufre.

Cortana, el asistente personal de Windows, viene incluido en todos los móviles con Windows Phone en inglés, pero parecía no estar disponible en los móviles en otros idiomas como el español. Pues se acabó. Desde hoy (al menos en versión preliminar), ya lo tenemos en español. Esperamos que salga pronto la versión definitiva. Cortana es el equivalente en Windows Phone de SIRI (de iOS en los iPhones) o de Google Now en los dispositivos Android.

Mientras, os dejo con un vídeo sobre Cortana en Español. Atención al momento en que Cortana se pone a cantar (con entonación que hace dudar si es una persona quien da el sonido, o es solo un programa) e incluso si se lo pides, sabe hacer imitaciones! Lo mejor de todo es la espontaneidad y aparente inteligencia de sus respuestas. Adelante con el vídeo:

Llevo casi un año usando Windows Phone, pero con Cortana un poquito menos (y en inglés). Mis hijos se mueren de la risa con las ocurrencias de este asistente personal de Microsoft. Y encima, estoy consiguiendo que mientras tanto, repasen inglés (yo tengo ahora mismo instalada la versión en inglés).

Dejaremos para más adelante el hablar de la plataforma Windows Phone, que se merece un estudio más profundo.

Ya llevaba algunos días usándolo, más por curiosidad que otra cosa. Y la verdad es que es una delicia comprobar hasta dónde están llegando las tecnologías, más después de ver cómo se comporta Siri (que no está mal), y cómo se comporta el equivalente de Google (Google Now).

¿Por qué incluyo este post en un blog de calidad y software? Cortana es un software, como lo son el resto de lo aquí comentados. Pero en el caso de Cortana, estamos hablando de un nivel de especificaciones y requisitos de calidad altísimos. Os podéis dar una vuelta algunos de los blogs de  Microsoft) (enlace1 y enlace2) para ver el nivel de ingeniería del software que se está alcanzando en muchos casos, acercando aquí el lenguaje natural y cierta inteligencia incluso, a los objetos cotidianos (como un móvil).

Material para preparar ISTQB

Hola, aquí dejo un enlace bastante interesante con material que ayuda a la preparación de la certificación ISTQB:

ISTQB es una certificación que pretende cubrir en diversos niveles, las áreas de conocimiento relacionadas con la ingeniería de pruebas.

Si alguno más se anima a la certificación, mucho ánimo.

Se me olvidaba! El enlace: https://sites.google.com/site/softwaretestingbooks4u/manual-testing

Por cierto, este post es el número 200 en este blog. Vaya, ya tenemos unos cuantos.
Un saludo.

Próxima parada: ISTQB

Hola, tras tanta certificación de calidad para la empresa, y viendo el éxito que ha tenido la de ITIL a nivel personal, varios compañeros y yo nos estamos certificando en la ISTQB. El objetivo es pasar el examen a principios de año.

¿Qué es eso de la ISTQB? Es una certificación personal, que no caduca, y que tiene varios niveles. En el Foundations, certifica unos conocimientos básicos y suficientes. ISTQB está relacionada con el testing, con las pruebas en el desarrollo de software. Y no sólo está orientado a testers. Todo el mundo involucrado en el desarrollo y en especial testers y gestores deberían conocer al menos el nivel foundations.

Aprovecharé que me estoy preparando yo mismo, para ir comentando aquí algunos conceptos y mi experiencia en la certificación.

Hasta otra.

La vuelta al trabajo y algo de usabilidad

Bueno, ya hemos vuelto al trabajo. En realidad hace tiempo que había vuelto, y aunque tengo (oh Dios mío) 30 post empezados sin terminar, no me he sentido con fuerzas de completar ninguno, y he preferido empezar uno nuevo.

Ha sido una época de mucho trabajo, grandes responsabilidades, dedicación, compromiso y sacrificio. Desde mi último post hemos renovado una certificación ISO 9001, hemos ampliado el alcance a toda la organización de un CMMI nivel 3, y para no aburrirnos, estamos cambiando completamente toda la metodología de trabajo para alinearnos todavía más a nivel mundial con el resto de la firma.

Dicho así que bien suena, eh? Uf. Ahí han quedado muchas noches, días y sufrimientos. Pero bueno, estamos de vuelta en el blog, y qué mejor forma de volver que ofreciendo conclusiones de hechos que creo nos afectan a todos y además de forma grave y sensible.

Blogs y Google+: un camino de ida y vuelta

Hace ya un tiempo que Google decidió ofrecerme en este blog el publicar los posts a través de google+. Leí la letra pequeña, pero no vi nada raro. Más bien, como descubrí después, la trampa estaba en lo que no se decía. Los comentarios dejaron de funcionar. Simple y llanamente, era físicamente imposible que mis lectores publicaran comentarios. Me encontré con que solamente podía obtener comentarios si publicaba en google+ y se me comentaba desde google+.

No es que tenga muchos comentarios en este blog, y a decir verdad, tampoco es algo que necesite. Como he dicho una y mil veces, yo no vendo. No me promociono. Y no pretendo que este blog os convenza de absolutamente nada. Si mi experiencia no os convence, podéis mirar por la web y encontrar miles de sinvergüenzas dispuestos a contaros su versión de la verdad a cambio de algún beneficio. Allá vosotros.

El caso es que esa conversión a Google+ me dejó prácticamente sin comentarios. Y los pocos comentarios, debía de responderlos a través de una red social que me era ajena. Yo no empecé este blog para hablar a un público limitado. Yo esperaba dejar una información útil que cualquiera podría leer y comentar mi blog, buscando siempre un conocimiento compartido y honesto. Y me cansé. Y dejé de usarlo. Incluso me cansé del uso de mi móvil android, que parecía obsesionado en obligarme a usar su red social una y otra vez.

Recientemente, he descubierto que las cosas han cambiado. Ya he recuperado la opción de que comenten mi blog a través de comentarios normales, sin pasar por ninguna red social. Pero en el camino me he desencantado un poco. Incluso he cambiado de sistema operativo en mi móvil, lo que comentaré otro día, puesto que ha supuesto una más que grata sorpresa. Gracias Windows Phone por ofrecerme un sistema pensado para que yo haga lo que necesito, no para que yo haga lo que necesita la empresa X.

No me queda claro qué ha pasado. No sé si los comentarios en mi blog están todos en Google+ (juraría que no), pero parece que tampoco están en este blog. Supongo que algunos se han perdido por el camino. Nadie me lo ha dicho, y no espero que me lo diga. Pero hablábamos de usabilidad, y aquí es donde he de decir que me siento cansado de ver cómo grandes empresas, toman decisiones puramente egoístas, pisoteando intereses con tal de obtener sus objetivos. Y lo hacen pisoteando la usabilidad en favor de supuestos beneficios que ellos obtienen, aunque perjudiquen claramente al consumidor.

Ahora me encuentro de nuevo aquí, con casi 200 post publicados (198 para no mentir), 30 post pendientes de publicar (en borrador), y nada menos que más de 100.000 entradas. Qué barbaridad. ¿Y qué hago yo ahora? Pues yo no sé vosotros, pero yo simplemente voy a seguir contando aquí cosas útiles o interesantes (para mí lo son al menos).

Hasta la próxima.

24h - El complejo de Jack Bauer

Ocurre en muchas ocasiones: más de las que nos gustaría y más de las que queremos admitir. En esta profesión de desarrollo de software, en la que tenemos metodologías, métricas, procesos, calidad, más de una vez nos habremos encontrado sufriendo el complejo de Jack Bauer.

Ocurre de forma progresiva: primero tenemos todo planificado y bajo control, todo parece ir sobre la seda, y cuando menos te lo esperas, salta un problema para el cual no tenías un plan de contingencia. La cuestión no es tanto si sabemos o no planificar, sino más bien cómo afrontar los problemas. Esos problemas que se suelen manejar en un comité y que en más ocasiones de las que nos gusta admitir, tememos escalarlos a ese comité por no asumir responsabilidades.

¿La consecuencia? Pues que trasladamos a nuestros equipos esa responsabilidad, enmascaramos la culpa con una falsa urgencia (o no tan falsa), y movilizamos nuestros ejércitos para afrontar lo que parece ser un capítulo de la serie de televisión "24". Con un plazo imposible de cumplir, nos embarcamos en una tarea sobrehumana, y sustituimos la culpa, la gestión y las metodologías por un compromiso y resolución que nos lleva a ser protagonistas de esa serie, donde hay que salvar el mundo, hacer tareas imposibles, recorrer varias veces toda la ciudad y todo ello en 24 horas.

¿Os suena? Pues sí, esto es el complejo de Jack Bauer, personaje protagonista de esa serie de televisión, y que representa muy bien las situaciones de "bombero" o "apagafuegos" en las que nos vemos inmersos.

Esta forma de afrontar los problemas, la podéis encontrar en la red con otros nombres. Uno que me ha gustado es el antipatrón "apagafuegos". Os recomiendo leer esa web de antipatrones.

Hay que tener mucho cuidado con esta forma de actuar, porque lleva a ser estimulante. Nos podemos sentir héroes salvando el mundo, apagando fuegos constantemente, en ese complejo de Jack Bauer. En lugar de afrontar los problemas como lo que son, no podemos tratar de resolverlos todos a la primera de cambio, en ese ciclo de subida (esfuerzo heroíco de resolver el problema) y de bajada (bajón inevitable que tenemos cuando la situación ya es estable y la adrenalina se agota...hasta el siguiente fuego).

Hay quien ve esta forma de actuar como una adaptación al cambio. Pero adaptarse al cambio no significa afrontar los problemas con sesiones a lo Jack Bauer (es decir 24 horas sin dormir y con esfuerzos histéricos para resolver las cosas). Hay que atajar los problemas de base, porque distraer al equipo de esa forma significa alejarlo del objetivo del proyecto. Esa distracción no supone 24 horas, sino mucho más: el coste de recuperar el ritmo, y también de recuperarse de ese esfuerzo.

Los cambios los gestionamos nosotros, no al revés.

Cuidado con las estimaciones ágiles

Hoy os voy a traer un caso real. En estos tiempos en las que las metodologías ágiles están en todas partes, es el momento de reflexionar el qué queremos, pero sobre todo, qué necesitan nuestros clientes.

En concreto, mucho cuidado con las estimaciones ágiles porque los clientes siguen necesitando saber en muchas ocasiones cuándo van a estar disponibles sus aplicaciones, y a qué precio. Os adjunto una conversación que podría ocurrir a pocos metros de donde estáis:

- [Cliente] ¿Cuánto va a costar esto? ¿Y cuánto tiempo tardaremos en tenerlo? La verdad es que tenemos unas fechas límite muy definidas, y el presupuesto no nos da para muchos cohetes.
- [Vendedor/Técnico ágil] Pues es que nosotros no estimamos en horas, sino en StoryPoints. Pero no se preocupe, porque esto es un marco de trabajo Scrum altamente reconocido.
- [Cliente] ¿Ah, sí? Pues que sepas que mientras tanto, te pagaré en BarPoints (tickets del bar). Pero no te preocupes, porque esto en nuestra cafetería de empresa es una forma de pago altamente reconocida.

En fin. Creo que ha quedado claro. Mucho cuidado con las obsesiones y sobre todo actitudes talibanes respecto al agilismo. De nuevo tenemos las balas de plata de nuestra generación. Y de nuevo, hemos de usarlas como lo que son: tan sólo una herramienta más, que hemos de adaptar a cada situación y necesidad.

¿Y tú ...qué les das a tus clientes? ¿Lo que ellos necesitan, o lo que tú les quieres dar?

Libro gratuito: Casos de Uso 2.0 de Ivar Jacobson

Hola a todos. Ya podéis descargaros de forma totalmente gratuita, el interesantísimo libro de Ivar Jacobson "Casos de uso 2.0", a través del siguiente enlace:

http://www.ivarjacobson.com/resources/resources/white_paper/

El autor, Ivar Jacobson, es más conocido por su participación en la creación de UML, RUP y la programación orientada a aspectos.

Feliz lectura.

No borres tus huellas, vaquero

Esta entrada en mi blog la dedico a todos aquellos que borran sus huellas en el trabajo. Los que sólo guardan los ficheros en su última versión. Los que no versionan los documentos. Los que cuando tienen un fichero incompleto lo destruyen al comenzar uno nuevo.

Son los amigos de lo imperfecto. Tal vez sea la obsesión de aparentar perfección, o no mostrar debilidad, tan habitual en algunas empresas.

No se trata de guardar un registro de todo lo que hacemos, sino más bien de protegernos de nosotros mismos. Después de todo, la mayoría de herramientas de versionado de código nos protegen de nuestras ganas de cambiar el código en exceso, permitiéndonos recuperar una versión previa que funcionaba o que simplemente queremos revisar. Si estamos de acuerdo en el caso del código fuente...¿qué pasa con la documentación?

La documentación es parte del proyecto.

Debemos cuidar la documentación, tal y como hacemos con el código. De nada servirá esto a los que entienden que la documentación se hace "después del código".
Cómo me duele ver en los diseños técnicos o funcionales, código fuente o pantallas que se han obtenido de la versión final.
Los documentos  hay que versionarlos y cuidarlos como cualquier otro resultado de nuestro trabajo.

La necesidad del versionado.

Algunas ventajas de tener la documentación versionada en un repositorio:

• Documentación alineada con cada versión del código.
• Es fácil identificar los cambios en los objetivos, del mismo modo que el versionado del código permite identificar los cambios en los resultados.
• Acceso centralizado. Al estar la documentación versionada y centralizada, todo el mundo accede a la última versión.
• Notificaciones de versionado. Muchos repositorios de documentos avisan de nuevas versiones. Esto es útil porque el equipo de desarrollo puede estar informado de cualquier cambio en una Historia de Usuario, un Requisito (o como lo queráis llamar).
• Permite escalar proyectos. Es muy sencillo trabajar con post-its para documentar requisitos, pero escalarlo a un equipo de 50 personas en 10 países, no es sencillo. En un repositorio documental, incorporar a un nuevo equipo en otro país es tan simple como darles acceso.
• Utilizar un repositorio permite ahorrar reuniones: todo el mundo puede estar al tanto de que se está cociendo una nueva versión de los requisitos, o de que se han modificado 5 de las 10 historias de usuario de nuestro producto. Esto no significa que no sean útiles las reuniones. Simplemente se trata de que las herramientas hagan el trabajo más simple.

¿Y qué hacemos en un proyecto pequeño?

Si tu proyecto es muy pequeño, puedes hacer el versionado de forma manual. Guarda el archivo como "requisitos_v02" y ya está. También puedes integrar la documentación como parte del código, y que tu herramienta (Subversion, Git, etc), se encargue del resto.
De todas formas, es útil seguir con la documentación, las mismas técnicas que un repositorio de código:

• Check-out: Avisa de que el documento lo vas a modificar. Que la gente tenga claro que hay una nueva versión en curso. Eso les hará organizarse mejor y centrarse en las áreas que menos cambios vayan a tener. Pocas cosas molestan más que ver cómo llega un gran cambio sobre algo en lo que hemos dedicado varias semanas con sus larguísimas jornadas. Y más cuando hay otras tareas que podríamos haber avanzado en su lugar. Avisa de la fecha prevista para terminar la nueva versión.
• Check-in: Avisa de cada nueva versión. Que la herramienta (o tú mismo mediante un correo), notifique al equipo de una nueva versión de lo que sea (requisitos, análisis, etc). Hazlo ágil y simple. Tanto para el que lo lee, como para tí que lo escribes y que lo vas a tener que actualizar.

Actitud y respeto, fuentes del problema.

Al final, es una cuestión de respeto profesional, de velar por que nuestras acciones ayuden en lugar de interferir al resto del equipo. De intentar prever las consecuencias de nuestros actos, no limitarnos a soltar nuestro (llámalo código, documento o lo que sea), y darnos la vuelta para no ver los resultados.

Muchas veces oigo a la gente quejarse de lo mismo repetidas veces: "para qué documentar si nunca voy a tener la documentación actualizada". Es deprimente, ya que muestra un grave problema de actitud. Hazlo o no lo hagas, pero no lo intentes. Deja ya esa actitud derrotista, por favor. ¿Somos ágiles y por tanto capaces de abrazar los cambios en el código? ¿Y sin embargo no somos capaces de hacer lo propio con la documentación? Claro que van a llegar cambios, es algo inherente en el software. El problema está en que no documentamos, sino que escribimos novelas.

Yo no sé si hay falta de programadores, pero de lo que estoy seguro de que sobran novelistas, y faltan buenos analistas o arquitectos que documenten los objetivos técnicos y funcionales. Menos verborrea, y más UML, casos de uso, historias de usuario.

Norma EN 301 549 - Requisitos de accesibilidad

Hola a todos, se ha publicado recientemente la EN 301 549, norma europea sobre requisitos de accesibilidad en la contratación pública de productos y servicios TIC en Europa. Habrá que prestar atención a esta norma europea de usabilidad, especialmente de cara a contrataciones públicas.

La norma está disponible para descarga en:
http://www.etsi.org/deliver/etsi_en/301500_301599/301549/01.01.01_60/en_301549v010101p.pdf

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.

MasterDev, el MasterChef del software

Hala, por fin se ha acabado en España la versión infantil o "Junior" de un conocido concurso internacional de televisión llamado "MasterChef".

Yo, personalmente, os propongo hacer uno parecido llamado "MasterDev". Los objetivos de este nuevo concurso serían más o menos los siguientes:

• Los concursantes, tendrían una sección inicial del programa en el que se mostraría el lado humano: cómo han convivido, cómo han aprendido las últimas técnicas de programación, frameworks, lenguajes, etc. Se les vería su día a día encerrados en "la casa", donde tendrían sus momentos de roce, tensiones internas, se formarían grupos...
• Por supuesto, habría un apartado de "expulsados" en el que los concursantes elegirían a los 3 nominados. De entre ellos, uno sería expulsado por votación del público.
• Finalmente, el plato fuerte del programa sería el desarrollo "en directo" de una aplicación, basada en los requisitos y exigencias de los chefs (bueno, en este caso, scrummasters o similar). En este apartado, unos famosos programadores harían de estrellas invitadas y propondrían los casos de uso a desarrollar. Serían los jueces que elegirían a los mejores programadores cada semana. Éstos "Master-Dev" podrían salvar a uno de los nominados, tal y como se hace en otro conocido concurso: "Gran Hermano". Durante esta parte del programa, se nos estaría mostrando a los programadores llevando a cabo las tareas encomendadas, con la tensión de ver el reloj. Para darle mayor realismo, podría ser un reloj marcando la hora de salida del  trabajo, lo que aportaría una tensión increíble.
• Finalmente, el momento culmen del programa sería cuando los jueces irían diciendo los puntos fuertes y débiles de cada programador, y se elegirían los "Master-Dev" de la semana.

No sé lo que os parece, pero yo creo que no tendría la misma tensión que el programa original "MasterChef". Ver 20 minutos a una serie de programadores, sentados en sus sillas, tecleando como si les fuera la vida en ello, no se si sería digno de ocupar el prime-time de las principales cadenas de televisión.
En el cine, "Swordfish" (2001) ha sido una de las películas en las que más tensión se ha podido observar mientras se mostraba a un programador (Hugh Jackman) tecleando en sus teclados y observando con pasión sus múltiples monitores. Sin embargo, veo difícil el llevar esto a la televisión, especialmente recordando el motivo que hace que Hugh Jackman salve su vida cuando es sometido a presión por John Travolta (sí, se trata del trabajo realizado por cierta señorita). Por cierto, ver a Hugh Jackman programando un peligroso virus simplemente "pegando" cubos entre sí en pantalla, es un puntazo. No tendría la misma tensión si "Swordfish" tuviera un diálogo más realista:
- "A ver...mierda. Me he dejado un punto y coma"
- "Compilo...y a ver....15%....40%....mierda. Dos warnings y 1 error. Pues vaya."
- "A ver...busco el error en google, pero ¿esto que es?"
- "Ah ya lo tengo. Venga, cambio el tipo de la variable....añado el parámetro que faltaba..."
- "Compilo...y a ver...15%...40%...(dios que lento)...60%...mierda. Otro error."

Tal vez se le podría dar algo más de emoción. Y no, no me refiero al trabajito que le hacen a Hugh Jackman en SwordFish para motivarle. Me refiero a comentarlo como si fuera....no sé...un partido de fútbol:
- Atención, John recibe el código, lo compila yyyyyyyyy Uyyyyyy. Un erroooor. Sí señores, un error ha entrado de llenoooooooo. Neumáticos Martinez, los mejores. Compreeeee neumáticos Martínez.
- Señoras y señores, qué tensión! John todavía no ha corregido su error, y Anthony ha compilado con éxito atencióoooooon que ha compiladoooooo.
- Cuidado, cuidado, que un tercer programador está a punto de terminar, es Juan. Recuerden que Juan no había destacado en otros programas, pero ha terminado sólo 1 segundo y 3 décimas por detrás de Philips. Cuidado, todavía no han hecho checkin! Beba Rock-cola, burbujeante, maravillosa!
- Increible! Philips ha perdido el código! Error de aplicación, eso lo deja fuera del concurso! Qué tensión, John está terminando de depuraaaaaar yyyyy gana Juan!  Por tan sólo unas líneas de código por delanteeeeee.

¿Y vosotros? ¿Os gustaría ver un "MasterDev" como concurso?
En fin. Feliz año nuevo.

Update: Gracias a Julián Gómez por la idea de cambiar el titular, y por leerme. Me había quedado muy simplón como "MasterDev" sin más.