Software funcionando sobre....¿pruebas exhaustivas e intensivas?

Siempre me he mantenido en algo que aprendí de tantas conversaciones con mis amigos y compañeros haciendo software, y de la experiencia:

LA CALIDAD DEBE TRABAJAR PARA EL SOFTWARE Y NO AL CONTRARIO

igual se podría leer en el contexto organizacional

LA CALIDAD 
Y/O PROCESOS DEBEN TRABAJAR PARA LA ORGANIZACIÓN Y NO AL CONTRARIO 

En Agile damos prioridad a software funcionando, pero es necesario hacer pruebas, ¿cuántas?¿cuáles?, la repuesta es: todas y cada una que le permitan entregar un software funcional y de valor, de modo que usted no pierda la tranquilidad y el sueño luego de terminar su jornada laboral, léase entonces:

• pruebas par
• pruebas unitarias
• pruebas funcionales
• pruebas de integración
• pruebas de seguridad
• pruebas de compatibilidad
• pruebas de adaptabilidad 
• pruebas de instalabilidad..
• pruebas de stress
• etc
• etc
• etc

Pero cuantas y cuales..vuelvo y lo repito  LAS NECESARIAS ni una más, ni una menos.

A que se refiere esto, por ejemplo dentro de las prácticas ágiles se encuentran:

•  TDD : Test driven development - desarrollo dirigido por las pruebas
• ATDD: Aceptance test driven development - desarrollo dirigido por las pruebas de aceptación

Y hablamos de cobertura (cuantas pruebas aseguran nuestro código).

Sobre lo que quiero llamar la atención es:

• NO ES NECESARIO cubrir todo el código con pruebas unitarias (ejemplos los POJO, DTO, o VO no lo requieren), solo objetos que tengan lógica de negocio (es mi humilde recomendación, ahora si a tu equipo esto le agrega valor, lo acepto y difiero respetuosamente).
• Ni es estratégico  volcarse a una cobertura de 100% de pruebas sobre el código.

Nuestro objetivo es proveer software funcional, las pruebas nos ayudan a hacer software funcional pero como tal:

• Las pruebas no son un entregable que agregue valor al cliente, me explico, si hacemos pruebas o no al cliente no le interesa, a el solo le interesa que funcione y no falle..
• Las pruebas codificadas se convierten en una pieza de código más para mantener
• incluir en el servidor de integración continua
• hacerle refactor
• corregir,
• adaptar,
• etc

Por lo tanto,  hagamos las pruebas suficientes para estar tranquilos y que nos aseguren ENTREGAR SOFTWARE DE CALIDAD.

LA CALIDAD NO ES NEGOCIABLE...

Pero 

LA CALIDAD DEBE TRABAJAR PARA EL SOFTWARE Y el no software para cumplir con tdd del 100%, atdd del 100%, etc, etc.

Saludos ágiles

Jorge Abad

Inspección y adaptación: Claves para las Personas, Producto y Proceso

Como lo dice la guía de Scrum para resolver problemas adaptativos complejos (como lo es la construcción de un producto software) es necesario el uso del empirismo (teoría de control de procesos empírica), o sea que el conocimiento procede de la experiencia y se debe tomar decisiones basándose en lo que se conoce.

El empirismo tiene tres pilares:

• Transparencia: Los aspectos significativos del proceso deben ser visibles para aquellos que son responsables del resultado
• Inspección: revisar frecuentemente los artefactos de Scrum y el progreso hacia un objetivo, para detectar variaciones y Adaptación
• Adaptación: Corregir desviaciones lo antes posible para que el resultado obtenido sea el esperado

Por lo general tomamos la inspección y adaptación (también reflejada en el ciclo de Demming de PHVA - planear, hacer, verificar y actuar - de mejora continua) solo para la construcción  iterativa e incremental del producto, mas lo que quiero enfatizar en este post es que se debe hacer Inspección y Adaptación para :

• el Proceso 
• como se esta construyendo el producto
• las herramientas usadas
• el nivel de documentación (adecuado, inadecuado, excesivo)
• estado y corrección de la deuda técnica
• la forma e intensidad como hacen prácticas técnicas
• programación por pares
• integración continua
• BDD
• TDD
• ATDD
• entre otras
• Proceso de despliegue
• Efectividad de las reuniones de Scrum
• Timebox de las reuniones
• la transparencia del proceso
• etc
• las Personas
• Las relaciones
• el funcionamiento del equipo
• el trabajo en equipo
• la felicidad del equipo
• el funcionamiento de las personas en las roles encomendados
• la comunicación
• la liberación de tensiones
• la sobrecarga de alguien
• la falta de compromiso de alguien
• la falta de compromiso del equipo
• la falta de foco
• la rigidez de algun miembro del Equipo Scrum (ya sea: Scrum Master, Product Owner, o Team Developer)
• la transparencia en las relaciones
• etc
• y obviamente el Producto y su forma en como esta siendo construido
• estamos realmente construyendo lo que le da valor al negocio (el 20% de las funcionalidades que apoyan el 80% del negocio)
• el producto esta cumpliendo la definition of done
• Cuando es el proximo realease
• entre muchos otros aspectos

Y los momentos de Inspección y Adaptación para estos tres elementos claves de Scrum son:

• Review para el producto
• Retrospectiva para el proceso y las personas

Espero que los equipos ágiles ( Scrum Masters, Product Owners y Team Members) aprovechen estos espacios y ciclos para la mejora continua (kaizen) de estos tres aspectos fundamentales en sus proyectos y logren llevar sus productos, procesos y relaciones a niveles de gran valor para todos los involucrados.

Saludos ágiles

Jorge Abad