¿Pila de sprint cerrada? II

Personalmente soy partidario de tener pilas de sprints cerradas porque eso quiere decir que se han trabajado las historias de usuario y que se dispone de toda la materia prima necesaria para ejecutar el proyecto. Además representa predecibilidad, con lo complicado que resulta eso en el desarrollo de software, ya que es el reflejo de una serie de compromisos del equipo de desarrollo con respecto al product owner dentro de la capacidad de trabajo que se puede asumir.

Para darle un tratamiento a las incidencias soy partidario de la existencia de personas, fuera del alcance del sprint, que se encarguen de ellas (no quiere decir que sean personas que específicamente se encarguen de esto, ya que podría ser válida la decisión de reservar una capacidad concreta del equipo de proyecto sobre el total para la realización de estas tareas). De esta forma, el cumplimiento de los compromisos no se debería ver afectado por la resolución de las incidencias (aunque esto es teórico porque una incidencia mal corregida o de gran impacto puede afectarle).

En el caso de que no llegasen incidencias en número y complejidad que consuman la capacidad disponible, siempre se puede aprovechar ese tiempo para trabajar sobre el sprint y ayudar al cumplimiento de los compromisos, además de realizar otro tipo de tareas que pueden resultar positivas: refactorizar código para reducir deuda técnica, realización de testing, automatizar pruebas, hacer mejoras sobre la infraestructura de desarrollo, etc…

Pero independientemente de que mi preferencia sea esa, soy de la opinión de que siempre hay que estar abierto a las circunstancias que se puedan producir en el proyecto y que si hay que abrir la pila de sprint, hacerlo.

¿Pila de sprint cerrada? I

Dependerá de si prefieres utilizar prácticas de Scrum o de Kanban, o de incluso si utilizas prácticas de ambas.

En el mundo real, es complicado ser muy ortodoxo con las metodologías y no es cuestión de ser más o menos disciplinado, ya que puedes tener unas ideas concretas sobre qué prácticas aplicar y después que las propias circunstancias del proyecto que te obliguen a cambiar sobre la marcha.

Sí que es conveniente trabajar sobre una idea pero es necesario ser flexible cuando las circunstancias lo aconsejen. De lo contrario estamos poniendo a la metodología sobre el producto y sabemos quién sale perdiendo cuando eso sucede.

Scrum parte de la idea de tener pilas de sprint cerradas. ¿Qué hay que corregir incidencias? No podemos ponernos una venda en los ojos cuando son críticas (si no lo son, se podría esperar a una de las siguientes iteraciones y contemplarlas como una tarea más dentro de la pila). Ante esta situación se puede renunciar a alguna de las historias de usuario comprometidas y dedicar el tiempo a solucionarlas o se ha podido prever la existencia de una o varias personas fuera del sprint dedicadas a hacer este tipo de tareas y que durante o al final del sprint (mejor cuanto antes) sincronizan o integran su trabajo con la línea base del producto.

En el ejemplo anterior, en una de las posibles soluciones, le hemos quitado la llave a la pila de sprint y sustituido una o más historias de usuario por una o más incidencias de carácter crítico (realmente se trata de una decisión a tomar en la que el carácter crítico de la incidencia puede influir más o menos) y no pasa nada, no por ello somos menos diligentes con la metodología, simplemente se han dado unas circunstancias y nuestra decisión, acertada o no, ha sido esa.

Diferencias entre aseguramiento de la calidad y control de la calidad VII

En el caso de un equipo QC, su funcionamiento se puede orientar perfectamente a un procedimiento: recibo una entrega en un formato determinado, hago las tareas de verificación y devuelvo unos resultados. Se puede ser ajeno al conocimiento del producto y del proyecto (se trabaja sobre la documentación escrita por el equipo de desarrollo). Por eso muchas organizaciones que se dedican a prestar este servicios, tienden a crear factorías de testing, ya que el modelo encaja perfectamente, y de esta forma pueden ofrecer precios todavía más competitivos porque “da igual” que la persona que vaya a trabajar sobre la entrega conozca el producto.

Después la pericia de los técnicos QC les puede hacer llegar más lejos, ya que pueden hacer testing exploratorio y aplicar otro tipo de técnicas que les permitan que la detección de defectos sea más efectiva.

