WCAG 2.0 (finalmente)

En la página del WCAG WG tenemos finalmente WCAG 2.0, la nueva versión de las recomendaciones de accesibilidad. Para facilitarnos la vida tenemos una referencia rápida personalizable, una referencia comprensible (ya se podía hacer este tipo de cosas siempre que se hacen referencias ilegibles) y una guía de técnicas. ¡Incluso una lista de fallos comunes de accesibilidad!
Las recomendaciones se agrupan en cuatro principios. Una web debe ser correctamente...

  • percibible: la información y los componentes del interfaz deben presentarse de forma que sean percibibles por los usuarios: alternativas textuales, contraste adecuado, presentable con estructura más simple...
  • operable: accesible a través del teclado, facilitar la localización y la navegación...
  • comprensible: texto legible y comprensible, navegación consistente, tolerante a errores de usuario...
  • robusta: maximizar compatibilidad con agentes de usuario presentes y futuros...
Se mantienen los tres niveles A, AA y AAA que indica los "criterios de éxito" que cumple la página o la alternativa propuesta.

Se dice explícitamente que no pasa nada por usar tecnologías no accesibles, siempre que no afecten a los criterios de accesibilidad.

Sí, se puede usar Javascript. Usarlo no hace que tu página sea usable ni deje de serlo. Desaparece, por tanto, la mayor limitación técnica que existía con la WCAG 1.0.

Ni siquiera es necesario que la página esté correctamente formada. Adecuarse totalmente a especificaciones es una técnica suficiente para pasar directamente varios criterios, pero no necesaria.

De hecho, muchas de las técnicas estas líneas me recuerdan más a criterios de usabilidad que a accesibilidad, aunque siempre hemos sabido que al segundo se llega a través del primero. Por ejemplo, aquello de no hacer enlaces de "pulsa aquí".

Seguiremos teniendo que realizar un trabajo en formación y desarrollo para que una página sea accesible, pero será algo lógico, centrándonos de verdad en que la página sea accesible, no en pasar ciertos criterios porque lo ponga en una especificación.

Es un paso adelante. Me queda todavía mucho trabajo para analizarlo en profundidad, pero era muy importante que apareciese una nueva versión definitiva de esta especificación, el impacto, incluso legal, de la misma es muy importante.

Posted by Juan Ignacio Sánchez Lara 17:40 Enlaces a esta entrada  



Accesibilidad y aplicaciones web

Hubo un tiempo en que la web era "sólo" información: texto, imágenes (poco más contenido multimedia, el ancho de banda era lamentable) e hiperenlaces. Como cualquiera se podía poner a hacer una página y los navegadores tragaban con todo el código era innecesariamente malo. Si a eso le sumamos la guerra de navegadores, en la que competían por ver cuál implementaba más etiquetas indeseables, no es difícil pensar la razón por la que los estándares web comenzaron a cobrar importancia.
Uno de los grupos de consolidación de estándares era el WCAG WG, encargado de algo tan loable como asegurarse de que aquella maraña de información cumplía unos requisitos mínimos para que la gente con discapacidad pueda disfrutar de ellos. En 1999 publican WCAG 1.0, la (única hasta hace poco) guía de referencia sobre qué es una página web accesible.
La web, que comenzó siendo puramente información, ha ido creciendo hasta tomar el papel de un simbionte en nuestra vida: la necesitamos para casi todo, y además ella se alimenta de nosotros, de nuestras aportaciones, en lo que se ha llamado Web 2.0. Se ha metido en nuestras vidas y en nuestros trabajos, en forma de aplicaciones web. Éstas no son sólo información, son también comportamiento. No son sólo una evolución de la web, sino que sustituyen a las aplicaciones de escritorio. Una aplicación web, técnicamente, es algo mucho más complejo que una página. Para que sea verdaderamente cómoda es necesario utilizar técnicas más avanzadas, que, entre otras cosas, implican scripts.
Eso choca con la WCAG 1.0, ya que en uno de sus puntos más restrictivos, dice que la página debe funcionar sin lenguajes de script. Eso lleva años sin ser asumible por una aplicación, especialmente desde que los usuarios exigen Ajax. El problema es que javascript ya NO es un problema real de accesibilidad. Los lectores de pantalla han mejorado notablemente, y no es necesario adherirse a una restricción tan exigente. El propio WCAG WG es consciente de ello y lleva años trabajando en la siguiente versión, que acaba de ser publicada. El 11 de diciembre de 2008 se ha publicado la primera versión pública no borrador de la guía WCAG 2.0. No sólo eso, sino que están trabajando en otra más, ARIA, que consigue que algo tan inaccesible (hasta ahora) como el framework GWT pueda serlo.

