Tag: Pensamientos

Éxito y Calidad de Software (Borrador)

Estaba pensando en una investigación que hace mucho dejé de lado, pero que he decidido retomar. El triángulo de hierro está involucrado y también una presentación que hice hace 9 años (!@#!@#! estamos envejeciendo)

Tenemos que aceptarlo, hace mucho que la calidad ha pasado a un segundo o tercer plano debido a la posiblle confusión generada por la agilidad y la necesidad del negocio porque es “transparente”, “ya debería venir”, “no habíamos pensado en eso” o bueno, “es una caja negra”, cuando en realidad es un factor crucial para el éxito en un proyecto.

Pero bueno, voy a darle una mirada a esa presentación que hice en Microsoft Perú por esa época, estoy seguro que muy pocos la recuerdan. También estoy seguro que mis chistes fueron malos, Pero diablos, tanto tiempo y esa ppt tiene cosas que siguen caladas en mi ser!

exito-suma-esfuerzos
Fuente: AMANCAY

Abrazo de gol peruano.

JD

Deuda técnica en el 2017

Si bien es cierto nunca he escrito sobre la deuda técnica, reconozco que cada cierto tiempo reviso o empiezo un nuevo borrador al respecto y lo dejo –con mucho dolor– en la lista de apuntes sin publicar.

Hoy por la noche voy a borrar aquellos apuntes y tengo un sinsabor que aumenta con el paso de los años.

Antes de continuar con ello y para quitarme el clavo, aquí algunos apuntes:

  1. Ward Cunningham indica que la deuda está asociada a la programación/reprogramación/corrección que harás más adelante, pues hoy –o ayer– no hiciste un programa sin seguir las recomendaciones, estándares o buenas prácticas de programación y/o arquitectura.
  2. McConnell y Fowler clasifican las causas como deliberadas, por desconocimiento o incluso ingeniudad.
  3. Por mi parte y considerando que más que software se entrega una solución, pienso que la deuda se debe analizar en todo sentido, en cada capa, etapa, proceso, modelo o secuencia utilizada para la creación del producto.
    • Esto significa que también se debe hacer una mención al hecho de cómo se definen las necesidades de los usuarios o cómo es que se compila, distribuye o instala el software resultante.
    • Tampoco se debe olvidar el prototipado/maquetado de la solución. El cual a veces es olvidado y otras es tan sobrevalorado que hasta llegas a odiarlo.
  4. La deuda se debe mitigar de a pocos ni bien se vaya identificando. Sería ideal eliminarla pero casi nunca es así.
  5. Para finalizar, creo que para no confundir, la deuda técnica debería cambiar de nombre o al menos de versión, pues la realidad ha cambiado y con tantos nuevos jugadores, debería existir algo así como una “Deuda Técnica 2.0”

Continue reading “Deuda técnica en el 2017”