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 .