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.

Más Singletonitis

Recientemente, he escrito una entrada sobre la Singletonitis, y hoy me he encontrado con una entrada en un interesante blog, que habla también del tema, abordando incluso aspectos que había pasado por alto.

Al final, el abuso de los patrones está encontrando la horma de su zapato: lo que hoy nos parece una buena idea, mañana resulta contraproducente. El antiguo patrón singleton, tan sencillo, resulta ser un dardo envenenado a prácticas tan aceptadas como indispensables hoy en día como el uso de pruebas unitarias.

Sin embargo, la alternativa es difícil. El autor de este blog propone el uso de otro patrón de diseño, que si bien es similar funcionalmente (el llamado patrón monostate) , resuelve los problemas del Singleton (aunque a costa de una implementación compleja).

Fuentes: enlace.

Un saludo.

Toma de Requisitos - Paso 6: Completar el prototipo

Hoy vamos a continuar explicando los pasos necesarios para una toma de requisitos, con el paso nº 6: completar el prototipo.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Una vez hemos llegado a este punto, y tenemos una guía de estilo en condiciones, podremos pasar a completar el prototipo hasta hacerlo totalmente funcional.

Ojo, no estamos diciendo que el prototipo se acabe convirtiendo en la aplicación final. Esto ha sido ampliamente discutido en muchos foros, y tiene sus defensores (especialmente en el ámbito del software ágil) y sus detractores (especialmente desde el punto de vista de la ingeniería del software).

De esta forma, se consigue que los desarrolladores tengan una visión completa de lo que será el producto final. Hay dos visiones:

• La visión del producto permite alinear el trabajo de los desarrolladores.
• El prototipo detallado permite una visión mucho más detallada, facilitando a los desarrolladores el trabajo.

El prototipo, llegados a este punto, deberá ofrecer toda la funcionalidad del software, con al menos:

• Todos los cuadros de diálogo, incluyendo los cuadros de diálogo estándar como Abrir, Cerrar, Imprimir, Guardar, etc.
• Todas las pantallas de inserción de datos.
• Todas las salidas de datos (pantallas, informes, listados...)
• Todas las interacciones con el sistema operativo (ejemplo: importación y exportación al portapapeles).
• Interacción con sistemas externos y otros productos de terceros.

El prototipo contendrá por tanto las principales interfaces:

• Con el usuario
• Con el sistema operativo
• Con otros sistemas externos

Llegados a este punto, tendremos que hacer una línea base (no olvidemos la gestión de la configuración, que sea un prototipo-borrador no significa que debamos correr el riesgo de perderlo!!).

Tal y como establece Steve McConnell en su magnífico libro Software Project Survival Guide:

"No deberías usar un prototipo como la base de software real, así como no deberías usar un decorado de Hollywood como base para una casa de verdad".

El prototipo es un callejón sin salida, útil, pero un callejón sin salida. No ha habido una arquitectura, no está preparado para construir sobre él la aplicación final. La mayoría de autores recomiendan construir el prototipo en un entorno y en un lenguaje de programación que facilite el desarrollo rápido, pero que claramente no vaya a usarse en el desarrollo final. Por ejemplo, úsese Visual Basic o un lenguaje similar de alto nivel, cuando el desarrollo final vaya a ser en Java o C++ o C#. Esto evitará tentaciones más adelante.

Ética e Ingeniería del Software

Fuente: http://www.asme.org/

Recientemente, en el blog de Javier Garzás he leído un post donde se propugna algo que llevo repitiendo hasta hartarme desde el primer post: que debemos comportarnos profesionalmente, de forma ética.

No somos charlatanes, patanes de feria que vendemos lo que nos convenga en función del beneficio que nos proporcione. En lugar de eso, damos al cliente lo que necesita en cada momento, maximizando su satisfacción y nuestro beneficio a largo plazo. Porque creemos en que la relación con nuestros clientes se cimenta en una confianza mutua, y ésta sólo puede realizarse a largo plazo.

Esta forma de pensamiento la he visto como eco en algún otro post. Me hace mucha gracia, que Javier afirma: "una metodología no es un equipo de fútbol, ni un partido político, ni una religión". Sin embargo, leo por doquier en la red continuas llamadas talibanistas a defender la religión del bloguero de turno:

• Metodologías ágiles
• Software libre
• CMMI
• Integración continua
• <Pon aquí tu práctica/metodología/marco de trabajo>

El pensamiento que defiendo es similar al promulgado por Alistair Cockburn hace ya unos años:

"Estoy cansado de la gente que es de una escuela de pensamiento y que rechaza las ideas de otra escuela de pensamiento. Tengo hambre de gente que no le importe de donde vienen las ideas, que les importe sólo lo que significan y lo que producen. Así que se me ocurrió esto del “juramento de no lealtad”.
Esto significa el fin de afirmaciones como “eso no está bien – no es ágil / orientado a objetos / puro / etc.”, en vez de discutir sobre si la idea (ágil o tradicional o impura o lo que sea) funciona bien en las condiciones del momento."

Por desgracia, hay gente que incluso afirmando defender estas ideas, confiesa sus prejuicios y reticencias al respecto de ciertas formas de trabajar: "metodologías", "prácticas", "marcos de trabajo"...llamadlo como queráis.

Podemos estar convencidos de una cosa, pero no debemos defenderla si no es con argumentos probados, objetivos y no sólo cualitativos sino también cuantitativos. Por desgracia, esta forma de pensar encaja perfectamente en los que yo llamo "indecisos patológicos" o "charlatanes del depende". Sí, ya los conocéis. Me refiero a los que siempre contestan a todo con un "depende" (hasta aquí todo va bien), pero que cuando se les pide algo más de detalle o chicha en su discurso, podemos tener dos tipos de respuesta:

• Verborrea coherente pero carente de fondo y forma, que al final no termina de dar ningún tipo de argumento veraz ni mucho menos objetivo hacia un lado u otro. Esta verborrea de político le viene muy bien a algunos individuos, que incluso les facilita la promoción profesional. Pero lástima de los clientes que acaben con ellos, y mucho peor: lástima de los que acaben en un proyecto dirigido por estos pseudo-profesionales.
• Verborrea que sólo está orientada a alimentar el ego del que escucha. Son los llamados aduladores, los pelotas, que difícilmente terminan hablando del tema, sino que redirigen la conversación a un terreno menos objetivo y relacionado con el proyecto en cuestión.

Al querer escribir yo este post, me he encontrado con otro post bastante interesante. En él, su autor deriva la conversación a la ética informática, y al colegio profesional. Este autor, plantea la existencia de un tribunal de ética. Yo no sé lo que pensaréis pero empiezo a estar harto de tribunales, comisiones, cortes, comités de supervisión, equipos de trabajo, etc, etc. Y estoy harto de apelar siempre a un "ser superior" que nos proteja y defienda.

