Hoy estuve reflexionando, y realmente me siento afortunado de haber empezado mi carrera en el rubro IT desempeñándome como QA (Quality Assurance); digamos que mi trabajo era garantizar que un buen producto saliera, y aportar calidad en el proceso de desarrollo. Una impresionante suerte tuve de contar con referentes que me impulsaron a priorizar las buenas prácticas como proceso, antes que la velocidad de entrega. Ésto, me permitió desarrollar criterios para entender la importancia y beneficios de equilibrar un proceso y código limpios, con la premura e interés del cliente.
Mientras trabajé como QA, en el equipo pasamos de tener esa etapa de validación solo al culminar el código, a incluir la calidad en la totalidad del proceso de desarrollo; chequeamos la calidad desde la creación de las tareas, la planificación de próximos features, gestación de diseños o rediseños, flujos de la app, incluso un testeo temprano de la app en instancia de desarrollo incompleto. Lo leo y la verdad suena difícil de lograr para una sola persona, pero cuando todo el equipo se compromete se vuelve algo muy ameno: el sentido de pertenencia se incrementa así como también la cohesión entre el equipo.
No predico de estas ideas con soluciones mágicas que vienen a resolver todo en la vida pues creo que cuando hablamos de equipos y procesos no existen balas de plata; sin embargo, no se debe dejar que la desidia dirija el rumbo de nuestro equipo de trabajo y nuestro producto. Menciono esto, porque es costumbre de algunas empresas desarrollar implementaciones rápidas, sin importar la calidad, o sin siquiera pensar en cómo impacta eso que hago en el producto, esto nos vuelve apáticos como profesionales, hace que nuestro código sea difícil de escalar y mantener(en el mejor de los casos).
En base a lo anterior, creo que no se debe tener en extremos contrapuestos la calidad y la felicidad del cliente (que por lo general se traduce en entregas rápidas). Hacer las cosas tomando en cuenta la calidad requiere de tiempo, pero hacerlas rápido y sin buenas prácticas en ese sentido, nos va a requerir aún más tiempo; por ejemplo, cuando el feature ya está en producción podría presentar bugs difíciles de corregir siendo necesario (en ocasiones) repensar y volver a hacer la solución.
Por otra parte, es fundamental hablar del agilismo que, ciertamente, vino con muchos aportes a la industria del software. Sin embargo, tomarlo como la segunda venida (cosa que sucede comúnmente), podría resultar un arma de doble filo. Que existan estrategias que han funcionado para algunos equipos no significa que puedan llegar a ser útiles y maravillosas para todos; por ejemplo, una retrospective donde solo un par de personas intervienen no es una meeting efectiva, ni los sprints de dos semanas “porque es la recomendación inicial de la metodología” son la fórmula correcta para todos los equipos. Pienso que resulta útil tomar información de las “bases” que componen esta idea (Manifiesto Ágil) y filtrar de entre tantas propuestas mesiánicas actuales (Blogs e información en la Web) el valor que puede aportar esta metodología a nuestro equipo y proceso; se debe analizar cada caso como un problema particular y único.
En un par de equipos en los que he participado conocí “líderes” que se autonombraron “ágiles” o afirman que siguen dicho proceso solo por implantar las ceremonias típicas (daily, standup, refining, retro, etc.), pero en el día a día, no tenían ningún contacto entre los equipos de desarrollo y producto, ni atención continua a la excelencia, mucho menos eso de mantener la motivación; se vuelve más en una especie de pseudo miniwaterfall donde se toma del agilismo la flexibilidad de cambio y entregas tempranas, pero con rigidez y prioridad del cliente ante todo.
Personalmente considero que las metodologías ágiles (bien aplicadas) pueden generar un cambio importante y positivo en el proceso de desarrollo (incluso en otros tipo de equipos) generando un ambiente más cohesionado, con mayor sentido de pertenencia en lo producido, mayor conocimiento del negocio, un equipo contento y un producto escalable...
A esta altura del texto podríamos pensar: ¿y esto, impacta en la calidad? pues sí, y mucho ya que justamente el agilismo en su manifiesto menciona distintos puntos al QA como parte del proceso de desarrollo, realizando testeo y cambios en el medio, y deja de ser una validación al final del producto para pasar a estar durante todo el proceso, garantizando que la entrega sea la esperada en el tiempo requerido. Y aún teniendo un equipo de QA grande no podemos como desarrolladores dejar de aportar nuestro grano de arena...
Ya sabemos que la calidad es preocupación principal del QA; sin embargo, pienso que como desarrolladores debemos procurar tener en nuestro proceso algo que valide nuestro formato al codear (prettier), estilo de código y reglas de convenciones en el equipo (lint), y como punto fundamental un set de tests unitarios y/o de integración. Todo lo anterior incluirá buenas prácticas a nuestro código, aprovechando la mejora continua para garantizar la escalabilidad de nuestro producto. Otra ganancia es que de esta forma, nuestro equipo de QA puede hacer foco en hacer diferentes tipos de tests (exploratorios, de seguridad, automatizados, etc..) en lugar de tener que repetir flujos, además de poder pensar nuevos features o improvements que puedan hacer un mejor producto.
Es importante que la diana sea la misma para todo el equipo, en ocasiones se vuelve frustrante ir en un sentido cuando otros van en un camino muy diferente. Para evitar esto debemos definir un plan donde estén involucrados y comprometidos todos los miembros del equipo (Algunos agilistas definen a esto como criterio de Ready/Done) incluyendo al equipo de producto, permitiendo así proponer un equilibrio entre las necesidades inmediatas y las futuras, siendo crucial para estas últimas los procesos de calidad y sobretodo un buen stack de pruebas.
Top comments (0)