ÑaaS (Ñapa as a Service)

Hoy os traigo una delicatesen que un buen amigo me ha proporcionado. Como ilustra la figura adjunta, la ñapa es una de las lacras de esta profesión del desarrollo de software, y por desgracia, hay quien la ofrecen como servicio de forma habitual.

Quiero pensar que el autor de la imagen, al escribir «Programming the spanish way», no hablaba en serio. Me niego a pensar que la forma habitual de programar en España sea la Ñapa.

Para los lectores de otros países, o que me lean mediante el traductor automático, vamos a ofrecer una traducción del término «Ñapa». No os molestéis en buscar en la RAE (Real Academia Española de la lengua). El término Ñapa no aparece allí. Sin embargo, es harto conocido al menos en España

ÑAPA: chapuza, mierda, parche, remiendo. En informática, dícese del trabajo mal remunerado y peor ejecutado, que consiste en construir un simulacro de aquello que espera ver el cliente, con el mínimo esfuerzo, y totalmente alejado de lo que una mente sana entendería como adecuado.

Eso es una ñapa. Este término está muy relacionado con otros que ya he blogueado (y algunos que aún no he terminado de escribir) como: cantamañanas, o vendemotos, o vendedor de humos (smokeseller para los amigos). Es gracias a esta fauna de la selva informática, a quienes debemos agradecer la existencia de las ñapas.

También hay que agradecerlos a los clientes, que también los hay, que son capaces de cambiar de opinión cada poco tiempo para disfrute de los programadores. Esos programadores que se encuentran que después de docenas o cientos de horas construyendo aplicaciones, éstas dejan de tener sentido debido a «un pequeño cambio».

Y me rio, me parto de la risa ácida que me entra de forma visceral e insostenible, cuando me salta el iluso de turno con su «esto se arregla siendo ágil». Amigo, esto no lo arregla SCRUM, ni CMMI ni nadie. Cuando el cliente decide que lo más importante no es identificar el impacto de un cambio, ni priorizarlo. Solamente llevarlo a cabo. Aunque haya que tirar a la basura semanas y semanas de duro trabajo para rehacer desde cero miles de líneas de código.

La ñapa o chapuza, es una enfermedad del software (podéis leer más enfermedades del software que he ido recopilando en esta categoría, como la comentitis, singletonitis, excusitis, cacheitis, patronitis… ). Y esta enfermedad es difícil de erradicar. Desde mi experiencia, lo más importante no es la metodología, no es ser más o menos ágil. Sino ser consecuentes y tener la mente fría. Identificar el impacto de las cosas, y asumir que los cambios existen, y que la forma más rápida de llevarlos a cabo es precisamente…no ponerse a ellos de forma inmediata. Sino ponerlos en cartera y ver cómo se relaciona con otros cambios solicitados, los desarrollos en curso, etc, etc.

Gracias José Antonio Herrero por la imagen.

El fin de los mensajes de error

Leía en linkedin un artículo de opinión (Error Messages are Evil), y mi sorpresa ha sido mayúscula al encontrar que se había formado todo un terremoto de respuestas, una pequeña polémica. Y mi sorpresa ha sido aún mayor al encontrar a gente joven entre los que responden en contra de la opinión del autor. En el artículo, el autor (Don Norman), defendía que los mensajes de error son el mal, y mostraba como ejemplo un mensaje de error ofrecido por una aplicación.

Yo esperaba que los usuarios más jóvenes apoyaran por fin estos conceptos de usabilidad, pero parece que al menos entre los lectores del artículo, no era así.

Y sí, estoy de acuerdo, los mensajes de error son malignos. Realmente, hay que erradicarlos. Ya lo comentaba hace tiempo Alan Cooper, uno de los maestros del UX en «The inmates are running the asylum». Los mensajes de error tradicionales violan las reglas de la usabilidad:

• Hacen sentir estúpido al usuario, al culparle por no saber usar el software.
• Distraen del objetivo del usuario, que no es usar el software, sino obtener resultados.

¿Por qué decimos al usuario lo que hay que hacer DESPUÉS de que lo haga? ¿Porqué asumimos que es un error algo como un texto mal introducido? ¿Porqué no nos centramos en guiar al usuario a cumplir sus tareas en lugar de obsesionarnos en que use «correctamente» nuestro software?

Pues porque al desarrollar software, caemos en la trampa del egoísmo. Sólo pensamos en nosotros mismos, de forma que cuando el usuario no hace lo que nosotros queremos/esperamos…es SU culpa! Malditos usuarios…

Bueno, no puedo irme sin recomendaros no sólo el artículo de opinión en sí, sino esa gran obra  pionera en el mundo del UX (User Experience) que es «The inmates are running the asylum».

Metodología XP – Introducción

Hoy me apetece hablar de la metodología XP (eXtreme Programming). Personalmente, me gusta porque es de las primeras metodologías ágiles con la que tuve contacto, allá por el año 1999. Al igual que en otras metodologías ágiles, es una metodología adaptativa y centrada en las personas. XP agrega buenas prácticas que abarcan más allá de la gestión de proyectos definiendo aspectos más técnicos y cercanos al desarrollo software. El autor o precursor de esta metodología fue Kent Beck, y está basada en 5 valores fundamentales:

• Respeto: todos los miembros del equipo muestran respeto por el trabajo de cada uno de los demás.
• Simplicidad: la he puesto en segundo lugar, porque aunque en teoría leeréis que lo simple y la búsqueda de lo simple es la base de XP, me niego a verlo por detrás del respeto.
• Comunicación: cada una de las tareas del equipo se consideran una forma de comunicación, desde el código, pruebas unitarias, etc.
• Feedback: XP fue una de las primeras metodologías en incorporar el feedback del cliente. De hecho, el cliente se considera parte del equipo de trabajo.
• Valor: se refiere principalmente al valor o valentía necesarios para realizar algunas de las prácticas ágiles que XP incorpora. Como el comenzar a programar lo antes posible, o valentía para que el código sea refactorizado y no haya deuda técnica desde el principio, etc.

Como metodología, XP es muy ligera, o más bien podríamos decir, poco estructurada («ligera» podría considerarse como un término despectivo en el mundo del desarrollo del software). Lo que sí hace XP es incorporar una serie de técnicas o buenas prácticas. Algunas prácticas fundamentales de XP:

• Programación por parejas: es el punto más controvertido, ya que propone que sean dos personas las que se dediquen a programar. Una persona escribiendo y otra revisando (se pueden alternar). De todas formas, el código se discute antes y durante la escritura. Aquí se practica el famoso «cuatro ojos ven mejor que dos».
• Desarrollo por iteraciones: el código se construye mediante iteraciones que van sumando valor o funcionalidad al resultado final.
• Simplicidad: el axioma «KISS» (Keep It Simple, Stupid), se aplica con regularidad.
• Refactorización: el código se refactoriza regularmente para que la calidad de código sea notoria, y se evite la deuda técnica. Recordemos que refactorizar, tal y como hemos indicado ya en este blog, nos puede llevar a la refactoritis, una enfermedad de la que ya hemos hablado anteriormente en este mismo blog.

Windows 10 y la gestión de pruebas beta

Hola a todos,
Supongo que muchos ya conoceréis el concepto de Alfa y Beta en el mundo del software. Pero es importante destacar, y en ello ISTQB lo diferencia claramente:

• Pruebas Beta es un software que se da a probar al cliente en su casa. Vamos, que se lo lleva a su casa, o su oficina, y lo prueba.
• Pruebas Alfa es un software por el contrario, que se prueba en un entorno controlado por el equipo fabricante, en las instalaciones del fabricante.

Y digo esto porque es muy típico confundir con el concepto de pruebas Alfa y Beta con la versión Beta y la versión Alfa (o pre-Beta) de un software.

Me acabo de acordar porque precisamente estos días, me he instalado Windows 10 en versión Beta, a través del Microsoft Insider Program.

Desde el punto de vista de la gestión de proyectos software, es muy interesante este concepto, ya que permitiría, bien llevado, a llevar el agilismo a extremos insospechados. Un cliente puede usar una aplicación (o en este caso, el sistema operativo), y a través del análisis de su uso del software, se podrían detectar funcionalidades mejorables, funcionalidades más usadas, etc. Por supuesto, en el caso de Windows 10, tenemos el caso del feedback tipo «esta aplicación no me ha funcionado», o «esta página web no se ha visto bien».

No digo que Microsoft esté haciendo Windows 10 añadiendo funcionalidades ad-hoc a nuestros gustos. Simplemente, que estamos cada vez más, ante una forma de trabajar adaptativa (ágil), permitiendo a posibles usuarios/clientes el ver prototipos tempranos, más o menos terminados.

Otro caso, también de Microsoft, es Windows 10 para móviles. Todos los usuarios de algunos modelos seleccionados, pueden instalarse una versión bastante avanzada (pero aún no terminada), para obtener feedback del uso, pulir defectos, detectar incompatibilidades, etc.

Por supuesto que todo esto ya existe, y tenemos aplicaciones web (recordemos que GMail ha sido una gran parte de su historia una versión Beta: más exactamente algo más de 5 años entre 2004 y 2009) que se ofrecen a los usuarios de manera muy temprana. Sin embargo, la aproximación que ha tomado este fabricante me parece valiente, y a la vez arriesgada, ya que una mala gestión del modelo de betas podría afectar gravemente a su imagen, si por ejemplo todos los ordenadores o todos los móviles dejasen de funcionar, o si los móviles comenzasen a hacer llamadas de forma autónoma y arbitraria.

Aquí desde el punto de vista de las pruebas y de la ingeniería del software, vemos como se presenta una disyuntiva, y hay que buscar un equilibrio entre la estabilidad del producto (por muy beta que sea), y la necesidad de hacerlo probar a un público lo mayor posible para obtener feedback. Desde luego, es necesario tener un gran control de las pruebas realizadas, y obtener métricas que nos permitan estimar (de forma aproximada, claro), el número de defectos y su gravedad en caso de liberar nuestro producto inacabado.