Es muy fácil: lo único que puede definir el comportamiento ético o no en un proyecto es la documentación. Los criterios objetivos, y la forma en que se basan y defienden, es lo único que puede usarse como valor ético en un proyecto. Pero claro, decir esto cuando la moda es ir en contra de la documentación, ser ágil, y entregar todo de forma rápida (y sin documentación), es poco menos que escupir al viento. Pero no deja de ser cierto. No es posible verificar la ética en un proyecto sin contrastar el contrato, con las decisiones tomadas (y las decisiones, o se documentan...o se pierden). Y es así en todas las profesiones.

Después de todo, en una profesión en la que no hay estándares cerrados, en los que no hay normas internacionales que establezcan la forma correcta de trabajar, todo vale. No podemos a la vez defender que hacer software es un arte, y al mismo tiempo querer crear Colegios, Comisiones éticas que verifiquen el buen hacer...respecto a qué?

En fin...excelentes Alistair Cockburn en su comentario, y Javier Garzás y Jorge Ubeda en sus respectivos posts. Espero que esta pequeña reflexión mía haya podido aportar algo.

Cuando la culpa no es del usuario II

Recientemente he conocido a Martin, y me ha comentado que le ha gustado mi post "La culpa no es del usuario".

Martin es un profesional en un sector difícil y cada día más competitivo. Conoce, aunque no es profesional del sector, la tecnología en sus diversos ámbitos. Le tocó sufrir la desidia y dejadez de las empresas de telefonía móvil en España, que muchas veces no se molestan en tener actualizado su software.

Recientemente, Martin quiso probar la disponibilidad y cobertura en su domicilio de una conocida empresa operadora de ADSL. Para saber si había cobertura, tenía que rellenar un formulario. En el mismo, se le solicitaba su dirección y número de teléfono. Nada fuera de lo normal hasta ahí. Sin embargo, cuál no sería su sorpresa al comprobar que no funcionaba. La respuesta fue que su número de teléfono estaba equivocado. Martin lo comprobó una y otra vez. Pero la respuesta fue la misma.

El software estaba equivocado, no su número de teléfono. En España, los teléfonos fijos empezaban en "9". Sin embargo, algunas provincias, han ampliado su capacidad utilizando números que empiezan en "8". ¿Resultado? Aunque ya hace bastante tiempo que existen números de teléfono que empiezan en "8", el proveedor de ADSL seguía con un software obsoleto, incapaz de adaptarse a esta realidad.

¿Y ahora qué? Pues este conocido operador de ADSL ha perdido a un cliente. Ha hecho perder el tiempo a este señor (y seguramente a muchos más).

Como he dicho ya muchas veces en este blog, lo importante, la base de todo desarrollo son los requisitos. Y este caso es un claro ejemplo de requisitos mal tomados y mal implementados.

Además, fallaron las pruebas. No se definieron correctamente pruebas que recogieran las diversas posibilidades. Los casos de prueba no contemplaron las posibilidades.

Al final, por muy ágiles que seamos, por muy rápidos que queramos ser al poner un producto al mercado, no puede ser despreciando un mínimo de disciplina en estas áreas tan necesarias: requisitos y pruebas.

Gracias Martin por dejarme este comentario tan real como aleccionador.

La culpa no es del usuario

Hoy vamos a ver quién tiene la culpa de los fallos del software.
Me acabo de encontrar una referencia a mi antigua entrada "Cuando la culpa es del usuario", en la que yo bromeaba sobre quién tiene la culpa de los fallos en el mundo del software. Yo pensaba contestar o comentar en aquél blog, pero al final, había que registrarse y he desistido. Sin embargo, al ver los argumentos a favor y en contra, he pensado que hay que darle otra oportunidad a mi antigua entrada, y recuperarla, esta vez de forma algo más seria.

¿Quién tiene la culpa de los fallos del software?

Vamos a verlo con un ejemplo. Supongamos que hacemos una casa: planos, diseño, ejecución de la obra...todo. Y el usuario entra en la casa a vivir. Hemos construido la casa en base a las funcionalidades habituales: comer, desayunar, ir a dormir, ir al baño, entradas de luz, etc. Además, hemos cumplido las normativas existentes: seguridad, anchura y altura de puertas y ventanas, acceso de luz, aislamiento térmico, etc.

Supongamos que el usuario hace algo imprevisto como intentar salir por la ventana (y es un 8º piso). Si se muere, ¿está claro que es su culpa, no? Pero si le dejamos abierta la puerta al cuarto de alta tensión y no ponemos ninguna medida de seguridad...si se electrocuta y muere...quizás la culpa SEA NUESTRA.

Ahora supongamos que hace otras cosas como entrar por el garage en vez de la puerta de entrada, o tiene la absurda (o no tan absurda?) idea de comprar un sofá o una cama y éstos no caben por la puerta. Puede también querer mirar por la ventana, y encontrarse conque ésta da a la pared del siguiente edificio al que el nuestro se encuentra pegado (vamos, que sólo va a ver y tocar pared). ¿Quién tiene la culpa de esto?

Volvamos al mundo del software y veamos unos pocos casos más tecnológicos:

• El usuario entra en una parte no permitida del sistema. No podemos impedir que alguien obtenga una contraseña. Hasta ahí es cierto. Pero es nuestra responsabilidad como desarrolladores de software, que no sea posible acceder a partes del sistema restringidas, con una clave no autorizada. Esto me hace mucha gracia, porque tenemos la chulería de exigir que Windows sea super-mega-seguro...pero luego hacemos aplicaciones con más agujeros que un colador. Y entendemos que necesitamos un tiempo razonable para probar y corregir nuestros agujeros de seguridad (somos humanos, verdad?), pero no tenemos la misma tolerancia cuando en vez de desarrolladores, somos usuarios. Exigimos que el programa o sistema operativo que falla, se corrija DE INMEDIATO (los que lo programan no deben de ser humanos, sino robots). Y gratis. Y....vamos, que está claro que sabemos pedir...pero no dar. Exigimos derechos desproporcionados a los deberes que asumimos.
• El usuario juega con el sistema. Pues que juegue. Es el usuario. ¿Que lo rompe o cuelga haciendo alguna tarea prohibida? Para eso están los logs. ¿Que mete datos estúpidos o incorrectos? Para eso están los logs y el sentido común. Por supuesto, también están las validaciones de datos. Si permitimos "XXX" como fecha de nacimiento, probablemente la función de cálculo de Edad fallará.
• El usuario tiene que sacar su trabajo, que no es precisamente saber de la tecnología interna del programa. No tiene porqué saber si es puro Java, o JQuery...o lo que sea.

En fin, habría muchos más ejemplos que ahora mismo no tengo tiempo de abarcar. Pero sí me gustaría comentaros un caso real de un colega de profesión ha tenido, y que creo que va a ser representativo.

Caso real.

