Cultura de Calidad

Por Víctor Gómez Adán

  • 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