Puede que para algunos no sea un contenido tan novedoso pero son temas a los que, en el mundo de la IA, Cloud y tecnologías novedosas apareciendo cada día, no se les presta demasiada atención.

En este artículo me referiré al principio de Encapsulamiento, o a la falta de éste ya que, si bien es un concepto fundamental de la programación, en ocasiones no se respeta, o quizás no se entiende.

Según Wikipedia: “encapsulación (o encapsulamiento) se refiere a la agrupación de datos con los métodos que operan en esos datos (…). La encapsulación se utiliza para ocultar los valores o el estado de un objeto(…), evitando el acceso directo a ellos (…).

Para ir aterrizando la idea, un ejemplo muy sencillo en código Java.

public class Cuadrado {
  private double lado;
  
  public Cuadrado(double lado) {
    this.lado = lado;
  }
  
  public double obtenerArea() {
    return this.lado * this.lado;
  }

  public double obtenerPerimetro() {
    return this.lado * 4;
  }
}

La clase Cuadrado agrupa los datos (el lado del cuadrado), con los métodos que operan esos datos (obtenerArea y obtenerPerimetro).

Ahora bien, ¿a qué me refiero cuando digo que el principio de Encapsulamiento no se respeta? Para responder, usaremos el siguiente ejemplo, en código Java.

public class Pizza {
  private Variedad variedad;
  private List<Ingrediente> ingredientes;
  private Tamano tamano; // Tamano es un ENUM Individual, Mediana, Familiar
  private double precio;

  public Pizza() {

  }

  public Pizza(Variedad variedad, List<Ingrediente> ingredientes, Tamano tamano, double precio) {
    this.variedad = variedad;
    this.tamano = tamano;
    this.precio = precio;
    this.ingredientes = ingredientes;
  }

  public List<String> getIngredientes() { 
    return this.ingredientes; 
  }

  public void setIngredientes(List<Ingrediente> ingredientes) { 
   this.ingredientes = ingredientes; 
  }

  public Variedad getVariedad() { 
    return this.variedad;
  }

  public void setVariedad(Variedad variedad) { 
    this.variedad = variedad; 
  }

  public Tamano getTamano() { 
    return this.tamano;
  }

  public void setTamano(Tamano tamano) { 
    this.tamano = tamano;
  }

  public double getPrecio() {
    return this.precio;
  }

  public void setPrecio(double precio) {
    this.precio = precio;
  }

}

Esta clase es muy sencilla pero refleja un estilo de programación muy común. Atributos privados, métodos públicos, un par de setter/getter para cada atributo y dos constructores, uno vacío y otro con todos los parámetros posibles.

Ahora bien, ¿qué problemas hay?

1. Implementar siempre Setter y Getter

El primero y más típico de los ‘vicios’ que he podido observar en este aspecto, corresponde a implementar un setter y un getter para todos los atributos de una clase. Siempre, para todos los atributos, para todas las clases del programa.

Si bien acceder a los atributos a través de métodos es una forma de encapsulamiento, al tener un getter y setter para cada atributo, la clase queda casi tan expuesta como si sus atributos fueran públicos. Este ejemplo en particular tiene dos problemas: de usabilidad (al programador que la utiliza) y de integridad de datos.

1. 1 Usabilidad

Con la implementación anterior, quien quiera utilizar la clase anterior tendrá mucho trabajo que hacer. Un ejemplo de cómo utilizar la clase Pizza podría ser el siguiente.

public static void main (String[] args) {
   Pizza pizza = new Pizza();
   pizza.setVariedad(new Variedad(Variedad.Hawaiana));
   List<Ingrediente> ingredientes = new ArrayList<>( 
     Arrays.asList( 
       new Ingrediente(“Queso”),
       new Ingrediente("Jamón"),
       new Ingrediente("Piña")
     )
   );
   pizza.setIngredientes(ingredientes);
   pizza.setTamano(Tamano.MEDIANA);
   double precio = /* alguna logica para calcular el precio */
   pizza.setPrecio(precio);
   System.out.println("Precio de la pizza: $" + pizza.getPrecio());
}

Es decir, quien use la clase debe:

• instanciar un objeto de tipo Variedad
• instanciar varios objetos del tipo Ingrediente
• construir una lista con estos últimos
• conocer la regla de cálculo de precios