• Se trata de una aplicación web.
• En uno de los cambios de especificación, se añade soporte para iPad.
• La aplicación se prueba, y funciona correctamente en varios navegadores, tanto en Windows como en dispositivos iPad (hasta en Android!)
• Cuando llega el usuario, descubre que cierta funcionalidad, sólo está disponible con ratón: al pasar el ratón por encima de los elementos de la página, aparece una información específica de cada elemento. Esto, se introdujo por diseño para disminuir la información de pantalla. Y está genial. Pero un iPad no tiene ratón.
• Resultado: enfado del usuario y rediseño de la aplicación.
• ¿Quién tuvo la culpa?

Conclusiones:

Para acabar, resumamos las conclusiones de lo que hemos visto, y de lo que la experiencia me ha hecho ver en todos (y son muchos) estos años:

• El usuario no tiene culpa alguna de los errores que se producen.
• Es nuestra responsabilidad poner "paredes" y "puertas y ventanas" a la aplicación para permitir el acceso o no a las funcionalidades.
• Es nuestra responsabilidad cumplir las normas y estándares existentes, así como adaptarlos no sólo al tipo de usuario, sino al entorno (hardware y sistemas software con los que interactúe).
• Es nuestra responsabilidad identificar posibles interacciones del producto con otros productos, y ponerlo  como funcionalidades (si funciona) o restricciones (si no funciona).
• Es nuestra responsabilidad probar. Y probar todo, o asumir los riesgos de lo que no se prueba. Leía recientemente un post donde un compañero de profesión decía que no se puede cubrir todo con las pruebas. Y es cierto. Pero eso no significa que nos tapemos los ojos e ignoremos los riesgos.
• Automatizar es la clave: debemos hacer pruebas unitarias, y automatizar también las funcionales en la medida de lo posible. En el caso real que se ha mencionado, el problema no era del usuario, era de que no se hicieron todas las pruebas en todos los entornos. Si probar todo en tu PC cuesta 2 días...añadir un nuevo entorno (iPad), costará el doble (bueno, es una primera estimación).

Toma de requisitos - Paso 5: Crear una guía de estilo

Hoy vamos a ver el paso 5º de la guía sobre toma de requisitos.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Los usuarios han aceptado y validado el prototipo (sí, eso fue el Paso 4 anterior). Así que ahora, los programadores deberían crear una guía de estilo: un pequeño manual o guía que identifique los estándares de estilo a seguir durante el inminente desarrollo software.

A ver, que esto no es una metodología: no hacen falta 200 páginas. Ni 20. Seguramente, con un par de páginas será suficiente. Habrá que añadir:

• Estilos visuales
• Imágenes con las pantallas más representativas (los 2 o 3 tipos de pantallas o cuadros de diálogo a mostrar).
• Ubicaciones de los botones, incluyendo los más habituales (Aceptar, Cancelar, etc).
• Estilos visuales: efectos, colores, tipos de letra.
• Mensajes de texto a mostrar. Se trata de buscar una terminología común, que todos los conceptos tengan un nombre único, usado de forma consistente en todas las pantallas, y sea un nombre familiar en el contexto del negocio del cliente.
• Estándares existentes a los cuales nos vamos a adherir sobre todo a nivel de usabilidad y accesibilidad.

Por supuesto, tras completarla, deberá revisarse y hacer una línea base (ponerla bajo control de cambios). Para esto no hace falta nada del otro mundo: un subversión o un repositorio similar bastarán.

Los estilos visuales, cuanto antes sean definidos, más fácilmente lograrán que haya consistencia en la interfaz de usuario. Después de todo, los requisitos cambiarán. Pero el aspecto visual ,es un buen sitio por el que empezar como base.

Para finalizar, van algunos estándares o normas relacionadas con los interfaces:

• ISO/IEC 9126: evaluación de productos software.
• ISO 9241: requisitos ergonómicos para trabajar con terminales de presentación visual (VDT)
• ISO/IEC 10741: interacción de diálogos.
• ISO/IEC 11581: símbolos y funciones de los iconos.
• ISO 11064: diseño ergonómico de centros de control.
• ISO 13406: requisitos ergonómicos para trabajar con presentaciones visuales basadas en paneles planos.
• ISO 13407: procesos de diseño centrados en la persona para sistemas interactivos.
• Guías de estilo para la web: IBM, W3C

Toma de requisitos - Paso 4: Presentar el prototipo

Hola, hoy vamos a ver el paso siguiente (Paso nº 4 en nuestra secuencia) en la definición de los requisitos, y para ello, tendremos que presentar a los usuarios, el prototipo que con tanto mimo hemos creado.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

En primer lugar, hay que hacer notar que la primera versión de un prototipo difícilmente va a gustar a los usuarios. Es algo normal, sus expectativas no van a cubrirse en esta primera versión.

Lo que hay que buscar en realidad es el feedback de dichos usuarios clave: sus comentarios son oro. Y lo son, porque tan sólo cuando esos usuarios ven el prototipo, la maqueta de nuestra aplicación, es cuando van a darse cuenta de detalles que habían pasado por alto, de información que difícilmente podría ser obtenida de otra manera.

Por supuesto, a los usuarios hay que dejarles claro que es un prototipo: ni hemos tenido un avance del 40% del proyecto en dos días, ni los problemas que vayan a surgir en la revisión han de ser tenidos en cuenta. Hay que tranquilizar a los usuarios en este sentido: aún estamos muy lejos de cerrar el prototipo, y por tanto, aún más lejos de tener avanzado el desarrollo del producto.

Es en esta fase cuando tendremos que hacer un auténtico ejercicio de usabilidad: conseguir no sólo que los requisitos se satisfacen, que han sido correctamente identificados. Además de esto, el producto debe ser sencillo, lógico, fácil de usar.

Es importante notar que en esta fase, hay que estar volcado al 100%, y hay que tener experiencia en el área que estamos prototipando. Si no es así, ni va a ser sencillo de usar, ni tampoco va a satisfacer las necesidades de los usuarios.

El objetivo final de esta fase es conseguir el apoyo, la excitación de los usuarios al lograr consciencia de que efectivamente, hemos entendido sus necesidades, y además, el producto va a facilitarles el día a día. No se trata de "satisfacer requisitos", sino más bien de satisfacer a los usuarios finales.

En esta fase, puede pensarse que se está perdiendo un tiempo precioso en algo que va a tirarse a la basura. Después de todo, ese es el final de todo prototipo. Nada más lejos de la realidad. Al contrario, todo el esfuerzo invertido facilitará y acelerará el desarrollo posterior, evitando problemas, revisiones, y cambios de última hora.

Como ya he comentado, es fundamental aclarar a los usuarios que el producto es un prototipo, un mero "esbozo" de la realidad que aún está por construir. Por eso, al final, vuelve a servir lo que comentaba en el artículo anterior, en el paso 3: las herramientas de prototipado simples como el Paint o PowerPoint, o un dibujo en un papel, son mucho más efectivas. Esto es así porque el usuario las percibe como algo realmente temporal, no aprovechable. Si nos liamos a hacer mucho código, HTML, css, JavaScript, menús desplegables, etc, etc el usuario pensará que lo que está probando es ya un producto real. Después de todo, se instala, se usa, y da resultados como un producto real. Si caemos en la trampa de dar un prototipo demasiado realista, el cliente pasará a meternos presión, ya que pensará que le estamos engañando, y que en realidad, tenemos ya avanzado buena parte del desarrollo.