Un aspecto a tener en cuenta en el QC es que parte de su ahorro de costes es provocado por un incremento de los costes de desarrollo del producto porque el nivel de detalle de la documentación entregada (sobre todo la relativa a las pruebas) tiene que ser superior al necesario para suplir el desconocimiento del negocio y del producto por parte de los técnicos QC.

Este aspecto no se tiene en cuenta generalmente a la hora de implantar este tipo de servicios y es muy importante porque para valorar la efectividad de la implantación de un QC es necesario evaluar sus resultados frente a los costes directos (los del propio equipo del QC) como los indirectos (los que ocasiona en los proyectos).

Diferencias entre aseguramiento de la calidad y control de la calidad VI

¿Por qué es más frecuente encontrarnos con QC que con QA (pese a que a ese QC se le llame de manera equivocada QA)? Por motivos económicos, ya que el QA requiere una mayor implicación en el proyecto por parte de los técnicos que realizan este tipo de tareas (salvo que se haya elegido el camino de validar procesos en cuyo caso ese trabajo se simplifica), por lo que la definición de un equipo QA+QC requiere una mayor inversión.

Sin embargo, lo que nos vamos a encontrar con más frecuencia es la combinación de QA y QC pero con una orientación reactiva: entrega y validación.

Como veremos en el artículo de mañana que está centrado en lo que sería el QC (pero que es perfectamente extensible a un QA+QC reactivo), se llega a esa circunstancia principalmente por dos motivos: es lo más cómodo, ya que permite definir un modelo con un interfaz definido, desapegado de la realidad de los proyectos que se están ejecutando (al no formar parte de ellos) y por otro lado, por la errónea convicción de que son los procesos, procedimientos y metodologías los que mandan y los que hacen buenos o no el resultado final del proyecto.

¿Pero no es lo ideal que los equipos de calidad y desarrollo sean distintos? Mi propuesta no es incompatible con eso, ya que lo que estoy indicando es que un grupo de personas dentro o no del equipo de calidad colaboren con el equipo de desarrollo (incluso siendo parte de él si las circunstancias lo permiten) para que tanto los trabajos que se realicen en el mismo como los propios artefactos que se vayan a entregar al QC sean lo más efectivos posibles.

Diferencias entre aseguramiento de la calidad y control de la calidad V

El control de la calidad (QC) es reactivo. Se ha llegado hasta el final y se realiza una entrega del producto y otros artefactos documentales asociados. En este punto, a lo más que se puede llegar es a la detección de defectos antes de su puesta en producción.

Estos defectos pueden ser de mayor calado, como por ejemplo, que alguno de los casos del plan de pruebas no funcione adecuadamente (se entiende que el plan de pruebas responde a la verificación de funcionalidades que implementadas adecuadamente y que, en conjunción con las demás, satisfarían las expectativas del usuario) o bien defectos de menor gravedad (alguna lista de valores no ordenada, algún enlace roto, algún mensaje de error demasiado críptico, etc…).

No es malo disponer de esta última línea de defensa, antes al contrario, puede ser muy interesante, pero su efectividad está muy condicionada por el trabajo del equipo de desarrollo, es decir, si se considera que una aplicación es válida porque cumple el plan de pruebas entregado por el desarrollador, estamos dejando toda la responsabilidad en ese plan de pruebas y todos sabemos que, salvo honrosas excepciones, los desarrolladores no somos expertos en eso.

Una cosa es que el desarrollador sepa qué es lo que tiene que hacer el sistema y otra que consiga plasmarlo en un documento, incluso con la mejor de las intenciones y dedicando el tiempo necesario.

Ante esta situación, lo más interesante resulta combinar ambos enfoques: QA y QC, porque cada uno, bien aplicado tienen repercusión en la calidad y valor del producto final.

Esto es así, siempre y cuando el QA, como he ido insistiendo en artículos anteriores, no se convierta en un simple verificador del cumplimiento de determinados procesos de desarrollo.

Diferencias entre aseguramiento de la calidad y control de la calidad IV

