Exprimiedo Scrum: Scrum y el triangulo de la gestión de proyectos: la calidad

Triangulo Escribía hace un tiempo sobre el triangulo de gestión de proyectos y la férrea dictadura que impone sobre la gestión de proyectos. En esencia, uses la metodología que uses para la gestión de proyectos o incluso si no usas ninguna hay cuatro factores sobre los que, como gestor de proyectos, puedes llevar a cabo tu gestión: la calidad, el alcance, el coste y el tiempo. De todos estos factores, el cliente puede controlar como máximo, tres. El cuarto será el que nos permite gestionar. Si el cliente o alguien externo a la gestión del proyecto controla la totalidad de los aspectos ¿que papel nos queda como gestores del proyecto?.

Dado que el dichoso tirano triángulo nos impone su realidad, cabe plantearse una serie de cuestiones sobre el mismo y su relación con Scrum: ¿Cuál es la relación de Scrum con estos factores? ¿Cómo se actúa sobre ellos en Scrum? ¿Cómo condicionan esta metodología? ¿Qué decisiones explicitas han tomado los diseñadores de Scrum sobre ellos? Estas son las preguntas que quiero responder, en la medida de mis conocimientos, con esta serie de post.

Hoy hablaremos de la calidad, desde la perspectiva de Scrum.

La calidad no es opcional, no es un factor sobre el que podamos especular. Ni siquiera lo podemos gestionar explícitamente: cualquier decisión que tomemos puede ser dañina, vaya esta en el sentido de incrementarla como en el sentido de reducirla. Es un aspecto que siempre decide el cliente no quien gestiona el proyecto. Si decidimos recortar calidad para ganar velocidad, por ejemplo, tarde o temprano lo pagaremos si la calidad que logramos no es la que el cliente está dispuesto a aceptar.

El riesgo, ocurre a menudo, es sobrereaccionar. Para asegurarnos de que cumplimos las expectativas ponemos más calidad de la necesaria en el proyecto. El problema es que la calidad adicional tiene un coste, pero sin embargo, no es percibida por el cliente. Suelo poner siempre el mismo ejemplo, que explica muy bien este asunto, solo es un ejemplo, que nadie se quede con los valores absolutos. A mi me gusta el vino, el buen vino, estoy dispuesto a pagar por un vino de cierta calidad. Si alguien me quiere regalar vino, que no se gaste más de 25 euros, ni menos de 10. Por debajo de 10 euros, es probable que el regalo no cumpla su cometido de agradarme, por encima de 25, estará tirando el dinero, ¡mi paladar no es capaz de distinguir un vino de 25 euros, de uno de 35!. A partir de 25 euros todos los vinos me parecen excelentes. Descubrir el nivel de calidad que satisface al cliente al menor coste, es nuestra principal labor a la hora de gestionar la calidad.

El otro aspecto clave la gestión de la calidad es mantenerla a lo largo del proyecto. Es sumamente difícil medir el nivel de calidad de una manera objetiva, precisamente, por que es algo que depende de los usuarios, de los clientes y de su percepción subjetiva. Pero siempre tenemos una idea más o menos intuitiva o analítica (será más analítica si tenemos métricas claras, un proceso de aseguramiento y validación y sobre todo si tenemos testers) sbore cual es nuestro nivel de calidad que nuestro cliente requiere. Y sobre todo de cuan lejos estamos del nivel de calidad que nuestro cliente esta dispuesto a aceptar: ¿se beberá nuestro cliente un Don Simón o un Castillo de Vulpi (dignísimos vinos en brick para calimotxo, pero capaces de corroer una copa de cristal) sin negarse a pagar la cuenta?. Supongamos que no, ¿cómo podemos descubrir que nuestro cliente no se conformará con nuestro Don Simón, sino que quiere mínimo un rioja joven un poco decente y en botella?. Y sobre todo, una vez que lo descubrimos, que sabemos el nivel mínimo de calidad que satisface a nuestro cliente, ¿cómo aseguramos que no estamos elaborando Don Simón?. Por que estaremos de acuerdo en que si estamos elaborando Don Simón es muy muy difícil que al final, hagamos lo que hagamos, logremos que nos salga un Vega Sicilia (¡hay clientes muy exigentes!). Debemos evitar a toda costa darnos cuenta al final de que no hemos alcanzado el nivel de calidad que nuestro cliente requiere, es un riesgo que no podemos asumir.