Es importante dar también una fecha límite a la fase de revisión del prototipo: 2 o como máximo 3 revisiones de prototipo, deberían ser suficientes. Si nos alargamos en su revisión, sí que podremos poner en peligro el plan general del proyecto.

Si quieres volver al índice haz clic en: Índice.
También puedes ir al paso anterior de la toma de requisitos haciendo clic aquí: Paso anterior.

Toma de requisitos - Paso 3: Cómo hacer un prototipo

Para que tu prototipo sea a prueba de idiotas...busca uno

Hacer un prototipo no es tan fácil como parece. Conviene seguir unas reglas, para que a la hora de continuar el desarrollo, no nos encontremos con problemas. Veamos un poco de qué hablo.


Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Simple.

El prototipo ha de ser simple. Se trata de ofrecer al usuario alternativas, de que pueda explorar cómo va a ser el sistema. Es por tanto el momento de explorar, de ofrecer opciones en cuanto a usabilidad, estilos, etc.

Alcance.

Se trata de ahorrar esfuerzos. No hace falta explorar todas las posibilidades, de abordar todos los casos de uso. De ofrecer todos los mensajes de error. De lo que se trata es de que el usuario reciba suficiente feedback de cómo se va a comportar el sistema. Para ello, hay que definir un alcance limitado, para que los esfuerzos de desarrollo también lo sean.

Por ejemplo, nos limitaremos a realizar los principales casos de uso. Es más interesante que cubramos una operación completa de varias pantallas, que por ejemplo cubrir una acción en cada pantalla.

El usuario no va a ser consciente de que funciona todo o parte en cada pantalla. Lo importante es que hemos cubierto una parte mayor de la aplicación. Por ejemplo, en un ERP haremos un alta en almacén, un alta de cliente, un alta pedido de ese cliente, y facturaremos ese producto para finalmente, contabilizarlo. Un caso de uso simple de cada pantalla, de forma que se cubra una gran parte del sistema.

Es más importante obtener la visión del look&feel, de qué se hace y cómo.

Herramientas.

¿Qué herramientas utilizar?Las más simples. Podría utilizarse HTML puro y duro en lugar de Java o código .Net. Pero tampoco es descabellado prototipar con herramientas más cercanas al diseño como Visio, Powerpoint o el mismísimo Paint que viene de serie en Windows.

¿Porqué no usar algo más elaborado como una herramienta profesional de prototipado? Pues porque precisamente en esta etapa, y los seguidores de las metodologías ágiles lo sabrán muy bien, no sirven mucho. Y no sirven, no porque sean malas, sino porque en esta etapa los requisitos aún son muy volátiles. Estas herramientas de prototipado pretenden ahorrar esfuerzo posterior, creando un sistema aprovechable. Sin embargo, el sistema no se va a aprovechar. El gran número de cambios lo echaría atrás. Claro, esto no ocurre cuando los requisitos tengan poca volatilidad. En ese caso, el sistema sí que puede prototiparse con herramientas que nos permitan en el futuro aprovechar los flujos, la estructura, o incluso el código.

Una recomendación: por simple que sea nuestro prototipo, si tiene código, siempre puede tener un error. después de todo es un prototipo. ¿Vamos a poner código de gestión de errores? ¿De logging? ¿Y qué más? ¡Si no hace falta! Queremos mostrar qué se va a hacer, nada más. Una pantalla Powerpoint, una imagen hecha con una herramienta de dibujo rápido, sería suficiente. Que la herramienta haga el trabajo por nosotros: para pasar de una pantalla a otra, usemos las acciones de Excel, de Powerpoint por ejemplo.

Otra ventaja de los prototipos hechos como "documento", es que difícilmente tienen errores. No dependen del PC en que se van a ejecutar. Se pueden mandar al cliente, ejecutar directamente desde un correo, sin instalación. Ni siquiera hace falta que se copie una carpeta con código HTML en el escritorio. Con que esté instalada la aplicación (Word, Excel, Powerpoint...es suficiente). Con algunos productos, es posible convertirlos en "ejecutable", de forma que en cualquier PC con Windows funcionen.

 

Detalles.

Los detalles, hay que cuidarlos pero con mínimo esfuerzo. ¿Que hay que sacar un informe al pulsar el botón "Imprimir"? Pues se muestra un documento de texto simulando el informe, o se muestra una imagen que muestre un informe típico.

Si queremos ahorrar esfuerzo mostrando datos encolumnados, nada más simple que usar una Excel, pegar ahí los datos a mostrar, y al ocultar la cuadrícula de fondo...¡premio! Tenemos un report simulado. También podemos simular la paginación, poniendo imágenes en celdas de forma que parezcan el botón "siguiente", y que dicho botón sirva de hipervínculo a la página siguiente del informe (también simulada, por supuesto).

Esfuerzo

Con todo lo dicho, hay que conseguir máximo en diseño, estilo y apariencia...pero con el mínimo esfuerzo. Si los datos son fijos, o se muestran en una imagen, no importa. Pero el esfuerzo por pantalla o acción debe ser el menor posible.

Es muy importante repartir adecuadamente el esfuerzo durante el prototipado. Si contamos con equipo que conozca el diseño gráfico, utilicémoslo. Si alguien conoce Powerpoint y su facilidad para crear vínculos y botones que nos lleven de una slide a otra...adelante. Es mejor que el equipo se sienta a gusto y explote una herramienta, que nos perdamos intentando usar la última "mega-herramienta-de-prototipado" del mercado.

La profundidad funcional ha de ser muy liviana. Si dedicamos por ejemplo más de 1h por pantalla, ya es demasiado. Mejor centrarse en pintar el aspecto y que "de el pego", que dedicar la hora a cargar datos XML y aplicar una hoja de estilos.

Como veo que el artículo me está saliendo muy largo, si no os importa, dejaré para una segunda parte todo lo que tengo en mente seguir contando sobre los prototipos.

Para ver el índice de artículos sobre Toma de Requisitos, haz clic aquí.
Para ir al paso anterior (nº2: Entrevistas), haz clic aquí.

Toma de Requisitos - Paso 2: Entrevistas





Reuniones según Dilbert



Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Para poder identificar los requisitos preliminares, es habitual llevar a cabo entrevistas (reuniones) con los usuarios clave, principalmente. A partir de los requisitos que se identifiquen, se creará posteriormente un prototipo que permita identificar la interfaz de usuario, y el flujo de la aplicación.

Steve McConnell, en su "Software Project Survival Guide" ya avisa de que los programadores, la gente que nos dedicamos al desarrollo de software, no somos buenos diseñando software que realmente guste a los usuarios. La buena noticia, es que sí que podemos ayudar a los usuarios clave a descubrir lo que les gusta, gracias a que los propios usuarios tampoco suelen ser buenos diseñando software.

Cómo preparar las entrevistas: Fases