Son muchos detalles. Rompe la definición misma de encapsulamiento, al inicio de este artículo.

1.2 Integridad

Con el método setPrecio, es posible manipular el precio después de construido el objeto, sin considerar los ingredientes o tamaño de la pizza. Por otra parte (aunque esto podría depender de las reglas de negocio de la pizzería), los ingredientes no deberían setearse directamente, sino que autoasignarse según la variedad seleccionada (‘Española’, ‘Hawaiana’, etc.). Nada impide que alguien haga algo así.

public static void main (String[] args) {
   Pizza pizza = new Pizza();
   pizza.setVariedad(new Variedad(Variedad.Hawaiana));
   List<Ingrediente> ingredientes = new ArrayList<>( 
     Arrays.asList( 
       new Ingrediente(“Queso”),
       new Ingrediente("Jamón"),
       new Ingrediente("Piña"),
     )
   );
   pizza.setIngredientes(ingredientes);
   pizza.setTamano(Tamano.MEDIANA);
   double precio = /* alguna logica para calcular el precio */
   pizza.setPrecio(precio);
   System.out.println("Precio de la pizza: $" + pizza.getPrecio());
   pizza.setTamano(Tamano.FAMILIAR);                // pizza familiar al precio de mediana
   ingredientes.push(new Ingrediente(“Pepperoni”);  // pepperoni gratis
   pizza.setIngredientes(ingredientes);
}

¿Está mal entonces agregar getters y setters? No, lo que está mal es hacerlo por defecto, casi automáticamente. Lo correcto es agregarlo para los atributos que realmente lo requieren.

Y ojo que si usas alguna librería o herramienta para autogeneración de métodos (como Java +Lombok, o C# con propiedades autoimplementadas), es aún más fácil caer en el error.

La siguiente mala práctica tiene relación con la implementación de constructores.

2. Implementar siempre un constructor vacío y/o uno con todos los atributos de la clase

En el ejemplo de la pizza, junto con los getters y setters se incluían dos constructores. El primero vacío, y el segundo con todos los atributos de la clase como parámetros del constructor. Este tipo de implementación también es muy común, pero también rompe el encapsulamiento de la clase de la misma forma que lo hacen los setters.

Por ejemplo, si a la clase pizza le sacamos los setters pero mantenemos el constructor con los parámetros quedaría así.

public class Pizza {
  private Variedad variedad;
  private List<Ingrediente> ingredientes;
  private Tamano tamano; // Tamano es un ENUM Individual, Mediana, Familiar
  private double precio;

  public Pizza() {

  }

  public Pizza(Variedad variedad, List<Ingrediente> ingredientes, Tamano tamano, double precio) {
    this.variedad = variedad;
    this.tamano = tamano;
    this.precio = precio;
    this.ingredientes = ingredientes;
  }

  public List<String> getIngredientes() { 
    return this.ingredientes; 
  }

  public Variedad getVariedad() { 
    return this.variedad;
  }

  public Tamano getTamano() { 
    return this.tamano;
  }

  public double getPrecio() {
    return this.precio;
  }

}

Es verdad que ya no es posible inyectar valores al objeto después de construido, pero sí es posible construirlo con cualquier valor en sus atributos. El problema de integridad es prácticamente el mismo.

Y en cuanto a usabilidad tampoco mejora.

public static void main (String[] args) {
   Variedad variedad = new Variedad(Variedad.Hawaiana);
   List<Ingrediente> ingredientes = new ArrayList<>( 
     Arrays.asList( 
       new Ingrediente(“Queso”),
       new Ingrediente("Jamón"),
       new Ingrediente("Piña")
     )
   );
   Tamano tamano = Tamano.MEDIANA;
   double precio = /* alguna logica para calcular el precio */
   Pizza pizza = new Pizza(variedad, ingredientes, tamano, precio);
   System.out.println("Precio de la pizza: $" + pizza.getPrecio());
}

En mi experiencia, rara vez un constructor va a necesitar realmente todos sus atributos en su construcción (salvo un objeto inmutable). Por otra parte, un constructor vacío no ayuda mucho. Sin embargo, es muy común ver la implementación de este par de constructores.

Lo que corresponde, entonces, es implementar constructores que tengan sentido para la naturaleza de la clase y de la aplicación.

Mejoras en la implementación

Mejorando la implementación de getters, setters y constructores, la clase Pizza podría quedar de la siguiente forma.

public class Pizza {
  private Variedad variedad;
  private List<Ingrediente> ingredientes;
  private Tamano tamano; // Tamano es un ENUM Individual, Mediana, Familiar
  private double precio;

  // Definimos que el tamano y variedad deben pasarse al construir un objeto
  public Pizza(Tamano tamano, Variedad variedad) { 
    this.tamano = tamano;
    this.variedad = variedad;
    // supongamos un método que retorna los ingredientes segun 
    // la variedad seleccionada
    this.ingredientes = variedad.obtenerIngredientesSegunVariedad(); 
    this.precio = calcularPrecio();
  }

  public List<String> getIngredientes() { 
    return this.ingredientes; 
  }

  public Variedad getVariedad() { 
    return this.variedad;
  }

  public Tamano getTamano() { 
    return this.tamano;
  }

  public double getPrecio() {
    return this.precio;
  }

  private double calcularPrecio() {
     double precio = /* calculos en base a los ingredientes y tamaño */
     return precio;
  }

}

Con estos cambios estamos protegiendo de mejor forma los datos de la clase y además dando una mayor claridad de cómo se debe consumir esta clase.

Para el consumidor quedaría así.

public static void main (String[] args) {
   Pizza pizza = new Pizza(Tamano.FAMILIAR, new Variedad(Variedad.Hawaiana));
   System.out.println("Precio de la pizza: $" + pizza.getPrecio());
} // solo dos lineas!!

¿Y si queremos una Hawaiana con Pepperoni? Creamos un método y lo utilizamos después de la creación del objeto.

public void agregarIngrediente(Ingrediente ingrediente) {
    this.ingredientes.add(ingrediente); // ¿ves un posible error acá? sigue leyendo
    this.precio = calcularPrecio(); // se actualiza el precio cada vez que se agrega 
                                    // un ingrediente extra
  }

public static void main (String[] args) {
   Pizza pizza = new Pizza(Tamano.FAMILIAR, new Variedad(Variedad.Hawaiana));
   pizza.agregarIngrediente(new Ingrediente("Pepperoni"));
   System.out.println("Precio de la pizza: $" + pizza.getPrecio());
}

Resumiendo …

La implementación de getters, setters y constructores debe respetar la naturaleza de la clase, exponiendo sólo lo que realmente necesite ser expuesto. En este sentido, mientras menos detalles sean expuestos, mejor. Y mientras más expuestos quedan los detalles de implementación de una clase, más fácilmente llegaremos a un código altamente acoplado.

Y Resumiendo el resumen …

Encapsulamiento va más allá de ‘atributos privados, métodos públicos’.

Mi objetivo es abordar temas técnicos, simples y concretos, que espero puedan servir de ayuda.

El primer tema que abordaré será el manejo de excepciones.

¿Qué es el manejo de excepciones?

El manejo de excepciones es una técnica de programación que permite controlar los errores ocasionados durante la ejecución de un programa (fuente: Wikipedia). Y complementando con su definición en inglés (también Wikipedia), permite manejar el caso Se trata de patrones — o antipatrones — de una pre condición no satisfecha.

¿Por qué es importante?

Tener un correcto manejo de excepciones nos protege de comportamientos inesperados hacia nuestros usuarios, nuestro negocio o hacia nosotros mismos como desarrolladores.

(imagen de mildlyinteresting/ en reddit)

Sin un correcto manejo de excepciones, podríamos tener inconsistencias a nivel de datos y/o flujos de la aplicación. Esto nos puede llevar a mostrar al usuario errores técnicos incomprensibles, dañando además nuestra imagen.

La implementación

A continuación usaré como ejemplo un proyecto sencillo escrito en Java y Spring Boot, pero poniendo foco en conceptos que se pueden aplicar de igual forma a otros frameworks o lenguajes.

Primero, partimos de una implementación sin manejo de excepciones. El siguiente código corresponde a un controlador Rest que responde a una petición HTTP GET.

@RestController
public class CustomersController {

   private CustomerService service;

   @GetMapping("/customers/{id}")
   public ResponseEntity<Customer> getCustomer(@PathVariable Long id) {
       Customer customer = service.getCustomer(id);
       return ResponseEntity.ok(customer);
   }
}

@Service
public class CustomerService {

   CustomerRepository repository;

   public Customer getCustomer(long id) {
       return repository.findById(id).get();
   }
}

Tomando el parámetro id desde la URL (https://url-server/customers/1), el controlador obtiene un objeto Customer desde el CustomerService. Finalmente, retorna un estado HTTP Ok y los atributos del objeto Customer en el cuerpo de la respuesta, de la siguiente forma:

{
   "id": 1,
   "firstName": "John",
   "lastName": "Doe"
}

Pero ¿qué pasa cuando hacemos una llamada por un id no existente? En este caso la respuesta que obtenemos será:

{
   "timestamp": "2024-02-07T15:01:13.087+00:00",
   "status": 500,
   "error": "Internal Server Error",
   "trace": "java.util.NoSuchElementException: No value present
            at java.base/java.util.Optional.get(Optional.java:143)
            at edu.fpoblete.exceptionhandlingdemo.services.CustomerService.getCustomer(CustomerService.java:19)
            at edu.fpoblete.exceptionhandlingdemo.controllers.CustomersController.getCustomer(CustomersController.java:25)
            at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
            at java.base/java.lang.reflect.Method.invoke(Method.java:580)
            at org.springframework.web.method.support.
 …
}

En este caso, la excepción java.util.NoSuchElementException indica que tratamos de acceder a un elemento inexistente. Más específicamente, el stacktrace nos indica el lugar de ocurrencia del error:

at edu.fpoblete.exceptionhandlingdemo.services.CustomerService
  .getCustomer(CustomerService.java:19)
at edu.fpoblete.exceptionhandlingdemo.controllers.CustomersController
  .getCustomer(CustomersController.java:25)

Es decir, dentro del método getCustomer en la clase CustomerService:

   public Customer getCustomer(long id) {
       return repository.findById(id).get();
   }

Esta implementación conlleva -al menos- tres problemas:

1. No hay manejo interno: el código no hace ningún manejo que nos ayude, como desarrolladores, a identificar qué pasó ni cómo podríamos resolverlo.
2. Respuesta de la API: nuestra API no retorna un código o mensaje de error claro. Nuestro consumidor (una aplicación web, un proceso de backend u otro servicio/API) no sabrá qué pasó ni qué hacer al respecto.
3. Exposición de detalles de implementación: a través del stacktrace del error, estamos revelando qué lenguaje utilizamos, algunas librerías, el nombre de nuestro controlador y servicio. Esto podría favorecer a un posible atacante.

A continuación implementaré paso a paso un manejo de excepciones para el código antes expuesto. Este paso a paso refleja distintas realidades de proyectos en los que he trabajado, y busca ayudar a quienes puedan estar teniendo dificultades diseñando o implementando el manejo de excepciones en sus proyectos.

#1 Capturar y relanzar la excepción

Como primer paso capturamos la excepción específica que ya conocemos y dejamos un log que nos ayudará a detectar y corregir el problema. Luego, relanzamos la excepción.

public Customer getCustomer(long id) {
   try {
       return repository.findById(id).get();
   } catch (NoSuchElementException e) {
       logger.error("Error getting customer with id " + id);
       throw e;
   }
}

Resolvimos el primero de los problemas expuestos arriba (manejo interno), pero seguimos sin resolver los otros dos (respuesta de la API y exposición de detalles de implementación). Mejoremos nuestra implementación.

# 2 Esconder la excepción

Con esta implementación, para evitar que el error llegue al usuario o consumidor, la excepción se captura y se esconde, retornando en el cuerpo un objeto vacío.

public Customer getCustomer(long id) {
   try {
       return repository.findById(id).get();
   } catch (NoSuchElementException e) {
       logger.error("Error getting customer with id " + id);
       return new Customer();
   }
}

En este caso, la respuesta de nuestra API quedaría:

{
   "id": null,
   "firstName": null,
   "lastName": null
}

Es decir, dejamos de enviar un código de error (junto con el stacktrace), pero aún no estamos indicando correctamente a nuestro consumidor qué fue lo que pasó.

# 3 Manejo ok pero con código repetido

Como siguiente paso, ahora que capturamos (try/catch) y manejamos internamente el error (de momento al menos el log), lo que nos falta es dar una respuesta correcta a nuestros consumidores.

Como primera forma de resolver esto, podemos agregar también un try/catch en el controlador, pero esta vez lo que haremos será retornar un HTTP 404 notFound. Esto ya indica una respuesta clara al consumidor.

@RestController
public class CustomersController {

   private CustomerService service;

   @GetMapping("/customers/{id}")
   public ResponseEntity<Customer> getCustomer(@PathVariable Long id) {
      try {
          Customer customer = service.getCustomer(id);
          return ResponseEntity.ok(customer);
      } catch (NoSuchElementException e) {
          return ResponseEntity.notFound().build();
      }
   }

}

@Service
public class CustomerService {

   CustomerRepository repository;

   public Customer getCustomer(long id) {
      try {
          return repository.findById(id).get();
      } catch (NoSuchElementException e) {
          logger.error("Error getting customer with id " + id);
          throw e;
      }
   }

}

En este caso, la respuesta queda así:

Con esta implementación, si bien ya estamos cubriendo los tres problemas expuestos, estamos repitiendo código entre el servicio y el controlador. Esta repetición de código aumenta aún más cuando implementamos, por ejemplo, la funcionalidad de deleteCustomer.

@RestController
public class CustomersController {

   private CustomerService service;

   @GetMapping("/customers/{id}")
   public ResponseEntity<Customer> getCustomer(@PathVariable Long id) {
      try {
          Customer customer = service.getCustomer(id);
      } catch (NoSuchElementException e) {
          return ResponseEntity.notFound().build();
      }
      return ResponseEntity.ok(customer);
   }

   @DeleteMapping("/customers/{id}")
   public ResponseEntity<String> deleteCustomer(@PathVariable Long id) {
      try {
         service.deleteCustomer(id);
      } catch (NoSuchElementException e) {
          return ResponseEntity.notFound().build();
      }
      return ResponseEntity.ok().build();
   }
}

@Service
public class CustomerService {

   CustomerRepository repository;

   public Customer getCustomer(long id) {
      try {
          return repository.findById(id).get();
      } catch (NoSuchElementException e) {
          logger.error("Error getting customer with id " + id);
          throw e;
      }
   }

   public void deleteCustomer(long id) {
      try {
          Customer customer = repository.findById(id).get();
          repository.delete(customer);           
      } catch (NoSuchElementException e) {
          logger.error("Error getting customer with id " + id);
          throw e;
      }
   }
}

Por otra parte, estamos generando un acoplamiento entre el controlador -la capa más externa de la aplicación- y una excepción de bajo nivel, como la java.util.NoSuchElementException, lo que no es deseable.

Así que vamos por el siguiente paso.

# 4 Refactorizando

Lo que toca ahora entonces será no sólo cumplir con la parte funcional del manejo de excepciones sino también con que la implementación siga un diseño consistente y escalable.

Los cambios que haremos son:

• Crear una clase CustomerNotFoundException. Esta excepción nos permite en el controlador manejar excepciones de alto nivel, orientado a lógica de negocio y no a detalles de implementación.
• Capturar en el servicio la NoSuchElementException pero lanzar hacia el controlador la recién creada CustomerNotFoundException.
• Mover el log desde el bloque catch del servicio hacia la excepción misma. Esto permite centralizar el loggeo (u otro tipo de manejo que hagamos de la excepción) evitando repetir código, no sólo entre capas sino también entre funcionalidades. Si más adelante queremos cambiar el log por, por ejemplo, la publicación de un mensaje en una cola, tenemos que hacer el cambio en un sólo lugar.

@RestController
public class CustomersController {

   private CustomerService service;

   @GetMapping("/customers/{id}")
   public ResponseEntity<Customer> getCustomer(@PathVariable Long id) {
      try {
          Customer customer = service.getCustomer(id);
      } catch (CustomerNotFoundException e) {
          return ResponseEntity.notFound().build();
      }
      return ResponseEntity.ok(customer);
   }

   @DeleteMapping("/customers/{id}")
   public ResponseEntity<String> deleteCustomer(@PathVariable Long id) {
      try {
         service.deleteCustomer(id);
      } catch (CustomerNotFoundException e) {
          return ResponseEntity.notFound().build();
      }
      return ResponseEntity.ok().build();
   }
}

@Service
public class CustomerService {

   CustomerRepository repository;

   public Customer getCustomer(long id) {
      try {
          return repository.findById(id).get();
      } catch (NoSuchElementException e) {
          throw new CustomerNotFoundException(id);
      }
   }

   public void deleteCustomer(long id) {
      try {
          Customer customer = repository.findById(id).get();
          repository.delete(customer);           
      } catch (NoSuchElementException e) {
          throw new CustomerNotFoundException(id);
      }
   }
}

public class CustomerNotFoundException extends Exception {

   Logger logger = new Logger();

   public CustomerNotFoundException(long id) {
       super("Error getting customer with id " + id);
       logger.error("Error getting customer with id " + id);
   }
}

Con este último cambio cumplimos funcionalmente y tenemos un diseño más escalable y desacoplado.

¿Qué piensas? ¿cómo implementas tú el manejo de excepciones en tus proyectos?

Nota: al usar Java se podría -y sugiere- utilizar funcionalidades de la librería Optional, como ifPresent() o orElse(), pero este ejemplo preferí dejarlo lo más independiente posible del uso de librerías o frameworks.

Esta diversidad, si bien no me acerca a ser realmente experto en una industria o tecnología, me permite (y obliga a) a abordar y entender la programación y la ingeniería de Software de una manera amplia, más allá de las características propias de cada lenguaje o tecnología.

Desde esta vereda, la del freelance, he detectado algunos patrones de código -o antipatrones de código- comunes. Aspectos que, por las razones que sea, distintos tipos de clientes, de distintas industrias, y con distintas tecnologías, están repitiendo.

Generalmente los técnicos atribuimos esto a la falta de tiempo, al apuro, que viene desde las áreas de negocio, y que nos obliga a sacar productos en plazos poco razonables. Creo también que se habla mucho de IA, de Cloud, de frameworks, pero poco de Ingeniería de Software, de programación, pura y dura. Quizás algo de eso hay también.

Todo lo anterior me motivó a volver a escribir, específicamente sobre temas de la Ingeniería de Software, quizás poco vendedores hoy en día, pero esenciales si queremos construir software de buena calidad. Manejo de excepciones, Inyección de dependencias, Métricas de código, Refactoring, Pruebas Unitarias, Acoplamiento, Encapsulamiento, por nombrar algunos.

Así, en próximos artículos quiero profundizar en temas técnicos a través de pinceladas de teoría, junto con ejemplos prácticos y justificación de por qué su relevancia, a nivel técnico y de negocio.

Espero lograrlo y, con esto, poder ayudar a otros desarrolladores a estar más consciente de este tipo de temas y a evitar los problemas en el tiempo que pueden traer.

Nos estamos leyendo.

Something happened in my team last Sprint that’s not very common: we finished all stories four days before the end of the Sprint. Our Product Owner was happy because we managed to add two more stories and we were happy because we were able to work on spikes and technical tasks from our continuous improvement backlog.

At our next retrospective some team members pointed at our improving velocity as a positive result, having set a new record of 23 story points. However, my take on this same event was that it was a bad result because we had overestimated two of our stories. This difference of opinion around the same event led us to discuss whether we wanted, as a team, to increase our velocity or not, as measured in story points delivered per Sprint.

My opinion is very clear on this — I DON’T want to increase my team’s velocity and not because I want to be mediocre or complacent. I do want to get better but I do not think that velocity is a useful way to measure a team’s performance. If we want to get better, it’s not velocity that we should be focusing on.

Before I continue with this post, I want to point out that I am very aware of #NoEstimates, but as a team we have decided not to change our approach to story points due to the fact that we face other changes, both in methodology and technology and I am of the opinion, as are others (here and here), that it is not helpful to change too many things at once.

So, why shouldn’t we try to increase our velocity? I can think of at least three reasons.

Continuous Improvement versus Velocity

When we estimate stories, we use the Fibonacci scale, and we consider three main factors that affect the size of a story:

1. Repetitiveness. Have we implemented anything similar in the past?
2. Risk. Are there any unknowns associated with the process, organization, definitions, stakeholders? Or is there something we don’t know whether it will affect us?
3. Complexity. How many tasks are needed to complete the story and what is their complexity?

As a part of our continuous improvement process, we are always looking at this three factors and every time we introduce an improvement for one of them, it allows us to make our stories smaller. Let me explain this with an example.

Let’s say in Sprint 1 we have to implement an interface to a configurations table. After a few refinements, we estimate that story as 8 points due to the following:

1. We’re going to work with an ORM that we have never used before (size increases due to low Repetitiveness).
2. We have to generate all the views manually, including forms and validations (size increases due to high Complexity).
3. There isn’t a clearly identified owner for that particular database (size increases due to high Risk).
4. Creating tables is a manual process in every environment (development, beta, UAT, production). (size increases due to high Complexity).

At the end of Sprint 1 we discussed all these factors in our Retrospective and, after talking to our PO, we defined two technical tasks for Sprint 2: one for automating the creation of views using a template and another for automating the creation of tables as we move across environments.

The PO also met with stakeholders and reached an agreement on who should own the database.

In Sprint 3, we have to make a similar interface but for a different table. The ORM is no longer new for us, we can create views and tables automatically, and we have a clearly identified owner for the database. As all factors for Sprint 1 no longer apply, now we give this story only 2 points. That means we can build eight interfaces instead of two, but our velocity is still the same!

That’s not really a problem, you just have to know how to read the numbers and what’s going on behind them.

Predictability versus Velocity

On one occasion, a project manager — new to agile and used to Gannt charts and detailed planning before the start of a project — claimed to be finally convinced by this new way of working and that even the executives were convinced. However, the one issue on which they remained unhappy was that Sprint after Sprint the team didn’t deliver what they had committed to.

This project manager didn’t care if the team delivered 10, 20 or 500 story points, but did care — a lot — about having certainty (or at least a high degree of certainty) of what the team was going to deliver in two weeks.

What’s the point of increasing such an arbitrary measure as story points? If nobody outside the team understands what a story point is, why would they want the team to deliver more of them? The team had better focus on improving predictability, not velocity.

The subconscious bias

If you have a goal of delivering more and more points every sprint, the easiest way to achieve that goal is to always overestimate. I’m not saying that people will cheat, but our subconscious can play tricks on us, especially when the goal is imposed by a manager outside the team or even worse, when that goal is linked to a performance appraisal and/or bonus.

So, how do we know if we are improving?

There are a lot of metrics we can measure and manage: bugs in production, automated test coverage, stakeholder satisfaction, just to name a few. The important thing to understand is that all metrics have pros and cons, that all of them can encourage bad behaviors if they’re misunderstood, and that having too many metrics is the same as having none, but that could be a topic for a new post.

Original post was written in Spanish and you can find it here. Many thanks to César Idrovo for his help with the english translation

En el último Sprint en mi equipo ocurrió algo que pocas veces ocurre: terminamos todas las historias cuando quedaban aún 4 días de Sprint. El Product Owner estaba feliz porque incluimos 2 historias más y nosotros estábamos felices porque incluimos Spikes y tareas técnicas de nuestro Backlog de mejora continua.

Al llegar la Retrospectiva algunos comentaron, como algo positivo, que habíamos subido nuestra productividad, llegando al récord de 23 puntos en un Sprint. Sin embargo, respecto del mismo hecho, yo comenté como algo negativo que habíamos sobreestimado dos de las historias. Esta diferencia de opinión respecto del mismo hecho nos llevó a discutir sobre si como equipo queremos/debemos o no tratar de subir nuestra velocidad, medida como story points entregados por sprint.

Mi postura al respecto es bastante clara, yo NO quiero subir la velocidad de mi equipo y no es que sea mediocre o conformista. Es normal que un equipo quiera mejorar en el tiempo y entiendo la tentación de tratar de entregar más en cada sprint, pero no es la velocidad lo que nos debe preocupar.

Antes de seguir con este artículo, quiero mencionar que sí conozco #NoEstimates pero como equipo hemos decidido mantenernos con los story points debido a que estamos enfrentando otros cambios, tanto metodológicos como tecnológicos y soy de la opinión, al igual que otras personas (aquí y aquí), que no es bueno hacer muchos cambios a la vez.

Ahora retomando, ¿por qué no debemos apuntar a aumentar la velocidad? Al menos a mí se me ocurren tres razones.

Mejora continua versus velocidad

En mi equipo usamos la escala de Fibonacci para estimar y consideramos tres factores que contribuyen en el tamaño de una historia:

1. Repetitividad. ¿Hemos implementado en el pasado algo similar en el pasado?
2. Riesgo. ¿Existe algo desconocido en el proceso, organización, definiciones, stakeholders? ¿o algo conocido pero que no sabemos si nos va a afectar?
3. Complejidad. ¿Cuántas tareas se necesitan para completar esta historia y cuál es su complejidad?

Como parte de la mejora continua, estamos preocupados permanentemente de estos tres factores y, cada vez que logramos implementar alguna mejora en uno de ellos, las historias se van haciendo cada vez más chicas. Déjenme ilustrar esto con un ejemplo para que quede más claro.

Supongamos que en el Sprint 1 tenemos que implementar un mantenedor para una tabla de configuración. Después de varios refinamientos estimamos la historia en 8 puntos, ya que identificamos lo siguiente:

1. Vamos a usar un ORM con el que nunca antes hemos trabajado. (baja Repetitividad, crece tamaño).
2. Tenemos que generar todas las vistas manualmente, incluyendo formularios y validaciones. (sube Complejidad, crece tamaño).
3. No está claro quién es el dueño de la Base de Datos. (sube Riesgo, crece tamaño).
4. El proceso de creación de tablas es manual en cada uno de los ambientes (desarrollo, beta, uat, producción). (sube Complejidad, crece tamaño).

Al terminar el Sprint 1, conversamos estos temas en la retrospectiva y, luego de hablarlo con el PO, incluimos en el Sprint 2 una tarea técnica para automatizar la creación de vistas a partir de un modelo y otra para automatizar la creación de tablas al pasar de un ambiente a otro.

Por otra parte, el PO logró reunir a los stakeholders y se llegó a un acuerdo sobre quién es el dueño de la Base de Datos.

En el Sprint 3 debemos implementar otro mantenedor, para otra tabla del sistema. ¿Cuántos puntos debiéramos darle a esta nueva historia? Dado que los 4 aspectos anteriores fueron mejorados o resueltos, ahora el equipo estima la historia en 2 puntos. Ahora podemos hacer 8 mantenedores por Sprint en vez de 2, ¡pero nuestra velocidad sigue siendo la misma!

La verdad es que esto no es realmente un problema, sólo hay que saber mirar los hechos detrás de los números.

Predicitibilidad versus velocidad

Una vez un jefe de proyecto, nuevo en la agilidad y acostumbrado a cartas Gantt y a la planificación anticipada y detallada, me comentó que finalmente se había convencido con esta nueva forma de trabajar y que incluso los ejecutivos ya estaban convencidos. Lo único que no lo tenía feliz era que el equipo, Sprint tras Sprint, no alcanzaba a entregar lo que había comprometido.

A este jefe de proyecto no le importaban si eran 10, 20 o 500 story points, lo que le importaba era tener una certeza (o un buen grado de certeza) de qué iba a entregar el equipo de aquí a dos semanas más.

¿Qué sentido tiene querer aumentar la velocidad de un equipo cuando se usa una medida tan arbitraria como story points? ¿a quién le sirve que aumente algo que es medido en una escala que nadie entiende fuera del equipo? Más vale la pena que el equipo se enfoque en mejorar su predictibilidad, no su velocidad.

La trampa del inconsciente

Dejé para el final la que quizás es la más obvia de las razones. Si uno tiene como objetivo aumentar la cantidad de puntos entregados por sprint, entonces lo más fácil es asignar números más grandes al estimar. No que las personas hagan intencionalmente trampa, pero el inconsciente nos puede engañar y llevar a este tipo de vicios, sobre todo cuando la capa de management introduce metas del tipo “aumentar en 20% la velocidad por semestre”, o peor aún cuando asocia la velocidad de un equipo a su evaluación y/o a su bono de desempeño.

¿Cómo sabemos si vamos mejorando?

Si no subimos nuestra velocidad, entonces ¿cómo sabemos si vamos mejorando? Existen muchas otras métricas que podemos implementar y gestionar: cantidad de defectos en producción, cobertura de pruebas automáticas, performance, complejidad ciclomática o satisfacción de los stakeholders, por nombrar algunas. Es importante entender eso sí que todas las métricas tienen ventajas y desventajas, todas pueden generar vicios y trampas inconscientes y que no nos podemos llenar de métricas porque tener muchas es lo mismo que no tener ninguna, pero eso podría quedar como tema para un futuro post.