¿Y vosotros? ¿Os atreveríais a hacer público un software inacabado siguiendo un modelo de pruebas Beta? ¿Cómo gestionaríais los riesgos de hacer público un producto sin terminar?

Modelo RACI – Qué es y para qué se usa

Hola de nuevo. Hoy quiero hablaros de una técnica que es a la vez tan simple como necesaria, y que sin embargo, se tilda de teórica e inútil en muchas ocasiones…incluso cuando nos damos cuenta de que hace falta.

Es una técnica de gestión de proyectos, por lo que efectivamente, aquellos proyectos que carezcan de una adecuada gestión, son los principales candidatos a quejarse de esta técnica.

El modelo RACI es una técnica que permite identificar quién se encarga de qué en el proyecto. Pero va mucho más allá, identificando los principales roles intervinientes en cada tarea. Los roles que identifica esta técnica son cuatro, cuyas iniciales en inglés dan nombre al modelo:

• Responsible: responsable de ejecutar la tarea. Vamos, quien la hace físicamente, el que se pone manos a la obra, y se «mancha» las manos.
• Accountable: responsable de que la tarea se ejecute, es quien rinde cuentas. ¿Porqué separar este rol con el anterior? En muchas ocasiones, yo puedo ser el responsable de que algo se haga, pero no lo hago directamente yo. Lo subcontrato, o lo asigno a un tercero. Y es importante diferenciar las tareas que hago yo directamente, de las que encargo a otros.
• Consulted: este rol tiene información útil o valiosa para la realización de las tareas, aunque no sean responsables de las mismas ni participan activamente en su ejecución. Por ejemplo, grupos de expertos en un tema, grupo de calidad, etc. Es importante destacar, que este rol interacciona bi-direccionalmente, es decir, se le consulta, y él responde, o bien participa de forma espontánea aportando su conocimiento.
• Informed: informado. En este rol incluiremos a todos los grupos que hay que mantener informados, poner en copia de los correos, etc. La principal diferencia con otros roles es que con éste se tiene comunicación unidireccional.

¿Cómo se hace todo esto?.

Una forma simple es hacer una tabla, donde por cada fila, escribiremos en la primera columna el nombre de las tareas. De esa forma, por cada fila (por cada tarea), rellenaremos a su derecha unas columnas adicionales, una por cada persona o grupo involucrado. En esas columnas adicionales, indicaremos su rol por las iniciales antes mencionadas: R, A, C, I.

A la hora de rellenar con estas letras/roles, tendremos en cuenta una serie de reglas:

• No es necesario usar todas las letras (R,A,C,I) en cada fila/actividad.
• Al menos, sí deben aparecer en cada fila/actividad, los roles R y A (es decir, responsable y encargado de ejecución). Los roles C,I, son por tanto opcionales en cada fila.
• En cada fila/actividad, debe aparecer un único R (responsable de ejecución), y un único A (responsable de la tarea).
• En cada fila/actividad, los roles C,I pueden repetirse.
• Una misma persona/grupo, puede asumir varios roles para una misma tarea. En ese caso, se anotaría algo como «R/A» si por ejemplo fuese a la vez responsable de la tarea y de su ejecución.

La imagen siguiente ejemplifica lo comentado:

¿Dónde se utiliza esto?

Yo lo he usado principalmente en documentación funcional para definir el «As-Is» o el «To-Be» de los procesos de negocio, o en contratos, o propuestas, donde es fundamental dejar claro el papel de las distintas partes durante el ciclo de vida de una tarea.
Es importante hacer notar, que el rol de las distintas partes puede cambiar en el tiempo. Por ejemplo, en un mantenimiento, el proveedor anterior de mantener la aplicación puede pasar de R/A, a solamente A/C (en la fase de transición) y finalmente solo C en un período de soporte en el que el nuevo proveedor de mantenimiento tiene ya el control total del soporte.

¿Y ya está?
Pues no. Como siempre, hay variantes para todos los gustos. Por ejemplo veremos dos a continuación.

RACI-S

Existe la variante RACI-S, que añade un rol adicional de Soporte («Support»). Ésta es la variante que he visto en la práctica. EL rol Soporte, se encarga de dar soporte de todo tipo al rol «R» (que es quien hace la tarea), en todo lo que éste necesite. No confundir con el rol «C», que sería más bien un experto en la materia, y que si bien también da soporte, digamos que dicho soporte sería más «pasivo» que el del rol «S».

RACI-VS

También existe la variante RACI-VS que añade dos roles:

• Verify (verificador): este rol se encarga de actividades de verificación, es decir, de comprobar si el producto está conforme con los criterios de aceptación establecidos en su descripción/diseño/calidad.
• Sign (aprobador o supervisor): este rol aprueba las decisiones del rol Verificador y autoriza el producto. Lo lógico es que el trabajo de un S preceda siempre al de un A.

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

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.

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