Fase 1: Preparación previa.

• Fijar objetivos
• Seleccionar los asistentes (en realidad esto ya lo hemos hecho en el paso anterior de la toma de requisitos: seleccionar a los usuarios clave).
• Acordar con los asistentes el día, hora, lugar y duración de la reunión, al menos inicialmente.
• Hacer los deberes: obtener información previa de los usuarios clave que van a asistir, sus necesidades, su negocio, las aplicaciones o productos que utilizan, los proveedores de servicios actuales...vamos, auténtica labor de detective.

Fase 2: Planificación.

• Preparar un orden del día, así como los materiales necesarios.
• Comunicar el orden del día a los asistentes
• Enviar la convocatoria de la reunión a los asistentes, gestionando las confirmaciones, de forma que se replanifique la fecha, hora o lugar si es necesario.
• Crear expectativas. Esta es la parte más delicada: es posible manejar las expectativas de los usuarios clave desde antes de la propia entrevista de recogida de requisitos.

Fase 3: Ejecución

• Hacer preguntas claras. Honestidad y sinceridad. Queremos solucionar los problemas del cliente.
• No debemos obsesionarnos con la tecnología.
• No debemos obsesionarnos con el cómo ni el cuándo, sino con el qué. Debemos aclarar qué necesita.
• Humildad. Solemos intentar proponer sistemas maravillosos cuando en realidad el cliente ya tiene sistemas muy buenos que cubren un porcentaje grande de sus necesidades. Es importante empezar aprendiendo (además del trabajo previo que ya deberíamos haber hecho) de qué y cómo se hace actualmente.
• Una vez aclarado el qué, podemos pasar al cómo, pero siempre a nivel funcional, sin tecnicismos.
• Es importante usar un lenguaje no técnico, o en todo caso, hablar en el lenguaje de su profesión o negocio, no en el nuestro. Pocas cosas hay tan irritantes como un joven friki sacando constantemente temas técnicos que no vienen a cuento.
• Limitar lo que pide el cliente o usuario clave.
• Detectar dependencias con temas que ya hayan comunicado otros usuarios clave, y anotar todo lo que se diga, ya que pueden ser pistas para lo que se trate en próximas entrevistas con otros usuarios.
• Paciencia y respeto.
• Anotar todos los detalles.
• Los plazos no son importantes aún: no está definido el alcance, ni cómo vamos a implementarlo, por lo que los plazos no deben ser un bloqueo.
• No adelantar la solución técnica. No matemos a la gallina sin haber empollado aún el huevo.

Fase 4: Revisión

• En esta fase la temática es simple: revisar todo lo que hayamos anotado y asegurarnos de que incluso lo no anotado en la reunión, se registra y no se pierde.

Fase 5: Consolidación

• Una vez que tenemos la documentación de la entrevista, habrá que consolidarla. Reducirla. Quitar lo redundante, lo que ya se haya obtenido en otras entrevistas. Quitar lo que corresponda a otras entrevistas (con otros usuarios clave), y completar su documentación allí.
• Revisar otras entrevistas, y actualizar las dependencias entre los resultados de las distintas entrevistas. 

Problemas habituales en las entrevistas de toma de requisitos

• No se entiende lo que se pide.
• Se tiende a dar una solución inmediata, en la mayoría de las ocasiones una solución técnica conocida, sin esperar a asegurarse de que realmente el requisito ha sido entendido.
• Se pierden en los detalles.
• Mayor preocupación por los plazos que por los objetivos funcionales.
• Enfasis en la tecnología, perdiendo de vista los requisitos.
• Desconocimiento de la terminología del cliente.
• Falta de paciencia. Los usuarios saben lo que quieren y hay que ayudales a expresarlo. Por sí solos, es difícil que sepan expresar todo lo que necesitan de un producto.
• Hay dependencias. Raro es que una sola persona tenga toda la información. Lo normal es que tras cada reunión, se solventen dudas que habían aparecido en reuniones anteriores con otros usuarios clave, y surjan nuevas dudas que se resolverán en entrevistas posteriores.
• Falta de limitaciones. Los usuarios no tienen límite a la hora de pedir. Y esto es un arma de doble filo: si les bloqueamos muy pronto, obtendremos usuarios insatisfechos. Si tardamos mucho, es posible que los requisitos sean difíciles de cumplir, complejos, oscuros.

Volver al Índice de pasos para la Toma de Requisitos.

Toma de Requisitos - Paso 1: Usuarios clave

Los usarios clave deben aportar valor

Los usuarios clave nos van a permitir definir los requisitos principales del producto, y nos van a guiar en las fases posteriores.

Esta entrada forma parte de una serie cuyo índice es el siguiente:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Éstos usuarios deben seleccionarse de forma que sean:

• Abiertos
• Capaces de aportar
• Conocedores del negocio
• Involucrados en la solución
• Sin motivaciones ocultas
• Variados funcionalmente

Abiertos

Deben ser abiertos, para que estén dispuestos a contar libremente lo que necesitan. Deben estar abiertos a dar sus necesidades actuales, abiertos a incorporar en su negocio las posibilidades tecnológicas.

Capaces de aportar

Han de ser capaces de aportar, de expresar lo que necesitan. Un usuario puede ser conocedor del negocio y abierto, pero si no es capaz de expresar lo que quiere...tenemos un problema.

Conocedores del negocio

El motivo de ser conocedores del negocio, está claro: han de aportar las cosas de forma que si un usuario clave dice que una característica es necesaria, o que debe cumplirse de una forma específica, sepamos que lo que dice es importante, y que realmente es necesario. Al contrario, si un usuario clave te dice claramente que algo puede no implementarse, y que dicha característica no es necesaria, créeme que es mejor que la quites, y que la quites ya.

Involucrados

La involucración es fundamental. Los usuarios clave han de estar dispuestos a dar su tiempo. Y nosotros debemos respetar ese tiempo, valorarlo, agradecerlo, y demostrarlo.

Motivados

El tema de la motivación es complejo. Muchas veces, a pesar de concurrir todas y cada una de las características anteriores, un usuario tiene motivaciones ocultas. Si es así, y dichas motivaciones no están alineadas con el negocio corporativo, es posible que surjan aplicaciones con funcionalidades contradictorias, o que sin tener apariencia contradictoria, hagan que su uso no sea consistente. Las motivaciones ocultas las he visto siempre más orientadas a las luchas internas de poder en las empresas, entre departamentos o áreas de negocio. Pero pueden producirse otros casos similares, y hay que vigilarlos.

Variados funcionalmente

¿A qué me refiero con variados funcionalmente? Pues que los usuarios clave deben abarcar el conocimiento de toda la funcionalidad del sistema a construir. Esto es muy fácil de decir, porque hasta que no esté construido el sistema, y se pruebe que es el adecuado, no sabremos quién tenía el conocimiento. Aquí de nuevo, entra la experiencia: lo obvio son las áreas funcionales del tipo "compras", "ventas", "almacén", etc. Donde ya no es tan obvio es en la definición de interacciones (requisitos de interfaz), u otros requisitos no funcionales.

