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

Advertisements

El desarrollo de software Ágile y la automatización

todo lo que he leído hasta el momento da claros inidicios de que la automatización es un hecho en los entornos de desarrollo Ágiles. Tal es así que pareciera que no existe programación sin Pruebas Unitarias o sin Intengración Contínua, ni pruebas de sistemas sin automatización, inclusive si las mismas fueran manuales.
También se está hablando a pleno de los ambientes colaborativos y automáticos para la generación de requerimientos.
Por experiencia puedo decir que en muchas fabricas de software no se utilizan tales herramientas y se utilizan procedimientos y técnicas “artesanales”.

Inclusive siguiendo metodologías de desarrollo Ágile para la gestión, tal como Scrum, no se ejecutan otras prácticas Ágile. 

Cual es el límite para decir que somos verdaderamente Ágile o que no lo somos?

Mi amigo Juan Carlos Sanchez Miralba, nos da desde XING una respuesta con un punto de vista completo y claro:
Primero debemos diferenciar entre modelo de desarrollo y de gestión. El modelo de gestión puede ser Scrum sin desarrollar utilizando metodologías ágiles.

Si miramos algunos Principios Ágile no forzosamente debemos automatizar todos los procesos. Por lo tanto podríamos aplicar perfectamente el manifesto agile a un proceso de desarrollo cascada iterativo en el que cada iteración sea de una o do semanas como mucho.

No obstante la metodología de programación extrema XP involucran prácticas y herramientas de test unitario e integración continua, las cuales son excelentes para dar soporte a un verdadero proceso de desarrollo Ágile. 
Aquí la automatización de las pruebas y la integración contínua son inobjetables.

Otras Metodologías Ágile no hacen referencias directas a la automatización.

Básicamente aplicando dos principios:
1- Encontrar errores antes en el ciclo de vida es más barato –> Inspección de código y test unitario.
2- Cuantos menos cambios antes del test fácil es la solución –> Integración continua / test automatico de integración.

podemos decir que son dos buenos pilares en los que asentar un desarrollo ágil.

Gracias Juan Carlos
https://www.xing.com/app/forum?op=showarticles;id=16233872;articleid=16254918#16254918