Esto, que personalmente es un hito alentador (¡voy a poder hacer aplicaciones web ajax accesibles de verdad y además certificadas!) legalmente en España sigue siendo un problema. Los políticos y abogados de este país no saben aquello del DRY, y disfrutan en su síndrome NIH. La norma UNE 139803:2004, sobre accesiblidad, en vez vez de decir algo como "la página web debe estar conforme a las especificaciones de accesibilidad del WCAG WG" es un cortapega de las normas presentes cuando fue redactada.

En mi opinión lo que debemos hacer es seguir WCAG 2.0 y/o ARIA, que son el presente y futuro de la accesibilidad web. Las demás consideraciones dejémoslas en manos de los abogados...

En breve, implicaciones de WCAG 2.0. ¡Stay tuned!

PD: mientras escribía esto ha sido cuando he visto que WCAG 2.0 es estable, no os imagináis el alegrón que me he llevado. Ahora, a empollarlo.

Posted by Juan Ignacio Sánchez Lara 10:36 Enlaces a esta entrada  



Los roles en el desarrollo de software

A raíz de mi reciente incorporación al incipiente Centro Experimental del Conocimiento me ha venido a la mente el recurrente tema de los roles y las jerarquías en el desarrollo de software.

En developer.com han hecho una serie de artículos sobre los roles en el desarrollo de software. Una frase es especialmente reveladora sobre lo que creo que debe ser cualquier clasificación:

Developer (Dev) - The heart and soul of the process
Es una serie de artículos bastante interesantes, hablando no sólo de en qué consiste cierto papel sino en qué debes hacer si aspiras a ciertos puestos.

Al menos en mi alrededor a la gente que toma parte en el desarrollo de software se la clasifica en programadores, analistas, diseñadores y jefes de proyecto (obviando las divisiones transversales de becario, junior y senior). En paralelo a esta jerarquía existe la nube de comerciales.

Problemas

Esta división jerárquica tiene, en mi opinión, innumerables problemas. Primero enunciaré los problemas que veo, para acabar con mi propuesta.

El Principio de Peter
Las personas que realizan bien su trabajo son promocionadas a puestos de mayor responsabilidad una y otra vez, hasta que alcanzan su nivel de incompetencia.
A largo plazo se acaba en puestos para los que no se vale, símplemente porque el inferior se hacía bien. Sí, hay formas de mitigarlo, pero denota un problema de esencia en una organización jerárquica.

Ser programador no es fracasar

Hace poco me contaban de un ingeniero informático que se refería a otro prácticamente en términos de fracaso, símplemente porque está trabajando como programador. En la carrera muchos profesores nos educan que programar es una tarea de bajo nivel, sin interés, mecánica, indigna para ingenieros, apropiada para "la gente de módulos". Sólo estoy de acuerdo en una cosa: programar puede ser inadecuada para ingenieros, sí, pero porque han salido de la carrera sin saber programar ni hacer nada por intentarlo. Obviamente a esos les pondría delante de unos libros y un teclado, y les haría trabajar hasta que corrigiesen eso.
Hay autores que opinan que programar es automatizable (coincidencia o no, suelen ser vendedores de herramientas CASE). Yo me alineo con Robert L. Glass, que dice que el 80% del trabajo de programar es intelectual. Programar no es una tarea mecánica ni menor. Ser programador es un trabajo de responsabilidad, intelectual, que requiere dedicación, esfuerzo, autoexigencia y constante renovación. Tener buenos programadores es crítico para el desarrollo de un proyecto.
La jerarquía promueve la visión de que "lo que hay que conseguir" es salir de los puestos "inferiores" (programador) lo antes posible y "ascender" a puestos de mayor "responsabilidad" (y sueldo). Esto es simplista, erróneo e indeseable. Conozco programadores incapaces cuya único plan profesional es hacer tiempo en puestos de codificador hasta que el contador sea suficientemente grande como para que el mercado le promocione a analista. Yo no le quiero ni de programador, ni de analista.

Quiero desarrolladores, no programadores

La jerarquía hace que los programadores se conviertan símplemente en recursos que pican código, ¡tanto desde su punto de vista como desde el de sus "superiores"! La jerarquía les hace convertirse en personas sin responsabilidades, sin iniciativas propias, que no se implican en el trabajo de los demás, que no cuestionan los planteamientos...

Quiero trabajo en equipo, no delegación de la responsabilidad

