La deuda técnica

1 Ago

En muchos proyectos de desarrollo software se suele presentar una disputa entre el satisfacer las restricciones de tiempo/costo versus el requerimiento de entrega de un producto de calidad.

Razones para esto son muchas entre las cuales tenemos:

  • Aspectos estratégicos: Las empresas buscan maximizar su rentabilidad estableciendo condiciones para que los productos se finalicen con tiempos y costos aceptables para el cliente (e ideales para la empresa) pero con niveles de calidad pobrísimos.
  • Aspectos Procedimentales: La calidad, no es correctamente gestionada durante el proceso de desarrollo del software.

Veamos algunos ejemplos gráficos que clarifican esta situación. Idealmente, tendríamos un esquema de avance en el proyecto como el siguiente:

Se espera que la totalidad de los requerimientos sean entregados en una fecha predeterminada.  Para lograr esto, el equipo trabaja a una velocidad planificada de entrega.

Comenzado el proyecto y con el correr del tiempo, aparecen los problemas debido al esfuerzo real que implica cumplir con un trabajo de alta calidad.  Son problemas puesto que las planificaciones iniciales subestimaron el esfuerzo de entregar calidad.

En el anterior gráfico se observa cómo se empieza desviar el avance real respecto al planificado.

Ante esta situación, el Project Manager (PM) acude a una presión extra sobre el equipo con el afán de que se pueda ajustar la fecha de entrega. Si esto funciona, tendremos un escenario como el siguiente:

Dicha presión sobre el equipo funcionó pero no es gratis, alguien tuvo que pagar y esa fue la calidad del producto. Se disminuyó en pos de poder cumplir con los tiempos y costos.

Viendo entonces que fue posible reencauzar el proyecto, el discurso de fundamentación del PM ante el cliente es que “se ha podido retomar el camino ya que el equipo ha adquirido una mejor performance, lo cual le permite avanzar mas rápido”. La realidad es que pudimos cumplir con los plazos y costos cuando se redujo la  calidad del producto. Esta diferencia entre lo que se entregó y lo que se debería haber entregado se denomina deuda técnica (ver orígenes del término en http://en.wikipedia.org/wiki/Technical_debt). Ésta deuda se genera al hacer las cosas de forma rápida y mal.

La deuda técnica es el trabajo vinculado a las funcionalidades comprometidas y que es diferido o descartado para poder cumplimentar con los cronogramas. Que sea diferido implica que no es entregado, por lo tanto afecta la calidad total del sistema.

Ahora pensemos que sucede si tomamos como base el código de proyecto “cumplido” para ejecutar otro proyecto similar. Todo se complica aún más puesto que se parte de código que ya acumula deuda técnica. Ocurre así un efecto de generación de mas cantidad de deuda técnica ya que el nuevo proyecto acumula no solo la deuda nueva generada sino también la heredada

Ejemplos de deuda técnica son, entre otros:

  • Retraso de las actualizaciones criticas.
  • Retraso en el refactoring  del código complejo.
  • En aplicaciones web, codificar toda la lógica de negocio en la capa de presentación.
  • No utilizar logs o manejo de errores robusto.
  • No realizar pruebas o realizarlas de forma muy superficial.

Consideremos una cuestión extra: si este trabajo técnico no hecho es necesario para la salud del producto ¿qué pasa cuando no se hace nada con él? ¿qué pasa cuando se acumula y continúa acumulando deuda técnica y no se la trata?

Veamos un ejemplo. Para un determinado producto, solemos crear la primera versión con deuda técnica. Luego se siguen mas versiones y así sucesivamente. Cada versión introduce nueva deuda. Esto crece al punto que cuando alguien solicita realizar un cambio al producto, el equipo de desarrolladores estalla de rechazo. ¿El motivo?: el producto es inmantenible, es muy complejo para modificar, el código tiene miles de LOC, se requieren desarrolladores expertos para poder modificarlo y cientos de etcéteras.

Cuando esto sucede se dice que el código ya presenta un diseño muerto.  Ante un diseño muerto, la verdad es que no queda mucho por hacer.

Sin dudas existen muchos proyectos como estos. Yo tengo un par de nombres que recuerdo con mucho “cariño”.

Como párrafo final, uno de los grandes facilitadores de este tipo de situaciones es, a mi criterio, el tipo de contrato que se establece entre el cliente y el proveedor, que suele ser del tipo predictivo y precio fijo. Estos contratos se establecen definiendo el alcance del proyecto en etapas tempranas (controlando luego que no se realicen los cambios sobre el mismo o que sean mínimos) e imponiendo restricciones de costo y tiempo. Esta situación, combinada con empresas como las mencionadas al inicio, en las que términos como patrones de diseño, pruebas continua, formación al personal, control de calidad prácticamente no existen, forman un cóctel que sirve deuda técnica en vasos cada vez más grandes.

¿Cómo se evitan o disminuyen los riesgos de deuda técnica?. Pensando solo en la arista referida a los contratos (la otra arista, la de las empresas ávidas de rentabilidad a cualquier costo la dejamos para otro momento) deberemos considerar la adopción de contratos ágiles. Simplemente se los comento ya que esto será inspiración para otro post.

Espero que les haya sido de utilidad.

Seguimos en contacto. Gastón.

Basado en: http://www.scrumalliance.org/articles/14-technical-debt-and-design-death

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: