Software Quality

En este artículo se comenta la importancia de la figura de un Chief Software Quality Officer en las organizaciones. Para muchas empresas esto es inviable, suena a entelequia pero no debería serlo para las empresas que se dediquen al desarrollo de software o estén involucradas.

Considero que se descuida mucho la calidad en los desarrollos de software. Por supuesto, nos llenemos la boca de palabras sobre la calidad y todo el mundo es muy consciente de su importancia. ¿Qué empresa no tiene una metodología en la que se detalla los procedimientos para asegurar la calidad de sus desarrollos?. No hay oferta (copy & paste) que se precia que no incluye una referencia a estos procedimientos.

En la práctica, qué ocurre: la fase de pruebas es muy deficiente, no se ponen medios ni recursos. Para mí es una de las fases más importantes, críticas diría yo.

Un responsable de Marketing es consciente de la importancia de la fase de pruebas antes de lanzar un producto al mercado, no creo que le agrade la medida de tener que retirar su producto del mercado debido a fallos. Porque en mayor o menor grado afecta a la percepción de su productos por parte de sus clientes y clientes potenciales.

La misma importancia debería de darse para un producto de software desarrollado ad-hoc para un cliente determinado que aunque no va a tener una comercialización si que tiene un grupo de "clientes". Los usuarios siempre son más reticentes al cambio, si la aplicación esta llena de defectos funcionales y errores de programación ya tienen un buen argumento para justificar su predisposición negativa a la aplicación. Y aunque los defectos no sean críticos (que no es excusa) es suficiente para que se escriban ríos de tinta sobre lo mala que es la aplicación y al final cualquier cosa que ocurra se le echa la culpa al nuevo aplicativo. Frecuentemente que se confunden modificaciones en los procedimientos de trabajo con funcionalidad de la aplicación; la nueva funcionalidad existe porque se ha modificado la operativa, no es que la funcionalidad modifique la operativa. No es lo mismo. Además hay que considerar todo lo que obliga (esfuerzo, costes, riesgos) tener que modificar aplicaciones que están ya en producción.

De este artículo me quedo:
"Create a cross-functional task force that focuses on the role of QA software development. This insures that quality is discussed with members of the business unit, not just the development team. Educate the application development and deployment teams on the role of QA in their success. With sufficient education, QA members will be consulted early and often. Insure that QA management is part of the team determining the new vision of applications. [....] Educate business management on the importance of quality testing. "

Productividad personal

A veces pensamos que podemos hacer muchas cosas, que el tiempo es infinito y al final no hacemos nada. El problema: no nos centramos, perdemos el foco de atención. Para las personas como yo, que nos gusta tocar tantos palos y que tenemos cierta tendencia a la dispersión* - no puedo centrarme en un sólo tema - el poder tener acceso a tanta información es una "bendición", pero en algunas ocasiones entramos en estados de "angustia informativa" cuando vemos que no podemos abarcar todo y sin embargo queremos, porque todo nos parece interesante.

Por eso es muy importante ser eficientes (a mí, me lo parece). David Allen es un reconocido autor (experto, guru) sobre temas de productividad personal, muy conocido por su libro Getting Things Done (GTD) que nos enseña muchas formas de aumentar nuestra productividad personal. Tiene una legión de seguidores (me incluyo).

Algunos enlaces sobre las propuesta de David Allen para aumentar nuestra productividad - de la revista fastcompany (que por cierto que me encanta).

• You can do anything - but not everything
  
• Don't Manage Time, Manage Yourself
  
• Sensei for the Time-Sensitive

La mayoría de sus técnicas son evidentes, pero no por ello dejan de ser válidas, ni hay que menospreciarlas. Es frecuente encontrarse con personas que enseguida que alguien explica cosas simples y evidentes tienen cierta tendencia etiquetar estos comentarios como que son humo o que son tonterías y no sirven para nada.

La cuestión es poner estos consejos en practica y no buscar excusas. Reconozco que se consigue hacer muchas más cosas cuando nos organizamos, ya sean con los métodos que propone Allen como con otros; cada persona debe adaptar estas prácticas a su estilo y objetivos.

Pero conviene no confundirse, ni engañarse. Ser más eficiente no significa ser más ordenado; si bien esto ayuda la el objetivo no es ese, por lo menos en mi caso. Existen personas muy ordenadas/organizadas sin embargo, nada productivas y/o eficientes; se pierden en su orden y en su organización. Para mí estas técnicas son un medio para poder hacer más, no un fin en sí mismo.

Existen muchas herramientas de software (programas, utilidades ) que nos ayudan diariamente a organizarnos ... pero esto lo dejamos para otro día.

_____________________________

Dispersión [RAE]: Dividir el esfuerzo, la atención o la actividad, aplicándolos desordenadamente en múltiples direcciones

Agile Management

El blog AgilemanagementBlog ha sido premiado en los Business Blogging Awards 2005 en la categoría Project Management Blog.

Muy interesante y razonable todo lo que escribe David J. Anderson.

El autor de este blog junto con otros consultores, gestores de diferentes áreas han elaborado los puntos principales respeto a Agile and Adaptive Management en lo que ellos denominan Declaration of Interdependence:

• We increase return on investment by making continuous flow of value our focus.
• We deliver reliable results by engaging customers in frequent interactions and shared ownership.
• We manage uncertainty through iterations, anticipation and adaptation.
• We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
• We boost performance through group accountability for results and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally specific strategies, processes and practices.

Considero que todos los proyectos deberían tener como objetivos estos principios; no sólo como frases hechas que quedan muy bonitas para adornar [léase una propuesta de proyecto para un cliente ] pero que al final en el día a día no se tienen presentes. Y creo que no cuesta tanto, con un poco de voluntad se puede conseguir.

Si, me interesa mucho todos los temas que tienen que ver con la gestión de proyectos, en especial (que no es excluyente) en el área de desarrollo de software. En otros países este área esta más profesionalizada. En España - desde mi punto de vista - aún andamos un poco despistados sobre el tema. Seguro que en futuros post escribiré sobre este tema.

Hibernate tips

Lista de tips para trabajar con hibernate.

Seis segundos

Leo Vía Seth Godin "A blog is created every 5.8 seconds, according to a US research think-tank" [ampliar]