La calidad es siempre negociable

La calidad es negociable y en Agile es tan negociable como que la misma es escalable y varia indudablemente con cada iteración, a medida que una historia de usuario emerge como un motor de trabajo para el equipo.

Que “La Calidad No Es Negociable”  lo he leído inclusive en el famoso libro “scrum-y-xp-desde-las-trincheras”, pero queda claro allí que podemos hacer distinciones entre cosas que pueden evolucionar desde diseños y modelos básico, hasta un entregable de avanzada, y cosas que necesariamente deben tener un grado de calidad mínimo y suficiente para garantizar trabajos futuros.

Entre ambas cosas, podemos distinguir para el primer caso, interfaces en general, botones, comandos, scripts, webservices y hasta funciones que son implementadas como soluciones de base y pueden evolucionar completamente en futuras iteraciones. Para el segundo caso, nos referimos a elementos de diseño y arquitectura que mal implementados atentan contra factores de calidad como la mantenibilidad, modularidad, escalabilidad, seguridad, integridad, disponibilidad, etc., e inclusive contra la testeabilidad.

En Agile tenemos presente que la potestad de la calidad la tiene todo el equipo de trabajo y no un “grupo de QA” y para un mejor aseguramiento, preferimos el “testing temprano y colaborativo”, el que nace desde el primer día en que se conversa con dueños de productos (PO), Analista de Negocios, usuarios y otros interesados, el que continúa en nuestras mesas de análisis y continua con las decisiones del equipo y que facilitan que cada involucrado pueda agregar valor a favor de un desarrollo de calidad.

Un principio que sostenemos y nos ayuda en esta cadena iterativa y evolutiva de la calidad del software, es que los equipos Agiles no se dividen en Desarrolladores y Testers (aún cuando hay especialistas en ambas cosas), sino que se mancomunan en la figura de Team Members.

En Agile sabemos que una actividad de testing, exhaustiva o no, al final de la cadena de desarrollo no aporta calidad, aún cuando pueda dar índices y métrica.

Sin embargo esto que suena tan lindo, de ninguna manera se obtiene en los primeras iteraciones, sino que en futuros Sprint, el esperado de calidad comienza a tomar la forma negociada. En nuestras discusiones de proyecto, constantemente evaluamos alguna posible falta de funcionalidad o funcionalidad pobremente desarrollada y la enorme mayoría de la veces, se logra determinar que mientras futuros Sprints darían la cobertura esperada, en el actual contamos con una calidad “lo suficientemente buena”, sin descartar que en cada Sprint finalizamos y demostramos un incremento “potencialmente entregable” Utilizamos un concepto que se llama “good enough quality”, lo cual nos da los límites suficientes y necesarios para el testing que aplicaremos en cada nivel del desarrollo. Lo más importante, negociamos con el PO el grado de calidad de cada incremento.

Puedo decir  a estas alturas de mi experiencia, que cada vez más, y más empresas de cualquier envergadura  migran a Agile, inclusive para sus productos más críticos. Ya lo se, las empresas maduras no buscan “la bala de plata” pues ya saben que no existen, y quien adopte Agile o cualquier otro framework por moda solo está destinado al fracaso rotundo, de hecho atribuyo el fracaso de CMMI a la tendencia fashion de quienes consiguieron una evaluación positiva y luego encajonaron el proceso.

Justamente, sucede que hasta el día de hoy no han podido lidiar con los tiempos de respuesta exigidos cada vez más cortos, los cambios de requerimientos cada vez más demandantes y mayor diversidad de servicios asociados a productos, por lo que vienen dejando enormes “huecos de calidad” que sus metodologías tradicionales facilitan.

No intento debatir sobre metodologías, pero si tal vez un paradigma y éste que a muchos trato de explicar nos dice que “la calidad es siempre negociable”, pero podrás con esta negociación o no, dependiendo de tu paradigma de gestión de proyectos y mucho más que eso, dependerá del paradigma cultural de las organizaciones.

Por eso podremos ver que los managers se entorpecen en intentar modificar sus procesos para adecuar sus organizaciones a las nuevas corriente, pero al carecer de los principios correctos del paradigma al que intentan imitar, solo logran confundir a su plantel y no pasa mucho tiempo en que prefieren retroceder debido a los intensos fracasos.

La evolución es para todos, para algunos de una forma, para otros de otra forma, pero bueno, insisto, no se puede tener cuerpo sin espíritu.

calidad

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s