En proyectos internos, es posible que los responsables recluten y proporcionen usuarios reales que estén involucrados en el proyecto y quieran dar sus visiones. Pero en proyectos llave en mano, o  externos, también es posible utilizar estas técnicas.

En cualquier caso, es importante planificar y estructurar adecuadamente el tiempo que dedican los usuarios clave. Esto lo veremos más adelante, en los pasos siguientes de la toma de requisitos.

Volver al Índice de pasos para la Toma de Requisitos.

Cómo hacer una toma de requisitos

Dilbert y sus problemas con los requisitos

Hoy vamos a volver a las bases de la ingeniería del software, e intentaremos aclarar algunos conceptos.

Para la toma de requisitos pasaremos habitualmente por 3 fases:

• Obtención de los requisitos candidatos. Para ello, pasaremos por las inevitables entrevistas a usuarios potenciales, análisis de mercado, realizando prototipos, etc.
• Especificar los requisitos, lo cual pasa inevitablemente, por escribirlos y documentarlos.
• Analizar los requisitos, estableciendo un profundo estudio de los requisitos, de forma que se dividan en sus más pequeños componentes.

Para la toma de requisitos, Steve McConnell en su Software Project Survival Guide propone un proceso más o menos secuencial de 9 pasos:

1. Identificación de usuarios finales clave.
2. Entrevista a dichos usuarios finales.
3. Construcción de un prototipo basado en los resultados de las entrevistas. Es importante que el prototipo sea a la vez simple e interactivo.
4. Presentación del prototipo a los usuarios finales, solicitando feedback.
5. Desarrollar una guía de estilo que refleje el diseño/interfaz del prototipo.
6. Completar y extender el prototipo hasta que demuestre funcionalmente todo el software.
7. Utilizar el prototipo como la primera línea de base de los requisitos.
8. Escribir una documentación de usuario detallada, basada en el prototipo anterior.
9. Crear documentación de requisitos no funcionales para algoritmos, procesos, interfaces con otros sistemas hardware y software, etc.

Por supuesto, hay que tener algunos puntos en consideración:

• Todos los documentos anteriores, así como el prototipo, se pondrán bajo control de cambios a partir de su primera versión. Es fundamental no esperar a fases posteriores, ya que el versionado no es sólo para controlar lo entregado al cliente, sino que nos evita múltiples problemas, proporciona agilidad (especialmente cuando hay que echar cambios atrás), y apenas nos quita tiempo (sobre todo si se automatiza).
• El prototipo no necesita tener código. Existen herramientas de prototipado basadas en flujos de acciones, flujos de procesos. Pero también las hay que simplemente dibujan pantallas. Un simple PowerPoint puede ser una herramienta de prototipado ágil, y efectiva. Un powerpoint es fácil de reproducir en cualquier dispositivo (PC, tablet, móvil, ...), no requiere instalación...

En las próximas entradas, revisaremos en detalle cada uno de estos puntos, y cerraremos el ciclo completo de toma de requisitos desde la experiencia.

Certificaciones Profesionales

Esta entrada la he creado a raíz de un comentario que he recibido en otra entrada anterior. Allí, un lector me preguntaba sobre las certificaciones de software. En concreto, me preguntaba además por la certificación ISQTB.

Un excelente estudio sobre las distintas certificaciones y su utilidad o necesidad, puede encontrarse en este post del blog de Javier Garzás.

He de decir que aunque este estudio me ha parecido un buen trabajo, los resultados desde mi punto de vista se desmerecen porque faltan datos. Es una buena idea tratar de obtener tendencias, pero con tan sólo dos valores es muy complejo tratar de analizar la verdadera situación del mercado en cuanto a estas certificaciones. Animo al autor a continuar con el estudio para ver la evolución de esas certificaciones a largo plazo.

Hay que considerar, que las certificaciones son muy específicas del perfil o rol del profesional. Por ejemplo, no son significativas las certificaciones en gestión para un tester o programador, lo mismo que la certificación ISQTB puede aportar escaso valor a un jefe de proyecto. Es por eso que las certificaciones están asociadas a los roles:

• Gestión (PMP, CAMP, ITIL,...)
• Auditoría (CISA, SCAMPI Lead Appraiser...)
• Seguridad (CISM...)
• Pruebas (TMAP, ISQTB...)
• Análisis (CPRE,...)
• Desarrollo

Otro punto a destacar es que las certificaciones no siempre terminan de cuajar. Por muy bueno que sea el nivel exigido, es más importante el prestigio o grado de aceptación en el mercado (número de empresas que los solicitan). Por desgracia, hay acreditaciones muy buenas como TMAP que no terminan de cuajar en su ámbito.

Esto me recuerda al típico problema del mercado: VHS vs BETAMAX; HD DVD vs BlueRay... y así unos cuantos. Al final, es posible que te gastes un dinero en una certificación, y que luego ésta no termine de tener el prestigio de otra cualquiera. Y se trata de una importante inversión en tiempo y dinero.

Hay otra consideración, y es que las certificaciones o bien "caducan", o bien son reemplazadas por otras versiones que las convierten en obsoletas. Es el caso de CMM, que se vio reemplazado por CMMi.

Para terminar de complicar la cosa, en algunos países se crean certificaciones o acreditaciones profesionales de ámbito local (como es el caso de CFCP en Mexico). Eso dificulta la decisión de las personas, que se encuentran entre la duda de certificarse en una cosa u otra. Además, las certificaciones que se presentan al mercado, no suelen cubrir de forma unívoca una acreditación existente, sino que suelen añadir o eliminar elementos de forma que una, no cubre el 100% de otra. Esto no quiere decir que las certificaciones estén mal pensadas o diseñadas, no quiero decir eso. Simplemente, no todas tienen el mismo marco de referencia (áreas de conocimiento o experiencia acreditadas), no tienen el mismo alcance (nacional, internacional), y tampoco tienen el mismo prestigio. Hasta aquí, ya tenemos 3 dimensiones a considerar.

Si a todo esto, añadimos lo que Javier Garzás trataba de identificar en su estudio (la evolución del prestigio o necesidad del mercado de esas acreditaciones a lo largo del tiempo), vemos que la decisión es complicada: ¡4 dimensiones!

• Ámbito
• Alcance
• Prestigio
• Evolución temporal

En concreto, y ya terminando de responder a mi lector en su comentario, diré que la ISQTB me parece una excelente certificación. Yo personalmente la veo solicitada en múltiples ofertas, y particularmente creo necesario que la gente dedicada al testing, tenga una formación específica. No por programar mejor o peor, se tienen porqué adquirir los skills relacionados con las pruebas. La de TMAP, apenas la veo en ofertas a día de hoy, por ejemplo (y quizás es tan exigente o más que la de ISQTB, lo ignoro).

En una entrada anterior ("¿Hace falta que un tester sepa programar?"), comentaba esto mismo.

