Cultura de Calidad

Por Víctor Gómez Adán

  • Vive para que tu ausencia se sienta a diario, no lo contrario

    El otro día, por casualidad, me topé con una frases de Bob Marley que me llamó mucho la atención, decía así:

    "No vivas para que tu presencia se note, sino para que tu ausencia se sienta"

    No le dí más importancia, incluso pensé que era la típica frase que se le aplicaba a Bob Marley pero en realidad no era ni suya y efectivamente, solo la repitió. Parece ser que es una frase bastante antigua del que su autor, nada se sabe.


    Poco a poco fui interiorizandola, pensándola, meditándola, observando a mi alrededor y efectivamente me dí cuenta de una cosa: la mayoría de la humanidad hacemos todo lo contrario. Nos desvivimos en el presente, en el que hacemos en este momento, como tratamos los temas, que dirán de mí, en este mismo instante...pero no pensamos en el futuro, en el que, una vez no estemos, que dirán, ¿se acordarán?, ¿verdaderamente dejaremos huella o seremos un humo pasajero que nadie recuerde, a excepción de nuestros seres queridos?

    En esta sociedad, que nos toca vivir, por suerte o por desgracia, está muy en tela de juicio esa situación, todo es presente, todo es pasajero, breve, incapaz de enraizarse y quedarse, tenemos tan poco tiempo para saber de una cosa, para que antes de que la sepamos, ya exista algo nuevo y lo demás, no es que que se use o no, es que está desfasado, es antiguo, ya no vale...creo que no le damos el valor necesario a las cosas y eso nos está lastrando a una vida triste y aburrida.

    Recuerdo cuando comencé a trabajar (y no es hace tantos años), el dedicarse a algo, aprenderlo o incluso certificarse de algo era un valor extra, algo que podíamos utilizar en ese momento y en un futuro (al menos a medio plazo). Había expertos de cosas concretas, centrados en un tema, en un conjunto de herramientas y que aportaban muchísimo en un proyecto, hasta el caso que, incluso, eran los únicos que sabían en cierta zona sobre eso en concreto.

    Ahora miro alrededor y no veo más que cambios, nadie está afianzado en nada en concreto, nadie se centra en nada, un día es experto en algo y al día siguiente es de otra cosa...la tecnología avanza, sí, pero cuidado, un experto no se forma de un día para otro, si no que tiene que tener años de experiencia en ello y así, poder afianzar y formalizar esos conocimientos.

    A día de hoy, necesitamos más, que nuestra presencia se note, necesitamos hacernos valer día tras día en un mundo cada vez más rápido, y nos estamos dejando cosas por el camino, se nos da muy bien el saber superficialmente de todo y profundamente de nada.

    Es un tema complicado, espinoso, que dará que hablar, pero no podemos agarrarnos a un tren en marcha y sentarnos sin más, que nos deje llevar, creo que, entre todos, frenarle un pelín, aprender todos juntos, observar a nuestro alrededor, ver un poco más allá y demostrar que nuestra ausencia se siente, porque somos verdaderos expertos de nuestro futuro, no somos uno más, esclavos de este tren en marcha que no frena y que cada vez corre más rápido, dejandonos solo observar lo banal y lo superficial, sin ser dueños de lo que queremos ser.

    Aprendamos a hacer notar nuestra ausencia, a dar valor a lo que hacemos, a ser expertos de lo que queremos ser y no dejarnos arrastrar por que se note nuestra presencia en el día de hoy, si no, en todos los días. 

    Y si no, que se lo digan a Bob Marley, una persona que dejó la huella necesaria para que su ausencia se note a diario.
  • ¡I love my job!

    Cuando miro hacía el pasado y voy haciendo memoria de los proyectos en los que he estado, la gente que he conocido, los compañeros que he tenido me doy cuenta de lo mucho que me gusta mi trabajo.


    Puede ser un trabajo que a simple vista no sea agradecido, pero que según llega la hora de entregar las cosas a los clientes, se va haciendo más y más y solo el hecho de que lo que has probado se utilice y se utilice de manera correcta sin problemas, es lo más agradecido y satisfactorio que puedes llegar a tener en la vida.

    Cuando las cosas se hacen bien, las personas que utilizan el software que has probado, están encantadas, hablan de ello, el boca a boca hace de las suyas, el positivismo te abruma y estas preparado para comerte el mundo, solo necesitas levantar la cabeza y andar con total calma y tranquilidad. De verdad, profesionalmente, es una sensación inigualable.

    Esos momentos que he ido viviendo a lo largo de mi carrera, donde van llegando comentarios positivos, escuchas que todo va bien, que la gente está contenta, te felicitan y piensas: ¡lo hemos logrado! Hemos hecho las cosas como hay que hacerlas, en condiciones, con responsabilidad y poniéndonos en la piel de los usuarios. Trabajando, entre todos, con cabeza, con fiabilidad y aportando las máximas energías para que todo sea un éxito.

    Si todo eso se cumple, se gana en motivación, el cuerpo te pide creatividad, ganas de más, de seguir haciéndolo bien y de aportar lo máximo a cada mínima cosa que se hace, en relativas cuentas, se hace con cariño.

    La motivación de hacer las cosas bien reside en cada uno, pero detrás, tiene que existir un equipo de personas que te motiven a ello, empujando y dando ejemplo, implantando calidad, garantía, satisfacción y fiabilidad. No vale el hacer las cosas por hacerlas, por entregarlas y borrarlas del listado, hay que creer en lo que se hace y el resto viene de la mano.

    Durante todos estos años, mi esfuerzo era, es y será el esforzarme al 200% en conseguir todo lo anterior, para ello, hay que tener personas alrededor con la misma actitud, con las mismas ganas, dándolo todo y esforzándose para que, juntos, el trabajo esté bien hecho, si no es así, una sola persona podrá arrastrar al resto y hundirla en un pozo de negatividad, en el que es muy complicado el escapar.

    Desde el primer día que empecé en el mundo de las pruebas, no he estado ni un minuto sin ellas en la cabeza, sin perder esa sensación de validar algo y entre la gente que lo desarrolla y tu, lo dejáis impoluto, como una patena, obtener el tan ansiado 0 defectos y que se pueda subir a producción con total tranquilidad.

    Día tras día, lo tengo más claro: ¡Me gusta mi trabajo!, ¡I love my job!
  • La etapa de desarrollo dentro de un proceso

    Hilando con el artículo publicado tan solo unos días, vamos a retomar el tema de la importancia de las siguientes fases o etapas de un proceso de trabajo en un proyecto.

    Hablábamos de la etapa con la que comienza todo proceso, con el diseño de la funcionalidad, la toma de requisitos, la implantación de las bases técnicas y la importancia de ese consenso o comunicación entre los equipos de negocio y de desarrollo o técnicos. 

    Una vez que esta etapa se ha cumplimentado y hemos dibujado un boceto o una buena línea de trabajo en un roadmap, podemos dar el paso a siguientes fases o etapas, como la del desarrollo y la validación. Esta etapa vendrá de la mano y a continuación, de manera obligatoria, de la etapa anterior y que ya habíamos hablado, comenzando una serie de pasos fundamentalmente técnicos y que serán el corazón de la funcionalidad que ya se ha diseñado y oficializado. 

    En ciertos proyectos y dependiendo de la manera de trabajar del mismo, es posible que exista un paso intermedio de realización de análisis funcionales, aunque ya, ese paso se suele fundir y solapar con el de los requisitos y funcionalidades, aportando de una sola vez todo el paquete de datos, registros, documentación o lo que fuese necesario. Esto, sobre todo, queda más patente en metodologías más nuevas, dejando de lado grandes documentos, que posiblemente no se actualicen después y dando paso a una forma de trabajo mucho más ágil y rápida. Esta manera de trabajo aporta ciertas cosas pero nos hará perder otras, que quizá sean importantes, como un nivel de detalle más profundo.



    El desarrollo de las funcionalidades ha de realizarse de una manera pulcra y siguiendo las especificaciones acordadas, tanto a nivel de detalles, como a nivel de negocio, intentando no salirse de lo establecido. Para que esto no suceda, se habló de que todo ha de ser consensuado por todas las partes implicadas, de esta manera no habrá nada que pareciera fácil y después de pudiera convertir en un imposible o cerrar tiempos y entregas mucho más acotadas. 

    Cuando se comienza el desarrollo, las personas encargadas de las diferentes validaciones a realizar, ya tienen que haber estipulado una base que lo cubra y que nos pueda aportar que todo lo que salga de los equipos tenga la calidad adecuada. Una de las mejores prácticas que se pueden realizar, bajo mi punto de vista, es crear un "boceto" de casos de prueba basados en los requisitos, de esta manera, tenemos cubierto todo lo solicitado, al menos mínimamente y después, se  irán sumando y agregando otros casos basados en el resto de información aportada (análisis, documentación, criterios de aceptación...).
    El desarrollo, como digo, se realiza en paralelo a todo lo descrito anteriormente, así cuando está ya finalizado, todo ese trabajo entrará en juego y se podrá realizar una validación exitosa.

    La comunicación, en esta etapa, entre el equipo de negocio y el de desarrollo es obligatoria, además de muy recomendada, ya que se podrán ir ajustando ciertos flecos que, seguramente, quedasen sin resolver anteriormente o que no se vieron y, si surgiera, se podría rectificar el trabajo antes de que sea demasiado tarde, por algo que no se pensó adecuadamente o que en el papel quedaba espectacular pero a la hora de reflejarlo pudiera llevarnos a un error de cara a los clientes.

    La etapa de desarrollo no solo la veo como una manera de plasmar esas funcionalidades de manera técnica o escribir el código, si no como una etapa, también, de rectificación, de consensuación, de validación más técnica (con pruebas unitarias y de integración), de demostración de lo realizado y de poder ser el punto de inflexión entre el poder parar algo antes de dar el siguiente paso o de ser demasiado tarde. 

    También tenemos que pensar que en esta etapa hay que optimizar el desarrollo lo máximo posible, teniendo en cuenta posibles componentes comunes, código reutilizable, multidioma, multiplataforma, tipo de lenguaje que se utilice, basándose en los análisis técnicos que se hayan realizado anteriormente y que tendrán ya especificada la tecnología que mejor se ajuste a lo que queremos crear.

    En relación a esta etapa, hay ciertas ideas o corrientes de trabajo con las que no estoy de acuerdo, porque he comprobado a lo largo de los años que no funcionan, como el subir por subir o el no levantar la mano para parar  la funcionalidad en concreto si se encuentra algún problema, haciendo una subida parcial o incluso asumir errores porque no son importantes o se pueden "ocultar" y solucionarlos más adelante.

    Cuando trabajamos de este modo, lo que suele pasar es que se acaba por asumir cada vez más y se pierde el control de manera total, implicando una estabilidad y una inseguridad enorme en entornos productivos. Siempre tengo una máxima, si al realizar un despliegue a producción tenemos inseguridad de como quedará, puedo asegurar que las cosas no se están haciendo bien, por mucho que hagamos validaciones, casos de prueba, que los desarrollos se estén haciendo genial y tengamos un proceso férreo y ordenado. Si la máxima se cumple, repito, las cosas no se están haciendo bien aunque nos lo parezca.

    Cuando mantenemos una etapa de desarrollo buena, con las pautas que hemos tratado y mantenemos cierto control, tendremos mucho ganado, implicando a otros equipos, manteniendo la comunicación y teniendo la seguridad de que lo que se está desarrollando sea lo que se quiere y no nos llevemos una sorpresa si al entregarse la funcionalidad no se ajusta a lo solicitado.

    Por esto, dentro de un proceso completo, la etapa de desarrollo y de una primera o temprana validación tiene una importancia vital para continuar por el camino de la entrega de funcionalidades a nuestros usuarios.

  • Gracias por tanto y descansa en paz

    Hace tan solo 24 horas, recién aterrizado para comenzar mis vacaciones, al encender el móvil para avisar que habíamos llegado bien mi mujer y yo, me saltó un whatsapp, un maldito y fatídico mensaje que me avisaba que había fallecido un familiar muy cercano, otro más de la larga lista que nos ha arrebatado el cancer, el puto cancer.



    Al instante recordé, tan solo unos días antes, una tarde junto a el, se le veía bien, con ganas de vivir, con fortaleza, como él decía: "que no me quiero morir, ¡ostias!". Esa tarde hablamos de todo, de política, de como estaba el país, de las noticias de esos días, de las vacaciones, de la familia y de todo en general, como siempre, era un gusto hablar con él, sinceramente, una de las personas más cultas e interesantes que conoceré a lo largo de mi vida.

    Los más cercanos sabemos que no tuvo las cosas fáciles desde muy pequeño, pero supo plantarse con determinación y rehizo su vida con la persona que le acompañó hasta su último aliento. No puedo estar más agradecido a ella, que ha servido de apoyo incondicional para que su voluntad fuese inquebrantable hasta el final. Gracias a ello hemos podido disfrutar de él varios años más.

    A pesar de esos vaivenes de su vida, siempre desprendía vitalidad, desparpajo, humor y cariño. Tengo grabado a fuego ese orgullo que mostraba cada vez que le daba alguna buena noticia, de que lo hacía de corazón, era sincero y se notaba. 

    La última buena noticia que le pude dar fue el regalarle mis dos libros en papel y como, esa misma tarde, a pesar de que su estado ya no era bueno, los intentó devorar, me escribió durante horas al whatsapp, preguntándome y resolviendo dudas, comprendiendo cual era mi trabajo y que intentaba aportar en este mundo, lo conseguí, estaba feliz y yo de verle, aunque fuera un rato, evadiéndose de todo y disfrutando cada instante. Al cabo de las horas me dijo que ya no podía continuar más, que lo estaba intentando pero el puto cancer no se lo permitía, me pidió que le firmara los libros, ahí está mi espinita clavada, no me dio tiempo, le ingresaron, nos dijeron que estaba estable y que disfrutaríamos de él unos meses más, y de repente, se nos fue. Nos lo arrebató el puto cancer.

    De él, me quedo muchas cosas que me guardo para mí, que las tengo grabadas a fuego al lado de muchas otras de las personas que se nos han marchando en estos malditos últimos años y meses.

    Al menos ahora, he podido terminar de escribir estás palabras, quizá porque el caparazón es cada vez más duro o el alma se enfría. Quizá algún día pueda continuar escribiendo dos cartas pendientes de dos personas aún más cercanas, sin que ese caparazón se rompa en mil pedazos y el alma se retuerza de dolor.

    De momento, su fortaleza y sus ganas de vivir están aquí, con los que le acompañaron hasta el final, sabiendo que desde arriba, junto a los demás, nos estará vigilando y estará pendiente de que jamas tiremos la toalla. 

    Gracias por tanto y descansa en paz.



  • La piedra angular de un proceso

    Cuando hablamos de implantación de procesos, debemos de pensar en todas las partes que vamos a cubrir, empezando por la parte que aplica al diseño del trabajo, definición y análisis, continuando con el desarrollo del trabajo y cumpliendo, en diferentes puntos del mismo, validaciones y controles.


    Un proceso debe de ser uno, pero afectará a muchos puntos, personas y se tendrán que dar y cumplir una serie de pautas o pasos que puedan garantizar su correcto funcionamiento. Estas pautas o pasos tienen que ser definidas y estipuladas de una manera férrea y sin fisuras, teniendo siempre las respuestas del porqué se realizan y en el caso de que exista una duda o una fuga, tener casuísticas que nos ayuden a retomar el camino de nuevo y a volver a poner en orden todas las piezas.
    Un proceso completo debe de comenzar en la fase de diseño de la funcionalidad en la que vamos a trabajar, quizá esta sea la pieza fundamental del conjunto, ya que si desde aquí, se comienzan a realizar las cosas no del todo bien, todo lo demás, caerá por su propio peso. Por ejemplo, un desarrollo sin una buena base de requisitos, acabará siendo un desarrollo vacío y que no se ajuste a las necesidades, no por el hecho de que se hagan las cosas mal, si no, porque el trabajo se basa en algo que ya viene desde el principio no del todo correcto. Otro ejemplo que podemos encontrarnos será en la definición de casos de prueba, si no partimos de unos buenos requisitos y criterios de aceptación, la cobertura de los casos no será la idónea.
    Si partimos de una primera fase rígida y bien realizada, lo demas, irá rodado, eso es seguro.
    En toda esta "sección" del proceso, entrarán en juego una serie de buenas prácticas o recomendaciones que se pueden resumir en los siguientes puntos:
    • Al realizar los requisitos, es esencial hacer un trabajo de consensuación con los equipos de desarrollo. Esto permitirá ajustarse más a la realidad, jugando con las dos visiones, la de negocio y la técnica.
    • Es importante escuchar las necesidades de los clientes y usuarios. Esto es un estudio de mercado gratuito y posiblemente podremos tener ideas que nos hagan destacar del resto de competidores.
    • La realización de un a Roadmap nos aportará visibilidad y firmeza, ya que el trabajo estará mejor organizado y permitirá dar luz a los clientes, pudiendo proporcionarles fechas y datos reales del avance de los diferentes desarrollos o funcionalidades abiertas o marcadas durante un periodo de tiempo.
    • El Roadmap no debe de ser puramente de negocio, si no que debe de tener ciertos hitos técnicos, esto permitirá aportar valor a los diferentes equipos de desarrollo y que no de la sensación de quedarse en segundo plano. Una buena repartición de componentes de negocio y técnicos es indispensable.
    Como veis, todo comienza de esta base, y por mucho empeño que se ponga en las siguientes, no llegarán a funcionar del todo bien si esta primera no está engrasada hasta el último milímetro.
    Debe de existir un contacto directo entre los equipos de producto o negocio y los técnicos, buscando siempre homogeneizar caminos e ir de la mano en la realización y diseño de las funcionalidades del proyecto donde nos embarquemos. Eso si, este contacto directo no debe de ser solo al inicio, si no que debe de existir durante todo el desarrollo de la funcionalidad, en forma de puntos de control, ajustes, reuniones o incluso demos, donde mostrar avances y pudiendo recolocar las piezas en el caso de que se hubieran descolocado.
    Con las nuevas formas de trabajo lejos quedan los tiempos donde se trabajaba de manera independiente, ahora los equipos deben de ser multidisciplinares, transversales y que trabajen mano a mano diariamente. Los modelos de trabajo actuales así lo demandan y los resultados en diferentes empresas lo reafirman. Ademas, con las metodologías emergentes esta filosofía es mucho mayor y, aunque, no estoy de acuerdo del todo con ciertas ideas, si que es verdad que el trabajo fluye mucho mejor, más rápido y habitualmente, con una mejor calidad.
  • TFS 2017 - Manual de usuario: Vol.1



    La página principal, que vemos cuando accedemos a TFS es la colección de proyectos o página de bienvenida. En ella podemos encontrar las secciones de “Proyectos”, “Favoritos”, “Elementos de trabajo, “Solicitudes de incorporación de cambios” y Salas (en desuso).

    En este artículo, a modo de introducción, vamos a destripar la sección de proyectos de manera más amplia, explicando que es todo lo que se puede realizar en la misma. Progresivamente, iremos viendo el resto de secciones, ampliando información y conformando un manual de usuario para que podamos aprender un poco más sobre Team Foundation Server en su versión más reciente, 2017.

    1. Pantalla de bienvenida


    La principal novedad que nos encontramos a la hora de acceder es esta pantalla de bienvenida donde se centraliza toda la información de la colección de proyectos, con un mensaje bastante divertido que cambia en función de la conexión (si es por la mañana, por la tarde o es reciente, como en el caso de la captura de pantalla), una pequeña tontería que nos brinda Microsoft pero que me parece un acierto de cara a que su aplicación sea mucho más cercana a los usuarios.

    2. Sección de Proyectos

    Por defecto, en esta pantalla de bienvenida, la primera sección que se muestra es la de los diferentes proyectos que existen en la colección de nuestra empresa (como novedad, no son independientes y pueden relacionarse y consultarse entre sí).

    En la cabecera, existe un buscador y un filtro y un botón de “Nuevo Proyecto”en el que podemos crear un proyecto nuevo en la colección del repositorio (este botón estará activado si tenemos permisos para ello, evidentemente).

      
    Si pulsamos en "Nuevo Proyecto", se abre una ventana nueva donde podemos dar de alta un proyecto nuevo en la colección, pudiendo seleccionar las siguientes opciones, según se muestran en la imagen:

    • Nombre del proyecto: Donde escribimos el nombre que queremos darle al proyecto que vamos a crear, no debe de tener el mismo que otro ya creado.
    • Descripción: Donde explicamos que es este proyecto y para que vamos utilizarlo, de esta manera, los usuarios sabrán para que sirve.
    • Control de versiones: Podemos seleccionar las opciones que tengamos configuradas, tanto GIT como el control de versiones nativo de Team Foundation. Según la configuración pueden ser diferentes a los descritos.
    • Proceso de elemento de trabajo: Se proponen una serie de plantillas por defecto que vienen preinstaladas, como Agile, CMMI, Scrum...Se selecciona la que mejor se adecue al proyecto en el que vamos a trabajar. En función de esta plantilla aparecerán unos elementos de trabajo u otros.
    A continuación, se observan los proyectos y áreas que hemos utilizado recientemente, a modo de acceso directo para agilizar la entrada a los mismos.
    En este caso me he creado un par de proyectos donde poder trastear agusto, uno con la plantilla de Agile y otro con la plantilla de CMMI.

    Para el proyecto de Agile, la plantilla predefine como elementos de trabajo, los siguientes:


    En la plantilla de CMMI, los elementos predefinidos son los siguiente:


    Al pasar el ratón por encima de uno de los proyectos nos encontramos con lo siguiente:

    • Paneles: una novedad de TFS 2017 es la creación de paneles independientes, antiguamente (sobre todo en TFS 2013), solo existía un único panel. Ahora se pueden crear diferentes paneles con gráficas y métricas según se considere.
    • Código: La sección de código nos muestra el repositorio del proyecto y el histórico del mismo
    • Trabajo: Casi es la sección esencial de TFS, donde poder consultar todos los elementos de trabajo y datos que están en el repositorio. Una novedad es que se pueden crear consultar entre proyectos, anteriormente, en TFS 2013, por ejemplo, solo se podían hacer consultas en un único proyecto. 
    • Compilación y lanzamiento: donde configuramos, vemos y utilizamos las integraciones y compilaciones que están disponibles en el proyecto. Con ellas se integra el código desde ramas o entornos. La novedad aquí, es una mayor integración con GIT, que me da la sensación que quiere sustituir al repositorio nativo de TFS.
    Tras estas opciones, se pueden observar dos iconos: un aspa, que eliminará el proyecto (si se tienen los permisos oportunos) y la estrella, que lo marca como favorito y aparecerá en la sección de "Favoritos" que veremos más adelante.

    De momento, esta es la funcionalidad que aporta la sección de Proyectos, tanto a la hora de tener controlados estos como los equipos que existen en ellos, teniendo un listado sencillo e intuitivo muy diferente al que se mostraba en versiones anteriores. Para mi gusto, una de las principales novedades de TFS 2017 es la sensación de minimalismo y limpieza que muchos demandábamos, más cercano a un estilo Jira que a, por ejemplo, un HP ALM 11.x que ya tenía una interfaz un tanto anticuada.
  • Libros benéficos

    En 2016 publiqué, “Aseguramiento de la Calidad”, cuyo beneficio es destinado a la Fundación Aladina, después le siguió: “Seis en 75”, destinado a la Fundación Menudos Corazones y “Asegurar la Calidad en dispositivos móviles...y no morir en el intento”, a la fundación Soñar Despierto. También he publicado una recopilación íntegra de los tres libros anteriores, llamada "Fundamentos de la calidad del software".

    Merchandising benéfico

    Desde la tienda de Cultura de Calidad se pueden adquirir diferentes artículos cuyo beneficio es destinado íntegramente a las tres fundaciones con las que colaboro actualmente: Fundación Aladina, Fundación Menudos Corazones y Fundación Soñar Despierto.

    Acciones benéficas futuras

    Esto no va a parar aquí. Mi cabeza no se está quieta, tengo muchas ideas que dar forma y convertirlas en realidad. Desde aquí, hago un llamamiento a diferentes fundaciones y ONGs para poder colaborar juntos y poder hacer cosas grandes que ayuden a personas o animales en todo el mundo. Si te apetece, ponte en contacto conmigo y hablamos.

    0
    Publicaciones
    0
    Seguidores
    0
    Visitas únicas
    0
    Me gusta