El único enfoque que funciona, es, sin duda el mantener de manera constante, durante toda la vida del proyecto, un nivel de calidad que sea aceptable al cliente. Si no averiguamos el nivel de calidad que el cliente esta dispuesto a aceptar y no lo mantenemos a lo largo del ciclo del vida del proyecto, a final, cuando los recursos y el tiempo que nos queden sean más bien justos, tendremos que, aunque la funcionalidad este completa, el proyecto se alargará para alcanzar el nivel de calidad necesario.

Las claves son claras: descubrir el nivel mínimo de calidad que el cliente esta dispuesto a aceptar y mantenerse alrededor del mismo durante todo el proyecto. La pregunta es ¿qué mecanismos establece Scrum para que esto ocurra?: El sprint review y los incrementos de funcionalidad potencialmente entregables.

El sprint review, actúa como regulador de la calidad. Por un lado nos va a permitir detectar, mediante el feedback que los asistentes aporten, si estamos lejos o no del nivel de calidad requerido. Además, que el equipo presente las nuevas funcionalidades, es un catalizador clave de la calidad: asegurando una calidad mínima (da mucha vergüenza que te ‘casque’ una demo) y asegurando que el equipo percibe cual es el nivel de calidad mínimo aceptable.

Los incrementos de funcionalidad potencialmente entregables son otro aspecto clave de Scrum. Si algo es ‘potencialmente entregable’, como debe ser el resultado de todo sprint en Scrum, debe cumplir las expectativas de calidad de nuestro clientes (o de su proxy, el Product Owner). Si algo no cumple las expectativas del cliente, no está completado y no se sigue avanzando. Esta es la única manera de asegurar que el equipo no toma atajos sacrificando funcionalidad o no cae en el preciosismo, añadiendo calidad que el cliente no está dispuesto a apreciar y mucho menos a pagar.

Un error habitual es recortar el sprint review o saltárselo, de tal manera que el equipo nunca llega a descubrir cual es el nivel de calidad mínimo aceptable por el cliente o no se asegura que no estamos lejos de este.

En la próxima entrega, Scrum y el triangulo de la gestión de proyectos: El alcance.

