Me he mudado a Wordpress.com

Hola, a partir de ahora, dejaré de actualizar este blog. Me he mudado a:

https://calidadysoftware.wordpress.com

Allí podréis encontrar mis análisis personales de situaciones cotidianas en el mundo del desarrollo de software y en la gestión de proyectos software principalmente.

Si os ha gustado la imagen que acompaña a esta entrada, podéis leer más en esta otra entrada en el blog de Enrique Dans donde se habla sobre las actitudes de las empresas.

Saludos,
Roberto.

El uso correcto de las plantillas...está en el contenido

Hola, de nuevo colaboro en el arranque de un proyecto, desde mi área de calidad. Y de nuevo, ayudo en la adaptación de las plantillas y procesos para que el proyecto se adapte a lo que el cliente necesita, cumpliendo al mismo tiempo los más altos estándares de calidad.

Acabo de recibir una felicitación porque el conjunto de plantillas y documentación para el proyecto, ha sido percibido por el cliente como excelente. Y sí, para no mentir, son las cosas que te llevas a casa tras un día de duro trabajo que te animan. Las cosas que te animan a seguir luchando por mejorar, por buscar la excelencia, por no apoltronarse sentados en la autocomplacencia.

Pero claro, como buen culo inquieto, quiero más. Y me pongo a pensar que efectivamente, las plantillas, con sus guías, ejemplos y bien pensada estructura, cubren todas las necesidades...¿o no? Pero...¿qué pasa con el contenido?

En algún momento,  todas esas plantillas se convertirán en documentación real, en contenidos que reflejen la realidad del proyecto en un cierto momento y sus objetivos, suposiciones y carencias. Y sin embargo, aquí es donde realmente empieza el valor aportado al cliente. Es como si al cliente le hubiéramos dado un puente. Y sí, el puente está bien. Pero el cliente no quiere un puente. Quiere cruzar el río. Del mismo modo, lo que necesita el cliente no es las plantillas. De hecho, no quiere ni la documentación. Sino el seguro, la garantía que proporciona el tener un adecuado control del proyecto.

La documentación me recuerda al seguro de la vivienda o del coche. Los programadores no quieren oir hablar de la documentación. Esto ya lo comentaba en mi artículo "Nos gusta programar, pero no documentar". Tampoco nadie quiere un seguro de coche o vivienda. Pero es algo necesario, ya que no podemos circular por ahí, sin convertirnos en "bombas en potencia". Del mismo modo, un proyecto sin adecuada documentación se convierte en una bomba en potencia, ya que ante el más mínimo problema, empezamos todos a correr como pollos sin cabeza, apagando el fuego como si fuéramos bomberos.

Y es importante recordar, que podemos ser muy buenos creando código super-optimizado, clases y estructuras de información super-funcionales y cumpliendo los más modernos estándares...Pero sin una adecuada documentación, no sirve. Eso me recuerda a los ofuscadores de código. Conozco  gente que no lo necesitaba: su código era auto-ofuscado.

En fin, espero que el equipo de los proyectos sigan trabajando bien, y sobre todo, documentando adecuadamente (evitando la "documentitis", por supuesto).

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?