No debemos olvidar que el fin último para el que estamos trabajando no es otro que el de conseguir productos que satisfagan las expectativas de los usuarios y que sean mantenibles, por lo que no puedo entender el aseguramiento de la calidad si no se colabora en la selección y aplicación de los casos de prueba que permitan verificar el cumplimiento de las expectativas, si no se tratan de establecer medidas que permitan mantener la deuda técnica bajo control y no se mejoran las técnicas de testing que se están utilizando con el objeto de automatizarlas en lo posible y detectar defectos cuanto antes.

Por tanto, sobre un proceso sostenible (adecuado a la realidad), la realización de una serie de actividades que permitan que el desarrollo sea más efectivo, que la respuesta a los defectos sea lo más rápida posible y como consecuencia de todo lo anterior conseguir un mejor aprovechamiento del esfuerzo (más productividad).

Si el QA tiene en cuenta esto sí que resulta realmente positivo para el proyecto y además es mucho más efectivo porque las tareas se realizan desde un conocimiento de la realidad del proyecto, de su contexto y del negocio.

Si el QA solo mira el proceso, se está perdiendo lo más importante.

Tanto el respeto al proceso como la aplicación de determinadas prácticas son elementos instrumentales o de apoyo, no lo olvidemos. El desarrollo de software es mucho más complicado que todo eso porque no debemos olvidar el propósito del proyecto que no es otro que satisfacer un conjunto de expectativas y necesidades y si eso no se consigue, habremos fracasado, en mayor o menor medida, pero fracasado.

Diferencias entre aseguramiento de la calidad y control de la calidad III

No digo que no haya que trabajar sobre algún aspecto del proceso, ya que estamos trabajando en una organización que requerirá unos ciertos mínimos para armonizar los desarrollos y estar informada sobre el estado de ejecución y presupuestario del proyecto.

La carga de trabajo y las contingencias de los proyectos en los que estamos trabajando provocan que los desarrolladores tengamos una visión muy acotada. Es lo que tiene estar en las trincheras, la preocupación es el presente y el corto plazo (a veces un poco más allá) de los proyectos en los que estamos trabajando.

Muchas veces se nos critica: “improvisáis, no tenéis un plan” (y muchas veces con razón), sin embargo, si hacemos las cosas bien, salvo excepciones (que ocurran hechos inesperados) no se improvisa, se trabaja con lo que hay y desde donde estamos, teniendo en cuenta la situación o contexto actual, siempre con intención.

Esta visión hace que en muchos casos no entendamos algunos procesos o los consideremos excesivos. A veces estaremos en lo cierto, otras veces equivocados.

Lo realmente importante es que exista una comunicación fluida entre todos los implicados con el objeto de buscar soluciones a los problemas y de esta forma conseguir de manera efectiva una mejora continua.

No se trata, por tanto, de eliminar los procesos, sino de que sean racionales y ajustados a lo que la organización necesita y puede soportar y nunca de espalda a la realidad de los proyectos de desarrollo de software que se realizan y el presupuesto con el que se puede contar en los mismos.

Diferencias entre aseguramiento de la calidad y control de la calidad II

Estoy de acuerdo en que dependerá de cómo se enfoque, pero considero peligroso que el proceso esté en primer plano porque se puede terminar pervirtiendo el modelo de manera que lo principal sea definir un procedimiento de trabajo, hacer algunos ajustes adaptados al proyecto y hacer que se cumplan.

Esto puede dar lugar a la creación de un cultura de cumplidores que traten de utilizar el proceso no como herramienta sino como escudo en el caso de que los proyectos no salgan bien. Al ser considerado un salvoconducto para escurrir responsabilidades, los cumplidores se convierten, más allá incluso de los QA, en fanáticos del procedimiento establecido. Y no porque crean en él, insisto, sino como actitud defensiva.

En el momento en que el procedimiento, el proceso o la metodología pasa de ser una herramienta (que debería estar bien calibrada a la realidad de la organización, de sus proyectos y del proyecto en el que se está trabajando) a un fin se ha elegido el camino equivocado porque independientemente de que sea más o menos efectivo, el modelo en lugar de ser proactivo se termina convirtiendo en reactivo. Y no solo es cuestión de que en lugar de buscar soluciones se verifiquen listas de comprobación, sino de entender algo que es conocido por la mayoría de lo que nos dedicamos a esto: el proceso no asegura nada.