El trabajo de un programador se limita a implementar la especificación de un diseñador. ¿Qué se consigue con esto?
  • Los programadores no se sienten con la responsabilidad de corregir el código de otros.
  • Los errores cometidos por los diseñadores no son corregidos, ya que nadie lo considera parte de su trabajo.
  • El trabajo de diseño lo hace una persona diferente al que realmente lo implementa (hecho #29 de "Facts and Fallacies of Software Engineering").
  • Se subcontrata el trabajo de programación, porque parece que no es importante, aunque al final lo que sucede es que las organizaciones dependen de subcontratas en sus herramientas clave, y el conocimiento adquirido se pierde al acabar el subcontrato.
  • Se acaba produciendo una separación entre los programadores, que se sienten minusvalorados, que no perciben formar parte de la organización, y el resto.
Si el modelo en cascada es erróneo, ¿para qué insistir en él?

Lo primero que te cuentan en Ingeniería del Software es el modelo en cascada, y lo segundo es que no vale como método de desarrollo. ¿Por qué insistimos en usarlo, directa o indirectamente? La jerarquía inicial no es más que el reflejo de esta metodología en el organigrama de la empresa.
En mi opinión, el proceso mental de desarrollo de software es en cascada, pero no se requiere de explicitación, de la misma forma que cuando se hace un modelo de datos se tienen en cuenta las formas normales pero no se explicitan.

¿Realmente respetas lo que implica la jerarquía en cascada?

Este tipo de jerarquías llevan implícito un orden numérico que suele obviarse. En un desglose tradicional del trabajo en cascada se asume que el nivel directamente inferior es numéricamente mayor: un jefe de proyecto, dos o tres analistas, cinco o seis diseñadores, diez o doce programadores... Esta organización puede tener un sentido cuando esto se respeta, y puede dar unas garantías que no dan otras, como que los analistas o diseñadores "firmen" partes del trabajo, asumiendo su corrección y adquiriendo su responsabilidad. Pero... ¿tu organización lo puede mantener? ¿Tiene sentido un proyecto en el que sus integrantes son un "analista" y dos "programadores"?

Reduce la versatilidad del equipo dificulta la gestión

Si alguien es programador no le pidas que haga de analista:
  • Le estarás pagando como programador pero estará asumiendo la responsabilidad de analista.
  • No tiene por qué asumir ese trabajo: no es analista.
  • Tendrá una visión de temporalidad de su trabajo.
Su uso refleja la inmadurez de la organización

Adoptarlo es una decisión que se adopta sin pensar. En mi opinión se adopta por los siguientes motivos:
  • Uso de metodologías en cascada (que no queremos, ¿no?).
  • Facilita la definición de la carrera profesional y salarial.
  • Situa a los comerciales en un punto muy elevado (cosa deseable, en mi experiencia, desde el punto de vista de los jefes).
Mi propuesta

No size fits all, así que un buen punto de partida es tirar a la basura la precondición de que la jerarquía es esa. Partiendo de eso...

Desarrolladores, no programadores, ni analistas, ni diseñadores

Un mismo miembro del equipo debe desarrollar su habilidad en todas las técnicas implicadas en el desarrollo. Además, adoptando el principio de desarrollo ágil de propiedad colectiva del código y extendiéndolo a cualquier otro producto del desarrollo, todos deben implicarse en el desarrollo, corrección y evolución del código, análisis y diseño.
Por otra parte, no me valen analistas que no saben programar. Deberíamos estar en una de esas condiciones que "nunca suceden", pero en la práctica sí hay analistas "puestos". Aunque el rol de analista funcional está ahí y es importante, sólo es un rol, no una responsabilidad ni una persona concreta. Lo mismo ocurre con el de arquitecto de soluciones (diseñador).
PD: aquí "análisis" y "diseño" no son las fases del modelo en cascada, sino las técnicas que se llevan a cabo para la resolución de ciertos problemas funcionales o técnicos ;)

Separa las condiciones contractuales de tu rol en los proyectos y en la organización

Si alguien es un buen desarrollador y está a gusto en ello, debe poder desarrollar toda su vida profesional como tal. Haz que un desarrollador pueda comenzar en tu empresa como becario o junior pero que pueda desempeñar ese mismo trabajo durante años, y que su contrato mejore en consecuencia. ¿Por qué un gran programador que lleva muchos años en la empresa no puede cobrar más que cualquier comercial? Permite un cambio de rol si él quiere y realmente vale, pero no lo impongas como necesario para mejoras contractuales. Esto conseguirá que los desarrolladores estén realmente motivados: verán su trabajo recompensado, tendrán responsabilidades...

Implica a las personas, no a los roles, en las decisiones clave de la organización

