Está en la página 1de 4

DEUDA TCNICA

La deuda tcnica es un eufemismo tecnolgico que hace referencia a las consecuencias de un


desarrollo apresurado de software o un despliegue descuidado de hardware.
La deuda tcnica suele materializarse en las siguientes formas:
Documentacin escasa, incompleta o inservible.
Errores.
Ausencia o deficiente control de versiones.
Arquitectura no escalable.
Rigidez para actualizar a nuevas tecnologas o plataformas.
Definicin
El sector informtico presenta la particularidad de que permite la implantacin de productos
no acabados o con errores conocidos. En ocasiones, la poltica de ahorro de costes en la
implantacin de hardware o el desarrollo de software se centra en recortar los procesos de
pruebas, control de calidad o documentacin, o incluso algunos parmetros bsicos de
optimalidad de procesos, lo que compromete la viabilidad a largo plazo del proyecto a cambio
de poder entregarlo en el plazo previsto y con el presupuesto acordado.
Consecuencias
El resultado de esta poltica implica que el desarrollo del software se prolonga en el tiempo
ms all de la entrega del producto supuestamente concluido; incluso en ocasiones son
distintos equipos de desarrollo los que acaban hacindose cargo de las mejoras. Si el proyecto
estaba delimitado en fases, la subsanacin de errores de las fases ms tempranas se solapara
con el desarrollo de las siguientes fases, lo que dificulta llevar a buen trmino ambas tareas.
Lo mismo es aplicable para el despliegue de hardware o tareas equivalentes.
En concreto, la deuda tcnica puede presentarse en alguna de las siguientes formas:
Documentacin desactualizada, escasa, incompleta, inservible o inexistente.
Errores no subsanados o desconocidos.
Control de versiones ineficiente o inexistente.
Desarrollo no escalable.
Problemas al incorporar nuevas funcionalidades
Dificultades a la hora de actualizar la tecnologa o migrar a una nueva plataforma.
PROGRAMACIN EXTREMA
La programacin extrema o extreme Programming (XP) es una metodologa de desarrollo de
la ingeniera de software formulada por Kent Beck, autor del primer libro sobre la materia,
Extreme Programming Explained: Embrace Change (1999). Es el ms destacado de los
procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se
diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la
adaptabilidad que en la previsibilidad. Los defensores de la XP consideran que los cambios de
requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo
de proyectos.
Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del
proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.
Se puede considerar la programacin extrema como la adopcin de las mejores metodologas
de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de
manera dinmica durante el ciclo de vida del software.
12 PRINCIPIOS DE XP
1. Planificacin incremental
2. Testing
3. Programacin en parejas
4. Refactorizacin
5. Diseo simple
6. Propiedad colectiva del cdigo
7. Integracin continua
8. Cliente en el equipo
9. Lanzamientos pequeos
10. Semanas de 40 horas
11. Estndares de codificacin
12. Uso de Metforas
LA CORRUPCIN DE GIL
Cuando se intenta ajustar CMMI o TSP a SCRUM, aparecen ideas como: en los Sprint hago las
inspecciones, los diseos de alto nivel y detallados, el post-mortem lo puedo reemplazar, el
registro de tiempos en el dashboard, los riesgos?. En general se busca acomodar dichos
modelos como sea adoptndolos para que cumplan con lo que ya est definido y desde luego
sin generar problemas.
En la industria, en pases y en general en diferentes contextos se han venido adoptando las
prcticas giles porque se han comprobado con resultados. Sin embargo, cuando se intentan
adoptar sin conviccin se busca a toda costa la trampa, los argumentos rancios y sobre todo
las posiciones con poca argumentacin pero si con una actitud blica (no puedo perder esta
batalla) como: no es necesario entregar software funcionando o una iteracin no tiene
porque tener entregas de valor! Qu es valor, acaso no es el tiempo, el alcance y el costo?
No es necesario que los miembros de un equipo de trabajo estn trabajando juntos!
An es ms difcil cuando empiezan las discusiones acerca de los principios giles. De igual
forma hay Organizaciones que promueven certificaciones de SCRUM (no incluyo a
ScrumAlliance) olvidando dichas bases acomodando sus intereses en actividades relacionadas
con cursos, coaching, entre otros, olvidando la coherencia.
En otros escenarios existen ciertos personajes que acomodan su discurso gil, buscando fines
publicitarios, de marketing o por cumplir con las exigencias de un Cliente; en trminos
generales se disfrazan pero en si son farsantes y no pueden sostener una mentira por mucho
tiempo pues no tienen conviccin. Estos a todo lo llaman gil o SCRUM e incluso incrustan
prcticas o tcnicas con aleaciones raras o hacen propias teoras o modelos ajenos; quizs en
la vida han desarrollado una buena lnea de cdigo.
Es obvio que en una empresa es complicado iniciar modelos giles arrancando todo a la vez,
de la noche a la maana; hay que decidir por dnde comenzar, pero no hay que olvidar la
visin, el fin, los objetivos propuestos creyendo y aplicando lo que se profesa.
En si, creo que debemos ser buenos artesanos de software adoptando las prcticas y tcnicas
que nos den ms productividad (como XP) a la vez que implantamos a SCRUM, LEAN u otro
modelo.
Sabes la cultura en la que ests observando las prcticas de las personas alrededor tuyo. Si
ves una mujer con una bura, puedes adivinar su cultura. Si ves a una novia y novio rompiendo
una copa, puedes adivinar su cultura. Si ves un grupo de nios agitando una vara hacia un
burro de papel mach colgando de un rbol, puedes adivinar su cultura.
No puedes tener una cultura sin prcticas; y las prcticas que sigues identifican tu cultura.
Bob piensa de otra manera:
[...] si te encuentras en un equipo que practica integracin continua, iteraciones cortas, pair
programming y TDD, es una indicacin de que ests en un equipo que comparte los valores
del manifiesto gil. Si no compartieran esos valores, no seguiran esas prcticas.
Corrupcin
Bob finalmente va tras los herejes:
As, para m, la verdadera corrupcin de la agilidad est en lo que dice Holub:
agilidad es una cultura, no un conjunto de prcticas
No. Agilidad es una cultura expresada a travs de un conjunto de prcticas.
Tal vez tales prcticas pueden cambiar y (dada la complejidad del desarrollo de software) no
ser universales? l est parcialmente de acuerdo con la primera parte:
Estn esas prcticas escritas en piedra? Son las 13 prcticas originales de XP la escritura
sagrada? Eres un apstata si no practicas TDD? Por supuesto que no. Pero si no usas esas
prcticas particulares, lo mejor es que uses algunas que sean tan buenas o mejores.
Desafortunadamente l parece creer en prcticas ms o menos universalmente
buenas/mejores. A veces no tengo idea si algo que probamos en Continuum va a ser aplicable
para nuestro siguiente proyecto/cliente Difcilmente podra saber si son generalizables
incluso ms all.
Y en cualquier caso, cmo se supone que uno sabe si una prctica puede ser igual de buena o
mejor sin horror! corromperte y desviarte de las prcticas originales para intentar
algo distinto (por tanto creyendo que la agilidad es realmente acerca la
cultura/valores/principios/creencias en lugar de tales prcticas originales)? Por lo tanto, me
declaro un profundamente corrupto agilista.
LA VERDADERA CORRUPCIN DE GIL
El problema ms grande que he visto en el movimiento gil es la eliminacin de las prcticas.
Uno por uno , a lo largo de los aos, las prcticas han sido desenfatizadas o despojado incluso
. Esta prdida de la prctica se ha diluido y ha cambiado la cultura Agile en algo que no
reconozco como Agile ms. Ha habido un alejamiento de la excelencia hacia la mediocridad ,
lejos de las duras realidades , hacia lugares comunes para sentirse bien.
Se inici con la idea de que cualquier persona puede convertirse en un "maestro" de nada por
sentado en una clase de hora pero an as conseguir un pedazo de papel. Poco a seguir fue la
dilucin y la eventual prdida de las prcticas tcnicas . Esto llev a Martin Fowler publicar su
clsico y definitivo blog: flcida Scrum. Luego vino el nfasis de la gestin de proyectos a
travs de la artesana y el aumento de las habilidades blandas ( actitudes) sobre las
habilidades duras (prcticas ) .
En esa reunin de 2001 en Snowbird , donde escribimos el Manifiesto gil , Kent Beck declar
una de nuestras metas : " .. Para sanar la brecha entre el desarrollo y los negocios. " Por
desgracia, la reduccin del nfasis de las prcticas dentro del movimiento Agile slo ha
servido para ensanchar esa brecha . Mientras que los directores de proyectos se han reunido
en el movimiento gil , los desarrolladores han huido de ella. El movimiento original ha
fracturado en dos movimientos . El movimiento Artesana Software ha conservado el
acoplamiento entre la prctica y la cultura; mientras que el movimiento Agile se ha alejado de
l.

As que , en mi opinin , la verdadera corrupcin de Agile es la declaracin de Holub:
" ... gil es una cultura, no un conjunto de prcticas..."
No. Agile es una cultura expresada a travs de un conjunto de prcticas.
Se establecen las prcticas en piedra? Son las 13 prcticas originales de XP la Sagrada
Escritura? Eres un apstata si no practicas TDD ? Por supuesto que no . Pero si usted no
utiliza esas prcticas particulares , es mejor que use algunos que son tan buenos o mejores . Y
las prcticas que utiliza se definen su cultura y ser una expresin de sus valores.
Si sus valores son los del Manifiesto gil , a continuacin, sus prcticas es probable que se
parecen mucho a los 13 originales ; debido en gran parte fueron esas 13 prcticas que nos
llevaron a escribir ese manifiesto .

También podría gustarte