Pese a todo, la forma más común en la que nos vamos a encontrar el QA será orientado al procedimiento y las metodologías, considerando a los proyectos como algo genérico o en el mejor de los casos, definiendo distintos itinerarios en función de una categorización que se haga de los mismos. De hecho esa será la definición de QA que encontraréis en la mayor parte de sitios.

Personalmente (y solo es una valoración personal), me niego a llamar a eso aseguramiento de la calidad.

Diferencias entre aseguramiento de la calidad y control de la calidad I

El término aseguramiento de la calidad se ha extendido a tareas de prevención en el momento en que se está desarrollando (detección de defectos, adecuado seguimiento de un proceso y/o una metodología) y a las tareas que se realizan una vez que se entrega una determinada versión de un producto o de un artefacto (que puede ser un determinado documento exigido por el proceso de desarrollo).

Y es que aseguramiento de la calidad (QA) vende más que control de la calidad (QC), porque asegurar resulta más rotundo que controlar.

El aseguramiento de la calidad está orientado a la prevención, pretende ser, por tanto, proactivo, lo que requiere que sea una parte más dentro del proyecto y suele centrarse en aspectos relacionados con el proceso de desarrollo y testing.

El hecho de que se considere que el QA está orientado al proceso, en mi opinión, ha restado efectividad a su aplicación porque el producto nunca debe quedar en segundo plano y en el momento en que se transmite el mensaje (aún con la mejor de las intenciones) de que la calidad está en el proceso empieza a interpretarse por los responsables del QA de que lo valioso es el procedimiento y que si se sigue probablemente el proyecto tenga éxito.

Curiosamente si se falla, será culpa de las personas por no haber seguido adecuadamente el proceso. Este doble rasero: las personas son secundarias porque quien asegura la calidad es el proceso, pero si todo falla los culpables son las personas, no lleva a nada bueno porque crea una espiral que irá separando a los equipos de desarrollos de los encargados del QA y que por regla general, si no se corta, agudizará el problema porque la respuesta del QA será hacer todavía más rígidos los procesos, hacer más severos los controles y si se siguen sin conseguir objetivos seguirá siendo culpa de las personas y así hasta el infinito.

Barry Boehm. Victor Basili. El impacto del esfuerzo evitable

En enero de 2001 en la revista IEEE Computer, Barry Boehm y Victor R. Basili publicaron un interesante artículo con el título: “Software Defect Reduction Top 10 List”.

En el mismo me llamó mucho la atención el siguiente dato (o estimación) que daban: “Entre el 40 y el 50% del esfuerzo en los proyectos se consume en retrabajo evitable”.

Es cierto que ha llovido mucho desde entonces pero también lo es que muchas malas prácticas siguen totalmente vigentes, entre otras cosas porque aunque el desarrollo de software trata de evolucionar conociendo y tratando los errores del pasado, el mensaje no llega en muchos casos ni en la etapa formativa ni en la laboral, ya que se enfocan las prioridades en otros objetivos.

Según los autores, este esfuerzo adicional es provocado por errores que se podían haber evitado desde el principio o que se deberían haber tratado lo más próximo posible a su origen.

En otra cita del mismo artículo, consideran que “aproximadamente el 80% del trabajo evitable proviene de un 20% de los defectos”. Como podéis ver es una aplicación del principio de Pareto a los defectos y al esfuerzo necesario para corregirlos.

Se trata por tanto, de trabajar con la detección de defectos cuanto antes, sabiendo que es prácticamente imposible detectarlos todos, prestando principal atención a los posibles defectos en áreas críticas del sistema tanto a nivel funcional como a nivel de arquitectura, y tratar de comenzar con su corrección lo antes posible, con el objeto de que su impacto sea el menor posible, no llegando a producción o no realizándose desarrollos sobre ellos que obliguen a rehacer o a retocar una mayor cantidad de código.

Muchos proyectos ven afectados su alcance final y su valor por el hecho de tener que invertir esfuerzo en actividades que perfectamente se podían haber evitado, seguro que personalmente conocéis muchos de ellos en los que llegado el momento habéis echado en falta algo más de presupuesto que os hubiera permitido darle a los mismos un mejor acabado.