Además, hemos de notar que nuestro lector se identifica como "Senior QA", de lo que deduzco que tiene experiencia más que suficiente en el ámbito de las pruebas. ¿Qué valor le puede aportar tener una acreditación en esa área para la que ya tiene experiencia? ¿Le aportaría más valor otra acreditación relacionada con el siguiente escalón en su carrera profesional? Este es otro punto a valorar, ya que me suelo encontrar con situaciones en las que tengo dos tipos de profesionales:

• Amplísima experiencia, pero ninguna acreditación concreta para el área profesional.
• Una o varias acreditaciones / certificaciones, pero escasa experiencia.

¿A quién contratarían ustedes? ¿En quién confiarían más? En concreto la ISQTB me parece estupenda, pero un señor con 3 o 4 años de experiencia en pruebas usando prestigiosas herramientas como HP Quality Center o cualquier otra marca, me merece también muchísima confianza (¿quizá más?).

Por hoy, creo que hemos dado suficientes vueltas a un tema, que veo que tiene muchas ramificaciones. Ya seguiremos otro día.

¿Han muerto las metodologías ágiles?

Me siento culpable. Y me siento culpable porque soy de los que no les gusta aceptar las cosas porque sí. Necesito verificar criterios, y confirmar que realmente, las indicaciones recibidas y los objetivos, son coherentes.

Y no, no me acabo de levantar con resaca tras una noche de alcohol y desenfreno. Estoy hablando de la muerte de las metodologías ágiles. Y me siento culpable, porque soy muy crítico con posturas tipo “si es ágil es bueno” o también “con SCRUM siempre es mejor”.

Yo veo las metodologías ágiles, SCRUM y XP entre ellas, como los representantes de una gran promesa, un mito casi religioso que ha alcanzado su paroxismo en un cierto momento, y se ha creado una burbuja insostenible. Y la desgracia, será que cuando fallen los proyectos, la culpa se la van a llevar los de siempre: los programadores. Precisamente las metodologías que ponen por encima a las personas, van a ser las que usen a dichas personas como chivos expiatorios, tratando de justificar sus fallos. Y es que tienen fallos (son "humanas"), como me esfuerzo en demostrar con éste y otros mitos.

Y me siento culpable, porque me gustaría ver muchos más proyectos usando Scrum, XP, Lean, etc. Pero no a cualquier precio. No a costa de terminar sufriendo los mismos fallos que las metodologías pesadas y tradicionales nos han traído:
-       Retrasos en las entregas.
-       Spaguetti Code.
-       Deuda técnica.
-       Etc..
Echo la vista atrás y veo que ya hace unos cuantos años que muchísima gente se hace las mismas preguntas que yo:
http://www.infoq.com/news/2008/11/decline-of-agile
http://stackoverflow.com/questions/301993/is-agile-development-dead
http://practicalagility.blogspot.com.es/2008/11/agile-circling-drain.html
http://www.boost.co.nz/blog/agile/rules-of-improv-applied-to-scrum/
http://craignicol.wordpress.com/2011/05/16/agile-is-dead/
http://agilesoftwaredevelopment.com/blog/janusz-gorycki/agile-dead
http://myagileeducation.com/2011/long-live-agile-is-agile-dead/
http://blog.recursivity.com/post/934000041/why-agile-is-dead

Y son sólo unos pocos ejemplos.

Viendo los comentarios que la gente escribe en esos blogs, al final es lo de siempre. Es un flujo que se está cumpliendo con exactitud:

1. Grandes promesas. En este caso, surge el manuscrito ágil.
2. No hay pruebas de lo contrario, de que las metodologías no sean el nuevo "resuelve-todo", por lo pero se genera gran expectativa esperando éxito en los proyectos. Curiosamente, con un esfuerzo mínimo. Y además, contentando al colectivo al que se dirige la promesa: por fin los programadores encuentran una metodología que promueve sus aspiraciones y les da el control. ¿Porqué me suena esto extrañamente a la pastilla que todos los años aparece de forma milagrosa y que permite adelgazar sin esfuerzo?
3. Conforme se añade gente, y un colectivo importante pasa a vivir de la formación, consultoría y porqué no decirlo: de apuntarse al carro y vivir del cuento y de la fama que se consigue con las metodologías ágiles, la burbuja se hace imparable.
4. ¿Y ahora qué? Pues decepción, sensación de tiempo perdido, proyectos con problemas (los ya comentados retrasos, código spaguetti,...).
5. ¿Y después? ¿Qué nos depara el futuro? Pues como siempre, adoptaremos las nuevas ideas, aunque esta vez sin verlas como una varita mágica, sino como lo que son: herramientas tan útiles como su adecuación al proyecto en curso, nuestra situación particular, etc...

No hay bola de cristal que nos solucione el punto 5. Ni siquiera tengo claro el que haya explotado aún la burbuja de las metodologías ágiles, a pesar de que muchos autores en la red así lo afirman. De momento, las metodologías “tradicionales” y “pesadas”, no han muerto tampoco. Siguen teniendo sus problemas, pero siempre encuentran un tipo de empresas o proyectos en los que ser de utilidad. En todo caso, evolucionan. Como espero que también evolucionen las metodologías ágiles, evitando convertirse en un elemento más de la cadena de palabras de moda:

·         2nd generation languages
·         3rd generation languages
·         CASE tools
·         UML
·         OOP
·         Java
·         CMM (and CMMI)
·         XML
·         Generics
·         Design patterns
·         .NET
·         Outsourcing/offshoring
·         Agile/Scrum
·         LINQ
·         TDD
·         Etc.

Todos ellos han sido útiles. Muchos de ellos se siguen usando. Pero han tenido su momento burbuja. La clave está en ser lo suficientemente inteligente en mirar atrás y darse cuenta de que al final, no son más que herramientas en nuestra mochila, y no constituye ninguna por sí misma una solución que elimine a las demás de un plumazo.

De todas formas, yo os recomiendo mirar con desconfianza cada vez que un supuesto gurú nos venda la nueva "pastilla milagrosa" en forma de metodología o herramienta.

Además, el uso de SCRUM y otras metodologías ágiles me recuerda a la teoría del caballo muerto que ya comenté en otro post. Se ha tratado de exprimir tanto y tanto a estas metodologías, llegando hasta sinsentidos, que en los casos en que realmente pueden ser útiles (que no son pocos), se genera desconfianza. Curiosamente, es lo mismo que ha pasado ya hace años con las metodologías tradicionales, el desarrollo en cascada, etc.

El coste de la calidad

La calidad cuesta. Y aquí es donde vais a empezar a pagar. Con horas extras. Uy no. No parece muy buena idea empezar este post parafraseando la frase de aquella serie de los 80 que se llamaba "Fama".

Y sin embargo es cierto: la calidad tiene un coste. Pero no hay que dramatizarlo. Como un compañero de trabajo cuyo nombre mantendremos en el anonimato me decía no hace mucho: "Pero esto de la calidad, ¿cuántas horas extra me va a costar a la semana?". Es curioso. Si se tratara de introducir en el proyecto una tecnología novedosa (aun cuando fuera totalmente irrelevante para el éxito del proyecto), no le importaría dejarse la piel en ello. Pero si se trata de aportar visiblidad, mejorar el número de defectos, introducir buenas prácticas, obtener un repositorio de componentes reutilizables....en ese caso, todo nos cuesta.

