¿Pila de sprint cerrada? IV

Otra circunstancia que puede darse es que tengamos en la pila de producto historias de usuario suficientes para completar la capacidad de trabajo del sprint, pero que muchas de ellas no se consideren prioritarias o lo sean bastante menos que otras que todavía no se han terminado de definir por completo, pero sobre las que se sabe que durante el período de ejecución del sprint van a terminar de completarse y que va a haber tiempo para abordar algunas de ellas.

No se trata en este caso, no tanto de no poder esperar sino de tratar de conseguir siempre el mayor valor posible del producto con respecto a la cantidad de esfuerzo invertido. Lo fácil sería tomar la decisión de trabajar sobre las historias de usuario que están definidas, incluso en muchos casos será la decisión acertada, pero no podemos cerrarnos a la posibilidad de que en determinadas circunstancias lo aconsejable sea dejar la pila de sprint abierta con una capacidad reservada para la realización de estas tareas.

En este caso, hay que anticiparnos con el objetivo de no desperdiciar capacidad de trabajo, de manera que si finalmente no da tiempo de definir algunas historias de usuario, se opte por trabajar con las que están definidos.

¿Y por qué no se han tenido definidas esas historias de usuario antes? Pues porque no siempre se puede, por mucha voluntad que le ponga el product owner o el equipo de desarrollo. Lo mismo uno y otros han tenido que dedicar su esfuerzo en otros objetivos del proyecto que hasta ahora han sido más prioritarios o el product owner ha tenido que consultar con terceros determinadas decisiones que le trascienden y cuya resolución se mueve en unos tiempos distintos al del proyecto y sus sprints.

Tener la pila abierta de esa manera es poco ortodoxo, lo sé, pero cada proyecto tiene sus propias circunstancias y en base a ello tanto el product owner como nosotros tenemos que tomar decisiones, con fundamento, con intención, evitando la arbitrariedad, siempre pensando en lo que más conviene al proyecto y al producto y con la mente abierta a hacer excepciones puntuales o no tan puntuales sobre la estrategia que venimos aplicando.

¿Pila de sprint cerrada? III

Hemos visto que un motivo puede ser la resolución de incidencias, bien porque no se ha previsto capacidad para resolverlas o incluso haciendo la previsión porque su volumen y/o complejidad, lo supera. No es la única circunstancia que nos puede llevar a modificar el alcance del sprint pero en cualquier caso, el product owner debe participar en la decisión como responsable de la línea de desarrollo del producto.

Otro posible motivo puede ser que el mismo product owner, una vez pactado el alcance del sprint, quiera que se trabaje sobre una historia de usuario no contemplada inicialmente. La experiencia del product owner resulta esencial para determinar si efectivamente es tan necesario ese cambio, porque supondrá una variación de los compromisos definidos, ya que para que una historia de usuario entre, otra u otras tienen que salir.

Lo de la experiencia lo digo no solo por su capacidad de acertar o no, sino por el hecho de que el desarrollo necesita estabilidad (siempre que sea posible y las circunstancias lo permitan) y los cambios de criterio no ayudan a conseguirla y, además, hay que tener en cuenta que los sprints son de corta duración y que el tiempo de espera para afrontar la tarea o tareas no contempladas no será excesivo.

También es posible incrementar la capacidad del equipo pero sabemos que las circunstancias que se tienen que dar para que eso sea efectivo son muy especiales, ya que generalmente este tipo de estrategias para conseguir objetivos a corto plazo no suele dar buenos resultados. ¿En qué casos puede funcionar? Reduciendo la capacidad de trabajo dedicada a la corrección de incidencias o incluyendo personas que por algún motivo han salido del proyecto no hace mucho tiempo y que controlan la tecnología, la infraestructura de desarrollo y determinados aspectos del negocio.

¿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.