Deuda tecnica
•Download as PPTX, PDF•
0 likes•483 views
Descripción de deuda técnica y tips para administrarla.
Recommended
Recommended
More Related Content
Similar to Deuda tecnica
Similar to Deuda tecnica (20)
Recently uploaded
Recently uploaded (20)
Deuda tecnica
- 1. DEUDA TECNICA “Preferible ir a dormir sin haber cenado que levantarse con una deuda.” Benjamin Franklin
- 2. • Que es una deuda técnica. • Que es exactamente una deuda técnica. • Consejos para manejar el uso de deuda técnica.
- 3. QUE ES UNA DEUDA TÉCNICA?
- 4. Steve McConnell … en el area de negocios piensan que podemos cargar deuda técnica porque nunca ven realmente las consecuencias. Pero esas consecuencias existen … solo que nunca expresadas un una manera que ellos puedan comprender.
- 5. ANALOGIA El problema del significado dual de las palabras.
- 9. QUE ES EXACTAMENTE UNA DEUDA TÉCNICA?
- 10. La deuda técnica se refiere a las consecuencias una arquitectura o un sistema diseñado pobremente dentro del código de un proyecto.
- 11. La deuda puede verse como trabajo que necesita realizarse antes que el proyecto pueda considerarse como completo.
- 12. Si la deuda no se paga, continuara incrementando interés haciendo difícil implementar cambios en el futuro.
- 13. • La deuda técnica se refiere a las consecuencias una arquitectura o un sistema diseñado pobremente dentro del código de un proyecto. • La deuda puede verse como trabajo que necesita realizarse antes que el proyecto pueda considerarse como completo. • Si la deuda no se paga, continuara incrementando interés haciendo difícil implementar cambios en el futuro.
- 14. UN EJEMPLO
- 15. Todo empieza con una app y dos tipos de usuario.
- 16. ¿Es necesario un sistema de permisos?
- 18. Permisos adicionales con una linea de código.
- 20. Quedan 3 posibles escenarios
- 21. Escenario 1 4 esta semana. 22 la próxima. 0 para futuros permisos. Dinero ahora
- 22. Escenario 2 21 esta semana. 0 para futuros permisos. Dinero después
- 23. Escenario 3 4 esta semana. 5, 6, 7 … para futuros permisos. Dinero ahora
- 24. Some civil engineering analogies
- 27. Legacy Code
- 32. The big rewrite (corregir todo el código)
- 33. COMO MANEJAR LA DEUDA TÉCNICA?
- 36. MVP
- 37. PROPÓSITOS DEL MVP • Posibilidad de probar un producto con el mínimo de recursos. • Acelerar el aprendizaje sobre la utilidad del producto. • Reducir el desperdicio de horas de ingeniería. • Liberar el producto a los usuarios lo mas pronto posible.
- 38. MLP Las tablets existían antes del iPad.
- 39. MLP Ya había autos eléctricos antes de Tesla.
- 40. MLP Antes de Google ya había motores de búsqueda.
- 42. MLP La ventaja esta en ser disruptivo, no en ser el primero.
- 43. CAMBIO CULTURAL Cuando la meta es la calidad …
- 44. VS Winners 2014 Hello World Open
- 45. BIBLIOGRAFIA • http://www.amazon.com/Working-Effectively- Legacy-Michael-Feathers/dp/0131177052 • https://medium.com/@joaomilho/festina-lente- e29070811b84 • https://en.wikipedia.org/wiki/Technical_debt
- 46. VOLUNTARIOS • Agile and Scrum. • Extreme Programming. • Kanban en el desarrollo de software. • Ubiquitous Computing and Internet of Things. • Computer Vision Applications. • Design Patterns. • A/B Testing
- 47. GRACIAS
Editor's Notes
- En esta presentación, ustedes aprenderán una de las principales causas de proyectos fuera de tiempo, fuera de presupuesto. Codigo que no puede ser mantenido, ni escalado. También conocerán formas para combatir este mal. Se trata de la deuda técnica. Les comparto esta frase atribuida a benjamin franklin: “Preferible ir a dormir sin haber cenado, que levantarse al dia siguiente con una deuda” Definitivamente nadie queremos vernos en la situación de deber algo a alguien mas especialmente si cobra intereses. Como veremos, la deuda tecnica se genera de esa clase de prestamos que generan un interes, es decir, mientras mas pides, la cantidad a pagar se incrementa exponecialmente. Y si esperas demasiado puedes termiar en la ruina.
- Este es Steve McConnell, el autor del libro Code Complete. entre otras obras maestras, en una entrevista para el sitio web "On Technical Debt" Steven C. McConnell es el autor de muchos libros de ingeniería que incluyen Code Complete, Rapid Development y Software Estimation. En 1998, McConnell fue nombrado como una de las tres personas mas influyentes de la industria de software por la revista Software Development, junto con Bill Gates y Linus Torvalds.
- En el desarrollo de software, las consecuencias de sacrificar la calidad son malentendidas por managers no-tecnicos. Dado que los managers no técnicos no poseen experiencia de primera mano creando software, hacemos uso de las analogias… Esta es una frase de Sigmund Freud: “Uno es dueño de lo que calla y esclavo de lo que habla” El problema aqui es que las palabras dueño y esclavo son utilizadas en un contexto totalmente nuevo, y la interpretación depende de quien escucha. Por eso, pretendo dar un explicación mas completa sobre lo que es la deuda técnica.
- Deuda es lo que resulta de adquirir algo ahora por el compromiso de pagar en el largo plazo. Si no pagas a tiempo, generas intereses y aunque te rehuses a pagar la deuda solo se incrementa con el tiempo.
- Y si ignoras la deuda por demasiado tiempo …
- Se convierte en impagable y por lo tanto estarás en bancarrota
- Todo empieza cuando el equipo a escribir una aplicación y no hay necesidad para roles de usuario. Cualquier usuario puede hacer cualquier cosa. En algún punto se plantean dos permisos de usuario distintos, un tipo de usuario puede ver un reporte y los demás no.
- El equipo técnico considera si crear un sistema completo de permisos, usando una serie de patrones de diseño para lograrlo. Pero a este punto esto se ve realmente como un ovekill, sobre-ingenieria … Un método en el controlador y un par en la interfaz gráfica serán suficientes.
- Algún tiempo después hay un nuevo requerimiento que necesita de la diferenciación de usuarios, y luego otra y otra … En este punto los desarrolladores se dan cuenta que el código está empezando a volverse enredoso y la solución es un “refactoring" del código que es básicamente, reestructurar el código fuente, sin alterar el funcionamiento del software para ahora si, tener un sistema de permisos decente.
- Hacer esta refactorización tomara mucho mas tiempo que solo agregar un nuevo método, pero simplificara el código y hará que agregar futuros permisos sea tan simple como agregar solo una línea de código o solamente agregando una fila en la base de datos.
- El problema es que existe una necesidad del negocio que requiere del sistema actual de permisos uno o dos días mas, pues cinco clientes muy importantes firmaran un contrato con la empresa esta misma semana, y no queremos hacerlos esperar hasta la próxima semana, ya que necesitan un nuevo permiso pero quizás nunca firmen, si no les gusta el hecho, de que la compañía no les cumplirá su única petición para esta semana.
- En este punto es donde la decisión de tomar un "prestamo" puede hacerse. Toda la información relevante para tal decisión es clara. Al principio, agregar un permiso tomo 3 story points. Ahora toma 4. Pronto tomara 5, 6 … no se puede predecir. La refactorización completa toma 21 ahora. Así que la decisión, hoy, no es entre 4 y 21. Es entre tres posibles escenarios:
- I. 4 story points ahora (el permiso), 22 story points después (la refactorización, que ahora será un poco mas complicada por el nuevo permiso) y algo cerca de 0 story points por cada nuevo permiso depuse de esto, seguido de un incremento general en la productividad del equipo; En este escenario la compañía a añadido 5 clientes al portafolio y el dinero del contrato llega pronto;
- II. 21 story points ahora (la refactorización), 0 después (el nuevo permiso); En este escenario la compañía no pudo agregar los 5 clientes al portafolio por ahora, así que el dinero por los contratos vendrá después;
- III. 4 story points ahora (el permiso), sin refactorizar nada, y luego 5 para el siguiente permiso, y luego 6, 7… hasta el punto que una nueva refactorización sea propuesta, pero ahora costanto mas de 50 story points; En este último escenario el dinero llega pronto, pero la próxima vez que sea requerido algo especifico para agregar permisos tomará mucho mas tiempo; Dato el tiempo total, siempre es mejor elegir el mejor diseño posible. Justo como el mejor escenario para una compañía es ser capaz de invertir en nuevas cosas sin tener que ir al banco. Pero como están las cosas en la historia, el primer escenario es la manera mas sabia de proceder. Solo una advertencia: incluso este tipo de estrategia no puede ser implementada constantemente. En cada proyecto toca analizar para encontrar la mejor solución.
- Algunos ejemplos encontrados en brasil nos pueden ilustrar las consecuencias de la construcción sin diseño alguno ni cuidado por la calidad.
- Esto es lo que se llama en portugués un “puxadinho" y se trata de una construcción hecha sin ninguna supervision, materiales precarios e ilegalmente.
- O el siguiente ejemplo que viene de la misma area. En el desarrollo de software esto es exactamente lo que sucede cuando un manager la programación no tiene un diseño mínimo definido. Y no es solo una falla de diseño, lo que hacemos es dañar código anterior, on incluso destruirlo. Esta tan enredado que puede hacer imposible correr la app. Y esta construido de una manera que hace virtualmente imposible una reconstrucción. Aquí, si quisieras arreglar la disposición de los cables, tendrías que tirar todo y empezar de nuevo con un plano.
- Y ahora pasamos a un tema complicado
- Porque evoca nuestros mas profundos temores.
- El codigo heredado puede convertirse en un grave problema pues, aunque en teoria un código fuente debería estar bien comentado y documentado la triste realidad es que casi nunca es así.
- La industria aun tiene camino por recorrer cuando se trata de código heredado. Existen técnicas especificas que involucran pruebas unitarias, patrones de diseño y refactorizacion. Sin embargo es un trabajo delicado, donde el mas minimo error puede dejar inhabilitadas partes de la aplicación sin explicación aparente.
- Lo que nos lleva al siguiente tema: Esta es una solución por default para muchos desarrolladores cuando se encuentran con un proyecto mal diseñado. Pero, desafortunadamente cuando los managers preguntan si toda la funcionalidad se mantendra, es muy complicado y virtualmente imposible asegurar tal cosa. Otra cosa casi imposible es estimar el tiempo que llevara esta reparación general. Ademas, si se trata del mismo equipo que creo el proyecto inicial y mal diseñado nada asegura que esta vez la reestructuracion sera exitosa o bien planeada.
- Muchas veces vamos a escuchar de los clientes o el area de negocios que lo mas importante para un proyecto es la rapidez de entrega. Sin embargo, hay que tener en cuenta que muchos proyectos y empresas quiebran por falta de calidad en sus productos.
- Todo se trata de llegar a un equilibrio entre nuestras decisiones de diseño y para eso existen ciertas estrategias como el Minimum Viable Product y la mas reciente el Minimum Lovable Product
- Minimum Viable Product tiene solo las características fundamentales para que un producto pueda ser creado, no mas. El producto puede ser orientado a los primeros usuarios en adoptarlo, quienes regularmente son mas comprehensivos y dispuestos a devolver retroalimentación.
- Iteracion tras iteración logran que el producto se acerque a lo que el usuario final necesita.
- The Intel Web Tablet connected wirelessly to a PC to allow a user to browse the Web. It had a touchscreen display, was powered by an ARM processor, featured a built-in MP3 player and it let you surf the Internet on your couch. Sound familiar? Think again. This was the Intel PAD or, as it was known internally at the time, the IPAD. It was officially branded the Intel Web Tablet, but it never made it to market.
- 1959: The Henney Kilowatt turns heads but not enough for people to buy it. The Eureeka Company manufactured 100 Kilowatts between 1959-1960, but was only able to sell 47 of them. Despite the lag in sales, the Kilowatt was a promising electric automobile for its time. It traveled 40 miles on a charge and hit a top speed of 40 miles per hour. The improved 1960 model pushed this to 60 miles per charge and a zippy 60 mile-per-hour top speed.
- Archie (1990): Archie. The first search engine created was Archie, created in 1990 by Alan Emtage, a student at McGill University in Montreal. The original intent of the name was "archives," but it was shortened to Archie.
- Luego vienen los promotores del Minimum Lovable Product. Ellos dicen que las ventajas del MVP no son tales en un mundo tan competitivo como en el que vivimos. La idea es que los usuarios finales ya no se conforman con productos que ofrecen solo lo mínimo posible. Y que el camino esta en lograr la aceptación desde la primer iteración Tratando de dejar una impresión favorable con ese mínimo de características.
- Cuando la meta a largo plazo involucra calidad en el producto la rapidez puede dejarnos en desventaja.
- Y finalmente, si deseamos mantener y atraer a los mejores desarrolladores debemos tomar mas en cuenta la calidad en el código y el producto. A group of computer programmers from the Poznan University of Technology (PUT) have triumphed in Hello World Open, the world coding championship. They defeated 2,500 teams from across the globe.