¡Haz que él también lo sepa! Tenle en cuenta a la hora de tomar decisiones técnicas. Que sepa que su papel en la organización no es sólo codificar.

¿Es esto válido en cualquier caso?

No, no size fits all. En el fondo estas ideas están fuertemente influenciadas por mi trabajo en aplicaciones web y de gestión, y en mi convencimiento de que una metodología de trabajo ágil es lo mejor en la mayor parte de los desarrollos. Siempre digo lo mismo: algo así no vale en todos los casos. Por ejemplo, si piensas desarrollar el software para poner un satélite en órbita, necesitarás un proceso muy estricto en el que las especificaciones pasen por muchas manos para asegurar su validez y determinar las responsabilidades.
Pero no ponemos satélites en órbita a diario. Creo que por defecto la organización debería reflejar las tendencias de los últimos años, y relegar las tradicionales a campos en los que son más adecuadas.

Posted by Juan Ignacio Sánchez Lara 17:07 Enlaces a esta entrada  



Reseña: Facts and Fallacies of Software Engineering

Facts and Fallacies of Software Engineering (FFSE, para abreviar) es un libro que recopila "55 hechos y 5 + 5 falacias" (al autor le gustaba la reiteración de la 'f') del desarrollo del software. Los hechos son un resumen de lo que considera más importante saber a la hora de gestionar y desarrollar proyectos software, y las falacias, los engaños o equivocaciones más frecuentemente extendidos como ciertas.

El autor es Robert L. Glass, uno de los pioneros en el desarrollo de software: lleva más de 54 años metido en esto, así que algo debe saber. Publica un newsletter bimensual de pago, The Software Practitioner. Declara que, tras haber trabajado tanto desarrollando como gestionando, "le gusta más hacer que dirigir hacer a otros". Un tipo así no me podía caer mal.

La estructura de cada hecho o falacia siempre es la misma: expone el contenido, la controversia (si la hay), y concluye con las fuentes y referencias citadas.

Ejemplos de hechos:

  • El factor más importante es la calidad de los programadores.
  • Los mejores programadores son hasta 28 veces mejores que los peores.
  • Una de las dos causas más probables de fracaso de proyectos son los requisitos inestables.
  • Eliminar los errores es la fase que más tiempo consume del ciclo de vida.
  • La estimación se hace en el momento equivocado y la hace la gente equivocada.
Ejemplos de falacias:
  • No puedes gestionar lo que no puedes medir.
  • Herramientas y técnicas: una vale para todos los casos.
El balance del libro no es positivo, pero más por culpa de mis expectativas que porque el libro falle. Me ha decepcionado, probablemente me equivoqué al encargarlo, me tenía que haber informado más. Mi primer fallo es no haber hecho cuenta de lo que implica que sean sólo 200 páginas. No me gustan los libros innecesariamente grandes, pero considerando que se ocupa de 65 temas, eso deja poco más de tres páginas para cada uno. Si a eso añadimos que de esas tres páginas un trozo no despreciable se va en citar fuentes, podéis imaginar que no trata en profundidad casi nada. Cada hecho se resume a mostrar su opinión, citando ejemplos o fuentes interesantes, y comentar muy por encima la discusión al respecto.
A esto le uno que estoy de acuerdo con prácticamente todo, y con todo lo importante, así que en mí genera poco debate, que es siempre una de las cosas interesantes de leer opiniones ("¿No pensamos igual? ¿Estoy equivocado, o es él?"). Para que me den la razón en todo prefiero no leer o no discutir, lo interesante es cuando las opiniones no son iguales.

Lo mejor
  • Es una buena recopilación del "estado del arte" de la ingeniería del software, para ver de qué pie cojeamos.
  • Es gratificante ver que no soy el único que le preguntó a su profesor (bueno, él a sus alumnos) que por qué la estimación se sitúa antes de la recogida de requisitos sin obtener respuesta :).
  • Las fuentes son una buena biblioteca que todos los ingenieros del software deberíamos leer.
  • Tener algo físico que lanzarle a tu jefe a la cabeza. Tener una opinión más contrastada que la propia que poder utilizar como argumento con jefes y gestores que desprecian la programación y otras tareas triviales de esto de desarrollar aplicaciones.
Lo peor
  • No entra en profundidad.
  • No se aportan soluciones a los problemas.
  • Las cifras concretas aportadas, sin que las considere importantes de todas formas, me siguen pareciendo vagas y poco contrastables. Valen como idea general, pero no como cálculo aproximado (aunque puede que nunca lo vayan a ser, así que lo mejor creo que sería no intentar aportar cifras).

Posted by Juan Ignacio Sánchez Lara 16:23 Enlaces a esta entrada