Esto me recuerda a cuando éramos niños pequeños: hay que ver cuánto nos costaba lavarnos los dientes. Y sin embargo, es una tarea que supone realmente un esfuerzo y tiempo ínfimos, y mucho más comparado con los beneficios que da. Pero claro, cuando tenemos 4 o 5 años no pensamos en los beneficios. Nos da todo igual.

El motivo de este post ha sido mi lectura reciente de un curso ofrecido por INTECO, en el que he aprovechado para ver si encontraba algo que o no conociera, o que al menos hacía tiempo de lo que no me acordaba. Y me he llevado la agradable sorpresa de un gráfico en el que se analiza el coste del proyecto. Vamos a recordar un poco estos conceptos:

1. Coste del Proyecto

Los costes del proyecto se dividen en Costes de Ejecución (lo que cuesta hacer las tareas productivas), y el Coste de la Calidad (básicamente, el resto)

1.1. Coste de Ejecución

Básicamente serían: la preventa, la planificación y el desarrollo.

1.2. Coste de la calidad

Se dividiría en:

• Coste de la Conformidad
• Coste de la No Conformidad

1.2.1. Coste de la Conformidad

• Evaluación: Son las revisiones, pruebas y auditorías que se hacen para ver que todo está conforme planificado en cuanto a funcionalidad y calidad.
• Prevención: Son las tareas adicionales de formación, documentación, toma y análisis de datos, etc., que permiten ayudar a que todo esté conforme en cuanto a funcionalidad y calidad.

1.2.2. Coste de la No Conformidad

• Internos: es el coste de volver a escribir requisitos, rehacer el diseño funcional y técnico, reescribir el código, etc.
• Externos: soporte técnico, gestión de quejas e incidencias, pérdidas de proyectos, reclamaciones, etc.

El coste de la calidad suele presentarse de forma gráfica de la siguiente forma (clic para ver más grande):

En esta gráfica se muestran los costes totales de la calidad como la suma de los costos de los fallos (lo que hemos llamado "Coste de la No Conformidad"), y los costes de prevención y evaluación (lo que hemos llamado "Coste de la Conformidad"). Vemos que existe un nivel óptimo en el que conseguimos mantener una cuota de fallos razonablemente baja, con un coste total mínimo.

Métricas - Las 7 preguntas al analizar los datos

Los datos son los datos. Y tendemos a darles mucha importancia. Y la tienen. Sin embargo, a la hora de interpretarlos, no solemos tener la disciplina de estudiar su origen y circunstancias. Lo que es peor, no solemos tener criterio a la hora de agregarlos o no a los demás datos recopilados.

Aquí van 7 preguntas que me parecen fundamentales a la hora de analizar los datos recopilados en un proceso de MA (Medición y Análisis), o en general en cualquier proceso de Métricas:

1. ¿Quién recopiló esos datos? (Esperemos que fueran las mismas personas que se formaron en las técnicas adecuadas de recopilación de datos)
2. ¿Cómo se recopilaron los datos? (Esperemos que fuese mediante herramientas/procesos automatizados, y que no requiriesen esfuerzo adicional al trabajo diario)
3. ¿Cuándo se recopilaron los datos? (Esperemos que fuese al mismo tiempo o en el mismo día que las tareas relacionadas a dichos datos)
4. ¿Qué significan esos valores? (¿Ha habido cambios recientes en el proceso? ¿Realmente esos valores me dicen lo que quiero o necesito saber?)
5. ¿Cómo se obtuvieron esos valores calculados a partir de los datos originales?
6. ¿Qué fórmulas se usaron para calcular esos datos? (¿Están midiendo lo que necesitamos medir? ¿Funcionan? ¿Son relevantes? ¿Son obsoletos?)
7. ¿Estamos recopilando los datos de la forma correcta? ¿Son los datos correctos? Los datos deberían ser consistentes, y la forma en que se recopilan, a su vez, también debería ser consistente. Hay que asegurarse de que los datos tengan la información requerida para los análisis que necesitamos llevar a cabo.

Veamos un ejemplo:
Tenemos unos datos de defectos encontrados en pruebas unitarias. Nos haríamos cada unas de las preguntas y analizaríamos las respuestas:

1. La persona nos dará una pista de en qué circunstancias se obtuvieron los datos, si han sido automáticos, o si se han rellenado de forma asíncrona al proceso de pruebas.
2. Si el proceso no es automatizado, será más propenso a errores o a manipulación deliberada. En este caso nos va a interesar saber las ejecuciones que se han hecho de los tests, y cómo se han obtenido los defectos. ¿Se han lanzado todas las pruebas, o se ha parado al llegar a un error grave?
3. Si el proceso no es automático, habrá que ver cuándo se han rellenado esos datos. Normalmente, todo lo que no se rellene en el mismo día en que se produce, es mucho menos fiable.
4. Significado: hay que interpretar si ante las mismas pruebas, ayer hubo 5 fallos, y hoy 10. ¿Qué ha cambiado en el código? ¿Y en el proceso? ¿Se han modificado los tests para que se justifiquen ese doble nº de fallos? ¿Ha habido un programador menos experimentado que haya estado tocando hoy el código? etc, etc. Hay que tener cuidado, porque seguramente los datos no nos van a dar las respuestas a las preguntas que busquemos (en este caso, buscamos la calidad del código).
5. Similar a la siguiente.
6. Las fórmulas (manuales o automáticas), pueden haber tergiversado el significado de los datos originales, eso hay que tenerlo en cuenta.
7. Hay que ver si estamos trabajando con los datos de forma consistente. El que haya variaciones (ayer 5 fallos, y hoy 10), puede tener muchos significados. Además, es posible que errores en diversas etapas del proceso de recogida y cálculo hayan alterado los datos o pervertido su significado.

Como resultado, siguiendo el ejemplo de que ayer teníamos 5 defectos en unit testing, y hoy tenemos 10, las preguntas pueden llevarnos a varias conclusiones:

• Se han alterado los casos de prueba, o el número de unit testings existentes.
• Por algún motivo, se han ejecutado más casos de prueba o más pruebas unitarias.
• El proceso automatizado o manual, ha cambiado.
• Las fórmulas usadas o la forma de recogida ha cambiado.
• Nuestra calidad de código es la mitad de ayer.

Estaremos tentados de ir directamente a la última conclusión. Sin embargo, es posible que cualquiera de las anteriores (o muchas otras), sean realmente las conclusiones. Como ingenieros de software, es nuestra responsabilidad llevar a cabo correctamente tanto el proceso como la interpretación de los resultados.

Fuente: Interpreting the CMMI: A Process Improvement Approach (by  Margaret K. Kulpa and Kent A. Johnson )

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