7 comentarios en “Exprimiedo Scrum: Scrum y el triangulo de la gestión de proyectos: la calidad”

  1. Sin embargo, aunque el cliente no realice una apuesta clara por la calidad, es importante remarcar que al menos debemos cumplir un mínimo de calidad, si no cumplimos ese mínimo, el mantenimiento y progresión de un proyecto pueden ser inviables. Muchas veces he tenido que abordar proyectos de terceros desde cero porque no había por donde cogerlos y estos son aspectos que la mayoría de las veces no se toman en cuenta para establecer un nivel de calidad optimo. Pienso que aunque se puede apreciar la calidad en sprint review, es difícil que el cliente pueda observar la ventajas de aplicar calidad a sus desarrollos pues muchos de los errores que se comenten afectan a módulos que ya habían pasado el sprint y se detectan en la fase final de producción si no disponemos de Unit Test que nos avisen. Creo que es importante trasladar y demostrar al cliente todas las ventajas de apostar por desarrollos de calidad y enseñarle que aunque el coste inicialmente sea mayor, se verá compensado rápidamente a lo largo de todas las fases de un proyecto. Creo que el reto está en buscar el nivel óptimo de equilibro entre calidad y el coste de nuestro proyecto.

    Un saludo.

  2. Juan, evidentemente hay un mínimo. Como mínimo tenemos que tener un nivel de calidad que evite el efecto montón de mierda. El efecto montón de mierda se resume en tener una base de código tan inestable o de tan baja calidad que impide el desarrollo de nuevas características.

    Pero yo no hablo de esa calidad en este caso. Hablo de la calidad que se ve.

    Si a ti te muestran un Mercedes para que puedas apreciar su calidad tiene que arrancar al menos. Que un coche arranque, es algo que se asume, que el software no casque estrepitosamente es algo que se debe asumir como un mínimo.

    En cuanto a los test unitarios, no son un tema de calidad, son un tema de ingeniería del software. Si usas test es más facil hacer software de calidad, más que nada por que el tiempo que ahorras por la detección temprana de impactos y por la flexibilidad para cambiar y refactorizar el código lo puedes invertir en funcionalidad, pero usar test no es por si mismo garantia de software de calidad. Puedes tener el 100% de cobertura y un rendimiento lamentable o una interfaz de usuario sin usabilidad ninguna.

    Un saludo, ¡gracias por tu aportación!.

  3. Sisi! muy de acuerdo en todo!
    Solo una pregunta… ¿Qué es la calidad?
    ¿La calidad es la misma para el cliente que para el equipo de desarrollo?

    O mas bien tenemos dos percepciones de la calidad:

    Calidad para el cliente: Aspectos externos de la aplicación (interface, rendimiento, robustez, usabilidad…)

    Calidad para el equipo de desarrollo: Calidad en el código (legible, mantenible, rendimiento, seguro…), modularizable, buena arquitectura, threading, aspectos, servicios …

    La segunda el cliente no la va a percibir a corto plazo y creo que esa también la debes fijar de alguna manera.

    Creo que cuando hablamos de calidad del software de manera general provocamos incertidumbre y diferentes apreciaciones.

    ¿Crees Rodrigo que deberíamos fijar también la calidad interna del producto?
    Yo creo que si, y creo que es muy variable dependiendo del tipo de proyecto.

    Por cierto la liberación de líneas base en CMMi, también te ayuda a reajustar el nivel de calidad externa ;P

  4. ¡Aúpa Miguel!

    Uff… ¿Qué es la calidad? casi nada… En tu blog lo cuentas muy bien (http://geeks.ms/blogs/msierra/)… pero en un comentario no cabe. Son muchos aspectos diferente y desde luego todos los que mencionas en tu post son relevantes.

    Yo creo, como decía en mi anterior comentario que hay dos grandes conjuntos en esto de la calidad con diferentes aspectos.

    La interna, que evita que el proyecto colapse bajo una montaña de código de baja calidad y bajo una tonelada de bugs. Pero esta no haca que el cliente perciba el producto como de calidad. Es condición necesaria pero no suficiente y es un catalizador de la otra. Lógicamente, hay que fijarla. Además este tipo de calidad es objetivable.

    Luego está la que percibe el cliente: el producto es estable, podemos adaptarlo con facilidad, la configuración no es un infierno, es usable, razonablemente rápido… esta es condición suficiente: si tenemos esta calidad lo demás da igual. Lo que pasa es que es casi imposible que esta aparezca si la anterior, creo yo.

    Cierto, liberar líneas base, también sirve, es menos dínamico, ágil y divertido que hacer demos y requiere más recursos, pero también funciona perfectamente. Es más, en proyectos de cierta entidad, quizás lo ideal sea mezclar una demo mensual con liberar ‘CTPs’ (queda más cool que línea base ejejjeej…) cada cierto tiempo.

    ¡Gracias por tu comentario!.

  5. Muchos sesudos artículos largan lo de “la calidad es innegociable” y se olvidan de ella para siempre, centrándose en el triángulo alcance, coste, tiempo.

    Menos mal que hay alguien que habla claramente de la calidad como una dimensión en la que nos podemos mover y que debemos medir. Es decir, una dimensión que hay que gestionar.

    Entonces, de triángulo nada. Se trata de un tetraedro bien sólido en el que hay que contemplar todas las dimensiones.

    Saludos.

  6. Muchos artículos largan lo de “la calidad es innegociable” y se olvidan de ella para siempre, centrándose en el triángulo alcance, coste, tiempo.

    Menos mal que hay alguien que habla claramente de que la calidad es una dimensión que hay que gestionar, intentando concertarla con el cliente y medirla en los desarrollos.

    Pero entonces, de triángulo nada. Es un tetraedro bien sólido. Haríamos bien en hablar de tetraedro en lugar de triángulo para que nadie se olvide de ninguno de los ingredientes.

  7. Miguel ha puesto el dedo en la llaga. Sobre la necesidad de asegurar la calidad, todo estamos de acuerdo. Pero ¿de qué estándar de calidad estamos hablando?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *